Re: [Intel-gfx] [PATCH 4/4] drm/vc4: Validate framebuffer pixel format/modifier

2018-03-09 Thread Eric Anholt
Ville Syrjala  writes:

> From: Ville Syrjälä 
>
> Only create framebuffers with supported format/modifier combinations by
> checking that at least one plane supports the requested combination.
>
> Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
> the planes have (mostly) uniform capabilities. But I was lazy and
> didn't feel like exporting drm_plane_format_check() and hand rolling
> anything better. Also I really just wanted to come up with another
> user for drm_any_plane_has_format() ;)

I'm not excited about vc4 having error-return behavior that other
drivers don't have.  Actually, I don't really see why we should be doing
this check in fb create at all, given that you have to do so again at
atomic_check time with the specific plane.

Could you just delete the i915 fb format check code?


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


[Intel-gfx] [PATCH v3 4/5] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()

2018-03-09 Thread Lyude Paul
Retraining MST is rather difficult. In order to do it properly while
guaranteeing that we'll never run into a spot where we commit a
physically impossible configuration, we have to do a lot of checks on
atomic commits which affect MST topologies. All of this work is going to
need to be repeated for every driver at some point, so let's save
ourselves some trouble and just implement these atomic checks as
a single helper.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 223 ++
 include/drm/drm_dp_mst_helper.h   |   2 +
 2 files changed, 225 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0d6604500b29..c4a91b1ba61b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2167,6 +2167,229 @@ int drm_dp_mst_topology_mgr_lower_link_rate(struct 
drm_dp_mst_topology_mgr *mgr,
 }
 EXPORT_SYMBOL(drm_dp_mst_topology_mgr_lower_link_rate);
 
+static bool drm_atomic_dp_mst_state_only_disables_mstbs(struct 
drm_atomic_state *state,
+   struct 
drm_dp_mst_topology_mgr *mgr,
+   struct 
drm_dp_mst_branch *mstb)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_state_only_disables_mstbs(
+   state, mgr, rmstb);
+   drm_dp_put_mst_branch_device(rmstb);
+   if (!ret)
+   return false;
+   }
+
+   connector = port->connector;
+   if (!connector)
+   continue;
+
+   conn_state = drm_atomic_get_new_connector_state(
+   state, connector);
+   if (!conn_state)
+   continue;
+
+   crtc = conn_state->crtc;
+   if (!crtc)
+   continue;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (!crtc_state)
+   continue;
+
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+   }
+
+   return true;
+}
+
+static int drm_atomic_dp_mst_all_mstbs_disabled(struct drm_atomic_state *state,
+   struct drm_dp_mst_topology_mgr 
*mgr,
+   struct drm_dp_mst_branch *mstb)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_all_mstbs_disabled(
+   state, mgr, rmstb);
+   drm_dp_put_mst_branch_device(rmstb);
+   if (ret <= 0)
+   return ret;
+   }
+
+   connector = port->connector;
+   if (!connector)
+   continue;
+
+   conn_state = drm_atomic_get_connector_state(
+   state, connector);
+   if (IS_ERR(conn_state))
+   return PTR_ERR(conn_state);
+
+   if (conn_state->crtc)
+   return false;
+   }
+
+   /* No enabled CRTCs found */
+   return true;
+}
+
+static int drm_atomic_dp_mst_retrain_mstb(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ bool full_modeset)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_retrain_mstb(
+   state, mgr, rmstb, full_modeset);
+   drm_dp_put_mst_branch_device(rmstb);
+ 

[Intel-gfx] [PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies

2018-03-09 Thread Lyude Paul
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if the sink changes it's RX caps after we've already set up
an MST link and we attempt to add or remove another sink from the
topology, we could put ourselves into an invalid state where we've tried
to configure different sinks on the same MST topology with different
link rates. We could also run into this situation if a sink reports a
higher link rate after suspend, usually from us having trained it with a
fallback bw configuration before suspending.

So: "lock" the bw config by only using the max DP link rate/lane count
on the first modeset for an MST topology. For every modeset following,
we instead use the last configured link bw for this topology. We only
unlock the bw config when we've detected a new MST sink.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 11 +--
 drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++---
 drivers/gpu/drm/i915/intel_drv.h|  6 ++
 3 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5abf0c95725a..5645a194de92 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
 static void
 intel_dp_configure_mst(struct intel_dp *intel_dp)
 {
+   bool was_mst;
+
if (!i915_modparams.enable_dp_mst)
return;
 
if (!intel_dp->can_mst)
return;
 
+   was_mst = intel_dp->is_mst;
intel_dp->is_mst = intel_dp_can_mst(intel_dp);
 
-   if (intel_dp->is_mst)
+   if (intel_dp->is_mst) {
DRM_DEBUG_KMS("Sink is MST capable\n");
-   else
+
+   if (!was_mst)
+   intel_dp->mst_bw_locked = false;
+   } else {
DRM_DEBUG_KMS("Sink is not MST capable\n");
+   }
 
drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
intel_dp->is_mst);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..c0553456b18e 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
-   int lane_count, slots;
+   int lane_count, link_rate, slots;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
@@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
  bpp);
}
/*
-* for MST we always configure max link bw - the spec doesn't
-* seem to suggest we should do otherwise.
+* for MST we always configure max link bw if we don't know better -
+* the spec doesn't seem to suggest we should do otherwise. But,
+* ensure it always stays consistent with the rest of this hub's
+* state.
 */
-   lane_count = intel_dp_max_lane_count(intel_dp);
+   if (intel_dp->mst_bw_locked) {
+   lane_count = intel_dp->lane_count;
+   link_rate = intel_dp->link_rate;
+   } else {
+   lane_count = intel_dp_max_lane_count(intel_dp);
+   link_rate = intel_dp_max_link_rate(intel_dp);
+   }
 
pipe_config->lane_count = lane_count;
-
pipe_config->pipe_bpp = bpp;
-
-   pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
+   pipe_config->port_clock = link_rate;
 
if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
@@ -221,6 +227,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
connector->encoder = encoder;
intel_mst->connector = connector;
 
+   intel_dp->mst_bw_locked = true;
+
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3f19dc80997f..fc338529e918 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1107,6 +1107,12 @@ struct intel_dp {
bool can_mst; /* this port supports mst */
bool is_mst;
int active_mst_links;
+   /* Set when we've already decided 

[Intel-gfx] [PATCH v3 3/5] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()

2018-03-09 Thread Lyude Paul
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps that must be taken in order to properly retrain the
entire topology under a lower link rate. Since the VCID allocations for
each mstb is determined based off the link rate for the top of the
topology, we also have to recalculate all of the VCID allocations for
the downstream ports as well to ensure that we still have enough link
bandwidth to drive each mstb.

Additionally, since we have multiple downstream connectors per port,
setting the link status of the parent mstb's port to bad isn't enough:
all of the downstream mstb ports have to have their link status set to
bad.

This basically follows the same paradigm that our DP link status logic
in DRM does, in that we simply tell userspace that all of the mstb ports
need retraining and additionally applying the new lower bandwidth
constraints to all of the atomic commits on the topology that follow.

Since the work of figuring out which connectors live downstream on an
MST topology and updating their link status is something that any driver
supporting MST is going to need to do in order to retrain MST links
properly, we add the drm_dp_mst_topology_mgr_lower_link_rate() helper
which simply recalculates the pbn_div for a given mst topology, then
marks the link status of all connectors living in that topology as bad.
We'll make use of it in i915 later in this series.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 73 ++-
 include/drm/drm_dp_mst_helper.h   |  3 ++
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6fac4129e6a2..0d6604500b29 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2076,7 +2076,7 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
 {
switch (dp_link_bw) {
default:
-   DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count: 
%d)\n",
+   DRM_DEBUG_KMS("invalid link bandwidth: %x (link count: %d)\n",
  dp_link_bw, dp_link_count);
return false;
 
@@ -2096,6 +2096,77 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
return true;
 }
 
+static void drm_dp_set_mstb_link_status(struct drm_dp_mst_branch *mstb,
+   enum drm_link_status status)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   drm_dp_set_mstb_link_status(rmstb, status);
+   drm_dp_put_mst_branch_device(rmstb);
+   }
+
+   if (port->connector)
+   port->connector->state->link_status = status;
+   }
+}
+
+/**
+ * drm_dp_mst_topology_mgr_lower_link_rate() - Override the DP link bw/count
+ * for all connectors in a given MST topology
+ * @mgr: manager to set state for
+ * @dp_link_bw: The new DP link bandwidth
+ * @dp_link_count: The new DP link count
+ *
+ * This is called by the driver when it detects that the current DP link for
+ * the given topology manager is unstable, and needs to be retrained at a
+ * lower link rate.
+ *
+ * This takes care of updating the link status on all downstream connectors
+ * along with recalculating the VC payloads. The driver should send a hotplug
+ * event after calling this function to notify userspace of the link status
+ * change.
+ *
+ * RETURNS:
+ *
+ * True for success, or negative error code on failure.
+ */
+int drm_dp_mst_topology_mgr_lower_link_rate(struct drm_dp_mst_topology_mgr 
*mgr,
+   int dp_link_bw, int dp_link_count)
+{
+   struct drm_device *dev = mgr->dev;
+   struct drm_dp_mst_branch *mst_primary;
+   int new_pbn_div;
+   int ret = 0;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+
+   if (!drm_dp_get_vc_payload_bw(drm_dp_link_rate_to_bw_code(dp_link_bw),
+ dp_link_count, _pbn_div)) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   mst_primary = drm_dp_get_validated_mstb_ref(mgr, mgr->mst_primary);
+   if (!mst_primary)
+   goto out;
+
+   DRM_DEBUG_KMS("MST link failed to retrain, lowering pbn_div to %d\n",
+ new_pbn_div);
+   mgr->pbn_div = new_pbn_div;
+
+   drm_dp_set_mstb_link_status(mst_primary, 

Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

2018-03-09 Thread Daniele Ceraolo Spurio



On 09/03/18 01:53, Tvrtko Ursulin wrote:


On 08/03/2018 18:46, Daniele Ceraolo Spurio wrote:

On 08/03/18 01:31, Tvrtko Ursulin wrote:


On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote:

The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're running
on in a consistent way.

Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_engine_cs.c  | 77 
+

  drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
  2 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c

index 4ba139c27fba..1dd92cac8d67 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,16 @@ static const struct engine_class_info 
intel_engine_classes[] = {

  },
  };
+#define MAX_MMIO_BASES 3
  struct engine_info {
  unsigned int hw_id;
  unsigned int uabi_id;
  u8 class;
  u8 instance;
-    u32 mmio_base;
+    struct engine_mmio_base {
+    u32 gen : 8;
+    u32 base : 24;
+    } mmio_bases[MAX_MMIO_BASES];
  unsigned irq_shift;
  };


It's not bad, but I am just wondering if it is too complicated versus 
simply duplicating the tables.


Duplicated tables would certainly be much less code and complexity, 
but what about the size of pure data?


In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES * 
sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times 
NUM_ENGINES equals 240 bytes for intel_engines[] array with this scheme.




we remove a u32 (the old mmio base) so we only grow 8 per engine, but 
the compiler rounds up to a multiple of u32 so 28 per engine, for a 
total of 224.



Separate tables per gens would be:

sizeof(struct engine_info) is 18 bytes.

For < gen6 we'd need 3 engines * 18 = 54
< gen11 = 5 engines * 18 = 90
 >= gen11 = 8 engines * 18 = 144

54 + 90 + 144 = 288 bytes

So a little bit bigger. Hm. Plus we would need to refactor so 
intel_engines[] is not indexed by engine->id but is contiguous array 
with engine->id in the elements. Code to lookup the compact array 
should be simpler than combined new code from this patch, especially 
if you add the test as Chris suggested. So separate engine info 
arrays would win I think overall - when considering size of text + 
size of data + size of source code.




Not sure. I would exclude the selftest, which is usually not compiled 
for released kernels, which leads to:


Yes, but we cannot exclude its source since selftests for separate 
tables wouldn't be needed.



add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93)
Function old new   delta
intel_engines    160 224 +64
__func__   13891   13910 +19
intel_engines_init_mmio 1247    1264 +17
intel_init_bsd_ring_buffer   142 135  -7
Total: Before=1479626, After=1479719, chg +0.01%

Total growth is 93, which is less then your estimation for the growth 
introduced by replicating the table.


But on the other hand your solution might be more future proof. So I 
don't know. Use the crystal ball to decide? :)




I think we should expect that the total engine count could grow with 
future gens. In this case to me adding a new entry to a unified table 
seems much cleaner (and uses less data) than adding a completely new 
table each time.


Okay I was off in my estimates. But in general I was coming from the 
angle of thinking that every new mmio base difference in this scheme 
grows the size for all engines. So if just VCS grows one new base, 
impact is multiplied by NUM_ENGINES. But maybe separate tables are also 
not a solution. Perhaps pulling out mmio_base arrays to outside struct 
engine_info in another set of static tables, so they could be null 
terminated would be best of both worlds?


struct engine_mmio_base {
 u32 gen : 8;
 u32 base : 24;
};

static const struct engine_mmio_base vcs0_mmio_bases[] = {
 { .gen = 11, .base = GEN11_BSD_RING_BASE },
 { .gen = 6, .base = GEN6_BSD_RING_BASE },
 { .gen = 4, .base = BSD_RING_BASE },
 { },
};

And then in intel_engines array, for BSD:

    {
 ...
 .mmio_bases = _mmio_bases;
 ...
    },

This way we limit data growth only to engines which change their mmio 
bases frequently.


Just an idea.



I gave this a try and the code actually grows:

add/remove: 8/0 grow/shrink: 2/0 up/down: 120/0 (120)
Function old new   

Re: [Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Use absolute tolerance in accuracy tests

2018-03-09 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-03-09 11:54:13)
> From: Tvrtko Ursulin 
> 
> We need to use absolute tolerance when asserting on percentages. Relative
> tolerance in this case is unfair and inaccurate since it's strictness
> varies with relative target busyness.
> 
> v2:
>  * Do not include spin batch edit and submit into measured time.
>  * Open PMU before child is in test PWM phase.
>  * No need to emit test PWM for twice as long with the new explicit
>synchroniazation via pipe.
>  * Log test duration in ms for better readability.
>  * Drop inverse assert. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson  # v1
Reviewed-by: Chris Wilson 

Would be nice to add a comment now we have a reasonable suspicion:

> @@ -1537,19 +1545,16 @@ accuracy(int gem_fd, const struct 
> intel_execution_engine2 *e,
>  
> igt_nsec_elapsed(_start);
> do {
> -   struct timespec t_busy = { };
> -   unsigned int target_idle_us;
> -
> -   igt_nsec_elapsed(_busy);
> +   unsigned int target_idle_us, t_busy;
>  
> /* Restart the spinbatch. */
> __rearm_spin_batch(spin);
> __submit_spin_batch(gem_fd, , e);

/*
 * Note that the submission may be delayed to a tasklet (ksoftirqd)
 * which cannot run until we sleep as we hog the cpu (we are RT).
 */

> -   measured_usleep(busy_us);
> +   t_busy = measured_usleep(busy_us);
> igt_spin_batch_end(spin);
> gem_sync(gem_fd, obj.handle);

And back to thinking how we can kick the tasklet, or kick the habit.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler

2018-03-09 Thread Daniele Ceraolo Spurio



On 08/03/18 17:33, Chris Wilson wrote:

Give the compiler a helping hand in mapping (bank,bit) to our struct
intel_engine_cs by trading object code size for data cache:

add/remove: 2/0 grow/shrink: 0/1 up/down: 48/-135 (-87)
Function old new   delta
bank1_map  -  32 +32
bank0_map  -  16 +16
gen11_irq_handler706 571-135

v2: u8 arrays for tighter packing

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/i915_irq.c | 53 +++--
  1 file changed, 14 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c8c29d8ecbab..e423ec58e5d2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2762,44 +2762,6 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915;  \
 __fini_wedge((W)))
  
-static void

-gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
-   const unsigned int bank,
-   const unsigned int engine_n,
-   const u16 iir)
-{
-   struct intel_engine_cs ** const engine = i915->engine;
-
-   switch (bank) {
-   case 0:
-   switch (engine_n) {
-
-   case GEN11_RCS0:
-   return gen8_cs_irq_handler(engine[RCS], iir);
-
-   case GEN11_BCS:
-   return gen8_cs_irq_handler(engine[BCS], iir);
-   }
-   case 1:
-   switch (engine_n) {
-
-   case GEN11_VCS(0):
-   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
-   case GEN11_VCS(1):
-   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
-   case GEN11_VCS(2):
-   return gen8_cs_irq_handler(engine[_VCS(2)], iir);
-   case GEN11_VCS(3):
-   return gen8_cs_irq_handler(engine[_VCS(3)], iir);
-
-   case GEN11_VECS(0):
-   return gen8_cs_irq_handler(engine[_VECS(0)], iir);
-   case GEN11_VECS(1):
-   return gen8_cs_irq_handler(engine[_VECS(1)], iir);
-   }
-   }
-}
-
  static u32
  gen11_gt_engine_intr(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit)
@@ -2836,10 +2798,23 @@ static void
  gen11_gt_irq_handler(struct drm_i915_private * const i915,
 const u32 master_ctl)
  {
+   static const u8 bank0_map[] = {
+   [GEN11_RCS0] = RCS,
+   [GEN11_BCS]  = BCS,
+   };
+   static const u8 bank1_map[] = {
+   [GEN11_VCS(0)]  = _VCS(0),
+   [GEN11_VCS(1)]  = _VCS(1),
+   [GEN11_VCS(2)]  = _VCS(2),
+   [GEN11_VCS(3)]  = _VCS(3),
+   [GEN11_VECS(0)] = _VECS(0),
+   [GEN11_VECS(1)] = _VECS(1),
+   };
void __iomem * const regs = i915->regs;
unsigned int bank;
  
  	for (bank = 0; bank < 2; bank++) {

+   const u8 *map = bank ? bank1_map : bank0_map;
unsigned long intr_dw;
unsigned int bit;
  
@@ -2859,7 +2834,7 @@ gen11_gt_irq_handler(struct drm_i915_private * const i915,

if (unlikely(!iir))
continue;
  
-			gen11_gt_engine_irq_handler(i915, bank, bit, iir);

+   gen8_cs_irq_handler(i915->engine[map[bit]], iir);


With guc and PM interrupts we get a couple of non-engine interrupts on 
bank0, so this may not scale very well depending how we approach it.


My vote still goes to deriving class and instance from the register 
(bits 16-18 and 20-25 respectively). If we return the full register 
value from gen11_gt_engine_intr, we can then do something like:


for_each_set_bit(bit, _dw, 32) {
const u32 ident = gen11_gt_engine_intr(i915, bank, bit);
u16 iir = ident & GEN11_INTR_ENGINE_MASK;
u8 class, instance;

if (unlikely(!iir))
continue;

class = (ident >> 16) & (BIT(3) - 1);
instance = (ident >> 20) &
(BIT(GEN11_ENGINE_INSTANCE_WIDTH) - 1);

gen8_cs_irq_handler(i915->engine_class[class][instance], iir);
}

Which saves a bit more code and is more adaptable to non-engine 
interrupts IMHO, since we have the class and all non-engine interrupts 
come under class 4.


add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-137 (-137)
Function old new   delta
gen11_irq_handler   

Re: [Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register

2018-03-09 Thread Rodrigo Vivi
On Fri, Mar 09, 2018 at 06:28:56PM +0530, Mahesh Kumar wrote:
> This patch creates a new macro to get PORT_TX register for any given DW.
> This will remove the need of defining register address for each port & DW.

please squash patches 1 and 2. I had to open both simultaneously to review it
what indicates that they should be 1 patch.

> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e6a8c0ee7df1..30ef3513dc6f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1964,6 +1964,34 @@ enum i915_power_well_id {
>   _CNL_PORT_PCS_DW1_LN0_F)
>  #define   COMMON_KEEPER_EN   (1 << 26)
>  
> +/* CNL Port TX registers */
> +#define _CNL_PORT_TX_AE_GRP_OFFSET   0x162340
> +#define _CNL_PORT_TX_B_GRP_OFFSET0x1623C0
> +#define _CNL_PORT_TX_C_GRP_OFFSET0x162B40
> +#define _CNL_PORT_TX_D_GRP_OFFSET0x162BC0
> +#define _CNL_PORT_TX_F_GRP_OFFSET0x162A40
> +#define _CNL_PORT_TX_AE_LN0_OFFSET   0x162440
> +#define _CNL_PORT_TX_B_LN0_OFFSET0x162640
> +#define _CNL_PORT_TX_C_LN0_OFFSET0x162C40
> +#define _CNL_PORT_TX_D_LN0_OFFSET0x162E40
> +#define _CNL_PORT_TX_F_LN0_OFFSET0x162840
> +#define CNL_PORT_TX_DW_GRP(port, dw) (_PICK((port), \
> +_CNL_PORT_TX_AE_GRP_OFFSET, \
> +_CNL_PORT_TX_B_GRP_OFFSET, \
> +_CNL_PORT_TX_B_GRP_OFFSET, \
> +_CNL_PORT_TX_D_GRP_OFFSET, \
> +_CNL_PORT_TX_AE_GRP_OFFSET, \
> +_CNL_PORT_TX_F_GRP_OFFSET) + \
> +4*(dw))

the math is right. I'm glad someone could see some logic on all these
numbers. I with we had a basic offset and math for all the port registers, 
but...

> +#define CNL_PORT_TX_DW_LN0(port, dw) (_PICK((port), \

who converts the offset to MMIO reg now?

> +_CNL_PORT_TX_AE_LN0_OFFSET, \
> +_CNL_PORT_TX_B_LN0_OFFSET, \
> +_CNL_PORT_TX_B_LN0_OFFSET, \
> +_CNL_PORT_TX_D_LN0_OFFSET, \
> +_CNL_PORT_TX_AE_LN0_OFFSET, \
> +_CNL_PORT_TX_F_LN0_OFFSET) + \
> +4*(dw))
> +
>  #define _CNL_PORT_TX_DW2_GRP_AE  0x162348
>  #define _CNL_PORT_TX_DW2_GRP_B   0x1623C8
>  #define _CNL_PORT_TX_DW2_GRP_C   0x162B48
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm/i915/cnl: Kill _MMIO_PORT6 macro

2018-03-09 Thread Rodrigo Vivi
On Fri, Mar 09, 2018 at 06:28:58PM +0530, Mahesh Kumar wrote:
> This patch replaces use of remaining _MMIO_PORT6 macro and removes the
> macro.

Thanks... I hope that we don't need to bring it back for the ICL patches...

> 
> Signed-off-by: Mahesh Kumar 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7987a3f85d04..37742d774ba0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -153,9 +153,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
>  #define _PLL(pll, a, b) ((a) + (pll)*((b)-(a)))
>  #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
> -#define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e, 
> f))
> -#define _MMIO_PORT6_LN(port, ln, a0, a1, b, c, d, e, f)  
> \
> - _MMIO(_PICK(port, a0, b, c, d, e, f) + (ln * (a1 - a0)))
>  #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
>  #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>  
> @@ -1948,20 +1945,21 @@ enum i915_power_well_id {
>  #define _CNL_PORT_PCS_DW1_LN0_C  0x162C04
>  #define _CNL_PORT_PCS_DW1_LN0_D  0x162E04
>  #define _CNL_PORT_PCS_DW1_LN0_F  0x162804
> -#define CNL_PORT_PCS_DW1_GRP(port)   _MMIO_PORT6(port, \
> +#define CNL_PORT_PCS_DW1_GRP(port)   _MMIO(_PICK(port, \
>   _CNL_PORT_PCS_DW1_GRP_AE, \
>   _CNL_PORT_PCS_DW1_GRP_B, \
>   _CNL_PORT_PCS_DW1_GRP_C, \
>   _CNL_PORT_PCS_DW1_GRP_D, \
>   _CNL_PORT_PCS_DW1_GRP_AE, \
> - _CNL_PORT_PCS_DW1_GRP_F)
> -#define CNL_PORT_PCS_DW1_LN0(port)   _MMIO_PORT6(port, \
> + _CNL_PORT_PCS_DW1_GRP_F))
> +
> +#define CNL_PORT_PCS_DW1_LN0(port)   _MMIO(_PICK(port, \
>   _CNL_PORT_PCS_DW1_LN0_AE, \
>   _CNL_PORT_PCS_DW1_LN0_B, \
>   _CNL_PORT_PCS_DW1_LN0_C, \
>   _CNL_PORT_PCS_DW1_LN0_D, \
>   _CNL_PORT_PCS_DW1_LN0_AE, \
> - _CNL_PORT_PCS_DW1_LN0_F)
> + _CNL_PORT_PCS_DW1_LN0_F))
>  #define   COMMON_KEEPER_EN   (1 << 26)
>  
>  /* CNL Port TX registers */
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/uc: Sanitize uC (rev2)

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915/uc: Sanitize uC (rev2)
URL   : https://patchwork.freedesktop.org/series/39634/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368 +2
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252 +1

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3338 pass:1754 dwarn:2   dfail:0   fail:14  skip:1566 
time:11690s
shard-hswtotal:3467 pass:1766 dwarn:1   dfail:0   fail:8   skip:1691 
time:11581s
shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
time:6947s
Blacklisted hosts:
shard-kbltotal:2994 pass:1678 dwarn:2   dfail:1   fail:13  skip:1293 
time:7175s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8293/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v3 5/5] drm/i915: Implement proper fallback training for MST

2018-03-09 Thread Lyude Paul
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.

MST retraining is somewhat different then SST retraining. While it's
possible during the normal link retraining sequence for a hub to indicate
bad link status, it's also possible for a hub to only indicate this
status through ESI messages and it's possible for this to happen after
the initial link training succeeds. This can lead to a pattern that
looks like this:

- Train MST link
- Training completes successfully
- MST hub sets Channel EQ failed bit in ESI
- Retraining starts
- Retraining completes successfully
- MST hub sets Channel EQ failed bit in ESI again
- Rinse and repeat

In these situations, we need to be able to actually trigger fallback
link training from the ESI handler as well, along with using the ESI
handler during retraining to figure out whether or not our retraining
actually succeeded.

This gets a bit more complicated since we have to ensure that we don't
block the ESI handler at all while doing retraining. If we do, due to
DisplayPort's general issues with being sensitive to IRQ latency most
MST hubs will just stop responding to us if their interrupts aren't
handled in a timely manner.

So: move retraining into it's own seperate handler. Running in a
seperate handler allows us to avoid stalling the ESI during link
retraining, and we can have the ESI signal that the channel EQ bit was
cleared through a simple completion struct. Additionally, we take care
to stick as much of this into the SST retraining path as possible since
sharing is caring.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 342 +++-
 drivers/gpu/drm/i915/intel_dp_mst.c |  42 -
 drivers/gpu/drm/i915/intel_drv.h|   8 +
 3 files changed, 302 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5645a194de92..7626652732b6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -45,6 +45,8 @@
 
 #define DP_DPRX_ESI_LEN 14
 
+#define DP_MST_RETRAIN_TIMEOUT (msecs_to_jiffies(100))
+
 /* Compliance test status bits  */
 #define INTEL_DP_RESOLUTION_SHIFT_MASK 0
 #define INTEL_DP_RESOLUTION_PREFERRED  (1 << INTEL_DP_RESOLUTION_SHIFT_MASK)
@@ -4224,6 +4226,118 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("Could not write test response to sink\n");
 }
 
+/* Get a mask of the CRTCs that are running on the given intel_dp struct. For
+ * MST, this returns a crtc mask containing all of the CRTCs driving
+ * downstream sinks, for SST it just returns a mask of the attached
+ * connector's CRTC.
+ */
+int
+intel_dp_get_crtc_mask(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct intel_connector *intel_connector;
+   struct drm_crtc *crtc;
+   int crtc_mask = 0;
+
+   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+
+   if (intel_dp->is_mst) {
+   struct drm_connector_list_iter conn_iter;
+
+   drm_connector_list_iter_begin(dev, _iter);
+   for_each_intel_connector_iter(intel_connector, _iter) {
+   if (intel_connector->mst_port != intel_dp)
+   continue;
+
+   conn_state = intel_connector->base.state;
+   if (!conn_state->crtc)
+   continue;
+
+   crtc_mask |= drm_crtc_mask(conn_state->crtc);
+   }
+   drm_connector_list_iter_end(_iter);
+   } else {
+   connector = _dp->attached_connector->base;
+   crtc = connector->state->crtc;
+
+   if (crtc)
+   crtc_mask |= drm_crtc_mask(crtc);
+   }
+
+   return crtc_mask;
+}
+
+static bool
+intel_dp_needs_link_retrain(struct intel_dp *intel_dp,
+   const u8 esi[DP_DPRX_ESI_LEN])
+{
+   u8 buf[max(DP_LINK_STATUS_SIZE, DP_DPRX_ESI_LEN)];
+   const u8 *link_status = NULL;
+
+   if (intel_dp->is_mst) {
+   if (!intel_dp->active_mst_links)
+   return false;
+   if (intel_dp->mst_link_is_bad)
+   return false;
+
+   if (esi) {
+   link_status = [10];
+   } else {
+   /* We're not running from the ESI handler, so wait a
+* little bit to see if the ESI handler lets us know
+   

[Intel-gfx] [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp

2018-03-09 Thread Lyude Paul
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're dealing with an MST device, along with being able to easily
trace the intel_dp struct back to it's respective connector (if there is
any). So, move the modeset_retry_work function out of the
intel_connector struct and into intel_dp.

Signed-off-by: Lyude Paul 
Reviewed-by: Manasi Navare 
Cc: Manasi Navare 
Cc: Ville Syrjälä 

V2:
 - Remove accidental duplicate modeset_retry_work in intel_connector
V3:
 - Also check against eDP in intel_hpd_poll_fini() - mdnavare
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/intel_display.c  | 25 +++--
 drivers/gpu/drm/i915/intel_dp.c   | 10 --
 drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  6 +++---
 4 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f424fff477f6..3b7fa430a84a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15394,16 +15394,37 @@ static void intel_hpd_poll_fini(struct drm_device 
*dev)
 {
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+   struct work_struct *work;
+   int conn_type;
 
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, _iter);
for_each_intel_connector_iter(connector, _iter) {
-   if (connector->modeset_retry_work.func)
-   cancel_work_sync(>modeset_retry_work);
if (connector->hdcp_shim) {
cancel_delayed_work_sync(>hdcp_check_work);
cancel_work_sync(>hdcp_prop_work);
}
+
+   conn_type = connector->base.connector_type;
+   if (conn_type != DRM_MODE_CONNECTOR_eDP &&
+   conn_type != DRM_MODE_CONNECTOR_DisplayPort)
+   continue;
+
+   if (connector->mst_port) {
+   work = >mst_port->modeset_retry_work;
+   } else {
+   struct intel_encoder *intel_encoder =
+   connector->encoder;
+   struct intel_dp *intel_dp;
+
+   if (!intel_encoder)
+   continue;
+
+   intel_dp = enc_to_intel_dp(_encoder->base);
+   work = _dp->modeset_retry_work;
+   }
+
+   cancel_work_sync(work);
}
drm_connector_list_iter_end(_iter);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4dd1b2287dd6..5abf0c95725a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 
 static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
 {
-   struct intel_connector *intel_connector;
-   struct drm_connector *connector;
+   struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
+modeset_retry_work);
+   struct drm_connector *connector = _dp->attached_connector->base;
 
-   intel_connector = container_of(work, typeof(*intel_connector),
-  modeset_retry_work);
-   connector = _connector->base;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
  connector->name);
 
@@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
int type;
 
/* Initialize the work for modeset in case of link train failure */
-   INIT_WORK(_connector->modeset_retry_work,
+   INIT_WORK(_dp->modeset_retry_work,
  intel_dp_modeset_retry_work_fn);
 
if (WARN(intel_dig_port->max_lanes < 1,
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..2cfa58ce1f95 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 
intel_dp->link_rate,
 
intel_dp->lane_count))
/* Schedule a Hotplug Uevent to userspace to start 
modeset */
-   schedule_work(_connector->modeset_retry_work);
+ 

[Intel-gfx] [PATCH i-g-t v2] tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()

2018-03-09 Thread Radhakrishna Sripada
From: Anusha Srivatsa 

Rework the rotate and reflect subtests by checking the
crtc supported properties against the ones that the
test is testing. Remove the hardcoded platform names in
igt_require()

v2: Make use of the property enums to get the supported rotations

Cc: Radhakrishna Sripada 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Cc: Maarten Lankhorst 
Cc: Mika Kahola 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Radhakrishna Sripada 
---
 lib/igt_kms.h|  1 +
 tests/kms_rotation_crc.c | 46 +-
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 1c46186e8a9d..c306aa1f5b8d 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -289,6 +289,7 @@ typedef enum {
 
 #define IGT_ROTATION_MASK \
(IGT_ROTATION_0 | IGT_ROTATION_90 | IGT_ROTATION_180 | IGT_ROTATION_270)
+#define IGT_REFLECT_MASK   (IGT_REFLECT_X | IGT_REFLECT_Y)
 
 typedef struct {
/*< private >*/
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 0cd5c6e52b57..8f7e5d4f2dd2 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -38,6 +38,7 @@ typedef struct {
igt_crc_t flip_crc;
igt_pipe_crc_t *pipe_crc;
igt_rotation_t rotation;
+   int **supported_rotation;
int pos_x;
int pos_y;
uint32_t override_fmt;
@@ -373,13 +374,14 @@ static void test_plane_rotation(data_t *data, int 
plane_type, bool test_bad_form
igt_plane_t *plane;
int i, j;
 
-   if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
-   continue;
-
igt_output_set_pipe(output, pipe);
 
plane = igt_output_get_plane_type(output, plane_type);
igt_require(igt_plane_has_prop(plane, IGT_PLANE_ROTATION));
+   igt_require(data->supported_rotation[pipe][plane->index] & 
data->rotation);
+
+   if (data->rotation & IGT_REFLECT_MASK)
+   
igt_require(data->supported_rotation[pipe][plane->index] & IGT_REFLECT_MASK);
 
prepare_crtc(data, output, pipe, plane);
 
@@ -460,6 +462,36 @@ static void test_plane_rotation_exhaust_fences(data_t 
*data,
igt_remove_fb(fd, [i]);
 }
 
+static void igt_supported_rotation_init(data_t *data)
+{
+   igt_display_t *display = >display;
+   bool found;
+   int i, j, k, n_pipes = display->n_pipes;
+   int **s_rotation;
+
+   s_rotation = calloc(sizeof(int *), n_pipes);
+
+   for (i = 0; i < n_pipes; i++) {
+   s_rotation[i] = calloc(sizeof(int), (display->pipes + 
i)->n_planes);
+
+   for (j = 0; j < (display->pipes + i)->n_planes; j++) {
+   drmModePropertyPtr prop;
+   found = kmstest_get_property(data->gfx_fd, 
display->pipes[i].planes[j].drm_plane->plane_id,
+   DRM_MODE_OBJECT_PLANE, 
"rotation", NULL, NULL, );
+   igt_assert(found);
+   igt_assert(prop->flags & DRM_MODE_PROP_BITMASK);
+
+   for (k = 0; k < prop->count_enums; k++) {
+   s_rotation[i][j] |= 1 << (prop->enums[k].value);
+   }
+
+   drmModeFreeProperty(prop);
+   }
+   }
+
+   data->supported_rotation = s_rotation;
+}
+
 static const char *plane_test_str(unsigned plane)
 {
switch (plane) {
@@ -552,15 +584,13 @@ igt_main
igt_require_pipe_crc(data.gfx_fd);
 
igt_display_init(, data.gfx_fd);
+   igt_supported_rotation_init();
}
 
for (subtest = subtests; subtest->rot; subtest++) {
igt_subtest_f("%s-rotation-%s",
  plane_test_str(subtest->plane),
  rot_test_str(subtest->rot)) {
-   igt_require(!(subtest->rot &
-   (IGT_ROTATION_90 | IGT_ROTATION_270)) ||
-   gen >= 9);
data.rotation = subtest->rot;
test_plane_rotation(, subtest->plane, false);
}
@@ -596,9 +626,7 @@ igt_main
igt_subtest_f("primary-%s-reflect-x-%s",
  tiling_test_str(reflect_x->tiling),
  rot_test_str(reflect_x->rot)) {
-   igt_require(gen >= 10 ||
-   (IS_CHERRYVIEW(data.devid) && 
reflect_x->rot == IGT_ROTATION_0
-&& reflect_x->tiling == 
LOCAL_I915_FORMAT_MOD_X_TILED));
+

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/4] drm: Add drm_any_plane_has_format()

2018-03-09 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/4] drm: Add drm_any_plane_has_format()
URL   : https://patchwork.freedesktop.org/series/39700/
State : failure

== Summary ==

 Possible new issues:

Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
pass   -> SKIP   (shard-snb)
Test kms_properties:
Subgroup plane-properties-atomic:
pass   -> DMESG-WARN (shard-hsw)
Test pm_rpm:
Subgroup cursor:
pass   -> FAIL   (shard-hsw)
Subgroup cursor-dpms:
pass   -> FAIL   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-apltotal:3467 pass:1826 dwarn:1   dfail:0   fail:8   skip:1632 
time:12225s
shard-hswtotal:3467 pass:1769 dwarn:2   dfail:0   fail:3   skip:1692 
time:11554s
shard-snbtotal:3467 pass:1364 dwarn:1   dfail:0   fail:1   skip:2101 
time:6936s
Blacklisted hosts:
shard-kbltotal:3467 pass:1950 dwarn:1   dfail:1   fail:7   skip:1508 
time:9378s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8291/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

2018-03-09 Thread Chris Wilson
Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests
v3: Do an up/down ramp for individual freq request, check nothing
changes after each invalid request
v4: Check the frequencies reported by the kernel across the entire
range.
v5: Rewrite sandwich to create a sandwich between multiple concurrent
engines.

Signed-off-by: Chris Wilson 
Cc: Praveen Paneri 
Cc: Sagar A Kamble 
Cc: Antonio Argenziano 
---
 tests/Makefile.am  |   1 +
 tests/Makefile.sources |   1 +
 tests/gem_ctx_freq.c   | 691 +
 tests/meson.build  |   1 +
 4 files changed, 694 insertions(+)
 create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be72..389f7fc7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4a81ac4a..3d079c42 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..fc5df3d9
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,691 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 7
+
+#define SAMPLE_PERIOD (USEC_PER_SEC / 10)
+
+static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   return __gem_context_set_param(fd, );
+}
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   igt_assert_eq(__set_freq(fd, ctx, min, max), 0);
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int period_us)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(period_us);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+#define N_STEPS 10
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+ 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: misc fixes in headers (RESEND)

2018-03-09 Thread Chris Wilson
Quoting Patchwork (2018-03-09 22:12:20)
> == Series Details ==
> 
> Series: drm/i915: misc fixes in headers (RESEND)
> URL   : https://patchwork.freedesktop.org/series/39589/
> State : failure
> 
> == Summary ==
> 
>  Possible new issues:
> 
> Test kms_cursor_legacy:
> Subgroup short-flip-after-cursor-atomic-transitions:
> pass   -> FAIL   (shard-hsw)
> Test kms_frontbuffer_tracking:
> Subgroup fbc-rgb101010-draw-pwrite:
> pass   -> FAIL   (shard-apl)
> 
>  Known issues:
> 
> Test gem_eio:
> Subgroup in-flight:
> incomplete -> PASS   (shard-apl) fdo#105341
> Test kms_cursor_crc:
> Subgroup cursor-128x128-suspend:
> skip   -> PASS   (shard-hsw) fdo#103540
> Test kms_flip:
> Subgroup 2x-modeset-vs-vblank-race:
> pass   -> DMESG-WARN (shard-hsw) fdo#103060
> Subgroup plain-flip-ts-check-interruptible:
> fail   -> PASS   (shard-hsw) fdo#100368
> Test pm_lpsp:
> Subgroup screens-disabled:
> pass   -> FAIL   (shard-hsw) fdo#104941
> 
> fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
> fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
> fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941
> 
> shard-apltotal:3398 pass:1792 dwarn:1   dfail:0   fail:8   skip:1596 
> time:11758s
> shard-hswtotal:3467 pass:1770 dwarn:2   dfail:0   fail:3   skip:1691 
> time:11639s
> shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
> time:6999s

As pw is finally happy, pushed. Thanks for the cleanup,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

2018-03-09 Thread Chris Wilson
Quoting Antonio Argenziano (2018-03-09 19:15:45)
> 
> 
> On 08/03/18 17:03, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-03-09 00:45:42)
> >>
> >>
> >> On 08/03/18 09:13, Chris Wilson wrote:
> >>> Exercise some new API that allows applications to request that
> >>> individual contexts are executed within a desired frequency range.
> >>>
> >>> v2: Split single/continuous set_freq subtests
> >>>
> >>> Signed-off-by: Chris Wilson 
> >>> Cc: Paneri, Praveen 
> >>> Cc: Kamble, Sagar A 
> >>> Cc: Antonio Argenziano 
> >>> ---
> >>>tests/Makefile.am  |   1 +
> >>>tests/Makefile.sources |   1 +
> >>>tests/gem_ctx_freq.c   | 604 
> >>> +
> >>>tests/meson.build  |   1 +
> >>>4 files changed, 607 insertions(+)
> >>>create mode 100644 tests/gem_ctx_freq.c
> >>>
> >>
> 
> >>> + uint32_t cur, discard;
> >>> +
> >>> + set_freq(fd, ctx, freq, freq);
> >>> + get_freq(fd, ctx, , );
> >>
> >> igt_assert_eq(freq, cur)?
> > 
> > Not quite. The trick is that the interface is not strictly idempotent,
> > since we pass in MHz, the driver converts that into freq bins and spits
> > it back out to the nearest MHz. So cur is not strictly freq, it just
> > happens that 50MHz is the bin size on gen9.
> > 
> > The idea here is that we grab the adjusted freq from the driver to
> > validate with.
> 
> I see, can we enforce a tolerance? It feels like we are trusting the 
> kernel too much, but if that is the only thing we can do...

for (i = min; i <= max; i++)
igt_assert(min <= set_and_fetch_freq(i) <= max);

I don't think we want to constrain the ABI any more than that.
But adding that level of check seems ok.

The behaviour is we ask the kernel for a range, the kernel tells us what
range it can provide based on the request. Then we expect that the
kernel upholds that contract. (Except where we make a conflicting
contract with another party, either parallel execution or sysadmin
override.)

Binding ourselves into a tighter contract feels overly prescriptive and
not flexible enough to weasel our way out of bad situations in future.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register

2018-03-09 Thread Lucas De Marchi
On Fri, Mar 09, 2018 at 11:55:47AM -0800, Rodrigo Vivi wrote:
> On Fri, Mar 09, 2018 at 06:28:56PM +0530, Mahesh Kumar wrote:
> > This patch creates a new macro to get PORT_TX register for any given DW.
> > This will remove the need of defining register address for each port & DW.
> 
> please squash patches 1 and 2. I had to open both simultaneously to review it
> what indicates that they should be 1 patch.
> 
> > 
> > Signed-off-by: Mahesh Kumar 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 28 
> >  1 file changed, 28 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index e6a8c0ee7df1..30ef3513dc6f 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1964,6 +1964,34 @@ enum i915_power_well_id {
> > _CNL_PORT_PCS_DW1_LN0_F)
> >  #define   COMMON_KEEPER_EN (1 << 26)
> >  
> > +/* CNL Port TX registers */
> > +#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340
> > +#define _CNL_PORT_TX_B_GRP_OFFSET  0x1623C0
> > +#define _CNL_PORT_TX_C_GRP_OFFSET  0x162B40
> > +#define _CNL_PORT_TX_D_GRP_OFFSET  0x162BC0
> > +#define _CNL_PORT_TX_F_GRP_OFFSET  0x162A40
> > +#define _CNL_PORT_TX_AE_LN0_OFFSET 0x162440
> > +#define _CNL_PORT_TX_B_LN0_OFFSET  0x162640
> > +#define _CNL_PORT_TX_C_LN0_OFFSET  0x162C40
> > +#define _CNL_PORT_TX_D_LN0_OFFSET  0x162E40
> > +#define _CNL_PORT_TX_F_LN0_OFFSET  0x162840
> > +#define CNL_PORT_TX_DW_GRP(port, dw)   (_PICK((port), \
> > +  _CNL_PORT_TX_AE_GRP_OFFSET, \
> > +  _CNL_PORT_TX_B_GRP_OFFSET, \
> > +  _CNL_PORT_TX_B_GRP_OFFSET, \
> > +  _CNL_PORT_TX_D_GRP_OFFSET, \
> > +  _CNL_PORT_TX_AE_GRP_OFFSET, \
> > +  _CNL_PORT_TX_F_GRP_OFFSET) + \
> > +  4*(dw))
> 
> the math is right. I'm glad someone could see some logic on all these
> numbers. I with we had a basic offset and math for all the port registers, 
> but...
> 
> > +#define CNL_PORT_TX_DW_LN0(port, dw)   (_PICK((port), \
> 
> who converts the offset to MMIO reg now?

I don't think this is supposed to be used outside the header is it?
I think it should have a underscore, because otherwise it's confusing
that CNL_PORT_TX_DW_LN0 returns an offsed and CNL_PORT_TX_DW[0-5]_LN0
return an mmio reg.

And if it's used elsewhere, maybe append _OFFSET to the macro?

Lucas De Marchi

> 
> > +  _CNL_PORT_TX_AE_LN0_OFFSET, \
> > +  _CNL_PORT_TX_B_LN0_OFFSET, \
> > +  _CNL_PORT_TX_B_LN0_OFFSET, \
> > +  _CNL_PORT_TX_D_LN0_OFFSET, \
> > +  _CNL_PORT_TX_AE_LN0_OFFSET, \
> > +  _CNL_PORT_TX_F_LN0_OFFSET) + \
> > +  4*(dw))
> > +
> >  #define _CNL_PORT_TX_DW2_GRP_AE0x162348
> >  #define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
> >  #define _CNL_PORT_TX_DW2_GRP_C 0x162B48
> > -- 
> > 2.14.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

2018-03-09 Thread Antonio Argenziano



On 08/03/18 17:03, Chris Wilson wrote:

Quoting Antonio Argenziano (2018-03-09 00:45:42)



On 08/03/18 09:13, Chris Wilson wrote:

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests

Signed-off-by: Chris Wilson 
Cc: Paneri, Praveen 
Cc: Kamble, Sagar A 
Cc: Antonio Argenziano 
---
   tests/Makefile.am  |   1 +
   tests/Makefile.sources |   1 +
   tests/gem_ctx_freq.c   | 604 
+
   tests/meson.build  |   1 +
   4 files changed, 607 insertions(+)
   create mode 100644 tests/gem_ctx_freq.c






+ uint32_t cur, discard;
+
+ set_freq(fd, ctx, freq, freq);
+ get_freq(fd, ctx, , );


igt_assert_eq(freq, cur)?


Not quite. The trick is that the interface is not strictly idempotent,
since we pass in MHz, the driver converts that into freq bins and spits
it back out to the nearest MHz. So cur is not strictly freq, it just
happens that 50MHz is the bin size on gen9.

The idea here is that we grab the adjusted freq from the driver to
validate with.


I see, can we enforce a tolerance? It feels like we are trusting the 
kernel too much, but if that is the only thing we can do...



+static void smoketest(int fd, int timeout)
+{
+ unsigned int engines[16];


use a macro instead of magic number 16.


#define 
THIS_IS_FAR_MORE_MAGIC_THAN_A_MEANINGLESS_BARE_NUMBER_THAT_YOU_SHOULD_NOT_BE_READING_ANYTHING_INTO
 16
/rant


We call that MAX_EGINES in gem_exec_schedule ;).

Thanks,
Antonio




+static void invalid_param(int fd)
+{


gem_ctx_param is going to be upset again pretty soon ;).


Poor thing.
-Chris


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


Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

2018-03-09 Thread Tvrtko Ursulin


On 09/03/2018 18:47, Daniele Ceraolo Spurio wrote:

On 09/03/18 01:53, Tvrtko Ursulin wrote:


On 08/03/2018 18:46, Daniele Ceraolo Spurio wrote:

On 08/03/18 01:31, Tvrtko Ursulin wrote:


On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote:

The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're 
running

on in a consistent way.

Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniele Ceraolo Spurio 


---
  drivers/gpu/drm/i915/intel_engine_cs.c  | 77 
+

  drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
  2 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c

index 4ba139c27fba..1dd92cac8d67 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,16 @@ static const struct engine_class_info 
intel_engine_classes[] = {

  },
  };
+#define MAX_MMIO_BASES 3
  struct engine_info {
  unsigned int hw_id;
  unsigned int uabi_id;
  u8 class;
  u8 instance;
-    u32 mmio_base;
+    struct engine_mmio_base {
+    u32 gen : 8;
+    u32 base : 24;
+    } mmio_bases[MAX_MMIO_BASES];
  unsigned irq_shift;
  };


It's not bad, but I am just wondering if it is too complicated 
versus simply duplicating the tables.


Duplicated tables would certainly be much less code and complexity, 
but what about the size of pure data?


In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES * 
sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times 
NUM_ENGINES equals 240 bytes for intel_engines[] array with this 
scheme.




we remove a u32 (the old mmio base) so we only grow 8 per engine, but 
the compiler rounds up to a multiple of u32 so 28 per engine, for a 
total of 224.



Separate tables per gens would be:

sizeof(struct engine_info) is 18 bytes.

For < gen6 we'd need 3 engines * 18 = 54
< gen11 = 5 engines * 18 = 90
 >= gen11 = 8 engines * 18 = 144

54 + 90 + 144 = 288 bytes

So a little bit bigger. Hm. Plus we would need to refactor so 
intel_engines[] is not indexed by engine->id but is contiguous array 
with engine->id in the elements. Code to lookup the compact array 
should be simpler than combined new code from this patch, especially 
if you add the test as Chris suggested. So separate engine info 
arrays would win I think overall - when considering size of text + 
size of data + size of source code.




Not sure. I would exclude the selftest, which is usually not compiled 
for released kernels, which leads to:


Yes, but we cannot exclude its source since selftests for separate 
tables wouldn't be needed.



add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93)
Function old new   delta
intel_engines    160 224 +64
__func__   13891   13910 +19
intel_engines_init_mmio 1247    1264 +17
intel_init_bsd_ring_buffer   142 135  -7
Total: Before=1479626, After=1479719, chg +0.01%

Total growth is 93, which is less then your estimation for the growth 
introduced by replicating the table.


But on the other hand your solution might be more future proof. So I 
don't know. Use the crystal ball to decide? :)




I think we should expect that the total engine count could grow with 
future gens. In this case to me adding a new entry to a unified table 
seems much cleaner (and uses less data) than adding a completely new 
table each time.


Okay I was off in my estimates. But in general I was coming from the 
angle of thinking that every new mmio base difference in this scheme 
grows the size for all engines. So if just VCS grows one new base, 
impact is multiplied by NUM_ENGINES. But maybe separate tables are 
also not a solution. Perhaps pulling out mmio_base arrays to outside 
struct engine_info in another set of static tables, so they could be 
null terminated would be best of both worlds?


struct engine_mmio_base {
 u32 gen : 8;
 u32 base : 24;
};

static const struct engine_mmio_base vcs0_mmio_bases[] = {
 { .gen = 11, .base = GEN11_BSD_RING_BASE },
 { .gen = 6, .base = GEN6_BSD_RING_BASE },
 { .gen = 4, .base = BSD_RING_BASE },
 { },
};

And then in intel_engines array, for BSD:

    {
 ...
 .mmio_bases = _mmio_bases;
 ...
    },

This way we limit data growth only to engines which change their mmio 
bases frequently.


Just an idea.



I gave this a try and the code actually grows:

add/remove: 8/0 grow/shrink: 2/0 up/down: 120/0 (120)

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: misc fixes in headers (RESEND)

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915: misc fixes in headers (RESEND)
URL   : https://patchwork.freedesktop.org/series/39589/
State : failure

== Summary ==

 Possible new issues:

Test kms_cursor_legacy:
Subgroup short-flip-after-cursor-atomic-transitions:
pass   -> FAIL   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb101010-draw-pwrite:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip   -> PASS   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-modeset-vs-vblank-race:
pass   -> DMESG-WARN (shard-hsw) fdo#103060
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3398 pass:1792 dwarn:1   dfail:0   fail:8   skip:1596 
time:11758s
shard-hswtotal:3467 pass:1770 dwarn:2   dfail:0   fail:3   skip:1691 
time:11639s
shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
time:6999s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8294/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)

2018-03-09 Thread Patchwork
== Series Details ==

Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)
URL   : https://patchwork.freedesktop.org/series/39571/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
5d71d7782a830843c7231fbd72ab3edae19b48d7 igt/gem_fd_exhaustion: Modify 
fs.nr_open for duration of the test

with latest DRM-Tip kernel build CI_DRM_3907
b97cfb3880fd drm-tip: 2018y-03m-09d-21h-14m-12s UTC integration manifest

Testlist changes:
+igt@gem_ctx_freq@blt-continuous
+igt@gem_ctx_freq@blt-inflight
+igt@gem_ctx_freq@blt-single
+igt@gem_ctx_freq@bsd1-continuous
+igt@gem_ctx_freq@bsd1-inflight
+igt@gem_ctx_freq@bsd1-single
+igt@gem_ctx_freq@bsd2-continuous
+igt@gem_ctx_freq@bsd2-inflight
+igt@gem_ctx_freq@bsd2-single
+igt@gem_ctx_freq@bsd-continuous
+igt@gem_ctx_freq@bsd-inflight
+igt@gem_ctx_freq@bsd-single
+igt@gem_ctx_freq@default-continuous
+igt@gem_ctx_freq@default-inflight
+igt@gem_ctx_freq@default-single
+igt@gem_ctx_freq@idempotent
+igt@gem_ctx_freq@independent
+igt@gem_ctx_freq@invalid
+igt@gem_ctx_freq@range
+igt@gem_ctx_freq@render-continuous
+igt@gem_ctx_freq@render-inflight
+igt@gem_ctx_freq@render-single
+igt@gem_ctx_freq@sandwich
+igt@gem_ctx_freq@smoketest
+igt@gem_ctx_freq@vebox-continuous
+igt@gem_ctx_freq@vebox-inflight
+igt@gem_ctx_freq@vebox-single

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test kms_chamelium:
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-4770) fdo#104944

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#104944 https://bugs.freedesktop.org/show_bug.cgi?id=104944

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:510s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:483s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:589s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:520s
fi-hsw-4770  total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:0   fail:1   skip:24  
time:470s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:423s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:434s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:504s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:509s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1101/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PULL] drm-misc-next

2018-03-09 Thread Sean Paul

Hi Dave,
Here are the -misc-next pulls for the last 2 weeks. Sorry for the hold-up
last week.

drm-misc-next-2018-03-09-3:
drm-misc-next for 4.17:

UAPI Changes:
 plane: Add color encoding/range properties (Jyri)
 nouveau: Replace iturbt_709 property with color_encoding property (Ville)

Core Changes:
 atomic: Move plane clipping into plane check helper (Ville)
 property: Multiple new property checks/verification (Ville)

Driver Changes:
 rockchip: Fixes & improvements for rk3399/chromebook plus (various)
 sun4i: Add H3/H5 HDMI support (Jernej)
 i915: Add support for limited/full-range ycbcr toggling (Ville)
 pl111: Add bandwidth checking/limiting (Linus)

Cc: Jernej Skrabec 
Cc: Jyri Sarha 
Cc: Ville Syrjälä 
Cc: Linus Walleij 

Cheers, Sean


The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:

  drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-03-09-3

for you to fetch changes up to 60beeccc72cabefcb8874fec542b3142e262b6c2:

  drm/rockchip: Don't use atomic constructs for psr (2018-03-08 23:28:53 +0100)


drm-misc-next for 4.17:

UAPI Changes:
 plane: Add color encoding/range properties (Jyri)
 nouveau: Replace iturbt_709 property with color_encoding property (Ville)

Core Changes:
 atomic: Move plane clipping into plane check helper (Ville)
 property: Multiple new property checks/verification (Ville)

Driver Changes:
 rockchip: Fixes & improvements for rk3399/chromebook plus (various)
 sun4i: Add H3/H5 HDMI support (Jernej)
 i915: Add support for limited/full-range ycbcr toggling (Ville)
 pl111: Add bandwidth checking/limiting (Linus)

Cc: Jernej Skrabec 
Cc: Jyri Sarha 
Cc: Ville Syrjälä 
Cc: Linus Walleij 


Arnd Bergmann (2):
  drm: fix drm_get_max_iomem type mismatch
  tinydrm: add backlight dependency

Baruch Siach (1):
  drm: of: simplify component probe code

Benjamin Gaignard (1):
  drm/stm: check pitch and size calculations even if !CONFIG_MMU

Chris Wilson (1):
  drm/mm: Fix caching of leftmost node in the interval tree

Christian König (2):
  drm/prime: fix potential race in drm_gem_map_detach
  drm/prime: make the pages array optional for 
drm_prime_sg_to_page_addr_arrays

Daniel Stone (1):
  drm/vc4: Advertise supported modifiers for planes

Jeffy Chen (10):
  drm/rockchip: Add device links for master and components
  drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale()
  drm/bridge: analogix: Do not use device's drvdata
  drm/bridge: analogix_dp: Fix connector and encoder cleanup
  drm/rockchip: analogix_dp: Add a sanity check for 
rockchip_drm_psr_register()
  drm/rockchip: analogix_dp: reorder psr_unregister call in unbind
  drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup.
  drm/rockchip: inno_hdmi: Fix error handling path.
  drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind
  drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind()

Jernej Skrabec (8):
  dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline
  drm/sun4i: Add support for H3 display engine
  drm/sun4i: Add support for H3 mixer 0
  drm/sun4i: Fix polarity configuration for DW HDMI PHY
  drm/sun4i: Add support for variants to DW HDMI PHY
  drm/sun4i: Move and expand DW HDMI PHY register macros
  drm/sun4i: Add support for H3 HDMI PHY variant
  drm/sun4i: Allow building on arm64

Joe Moriarty (2):
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

Jyri Sarha (1):
  drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

Linus Walleij (7):
  drm/panel: Fix ARM Versatile panel clocks
  bridge: Elaborate a bit on dumb VGA bridges in Kconfig
  drm: simple_kms_helper: Fix .mode_valid() documentation
  drm/pl111: Make the default BPP a per-variant variable
  drm/pl111: Handle the RealView variant separately
  drm/bridge: sii902x: Retry status read after DDI I2C
  drm/pl111: Use max memory bandwidth for resolution

Maarten Lankhorst (1):
  drm/atomic: Call ww_acquire_done after drm_modeset_lock_all

Marek Szyprowski (2):
  drm/bridge: analogix_dp: Postpone enabling runtime power management
  drm/bridge: analogix_dp: Don't create useless connectors

Maxime Ripard (4):
  drm/sun4i: backend: Assign the pipes automatically
  drm/sun4i: Remove the plane description structure
  drm/sun4i: backend: Make zpos configurable
  drm/sun4i: 

[Intel-gfx] [RFC v3 1/8] drm: Add Enhanced Gamma LUT precision structure

2018-03-09 Thread Uma Shankar
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values. Also added the code,
for extracting the same from values passed from userspace.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_plane.c | 19 +++
 include/uapi/drm/drm_mode.h | 15 +++
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7..e706da6 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -426,6 +426,25 @@ void drm_plane_force_disable(struct drm_plane *plane)
 }
 EXPORT_SYMBOL(drm_plane_force_disable);
 
+/*
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t bit_precision)
+{
+   uint32_t val = user_input;
+   uint32_t max = 0x >> (32 - bit_precision);
+
+   /* Round only if we're not using full precision. */
+   if (bit_precision < 32) {
+   val += 1UL << (32 - bit_precision - 1);
+   val >>= 32 - bit_precision;
+   }
+
+   return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract_ext);
+
 /**
  * drm_mode_plane_set_obj_prop - set the value of a property
  * @plane: drm plane object to set property value for
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index b5d7d9e..5f3ed88 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -615,6 +615,21 @@ struct drm_color_lut {
__u16 reserved;
 };
 
+/*
+ * Creating 32 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+   /*
+* Data is U0.32 fixed point format.
+*/
+   __u32 red;
+   __u32 green;
+   __u32 blue;
+   __u32 reserved;
+};
+
 #define DRM_MODE_PAGE_FLIP_EVENT 0x01
 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
 #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
-- 
1.9.1

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


[Intel-gfx] [RFC v3 0/8] Add Plane Color Properties

2018-03-09 Thread Uma Shankar
This patch series adds properties for plane color features. It adds
properties for degamma used to linearize data, CSC used for gamut
conversion, and gamma used to again non-linearize data as per panel
supported color space. These can be utilize by user space to convert
planes from one format to another, one color space to another etc.

Usersapce can take smart blending decisions and utilize these hardware
supported plane color features to get accurate color profile. The same
can help in consistent color quality from source to panel taking
advantage of advanced color features in hardware.

These patches just add the property interfaces and enable helper
functions.

This series adds Intel Gen9 specific plane gamma feature. We can
build up and add other platform/hardware specific implementation
on top of this series

Note: This is just to get a design feedback whether these interfaces
look ok. Based on community feedback on interfaces, we will implement
IGT tests to validate plane color features. This is un-tested currently.
Also, userspace implementation to use these properties is currently not
available.

v2: Dropped legacy gamma table for plane as suggested by Maarten. Added
Gen9/BDW plane gamma feature and rebase on tot.

v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision
entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul
comments and moved plane color properties to drm_plane instead of
mode_config. Added property documentation as suggested by Daniel, Vetter.
Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov.

Uma Shankar (8):
  drm: Add Enhanced Gamma LUT precision structure
  drm: Add Plane Degamma properties
  drm: Add Plane CTM property
  drm: Add Plane Gamma properties
  drm: Define helper function for plane color enabling
  drm/i915: Enable plane color features
  drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
  drm/i915: Load plane color luts from atomic flip

 Documentation/gpu/drm-kms.rst |  18 
 drivers/gpu/drm/drm_atomic.c  |  30 +++
 drivers/gpu/drm/drm_atomic_helper.c   |  12 +++
 drivers/gpu/drm/drm_plane.c   | 131 ++
 drivers/gpu/drm/i915/i915_drv.h   |   5 ++
 drivers/gpu/drm/i915/i915_pci.c   |   5 +-
 drivers/gpu/drm/i915/i915_reg.h   |  24 ++
 drivers/gpu/drm/i915/intel_atomic_plane.c |   4 +
 drivers/gpu/drm/i915/intel_color.c|  80 ++
 drivers/gpu/drm/i915/intel_device_info.h  |   5 ++
 drivers/gpu/drm/i915/intel_display.c  |   4 +
 drivers/gpu/drm/i915/intel_drv.h  |  10 +++
 drivers/gpu/drm/i915/intel_sprite.c   |   4 +
 include/drm/drm_color_mgmt.h  |   5 ++
 include/drm/drm_plane.h   |  66 +++
 include/uapi/drm/drm_mode.h   |  15 
 16 files changed, 417 insertions(+), 1 deletion(-)

-- 
1.9.1

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


[Intel-gfx] [RFC v3 3/8] drm: Add Plane CTM property

2018-03-09 Thread Uma Shankar
Add a blob property for plane CSC usage.

v2: Rebase

v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.

Signed-off-by: Uma Shankar 
---
 Documentation/gpu/drm-kms.rst   |  3 +++
 drivers/gpu/drm/drm_atomic.c| 10 ++
 drivers/gpu/drm/drm_atomic_helper.c |  3 +++
 drivers/gpu/drm/drm_plane.c | 12 
 include/drm/drm_plane.h | 16 
 5 files changed, 44 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2c943f6..69b0b56 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -541,6 +541,9 @@ Plane Color Management Properties
 .. kernel-doc:: drivers/gpu/drm/drm_plane.c
:doc: degamma_lut_size_property
 
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: ctm_property
+
 Tile Group Property
 ---
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 409c058..f86384fa 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -771,6 +771,14 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
val, -1, );
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == plane->ctm_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >ctm,
+   val,
+   sizeof(struct drm_color_ctm),
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -837,6 +845,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
} else if (property == plane->degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+   } else if (property == plane->ctm_property) {
+   *val = (state->ctm) ? state->ctm->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d9384fd..76b4b41 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3507,6 +3507,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
if (state->degamma_lut)
drm_property_reference_blob(state->degamma_lut);
+   if (state->ctm)
+   drm_property_reference_blob(state->ctm);
state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3554,6 +3556,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
drm_crtc_commit_put(state->commit);
 
drm_property_unreference_blob(state->degamma_lut);
+   drm_property_unreference_blob(state->ctm);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 543a693..e635b63 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -485,6 +485,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
  *
  * degamma_lut_size_property:
  * Range Property to indicate size of the plane degamma LUT.
+ *
+ * ctm_property:
+ * Blob property which allows a userspace to provide CTM coefficients
+ * to do color space conversion or any other enhancement by doing a
+ * matrix multiplication using the h/w CTM processing engine
  */
 int drm_plane_color_create_prop(struct drm_device *dev,
struct drm_plane *plane)
@@ -505,6 +510,13 @@ int drm_plane_color_create_prop(struct drm_device *dev,
return -ENOMEM;
plane->degamma_lut_size_property = prop;
 
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   plane->ctm_property = prop;
+
return 0;
 }
 EXPORT_SYMBOL(drm_plane_color_create_prop);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 03291b1..35535c5 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -147,6 +147,14 @@ struct drm_plane_state {
struct drm_property_blob *degamma_lut;
 
/**
+* @ctm:
+*
+* Color transformation matrix. See 

[Intel-gfx] [RFC v3 6/8] drm/i915: Enable plane color features

2018-03-09 Thread Uma Shankar
Enable and initialize plane color features.

v2: Rebase and some cleanup

v3: Updated intel_plane_color_init to call
drm_plane_color_create_prop function, which will
in turn create plane color properties.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 +
 drivers/gpu/drm/i915/intel_color.c   | 14 ++
 drivers/gpu/drm/i915/intel_device_info.h |  5 +
 drivers/gpu/drm/i915/intel_drv.h |  9 +
 4 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7eec99d7..cfbb0e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -434,6 +434,11 @@ struct drm_i915_display_funcs {
 
void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
void (*load_luts)(struct drm_crtc_state *crtc_state);
+   /* Add Plane Color callbacks */
+   void (*load_plane_csc_matrix)(const struct drm_plane_state
+ *plane_state);
+   void (*load_plane_luts)(const struct drm_plane_state
+   *plane_state);
 };
 
 #define CSR_VERSION(major, minor)  ((major) << 16 | (minor))
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 89ab0f7..2d38ab8 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -648,6 +648,20 @@ int intel_color_check(struct drm_crtc *crtc,
return -EINVAL;
 }
 
+void intel_plane_color_init(struct drm_plane *plane)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   drm_plane_color_create_prop(plane->dev, plane);
+
+   /* Enable color management support when we have degamma & gamma LUTs. */
+   if (INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size != 0 &&
+   INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size != 0)
+   drm_plane_enable_color_mgmt(plane,
+   INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size,
+   true, INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size);
+}
+
 void intel_color_init(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index ab5bfd3..d277926 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -167,6 +167,11 @@ struct intel_device_info {
u16 degamma_lut_size;
u16 gamma_lut_size;
} color;
+
+   struct plane_color_luts {
+   u16 plane_degamma_lut_size;
+   u16 plane_gamma_lut_size;
+   } plane_color;
 };
 
 struct intel_driver_caps {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1a7c5ad..0a58fce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -529,6 +529,14 @@ struct intel_plane_state {
 */
int scaler_id;
 
+   /*
+* Use reduced/limited/broadcast rbg range, compressing from the full
+* range fed into the crtcs.
+*/
+   bool limited_color_range;
+   /* Gamma mode programmed on the plane */
+   uint32_t gamma_mode;
+
struct drm_intel_sprite_colorkey ckey;
 };
 
@@ -2123,6 +2131,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
 int intel_color_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
 void intel_color_set_csc(struct drm_crtc_state *crtc_state);
 void intel_color_load_luts(struct drm_crtc_state *crtc_state);
+void intel_plane_color_init(struct drm_plane *plane);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
-- 
1.9.1

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


[Intel-gfx] [RFC v3 5/8] drm: Define helper function for plane color enabling

2018-03-09 Thread Uma Shankar
Define helper function to enable Plane color features
to attach plane color properties to plane structure.

v2: Rebase

v3: Modiefied the function to use updated property names.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_plane.c  | 42 ++
 include/drm/drm_color_mgmt.h |  5 +
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index b837020..bbf55c5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -144,6 +144,48 @@ static int create_in_format_blob(struct drm_device *dev, 
struct drm_plane *plane
 }
 
 /**
+ * drm_plane_enable_color_mgmt - enable color management properties
+ * @plane: DRM Plane
+ * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
+ * @plane_has_ctm: whether to attach ctm_property for CSC matrix
+ * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
+ *
+ * This function lets the driver enable the color correction
+ * properties on a plane. This includes 3 degamma, csc and gamma
+ * properties that userspace can set and 2 size properties to inform
+ * the userspace of the lut sizes. Each of the properties are
+ * optional. The gamma and degamma properties are only attached if
+ * their size is not 0 and ctm_property is only attached if has_ctm is
+ * true.
+ */
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+   uint plane_degamma_lut_size,
+   bool plane_has_ctm,
+   uint plane_gamma_lut_size)
+{
+   if (plane_degamma_lut_size) {
+   drm_object_attach_property(>base,
+   plane->degamma_lut_property, 0);
+   drm_object_attach_property(>base,
+   plane->degamma_lut_size_property,
+   plane_degamma_lut_size);
+   }
+
+   if (plane_has_ctm)
+   drm_object_attach_property(>base,
+   plane->ctm_property, 0);
+
+   if (plane_gamma_lut_size) {
+   drm_object_attach_property(>base,
+   plane->gamma_lut_property, 0);
+   drm_object_attach_property(>base,
+   plane->gamma_lut_size_property,
+   plane_gamma_lut_size);
+   }
+}
+EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
+
+/**
  * drm_universal_plane_init - Initialize a new universal plane object
  * @dev: DRM device
  * @plane: plane object to init
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index b3b6d30..e220019 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -56,4 +56,9 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
  u32 supported_ranges,
  enum drm_color_encoding default_encoding,
  enum drm_color_range default_range);
+
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+uint plane_degamma_lut_size,
+bool plane_has_ctm,
+uint plane_gamma_lut_size);
 #endif
-- 
1.9.1

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


[Intel-gfx] [RFC v3 2/8] drm: Add Plane Degamma properties

2018-03-09 Thread Uma Shankar
Add Plane Degamma as a blob property and plane degamma size as
a range property.

v2: Rebase

v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.

Signed-off-by: Uma Shankar 
---
 Documentation/gpu/drm-kms.rst   |  9 +
 drivers/gpu/drm/drm_atomic.c| 12 
 drivers/gpu/drm/drm_atomic_helper.c |  6 ++
 drivers/gpu/drm/drm_plane.c | 35 +++
 include/drm/drm_plane.h | 26 ++
 5 files changed, 88 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 56a3780..2c943f6 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -532,6 +532,15 @@ Color Management Properties
 .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:export:
 
+Plane Color Management Properties
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: degamma_lut_property
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: degamma_lut_size_property
+
 Tile Group Property
 ---
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34b7d42..409c058 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -717,6 +717,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
 {
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = >mode_config;
+   bool replaced = false;
+   int ret;
 
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
@@ -763,6 +765,12 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->color_encoding = val;
} else if (property == plane->color_range_property) {
state->color_range = val;
+   } else if (property == plane->degamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >degamma_lut,
+   val, -1, );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -826,6 +834,9 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
*val = state->color_range;
+   } else if (property == plane->degamma_lut_property) {
+   *val = (state->degamma_lut) ?
+   state->degamma_lut->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
@@ -958,6 +969,7 @@ static void drm_atomic_plane_print_state(struct drm_printer 
*p,
   drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
   drm_get_color_range_name(state->color_range));
+   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
 
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ae3cbfe..d9384fd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3504,6 +3504,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
state->fence = NULL;
state->commit = NULL;
+
+   if (state->degamma_lut)
+   drm_property_reference_blob(state->degamma_lut);
+   state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
 
@@ -3548,6 +3552,8 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 
if (state->commit)
drm_crtc_commit_put(state->commit);
+
+   drm_property_unreference_blob(state->degamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index e706da6..543a693 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -474,6 +474,41 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
 }
 EXPORT_SYMBOL(drm_mode_plane_set_obj_prop);
 
+/**
+ * DOC: degamma_lut_property
+ *
+ * degamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply degamma curve using the h/w plane degamma processing
+ * engine, 

[Intel-gfx] [RFC v3 4/8] drm: Add Plane Gamma properties

2018-03-09 Thread Uma Shankar
Add plane gamma as blob property and size as a
range property.

v2: Rebase

v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.

Signed-off-by: Uma Shankar 
---
 Documentation/gpu/drm-kms.rst   |  6 ++
 drivers/gpu/drm/drm_atomic.c|  8 
 drivers/gpu/drm/drm_atomic_helper.c |  3 +++
 drivers/gpu/drm/drm_plane.c | 23 +++
 include/drm/drm_plane.h | 24 
 5 files changed, 64 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 69b0b56..3561deb 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -544,6 +544,12 @@ Plane Color Management Properties
 .. kernel-doc:: drivers/gpu/drm/drm_plane.c
:doc: ctm_property
 
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: gamma_lut_property
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :doc: gamma_lut_size_property
+
 Tile Group Property
 ---
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f86384fa..d636a81 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -779,6 +779,12 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == plane->gamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >gamma_lut,
+   val, -1, );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -847,6 +853,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->degamma_lut->base.id : 0;
} else if (property == plane->ctm_property) {
*val = (state->ctm) ? state->ctm->base.id : 0;
+   } else if (property == plane->gamma_lut_property) {
+   *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 76b4b41..3337e04 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3509,6 +3509,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
drm_property_reference_blob(state->degamma_lut);
if (state->ctm)
drm_property_reference_blob(state->ctm);
+   if (state->gamma_lut)
+   drm_property_reference_blob(state->gamma_lut);
state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3557,6 +3559,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 
drm_property_unreference_blob(state->degamma_lut);
drm_property_unreference_blob(state->ctm);
+   drm_property_unreference_blob(state->gamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index e635b63..b837020 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -490,6 +490,15 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
  * Blob property which allows a userspace to provide CTM coefficients
  * to do color space conversion or any other enhancement by doing a
  * matrix multiplication using the h/w CTM processing engine
+ *
+ * gamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply gamma/tone-mapping curve using the h/w plane gamma
+ * processing engine, thereby making the content as non-linear
+ * or to perform any tone mapping operation for HDR usecases.
+ *
+ * gamma_lut_size_property:
+ * Range Property to indicate size of the plane gamma LUT.
  */
 int drm_plane_color_create_prop(struct drm_device *dev,
struct drm_plane *plane)
@@ -517,6 +526,20 @@ int drm_plane_color_create_prop(struct drm_device *dev,
return -ENOMEM;
plane->ctm_property = prop;
 
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_GAMMA_LUT", 0);
+   if (!prop)
+   return -ENOMEM;
+   plane->gamma_lut_property = prop;
+
+   prop = 

[Intel-gfx] [RFC v3 8/8] drm/i915: Load plane color luts from atomic flip

2018-03-09 Thread Uma Shankar
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 4 
 drivers/gpu/drm/i915/intel_color.c| 8 
 drivers/gpu/drm/i915/intel_drv.h  | 1 +
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce8..e519eab 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -231,6 +231,10 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
intel_atomic_get_new_plane_state(state, intel_plane);
struct drm_crtc *crtc = new_plane_state->base.crtc ?: old_state->crtc;
 
+   if (new_plane_state->base.color_mgmt_changed) {
+   intel_color_load_plane_luts(_plane_state->base);
+   }
+
if (new_plane_state->base.visible) {
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, 
to_intel_crtc(crtc));
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index a40fafa..f67115b 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -670,6 +670,14 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state)
dev_priv->display.load_luts(crtc_state);
 }
 
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
+{
+   struct drm_device *dev = plane_state->plane->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   dev_priv->display.load_plane_luts(plane_state);
+}
+
 int intel_color_check(struct drm_crtc *crtc,
  struct drm_crtc_state *crtc_state)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0a58fce..1da5a35 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2132,6 +2132,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
 void intel_color_set_csc(struct drm_crtc_state *crtc_state);
 void intel_color_load_luts(struct drm_crtc_state *crtc_state);
 void intel_plane_color_init(struct drm_plane *plane);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
-- 
1.9.1

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


[Intel-gfx] [RFC v3 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms

2018-03-09 Thread Uma Shankar
Implement Plane Gamma feature for BDW and Gen9 platforms.

v2: Used newly added drm_color_lut_ext structure for enhanced
precision for Gamma LUT entries.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_pci.c  |  5 +++-
 drivers/gpu/drm/i915/i915_reg.h  | 24 +++
 drivers/gpu/drm/i915/intel_color.c   | 58 
 drivers/gpu/drm/i915/intel_display.c |  4 +++
 drivers/gpu/drm/i915/intel_sprite.c  |  4 +++
 5 files changed, 94 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 26e8f5c..c14b8f3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -54,7 +54,10 @@
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, 
IVB_CURSOR_C_OFFSET }
 
 #define BDW_COLORS \
-   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
+   .plane_color = { .plane_degamma_lut_size = 0, \
+.plane_gamma_lut_size = 16 }
+
 #define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
 #define GLK_COLORS \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 258e86e..385c3fc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -159,6 +159,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
 #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
 
+#define _MMIO_PLANE_GAMC(plane, i, a, b)  _MMIO(_PIPE(plane, a, b) + (i) * 4)
+#define _MMIO_PLANE_GAMC16(plane, i, a, b)  _MMIO(_PIPE(plane, a, b) + (i) * 4)
+
 #define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask))\
BUILD_BUG_ON_MSG(((mask) & 0x), "Incorrect mask"); \
@@ -9142,6 +9145,27 @@ enum skl_power_gate {
 #define PRE_CSC_GAMC_INDEX(pipe)   _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A, 
_PRE_CSC_GAMC_INDEX_B)
 #define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe, 
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
 
+/* Plane Gamma in Gen9+ */
+#define _PLANE_GAMC_1_A0x701d0
+#define _PLANE_GAMC_1_B0x711d0
+#define _PLANE_GAMC_2_A0x702d0
+#define _PLANE_GAMC_2_B0x712d0
+#define _PLANE_GAMC_1(pipe)_PIPE(pipe, _PLANE_GAMC_1_A, _PLANE_GAMC_1_B)
+#define _PLANE_GAMC_2(pipe)_PIPE(pipe, _PLANE_GAMC_2_A, _PLANE_GAMC_2_B)
+#define PLANE_GAMC(pipe, plane, i) \
+   _MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe), _PLANE_GAMC_2(pipe))
+
+#define _PLANE_GAMC16_1_A  0x70210
+#define _PLANE_GAMC16_1_B  0x71210
+#define _PLANE_GAMC16_2_A  0x70310
+#define _PLANE_GAMC16_2_B  0x71310
+#define _PLANE_GAMC16_1(pipe)  _PIPE(pipe, _PLANE_GAMC16_1_A, \
+_PLANE_GAMC16_1_B)
+#define _PLANE_GAMC16_2(pipe)  _PIPE(pipe, _PLANE_GAMC16_2_A, \
+_PLANE_GAMC16_2_B)
+#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
+   _PLANE_GAMC16_1(pipe), _PLANE_GAMC16_2(pipe))
+
 /* pipe CSC & degamma/gamma LUTs on CHV */
 #define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
 #define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 2d38ab8..a40fafa 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -496,6 +496,59 @@ static void broadwell_load_luts(struct drm_crtc_state 
*state)
I915_WRITE(PREC_PAL_INDEX(pipe), 0);
 }
 
+static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
+u32 offset)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+   enum pipe pipe = to_intel_plane(state->plane)->pipe;
+   enum plane_id plane = to_intel_plane(state->plane)->id;
+   uint32_t i, lut_size =
+   INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size;
+
+   if (state->gamma_lut) {
+   struct drm_color_lut_ext *lut =
+   (struct drm_color_lut_ext *) state->gamma_lut->data;
+
+   for (i = 0; i < lut_size; i++) {
+   uint32_t word =
+   (drm_color_lut_extract(lut[i].red, 10) << 20) |
+   (drm_color_lut_extract(lut[i].green, 10) << 10) |
+   drm_color_lut_extract(lut[i].blue, 10);
+
+   I915_WRITE(PLANE_GAMC(pipe, plane, i), word);
+   }
+
+   /* Program the max register to clamp values > 1.0. */
+   i = lut_size - 1;
+   I915_WRITE(PLANE_GAMC16(pipe, plane, 0),
+  drm_color_lut_extract(lut[i].red, 16));
+  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add Plane Color Properties (rev3)

2018-03-09 Thread Patchwork
== Series Details ==

Series: Add Plane Color Properties (rev3)
URL   : https://patchwork.freedesktop.org/series/30875/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm: Add Enhanced Gamma LUT precision structure
+drivers/gpu/drm/drm_plane.c:433:10: warning: symbol 
'drm_color_lut_extract_ext' was not declared. Should it be static?

Commit: drm: Add Plane Degamma properties
Okay!

Commit: drm: Add Plane CTM property
Okay!

Commit: drm: Add Plane Gamma properties
Okay!

Commit: drm: Define helper function for plane color enabling
Okay!

Commit: drm/i915: Enable plane color features
Okay!

Commit: drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
Okay!

Commit: drm/i915: Load plane color luts from atomic flip
Okay!

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Add Plane Color Properties (rev3)

2018-03-09 Thread Patchwork
== Series Details ==

Series: Add Plane Color Properties (rev3)
URL   : https://patchwork.freedesktop.org/series/30875/
State : success

== Summary ==

Series 30875v3 Add Plane Color Properties
https://patchwork.freedesktop.org/api/1.0/series/30875/revisions/3/mbox/

 Known issues:

Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-cnl-y3) fdo#103167

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:508s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:495s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:484s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:471s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-cnl-y3total:288  pass:261  dwarn:0   dfail:0   fail:1   skip:26  
time:582s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:411s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:520s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:416s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:401s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:506s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:515s

2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC 
integration manifest
f68e8e8bf982 drm/i915: Load plane color luts from atomic flip
c78c5ef1ab64 drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
d950a92e81f3 drm/i915: Enable plane color features
2ef90e536d90 drm: Define helper function for plane color enabling
25248846877a drm: Add Plane Gamma properties
a3b85657b9c9 drm: Add Plane CTM property
f7fc900392ed drm: Add Plane Degamma properties
09fc571cdbfc drm: Add Enhanced Gamma LUT precision structure

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8297/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control

2018-03-09 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control
URL   : https://patchwork.freedesktop.org/series/39710/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test gem_exec_capture:
Subgroup capture-vebox:
pass   -> FAIL   (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_plane_multiple:
Subgroup atomic-pipe-c-tiling-y:
pass   -> FAIL   (shard-apl) fdo#103166

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166

shard-apltotal:3262 pass:1716 dwarn:2   dfail:0   fail:17  skip:1524 
time:11509s
shard-hswtotal:3467 pass:1770 dwarn:1   dfail:0   fail:3   skip:1692 
time:11547s
shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
time:6868s
Blacklisted hosts:
shard-kbltotal:3168 pass:1779 dwarn:2   dfail:1   fail:18  skip:1364 
time:8065s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8295/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable LVDS on Radiant P845

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Disable LVDS on Radiant P845
URL   : https://patchwork.freedesktop.org/series/39732/
State : success

== Summary ==

Series 39732v1 drm/i915: Disable LVDS on Radiant P845
https://patchwork.freedesktop.org/api/1.0/series/39732/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:500s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:487s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:586s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:519s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:513s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:505s
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:510s

7e5ff4244a75361f62abdb9e484e31a125131920 drm-tip: 2018y-03m-09d-22h-21m-43s UTC 
integration manifest
7985fffe1a0d drm/i915: Disable LVDS on Radiant P845

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8298/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for Add Plane Color Properties (rev3)

2018-03-09 Thread Patchwork
== Series Details ==

Series: Add Plane Color Properties (rev3)
URL   : https://patchwork.freedesktop.org/series/30875/
State : failure

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
pass   -> DMESG-FAIL (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3467 pass:1825 dwarn:1   dfail:0   fail:8   skip:1632 
time:12253s
shard-hswtotal:3467 pass:1770 dwarn:1   dfail:1   fail:2   skip:1692 
time:11436s
shard-snbtotal:3467 pass:1365 dwarn:1   dfail:0   fail:1   skip:2100 
time:6926s
Blacklisted hosts:
shard-kbltotal:3398 pass:1907 dwarn:7   dfail:1   fail:6   skip:1476 
time:8953s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8297/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

2018-03-09 Thread Atwood, Matthew S
On Thu, 2018-03-08 at 09:22 +0200, Jani Nikula wrote:
> On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote:
> > 
> > From: Matt Atwood 
> > 
> > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme
> > from 8
> > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> > receiver capabilities. For panels that use this new feature wait
> > interval
> > would be increased by 512 ms, when spec is max 16 ms. This behavior
> > is
> > described in table 2-158 of DP 1.4 spec address eh.
> > 
> > With the introduction of DP 1.4 spec main link clock recovery was
> > standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL
> > value.
> > 
> > To avoid breaking panels that are not spec compiant we now warn on
> > invalid values.
> > 
> > V2: commit title/message, masking all 7 bits, warn on out of spec
> > values.
> > V3: commit message, make link train clock recovery follow DP 1.4
> > spec.
> > V4: style changes
> > V5: typo
> > 
> > Signed-off-by: Matt Atwood 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 18 ++
> >  include/drm/drm_dp_helper.h |  6 ++
> >  2 files changed, 20 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index adf79be..cdb04c9 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -119,18 +119,28 @@ u8
> > drm_dp_get_adjust_request_pre_emphasis(const u8
> > link_status[DP_LINK_STATUS_SI
> >  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> >  
> >  void drm_dp_link_train_clock_recovery_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > -   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > +   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > DP_TRAINING_AUX_RD_MASK;
> > +
> > +   if (rd_interval > 4)
> > +   DRM_DEBUG_KMS("AUX interval %d, out of range (max
> > 4)", rd_interval);
> \n missing.
will do
> 
> > 
> > +
> > +   if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
> >     udelay(100);
> >     else
> > -   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > +   mdelay(rd_interval * 4);
> >  }
> >  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
> >  
> >  void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > -   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > +   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > DP_TRAINING_AUX_RD_MASK;
> > +
> > +   if (rd_interval > 4)
> > +   DRM_DEBUG_KMS("AUX interval %d, out of range (max
> > 4)", rd_interval);
> \n missing.
will do
> 
> > 
> > +
> > +   if (rd_interval == 0)
> >     udelay(400);
> >     else
> > -   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > +   mdelay(rd_interval * 4);
> >  }
> >  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
> >  
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index da58a42..1269ef8 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -64,6 +64,11 @@
> >  /* AUX CH addresses */
> >  /* DPCD */
> >  #define DP_DPCD_REV 0x000
> > +# define DP_REV_10  0x10
> > +# define DP_REV_11  0x11
> > +# define DP_REV_12  0x12
> > +# define DP_REV_13  0x13
> > +# define DP_REV_14  0x14
> I am not sure what good these buy us, but if people think they're the
> way to go, then so be it. Just bear in mind that per spec, "The DPCD
> revision number does not necessarily match the DisplayPort version
> number." so "DP_REV" doesn't actually mean *DP* revision.
> 
> 
> BR,
> Jani.
you're right likely a better name is DPCD_REV_XX. I think we sill want
to base the main-link clock recovery on time on this value. Next
revision will include this naming convention. 
> 
> > 
> >  
> >  #define DP_MAX_LINK_RATE0x001
> >  
> > @@ -118,6 +123,7 @@
> >  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2
> > or higher */
> >  
> >  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> > +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
Rodrigo has shown me a DP 1.2 spec that had this change and conflicts
with my copy so I'll be changing to XXX 1.2

Matt
> >  
> >  #define DP_ADAPTER_CAP 0x00f   /* 1.2
> > */
> >  # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for Add NV12 support

2018-03-09 Thread Patchwork
== Series Details ==

Series: Add NV12 support
URL   : https://patchwork.freedesktop.org/series/39670/
State : failure

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-a-128x128-left-edge:
fail   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-c-ctm-negative:
pass   -> INCOMPLETE (shard-apl)
Test kms_plane_scaling:
Subgroup pipe-a-scaler-with-pixel-format:
pass   -> FAIL   (shard-apl)
Subgroup pipe-a-scaler-with-rotation:
pass   -> FAIL   (shard-apl)
Subgroup pipe-b-scaler-with-pixel-format:
pass   -> FAIL   (shard-apl)
Subgroup pipe-b-scaler-with-rotation:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
pass   -> DMESG-WARN (shard-snb) fdo#101623
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3388 pass:1782 dwarn:1   dfail:0   fail:10  skip:1592 
time:11647s
shard-hswtotal:3467 pass:1772 dwarn:1   dfail:0   fail:1   skip:1692 
time:11578s
shard-snbtotal:3467 pass:1364 dwarn:2   dfail:0   fail:1   skip:2100 
time:6943s
Blacklisted hosts:
shard-kbltotal:3398 pass:1909 dwarn:2   dfail:0   fail:10  skip:1476 
time:8942s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8296/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Disable LVDS on Radiant P845

2018-03-09 Thread Ondrej Zary
Radiant P845 does not have LVDS, only VGA.

Signed-off-by: Ondrej Zary 
---
 drivers/gpu/drm/i915/intel_lvds.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index ef80499113ee..6939e63d8bae 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -819,6 +819,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_EXACT_MATCH(DMI_BOARD_NAME, "D525MW"),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "Radiant P845",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Radiant Systems Inc"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "P845"),
+   },
+   },
 
{ } /* terminating entry */
 };
-- 
Ondrej Zary

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


Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/uc: Sanitize uC together with GEM

2018-03-09 Thread Daniele Ceraolo Spurio



On 09/03/18 08:01, Michal Wajdeczko wrote:

Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.

v2: don't forget about reset path (Daniele)
 sanitize uc before gem initiated full reset (Daniele)

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 


Reviewed-by: Daniele Ceraolo Spurio 

a small comment below





diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
  }
  
+void intel_uc_sanitize(struct drm_i915_private *i915)

+{
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   guc_disable_communication(guc);


With this here, can we now drop the guc_disable_communication in 
intel_uc_init_hw?


Thanks,
Daniele


+
+   intel_huc_sanitize(huc);
+   intel_guc_sanitize(guc);
+
+   __intel_uc_reset_hw(i915);
+}
+
  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
  void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
  int intel_uc_init_misc(struct drm_i915_private *dev_priv);
  void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
  int intel_uc_init_hw(struct drm_i915_private *dev_priv);
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
  }
  
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)

+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
  void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   struct intel_uc_fw *uc_fw);
  int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,


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


Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

2018-03-09 Thread Atwood, Matthew S
On Fri, 2018-03-09 at 14:05 +0200, Jani Nikula wrote:
> On Thu, 08 Mar 2018, matthew.s.atw...@intel.com wrote:
> > 
> > From: Matt Atwood 
> > 
> > Previously it was assumed that eDP panels would advertise the
> > lowest link
> > rate required for their singular mode to function. With the
> > introduction
> > of more advanced features there are advantages to a panel
> > advertising a
> > higher rate then it needs for a its given mode. For panels that
> > did, the
> > driver previously used a higher rate then necessary for that mode.
> > 
> > Signed-off-by: Matt Atwood 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 10 --
> >  1 file changed, 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index a2eeede..aa6d77d 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1758,16 +1758,6 @@ intel_dp_compute_config(struct intel_encoder
> > *encoder,
> >       dev_priv->vbt.edp.bpp);
> >     bpp = dev_priv->vbt.edp.bpp;
> >     }
> > -
> > -   /*
> > -    * Use the maximum clock and number of lanes the
> > eDP panel
> > -    * advertizes being capable of. The panels are
> > generally
> > -    * designed to support only a single clock and
> > lane
> > -    * configuration, and typically these values
> > correspond to the
> > -    * native resolution of the panel.
> > -    */
> > -   min_lane_count = max_lane_count;
> > -   min_clock = max_clock;
> Please see my reply to Manasi's identical patch [1]. If we apply this
> as-is, it will regress and will be reverted.
> 
> BR,
> Jani.
> 
> 
> [1] http://patchwork.freedesktop.org/patch/msgid/1520579339-14745-1-
> git-send-email-manasi.d.nav...@intel.com
to consolidate some of the information the bug that's referenced in
Manasi's patch is https://bugs.freedesktop.org/show_bug.cgi?id=73539. I
understand this bug as the following some panels may advertise a mode
that requires less then MAX_LANE_COUNT, however those panels would fail
if less lanes were used.

When this bug was filed the compute config inner for loop iterated on
rate and the outer iterated on lanes; this is now flipped. It *should*
be the case that the lowest frequency with the max amount of lanes is
preferred. Given the opposite behavior of the alogorithm to select I
dont think we'd come across this again. Even if I'm wrong we could
still min_lane_count = max_lane count and let the clock optimize
itself.

I guess my question is, is there also a bug where if MAX_RATE wasnt
used we saw a panel fail as well?

Matt
> 
> 
> > 
> >     }
> >  
> >     for (; bpp >= 6*3; bpp -= 2*3) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)

2018-03-09 Thread Patchwork
== Series Details ==

Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)
URL   : https://patchwork.freedesktop.org/series/39571/
State : failure

== Summary ==

 Possible new issues:

Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-xtiled:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
skip   -> PASS   (shard-snb) fdo#102365
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> FAIL   (shard-apl) fdo#103375
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3407 pass:1770 dwarn:1   dfail:0   fail:9   skip:1625 
time:11840s
shard-hswtotal:3494 pass:1771 dwarn:1   dfail:0   fail:3   skip:1718 
time:11673s
shard-snbtotal:3494 pass:1365 dwarn:1   dfail:0   fail:1   skip:2127 
time:7011s
Blacklisted hosts:
shard-kbltotal:3331 pass:1849 dwarn:1   dfail:0   fail:5   skip:1474 
time:8608s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1101/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable LVDS on Radiant P845

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Disable LVDS on Radiant P845
URL   : https://patchwork.freedesktop.org/series/39732/
State : success

== Summary ==

 Possible new issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
skip   -> PASS   (shard-snb)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
pass   -> SKIP   (shard-snb) fdo#102365
Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-apl) fdo#101623

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:3467 pass:1825 dwarn:1   dfail:0   fail:8   skip:1632 
time:12221s
shard-hswtotal:3467 pass:1773 dwarn:1   dfail:0   fail:1   skip:1691 
time:11580s
shard-snbtotal:3467 pass:1364 dwarn:1   dfail:0   fail:1   skip:2101 
time:7005s
Blacklisted hosts:
shard-kbltotal:3405 pass:1911 dwarn:4   dfail:0   fail:7   skip:1481 
time:8597s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8298/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler

2018-03-09 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-03-09 10:06:48)
> 
> On 09/03/2018 01:38, Chris Wilson wrote:
> And in general I think too many bike-sheds on this area of code before 
> we are even running it on real hw. :(

Come on now, it's not a proper bikeshed if the discussion is meaningful!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/dp: Do not set the eDP link rate/lane count to max

2018-03-09 Thread Chris Wilson
Quoting Jani Nikula (2018-03-09 10:20:37)
> On Thu, 08 Mar 2018, Manasi Navare  wrote:
> > The panels are generally designed to support only a single
> > clock and lane configuration, and typically these values
> > correspond to the native resolution of the panel. But some
> > panels advertise the MAX_LINK_RATE in DPCD higher than what
> > is required to support the native resolution.
> > So optimize and set the link rate and lane count to the
> > least values required by the panel to support the native
> > resolution. This will also be an effective power saving
> > for such eDP panels.
> 
> I'm afraid this will lead to flickering on plenty of laptops. It will
> just get reverted when it hits end users. We've been down this path
> before. If we decide to try to do this again, we need to figure out how
> *not* to regress those machines. We can't just talk our way out of this.
> 
> As a tip, it's often useful to have a look at git blame and git log when
> you're considering changes to code that seems odd or contentious or
> something. In this case that leads to commit 344c5bbcb7a2
> ("drm/i915/edp: use lane count and link rate from DPCD for eDP"), which
> in turn leads to commit 56071a207602 ("drm/i915: use lane count and link
> rate from VBT as minimums for eDP") and a bunch of bugzilla links.

Also include a bit of rationale in the comment about what happens if we
don't have that block. 

* Use the maximum clock and number of lanes the eDP panel
* advertizes being capable of. The panels are generally
* designed to support only a single clock and lane
* configuration, and typically these values correspond to the
* native resolution of the panel.

+ On some? many? panels, failure to force the maximum bandwidth results
+ in flickering, hence we unconditionally apply this w/a.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PULL] gvt-next for 4.17

2018-03-09 Thread Jani Nikula

Joonas, so did this miss the deadline for v4.17? You're not making
another pull request?

BR,
Jani.

On Thu, 08 Mar 2018, Joonas Lahtinen  wrote:
> Pulled.
>
> Regards, Joonas
>
> Quoting Zhenyu Wang (2018-03-08 04:31:52)
>> 
>> Hi,
>> 
>> Here's gvt-next update for 4.17. Biggest update is for huge code
>> refactor of shadow ppgtt from Changbin which is the most obscured
>> part, and with KBL context save/restore improvement from Weinan,
>> with other fixes.
>> 
>> Thanks.
>> --
>> The following changes since commit 1f267a572b573b0b155022750cba93001f4367a8:
>> 
>>   drm/i915: Update DRIVER_DATE to 20180305 (2018-03-05 11:56:15 +0200)
>> 
>> are available in the Git repository at:
>> 
>>   https://github.com/intel/gvt-linux.git tags/gvt-next-2018-03-08
>> 
>> for you to fetch changes up to 991ecefbdd4b81719597d6c406df8d26ef5c1546:
>> 
>>   drm/i915/gvt: Return error at the failure of finding page_track 
>> (2018-03-06 14:49:38 +0800)
>> 
>> 
>> gvt-next-2018-03-08
>> 
>> - big refactor for shadow ppgtt (Changbin)
>> - KBL context save/restore via LRI cmd (Weinan)
>> - misc smatch fixes (Zhenyu)
>> - Properly unmap dma for guest page (Changbin)
>> - other misc fixes (Xiong, etc.)
>> 
>> 
>> Changbin Du (18):
>>   drm/i915/gvt: Rework shadow graphic memory management code
>>   drm/i915/gvt: Refine the intel_vgpu_mm reference management
>>   drm/i915/gvt: Refine ggtt and ppgtt root entry ops
>>   drm/i915/gvt: Refine ggtt_set_shadow_entry
>>   drm/i915/gvt: Add verbose gtt shadow logs
>>   drm/i915/gvt: Rename ggtt related functions to be more specific
>>   drm/i915/gvt: Factor out intel_vgpu_{get, put}_ppgtt_mm interface
>>   drm/i915/gvt: Use standard pte bit definition
>>   drm/i915/gvt: Refine pte shadowing process
>>   drm/i915/gvt: Rework shadow page management code
>>   drm/i915/gvt: Rename shadow_page to short name spt
>>   drm/i915/gvt: Rename mpt api {set, unset}_wp_page to {enable, 
>> disable}_page_track
>>   drm/i915/gvt: Don't extend page_track to mpt layer
>>   drm/i915/gvt: Provide generic page_track infrastructure for 
>> write-protected page
>>   drm/i915/gvt: Manage shadow pages with radix tree
>>   drm/i915/gvt: Define PTE addr mask with GENMASK_ULL
>>   drm/i915/gvt: Fix guest vGPU hang caused by very high dma setup 
>> overhead
>>   drm/i915/kvmgt: Add kvmgt debugfs entry nr_cache_entries under vgpu
>> 
>> Weinan Li (3):
>>   drm/i915/gvt: add define GEN9_MOCS_SIZE
>>   drm/i915/gvt: add interface to check if context is inhibit
>>   drm/i915/gvt: init mmio by lri command in vgpu inhibit context
>> 
>> Xiong Zhang (2):
>>   drm/i915/gvt: Release gvt->lock at the failure of finding page track
>>   drm/i915/gvt: Return error at the failure of finding page_track
>> 
>> Zhenyu Wang (7):
>>   drm/i915/gvt: Fix one gvt_vgpu_error() use in dmabuf.c
>>   drm/i915/gvt: remove gvt max port definition
>>   drm/i915/gvt: Fix vGPU sched timeslice calculation warning
>>   drm/i915/gvt: Fix check error of vgpu create failure message
>>   drm/i915/gvt: Fix check error on fence mmio handler
>>   drm/i915/gvt: Fix one indent error
>>   drm/i915/gvt: Fix check error on hws_pga_write() fail message
>> 
>>  drivers/gpu/drm/i915/gvt/Makefile   |2 +-
>>  drivers/gpu/drm/i915/gvt/dmabuf.c   |2 +-
>>  drivers/gpu/drm/i915/gvt/gtt.c  | 1457 
>> ++-
>>  drivers/gpu/drm/i915/gvt/gtt.h  |  189 ++--
>>  drivers/gpu/drm/i915/gvt/gvt.c  |2 +-
>>  drivers/gpu/drm/i915/gvt/gvt.h  |   21 +-
>>  drivers/gpu/drm/i915/gvt/handlers.c |   38 +-
>>  drivers/gpu/drm/i915/gvt/hypercall.h|9 +-
>>  drivers/gpu/drm/i915/gvt/kvmgt.c|  313 ---
>>  drivers/gpu/drm/i915/gvt/mmio.c |9 +-
>>  drivers/gpu/drm/i915/gvt/mmio_context.c |  210 -
>>  drivers/gpu/drm/i915/gvt/mmio_context.h |5 +
>>  drivers/gpu/drm/i915/gvt/mpt.h  |   67 +-
>>  drivers/gpu/drm/i915/gvt/page_track.c   |  184 
>>  drivers/gpu/drm/i915/gvt/page_track.h   |   56 ++
>>  drivers/gpu/drm/i915/gvt/sched_policy.c |5 +-
>>  drivers/gpu/drm/i915/gvt/scheduler.c|   44 +-
>>  drivers/gpu/drm/i915/gvt/trace.h|   10 +-
>>  drivers/gpu/drm/i915/gvt/vgpu.c |1 +
>>  19 files changed, 1468 insertions(+), 1156 deletions(-)
>>  create mode 100644 drivers/gpu/drm/i915/gvt/page_track.c
>>  create mode 100644 drivers/gpu/drm/i915/gvt/page_track.h
>> 
>> 
>> -- 
>> Open Source Technology Center, Intel ltd.
>> 
>> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)
URL   : https://patchwork.freedesktop.org/series/39674/
State : success

== Summary ==

Series 39674v2 drm/i915: Show GEM_TRACE when detecting a failed GPU idle
https://patchwork.freedesktop.org/api/1.0/series/39674/revisions/2/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700k2) fdo#104108

fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:505s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:471s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:467s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:498s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:520s

7e7b29286da55ce67130fb58e370542181f91ade drm-tip: 2018y-03m-09d-09h-43m-23s UTC 
integration manifest
352ba8c6113d drm/i915: Show GEM_TRACE when detecting a failed GPU idle

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8288/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level

2018-03-09 Thread Michal Wajdeczko
On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski  
 wrote:



Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a way to create a
relay on demand, when it wants to read a continuous log rather than a
snapshot.

v2: Don't touch guc_log_level on relay creation error, adjust locking
after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
Use struct_mutex rather than runtime.lock for set_log_level

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---


/snip/

diff --git a/drivers/gpu/drm/i915/intel_uc.c  
b/drivers/gpu/drm/i915/intel_uc.c

index 90d2f38e22c9..abce0e38528a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc  
*guc)

i915_gem_object_put(guc->load_err_log);
 }
-int intel_uc_register(struct drm_i915_private *i915)
-{
-   int ret = 0;
-
-   if (!USES_GUC(i915))
-   return 0;
-
-   if (i915_modparams.guc_log_level)
-   ret = intel_guc_log_register(>guc);
-
-   return ret;
-}
-
-void intel_uc_unregister(struct drm_i915_private *i915)
-{
-   if (!USES_GUC(i915))
-   return;
-
-   if (i915_modparams.guc_log_level)
-   intel_guc_log_unregister(>guc);
-}
-
 static int guc_enable_communication(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.h  
b/drivers/gpu/drm/i915/intel_uc.h

index d6af984cd789..f76d51d1ce70 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -31,8 +31,6 @@
 void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
 void intel_uc_init_early(struct drm_i915_private *dev_priv);
 void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
-int intel_uc_register(struct drm_i915_private *dev_priv);
-void intel_uc_unregister(struct drm_i915_private *dev_priv);


hmm, it looks that timelines of these two functions were very short
(from patch 2 till patch 8) - so maybe by doing some patch re-order
can we fully skip them ?


 void intel_uc_init_fw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
 int intel_uc_init_misc(struct drm_i915_private *dev_priv);

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


[Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Use absolute tolerance in accuracy tests

2018-03-09 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

We need to use absolute tolerance when asserting on percentages. Relative
tolerance in this case is unfair and inaccurate since it's strictness
varies with relative target busyness.

v2:
 * Do not include spin batch edit and submit into measured time.
 * Open PMU before child is in test PWM phase.
 * No need to emit test PWM for twice as long with the new explicit
   synchroniazation via pipe.
 * Log test duration in ms for better readability.
 * Drop inverse assert. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson  # v1
---
 tests/perf_pmu.c | 33 +++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 9ebffc64d1f1..ff9f71540ee4 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1459,7 +1459,15 @@ static void __rearm_spin_batch(igt_spin_t *spin)
__sync_synchronize();
 }
 
-#define div_round_up(a, b) (((a) + (b) - 1) / (b))
+#define __assert_within(x, ref, tol_up, tol_down) \
+   igt_assert_f((double)(x) <= ((double)(ref) + (tol_up)) && \
+(double)(x) >= ((double)(ref) - (tol_down)), \
+"%f not within +%f/-%f of %f! ('%s' vs '%s')\n", \
+(double)(x), (double)(tol_up), (double)(tol_down), \
+(double)(ref), #x, #ref)
+
+#define assert_within(x, ref, tolerance) \
+   __assert_within(x, ref, tolerance, tolerance)
 
 static void
 accuracy(int gem_fd, const struct intel_execution_engine2 *e,
@@ -1493,8 +1501,8 @@ accuracy(int gem_fd, const struct intel_execution_engine2 
*e,
while (test_us < min_test_us)
test_us += busy_us + idle_us;
 
-   igt_info("calibration=%luus, test=%luus; ratio=%.2f%% (%luus/%luus)\n",
-pwm_calibration_us, test_us,
+   igt_info("calibration=%lums, test=%lums; ratio=%.2f%% (%luus/%luus)\n",
+pwm_calibration_us / 1000, test_us / 1000,
 (double)busy_us / (busy_us + idle_us) * 100.0,
 busy_us, idle_us);
 
@@ -1507,7 +1515,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2 
*e,
igt_fork(child, 1) {
struct sched_param rt = { .sched_priority = 99 };
const unsigned long timeout[] = {
-   pwm_calibration_us * 1000, test_us * 2 * 1000
+   pwm_calibration_us * 1000, test_us * 1000
};
struct drm_i915_gem_exec_object2 obj = {};
uint64_t total_busy_ns = 0, total_idle_ns = 0;
@@ -1537,19 +1545,16 @@ accuracy(int gem_fd, const struct 
intel_execution_engine2 *e,
 
igt_nsec_elapsed(_start);
do {
-   struct timespec t_busy = { };
-   unsigned int target_idle_us;
-
-   igt_nsec_elapsed(_busy);
+   unsigned int target_idle_us, t_busy;
 
/* Restart the spinbatch. */
__rearm_spin_batch(spin);
__submit_spin_batch(gem_fd, , e);
-   measured_usleep(busy_us);
+   t_busy = measured_usleep(busy_us);
igt_spin_batch_end(spin);
gem_sync(gem_fd, obj.handle);
 
-   total_busy_ns += igt_nsec_elapsed(_busy);
+   total_busy_ns += t_busy;
 
target_idle_us =
(100 * total_busy_ns / target_busy_pct 
- (total_busy_ns + total_idle_ns)) / 1000;
@@ -1569,12 +1574,13 @@ accuracy(int gem_fd, const struct 
intel_execution_engine2 *e,
igt_spin_batch_free(gem_fd, spin);
}
 
+   fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance));
+
/* Let the child run. */
read(link[0], , sizeof(expected));
-   assert_within_epsilon(expected, target_busy_pct/100., 0.05);
+   assert_within(100.0 * expected, target_busy_pct, 5);
 
/* Collect engine busyness for an interesting part of child runtime. */
-   fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance));
val[0] = __pmu_read_single(fd, [0]);
read(link[0], , sizeof(expected));
val[1] = __pmu_read_single(fd, [1]);
@@ -1590,8 +1596,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2 
*e,
igt_info("error=%.2f%% (%.2f%% vs %.2f%%)\n",
 __error(busy_r, expected), 100 * busy_r, 100 * expected);
 
-   assert_within_epsilon(busy_r, expected, 0.15);
-   assert_within_epsilon(1 - busy_r, 1 - expected, 0.15);
+   assert_within(100.0 * busy_r, 100.0 * expected, 2);
 }
 
 igt_main
-- 
2.14.1


[Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL

2018-03-09 Thread Lionel Landwerlin
No significant changes from either context offsets, nor report
formats, nor register whitelist.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_oa_icl.c | 118 +
 drivers/gpu/drm/i915/i915_oa_icl.h |  34 +++
 drivers/gpu/drm/i915/i915_perf.c   |   5 +-
 4 files changed, 158 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4eee91a3a236..ead1e4ff1575 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -171,7 +171,8 @@ i915-y += i915_perf.o \
  i915_oa_glk.o \
  i915_oa_cflgt2.o \
  i915_oa_cflgt3.o \
- i915_oa_cnl.o
+ i915_oa_cnl.o \
+ i915_oa_icl.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_oa_icl.c 
b/drivers/gpu/drm/i915/i915_oa_icl.c
new file mode 100644
index ..a5667926e3de
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_icl.c
@@ -0,0 +1,118 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "i915_oa_icl.h"
+
+static const struct i915_oa_reg b_counter_config_test_oa[] = {
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2770), 0x0004 },
+   { _MMIO(0x2774), 0x },
+   { _MMIO(0x2778), 0x0003 },
+   { _MMIO(0x277c), 0x },
+   { _MMIO(0x2780), 0x0007 },
+   { _MMIO(0x2784), 0x },
+   { _MMIO(0x2788), 0x0012 },
+   { _MMIO(0x278c), 0xfff7 },
+   { _MMIO(0x2790), 0x0012 },
+   { _MMIO(0x2794), 0xffcf },
+   { _MMIO(0x2798), 0x00100082 },
+   { _MMIO(0x279c), 0xffef },
+   { _MMIO(0x27a0), 0x001000c2 },
+   { _MMIO(0x27a4), 0xffe7 },
+   { _MMIO(0x27a8), 0x0011 },
+   { _MMIO(0x27ac), 0xffe7 },
+};
+
+static const struct i915_oa_reg flex_eu_config_test_oa[] = {
+};
+
+static const struct i915_oa_reg mux_config_test_oa[] = {
+   { _MMIO(0xd04), 0x0200 },
+   { _MMIO(0x9840), 0x },
+   { _MMIO(0x9884), 0x },
+   { _MMIO(0x9888), 0x1006 },
+   { _MMIO(0x9888), 0x2206 },
+   { _MMIO(0x9888), 0x1606 },
+   { _MMIO(0x9888), 0x2406 },
+   { _MMIO(0x9888), 0x1806 },
+   { _MMIO(0x9888), 0x1a06 },
+   { _MMIO(0x9888), 0x1206 },
+   { _MMIO(0x9888), 0x1406 },
+   { _MMIO(0x9888), 0x1006 },
+   { _MMIO(0x9888), 0x2206 },
+   { _MMIO(0x9884), 0x0003 },
+   { _MMIO(0x9888), 0x1613 },
+   { _MMIO(0x9888), 0x2401 },
+   { _MMIO(0x9888), 0x0e130056 },
+   { _MMIO(0x9888), 0x1013 },
+   { _MMIO(0x9888), 0x1a13 },
+   { _MMIO(0x9888), 0x541f0001 },
+   { _MMIO(0x9888), 0x181f },
+   { _MMIO(0x9888), 0x4c1f },
+   { _MMIO(0x9888), 0x301f },
+};
+
+static ssize_t
+show_test_oa_id(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "1\n");
+}
+
+void
+i915_perf_load_test_config_icl(struct drm_i915_private *dev_priv)
+{
+   strlcpy(dev_priv->perf.oa.test_config.uuid,
+   "a291665e-244b-4b76-9b9a-01de9d3c8068",
+   sizeof(dev_priv->perf.oa.test_config.uuid));
+   dev_priv->perf.oa.test_config.id = 1;
+
+   dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa;
+   

Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

2018-03-09 Thread Jani Nikula
On Thu, 08 Mar 2018, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
>
> Previously it was assumed that eDP panels would advertise the lowest link
> rate required for their singular mode to function. With the introduction
> of more advanced features there are advantages to a panel advertising a
> higher rate then it needs for a its given mode. For panels that did, the
> driver previously used a higher rate then necessary for that mode.
>
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a2eeede..aa6d77d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1758,16 +1758,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> dev_priv->vbt.edp.bpp);
>   bpp = dev_priv->vbt.edp.bpp;
>   }
> -
> - /*
> -  * Use the maximum clock and number of lanes the eDP panel
> -  * advertizes being capable of. The panels are generally
> -  * designed to support only a single clock and lane
> -  * configuration, and typically these values correspond to the
> -  * native resolution of the panel.
> -  */
> - min_lane_count = max_lane_count;
> - min_clock = max_clock;

Please see my reply to Manasi's identical patch [1]. If we apply this
as-is, it will regress and will be reverted.

BR,
Jani.


[1] 
http://patchwork.freedesktop.org/patch/msgid/1520579339-14745-1-git-send-email-manasi.d.nav...@intel.com


>   }
>  
>   for (; bpp >= 6*3; bpp -= 2*3) {

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)
URL   : https://patchwork.freedesktop.org/series/39674/
State : failure

== Summary ==

 Possible new issues:

Test kms_cursor_legacy:
Subgroup cursorb-vs-flipb-atomic-transitions-varying-size:
pass   -> DMESG-WARN (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-indfb-fliptrack:
pass   -> FAIL   (shard-apl)
Subgroup fbc-1p-offscren-pri-indfb-draw-pwrite:
fail   -> PASS   (shard-apl)
Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
dmesg-fail -> PASS   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions:
pass   -> FAIL   (shard-apl) fdo#103207
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
fail   -> PASS   (shard-snb) fdo#103167 +1
Subgroup fbc-suspend:
pass   -> FAIL   (shard-apl) fdo#101623
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3467 pass:1822 dwarn:1   dfail:0   fail:11  skip:1632 
time:12231s
shard-hswtotal:3467 pass:1769 dwarn:2   dfail:0   fail:4   skip:1691 
time:11689s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6891s
Blacklisted hosts:
shard-kbltotal:3381 pass:1899 dwarn:1   dfail:0   fail:9   skip:1471 
time:9138s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8288/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: enable perf support on ICL

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: enable perf support on ICL
URL   : https://patchwork.freedesktop.org/series/39689/
State : success

== Summary ==

Series 39689v1 drm/i915/perf: enable perf support on ICL
https://patchwork.freedesktop.org/api/1.0/series/39689/revisions/1/mbox/

 Known issues:

Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-cnl-y3) fdo#103167
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#103191

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:425s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:507s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:493s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:484s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:473s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:410s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:470s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:512s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:523s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:423s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:531s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:509s

074e834cb3cccf697895a7dc471d324c2309a610 drm-tip: 2018y-03m-09d-10h-30m-56s UTC 
integration manifest
07c313f0dad2 drm/i915/perf: enable perf support on ICL

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8289/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH igt] igt/gem_mocs_settings: Wait for RC6 EI before polling

2018-03-09 Thread Chris Wilson
On bxt, we see that the rc6 subtest flip-flops as RC6 does not restart
within our desired interval. Improve the likelihood of the inspection
passing by idling the GPU and waiting for 2 Evaluation Intervals before
we start polling of RC6 residency.

Signed-off-by: Chris Wilson 
---
 tests/gem_mocs_settings.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
index 9705fbfd..85fd637a 100644
--- a/tests/gem_mocs_settings.c
+++ b/tests/gem_mocs_settings.c
@@ -336,12 +336,15 @@ static uint32_t rc6_residency(int dir)
 
 static void rc6_wait(int fd)
 {
-   int sysfs;
uint32_t residency;
+   int sysfs;
 
sysfs = igt_sysfs_open(fd, NULL);
igt_assert_lte(0, sysfs);
 
+   gem_quiescent_gpu(fd);
+   usleep(320e3); /* Wait for 2 EIs before polling; should now be active */
+
residency = rc6_residency(sysfs);
igt_require(igt_wait(rc6_residency(sysfs) != residency, 1, 2));
 
-- 
2.16.2

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


Re: [Intel-gfx] [PATCH v2 10/15] drm/i915/guc: Get rid of GuC log runtime

2018-03-09 Thread Sagar Arun Kamble



On 3/8/2018 9:17 PM, Michał Winiarski wrote:

Runtime is not a very good name. Let's also move counting relay
overflows inside relay struct.

v2: Rename things rather than remove the struct (Chris)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Some might want other stats too as part of relay since we print them 
when relay is enabled.

But this is not a big issue. w/ or w/o that change:
Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_debugfs.c  |  4 +--
  drivers/gpu/drm/i915/intel_guc.c | 12 +++
  drivers/gpu/drm/i915/intel_guc_log.c | 66 ++--
  drivers/gpu/drm/i915/intel_guc_log.h |  7 ++--
  4 files changed, 44 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f99fe9910634..d7c0bf6facf6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2348,8 +2348,8 @@ static void i915_guc_log_info(struct seq_file *m,
seq_printf(m, "\tTotal flush interrupt count: %u\n",
   guc->log.flush_interrupt_count);
  
-	seq_printf(m, "\tCapture miss count: %u\n",

-  guc->log.capture_miss_count);
+   seq_printf(m, "\tRelay full count: %u\n",
+  guc->log.relay.full_count);
  }
  
  static void i915_guc_client_info(struct seq_file *m,

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 0d92caf6a83f..cab158e42577 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -87,9 +87,9 @@ int intel_guc_init_wq(struct intel_guc *guc)
 * or scheduled later on resume. This way the handling of work
 * item can be kept same between system suspend & rpm suspend.
 */
-   guc->log.runtime.flush_wq = alloc_ordered_workqueue("i915-guc_log",
+   guc->log.relay.flush_wq = alloc_ordered_workqueue("i915-guc_log",
WQ_HIGHPRI | WQ_FREEZABLE);
-   if (!guc->log.runtime.flush_wq) {
+   if (!guc->log.relay.flush_wq) {
DRM_ERROR("Couldn't allocate workqueue for GuC log\n");
return -ENOMEM;
}
@@ -112,7 +112,7 @@ int intel_guc_init_wq(struct intel_guc *guc)
guc->preempt_wq = alloc_ordered_workqueue("i915-guc_preempt",
  WQ_HIGHPRI);
if (!guc->preempt_wq) {
-   destroy_workqueue(guc->log.runtime.flush_wq);
+   destroy_workqueue(guc->log.relay.flush_wq);
DRM_ERROR("Couldn't allocate workqueue for GuC "
  "preemption\n");
return -ENOMEM;
@@ -130,7 +130,7 @@ void intel_guc_fini_wq(struct intel_guc *guc)
USES_GUC_SUBMISSION(dev_priv))
destroy_workqueue(guc->preempt_wq);
  
-	destroy_workqueue(guc->log.runtime.flush_wq);

+   destroy_workqueue(guc->log.relay.flush_wq);
  }
  
  static int guc_shared_data_create(struct intel_guc *guc)

@@ -389,8 +389,8 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc)
  
  	if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |

   INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) {
-   queue_work(guc->log.runtime.flush_wq,
-  >log.runtime.flush_work);
+   queue_work(guc->log.relay.flush_wq,
+  >log.relay.flush_work);
  
  		guc->log.flush_interrupt_count++;

}
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 92a7bf0fd729..7c4339dae534 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -151,10 +151,10 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
smp_wmb();
  
  	/* All data has been written, so now move the offset of sub buffer. */

-   relay_reserve(guc->log.runtime.relay_chan, 
guc->log.vma->obj->base.size);
+   relay_reserve(guc->log.relay.channel, guc->log.vma->obj->base.size);
  
  	/* Switch to the next sub buffer */

-   relay_flush(guc->log.runtime.relay_chan);
+   relay_flush(guc->log.relay.channel);
  }
  
  static void *guc_get_write_buffer(struct intel_guc *guc)

@@ -168,7 +168,7 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
 * done without using relay_reserve() along with relay_write(). So its
 * better to use relay_reserve() alone.
 */
-   return relay_reserve(guc->log.runtime.relay_chan, 0);
+   return relay_reserve(guc->log.relay.channel, 0);
  }
  
  static bool guc_check_log_buf_overflow(struct intel_guc *guc,

@@ -219,13 +219,13 @@ static void 

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.

2018-03-09 Thread Maarten Lankhorst
Op 06-03-18 om 16:57 schreef Maxime Ripard:
> Hi,
>
> On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote:
>> Only try to set those values if the properties are supported.
>> This fixes the kms_chameium tests to run on vc4 again.
>>
>> Reported-by: Maxime Ripard 
>> Cc: Paul Kocialkowski 
>> Cc: Eric Anholt 
>> Cc: Boris Brezillon 
>> Signed-off-by: Maarten Lankhorst 
> This works like a charm now, thanks!
> Tested-by: Maxime Ripard 
>
> Maxime
>
Can you upgrade this to a reviewed-by so I can apply this change?

~Maarten

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


Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM

2018-03-09 Thread Sagar Arun Kamble



On 3/9/2018 2:30 AM, Michal Wajdeczko wrote:

Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem.c|  2 ++
  drivers/gpu/drm/i915/intel_guc.h   |  6 ++
  drivers/gpu/drm/i915/intel_huc.h   |  6 ++
  drivers/gpu/drm/i915/intel_uc.c| 18 ++
  drivers/gpu/drm/i915/intel_uc.h|  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca5..49c81ae 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4892,6 +4892,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 */
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
above intel_gpu_reset also resets uC. Should we just let it reset only 
real engines with this change then?

+
+   intel_uc_sanitize(i915);
  }
  
  int i915_gem_suspend(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424ac..ec8569f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
  u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  
+static inline int intel_guc_sanitize(struct intel_guc *guc)

+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 5d6e804..b185850 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,10 @@ struct intel_huc {
  void intel_huc_init_early(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  
+static inline int intel_huc_sanitize(struct intel_huc *huc)

+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
  }
  
+void intel_uc_sanitize(struct drm_i915_private *i915)

+{
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   guc_disable_communication(guc);
+
+   intel_huc_sanitize(huc);
+   intel_guc_sanitize(guc);
+
+   __intel_uc_reset_hw(i915);
+}
+
  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
  void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
  int intel_uc_init_misc(struct drm_i915_private *dev_priv);
  void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
  int intel_uc_init_hw(struct drm_i915_private *dev_priv);
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
  }
  
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)

+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
  void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   struct intel_uc_fw *uc_fw);
  int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,


--
Thanks,
Sagar

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


Re: [Intel-gfx] [PATCH v2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

2018-03-09 Thread Chris Wilson
Quoting Chris Wilson (2018-03-09 01:08:08)
> Originally we were inlining gen8_cs_irq_handler() and so expected the
> compiler to constant-fold away the irq_shift (so we had hardcoded it as
> opposed to use engine->irq_shift). However, we dropped the inline given
> the proliferation of gen8_cs_irq_handler()s. If we pull the shifting
> of the iir into the caller, we can shrink the code still further:
> 
> add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34)
> Function old new   delta
> gen8_cs_irq_handler  123 118  -5
> gen8_gt_irq_handler  261 248 -13
> gen11_irq_handler722 706 -16
> 
> v2: Drop gen11_cs_irq_handler now that it is a simple
> stub around gen8_cs_irq_handler (Daniele)
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Cc: Daniele Ceraolo Spurio 
> Reviewed-by: Daniele Ceraolo Spurio 

Pushed, thanks for the review and prompting.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level

2018-03-09 Thread Sagar Arun Kamble



On 3/8/2018 9:17 PM, Michał Winiarski wrote:

Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a way to create a
relay on demand, when it wants to read a continuous log rather than a
snapshot.

v2: Don't touch guc_log_level on relay creation error, adjust locking
 after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
 Use struct_mutex rather than runtime.lock for set_log_level

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 



diff --git a/drivers/gpu/drm/i915/intel_guc_log.h 
b/drivers/gpu/drm/i915/intel_guc_log.h
index 8c26cce77a98..df91f12a36ed 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/intel_guc_log.h
@@ -61,9 +61,10 @@ struct intel_guc_log {
  int intel_guc_log_create(struct intel_guc *guc);
  void intel_guc_log_destroy(struct intel_guc *guc);
  void intel_guc_log_init_early(struct intel_guc *guc);
-int intel_guc_log_control_get(struct intel_guc *guc);
-int intel_guc_log_control_set(struct intel_guc *guc, u64 control_val);
-int intel_guc_log_register(struct intel_guc *guc);
-void intel_guc_log_unregister(struct intel_guc *guc);
+int intel_guc_log_level_get(struct intel_guc *guc);
+int intel_guc_log_level_set(struct intel_guc *guc, u64 control_val);
+int intel_guc_log_relay_open(struct intel_guc *guc);
+void intel_guc_log_relay_close(struct intel_guc *guc);
+void intel_guc_log_relay_flush(struct intel_guc *guc);

Need to maintain order of definition. init_early is also not in order.
With that:
Reviewed-by: Sagar Arun Kamble 
  
  #endif

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 90d2f38e22c9..abce0e38528a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc *guc)
i915_gem_object_put(guc->load_err_log);
  }
  
-int intel_uc_register(struct drm_i915_private *i915)

-{
-   int ret = 0;
-
-   if (!USES_GUC(i915))
-   return 0;
-
-   if (i915_modparams.guc_log_level)
-   ret = intel_guc_log_register(>guc);
-
-   return ret;
-}
-
-void intel_uc_unregister(struct drm_i915_private *i915)
-{
-   if (!USES_GUC(i915))
-   return;
-
-   if (i915_modparams.guc_log_level)
-   intel_guc_log_unregister(>guc);
-}
-
  static int guc_enable_communication(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index d6af984cd789..f76d51d1ce70 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -31,8 +31,6 @@
  void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
  void intel_uc_init_early(struct drm_i915_private *dev_priv);
  void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
-int intel_uc_register(struct drm_i915_private *dev_priv);
-void intel_uc_unregister(struct drm_i915_private *dev_priv);
  void intel_uc_init_fw(struct drm_i915_private *dev_priv);
  void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
  int intel_uc_init_misc(struct drm_i915_private *dev_priv);


--
Thanks,
Sagar

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


Re: [Intel-gfx] [PATCH] drm/i915/dp: Do not set the eDP link rate/lane count to max

2018-03-09 Thread Jani Nikula
On Thu, 08 Mar 2018, Manasi Navare  wrote:
> The panels are generally designed to support only a single
> clock and lane configuration, and typically these values
> correspond to the native resolution of the panel. But some
> panels advertise the MAX_LINK_RATE in DPCD higher than what
> is required to support the native resolution.
> So optimize and set the link rate and lane count to the
> least values required by the panel to support the native
> resolution. This will also be an effective power saving
> for such eDP panels.

I'm afraid this will lead to flickering on plenty of laptops. It will
just get reverted when it hits end users. We've been down this path
before. If we decide to try to do this again, we need to figure out how
*not* to regress those machines. We can't just talk our way out of this.

As a tip, it's often useful to have a look at git blame and git log when
you're considering changes to code that seems odd or contentious or
something. In this case that leads to commit 344c5bbcb7a2
("drm/i915/edp: use lane count and link rate from DPCD for eDP"), which
in turn leads to commit 56071a207602 ("drm/i915: use lane count and link
rate from VBT as minimums for eDP") and a bunch of bugzilla links.

That stuff was done by yours truly years ago, so I'd rather not repeat
my mistakes now. ;)


BR,
Jani.

>
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Matt Atwood 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8d1d7af..ba1114b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1812,15 +1812,14 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   bpp = dev_priv->vbt.edp.bpp;
>   }
>  
> - /*
> -  * Use the maximum clock and number of lanes the eDP panel
> -  * advertizes being capable of. The panels are generally
> -  * designed to support only a single clock and lane
> -  * configuration, and typically these values correspond to the
> -  * native resolution of the panel.
> + /* The panels are generally designed to support only a single
> +  * clock and lane configuration, and typically these values
> +  * correspond to the native resolution of the panel. But some
> +  * panels advertise higher link rates that might not be required
> +  * for the native resolution of the panel. So use the least
> +  * required link rate/lane count for the panel's native
> +  * resolution.
>*/
> - min_lane_count = max_lane_count;
> - min_clock = max_clock;
>   }
>  
>   for (; bpp >= 6*3; bpp -= 2*3) {

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/icl: do not save DDI A/E sharing bit for ICL

2018-03-09 Thread Jani Nikula
On Tue, 06 Mar 2018, Ville Syrjälä  wrote:
> On Tue, Mar 06, 2018 at 12:41:55PM +0200, Jani Nikula wrote:
>> We don't want to preserve the DDI A 4 lane bit on ICL.
>> 
>> Fixes: 3d2011cfa41f ("drm/i915/icl: remove port A/E lane sharing 
>> limitation.")
>> Cc: Mahesh Kumar 
>> Cc: Paulo Zanoni 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Ville Syrjälä 

Pushed, thanks for the review.

The one CI warning is unrelated.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index bfdaa5d86861..66417dd24bfc 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -2932,9 +2932,12 @@ void intel_ddi_init(struct drm_i915_private 
>> *dev_priv, enum port port)
>>  intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
>>  intel_encoder->cloneable = 0;
>>  
>> -intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
>> -  (DDI_BUF_PORT_REVERSAL |
>> -   DDI_A_4_LANES);
>> +if (INTEL_GEN(dev_priv) >= 11)
>> +intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
>> +DDI_BUF_PORT_REVERSAL;
>> +else
>> +intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
>> +(DDI_BUF_PORT_REVERSAL | DDI_A_4_LANES);
>>  intel_dig_port->dp.output_reg = INVALID_MMIO_REG;
>>  intel_dig_port->max_lanes = intel_ddi_max_lanes(intel_dig_port);
>>  
>> -- 
>> 2.11.0
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled

2018-03-09 Thread Sagar Arun Kamble



On 3/8/2018 9:17 PM, Michał Winiarski wrote:

If nobody has enabled the relay, we're not comunicating with GuC, which
means that the stats don't have any meaning. Let's also remove interrupt
counter and tidy the debugfs formatting.

v2: Correct stats accounting (Sagar)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
  drivers/gpu/drm/i915/i915_debugfs.c  | 45 
  drivers/gpu/drm/i915/intel_guc.c |  5 +---
  drivers/gpu/drm/i915/intel_guc_log.c | 22 +-
  drivers/gpu/drm/i915/intel_guc_log.h | 10 
  4 files changed, 48 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d29bacb1f308..94516ab4eaed 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2326,30 +2326,45 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)
return 0;
  }
  
+static const char *

+stringify_guc_log_type(enum guc_log_buffer_type type)
+{
+   switch (type) {
+   case GUC_ISR_LOG_BUFFER:
+   return "ISR";
+   case GUC_DPC_LOG_BUFFER:
+   return "DPC";
+   case GUC_CRASH_DUMP_LOG_BUFFER:
+   return "CRASH";
+   default:
+   MISSING_CASE(type);
+   }
+
+   return "";
+}
+
  static void i915_guc_log_info(struct seq_file *m,
  struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
+   enum guc_log_buffer_type type;
  
-	seq_puts(m, "GuC logging stats:\n");

-
-   seq_printf(m, "\tISR:   flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_ISR_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]);
-
-   seq_printf(m, "\tDPC:   flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_DPC_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]);
-
-   seq_printf(m, "\tCRASH: flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]);
+   if (!intel_guc_log_relay_enabled(guc)) {
+   seq_puts(m, "GuC log relay disabled\n");
+   return;
+   }
  
-	seq_printf(m, "\tTotal flush interrupt count: %u\n",

-  guc->log.flush_interrupt_count);
+   seq_puts(m, "GuC logging stats:\n");
  
  	seq_printf(m, "\tRelay full count: %u\n",

   guc->log.relay.full_count);
+
+   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+   seq_printf(m, "\t%s:\tflush count %10u, overflow count %10u\n",
+  stringify_guc_log_type(type),
+  guc->log.stats[type].flush,
+  guc->log.stats[type].overflow);

Didn't see this earlier. Should be sampled_overflow.
And ordering of intel_guc_log_relay_enabled() declaration w.r.t other 
declarations needs to be fixed.

With that:
Reviewed-by: Sagar Arun Kamble 

+   }
  }
  
  static void i915_guc_client_info(struct seq_file *m,

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index cab158e42577..3e2f0f8503ed 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -388,12 +388,9 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc)
spin_unlock(>irq_lock);
  
  	if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |

-  INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) {
+  INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
queue_work(guc->log.relay.flush_wq,
   >log.relay.flush_work);
-
-   guc->log.flush_interrupt_count++;
-   }
  }
  
  int intel_guc_sample_forcewake(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 7c4339dae534..a72fe4a369f4 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -171,22 +171,22 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
return relay_reserve(guc->log.relay.channel, 0);
  }
  
-static bool guc_check_log_buf_overflow(struct intel_guc *guc,

+static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
   enum guc_log_buffer_type type,
   unsigned int full_cnt)
  {
-   unsigned int prev_full_cnt = guc->log.prev_overflow_count[type];
+   unsigned int prev_full_cnt = log->stats[type].sampled_overflow;
bool overflow = false;
  
  	if 

Re: [Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Default to non-verbose GuC logging

2018-03-09 Thread Sagar Arun Kamble



On 3/8/2018 9:17 PM, Michał Winiarski wrote:

Now that we've decoupled logging from relay, GuC log level is only
controlling the GuC behavior - there shouldn't be any impact on i915
behaviour. We're only going to see a single extra interrupt when log
will get half full.
That, and the fact that we're seeing igt/gem_exec_nop/basic-series
failing with non-verbose logging being disabled.

v2: Bring back the "auto" guc_log_level, now that we fixed the log

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Reviewed-by: Sagar Arun Kamble  (v1)

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_params.h | 2 +-
  drivers/gpu/drm/i915/intel_uc.c| 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..c96360398072 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -48,7 +48,7 @@ struct drm_printer;
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
param(int, enable_guc, 0) \
-   param(int, guc_log_level, 0) \
+   param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
param(int, mmio_debug, 0) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 3fb5f75aa7c9..2f579fff58cd 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -69,7 +69,7 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
  
  static int __get_default_guc_log_level(struct drm_i915_private *dev_priv)

  {
-   int guc_log_level = 0; /* disabled */
+   int guc_log_level = 1; /* non-verbose */
  
  	/* Enable if we're running on platform with GuC and debug config */

if (HAS_GUC(dev_priv) && intel_uc_is_using_guc() &&


--
Thanks,
Sagar

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


[Intel-gfx] [PATCH v13 13/17] drm/i915: Add NV12 as supported format for primary plane

2018-03-09 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 to list of supported formats for
primary plane

v2: Rebased (Chandra Konduru)

v3: Rebased (me)

v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats

v5: Rebased (me)

v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)

v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.

v11: Adding Reviewed By tag from Shashank Sharma

v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 50 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7fd8354..d668eff 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,6 +88,22 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint32_t skl_pri_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13074,6 +13090,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -13280,6 +13297,30 @@ static bool skl_plane_has_fbc(struct drm_i915_private 
*dev_priv,
return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
 }
 
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum plane_id plane_id)
+{
+   if (plane_id == PLANE_PRIMARY) {
+   if (IS_SKYLAKE(dev_priv))
+   return false;
+   else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
+   !IS_GEMINILAKE(dev_priv))
+   return false;
+   } else if (plane_id >= PLANE_SPRITE0) {
+   if (plane_id == PLANE_CURSOR)
+   return false;
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
+   if (plane_id != PLANE_SPRITE0)
+   return false;
+   } else {
+   if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
+   IS_SKYLAKE(dev_priv))
+   return false;
+   }
+   }
+   return true;
+}
+
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13340,8 +13381,13 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
primary->check_plane = intel_check_primary_plane;
 
if (INTEL_GEN(dev_priv) >= 9) {
-   intel_primary_formats = skl_primary_formats;
-   num_formats = ARRAY_SIZE(skl_primary_formats);
+   if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+   intel_primary_formats = skl_pri_planar_formats;
+   num_formats = ARRAY_SIZE(skl_pri_planar_formats);
+   } else {
+   intel_primary_formats = skl_primary_formats;
+   num_formats = ARRAY_SIZE(skl_primary_formats);
+   }
 
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_PRIMARY))
modifiers = skl_format_modifiers_ccs;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dadfa09..31ef593 

[Intel-gfx] [PATCH v13 05/17] drm/i915/skl+: NV12 related changes for WM

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

NV12 requires WM calculation for UV plane as well.
UV plane WM should also fulfill all the WM related restrictions.

v2: Addressed review comments from Shashank Sharma.

v3: Addressed review comments from Shashank Sharma
Changed plane_num to plane_id in skl_compute_plane_wm_params
and skl_compute_plane_wm.
Adding reviewed by tag from Shashank Sharma

Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 50 +---
 3 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5abbd04..11551f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1471,6 +1471,7 @@ struct skl_wm_level {
 struct skl_wm_params {
bool x_tiled, y_tiled;
bool rc_surface;
+   bool is_planar;
uint32_t width;
uint8_t cpp;
uint32_t plane_pixel_rate;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dffe875..e5c17f5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -598,6 +598,7 @@ struct intel_pipe_wm {
 
 struct skl_plane_wm {
struct skl_wm_level wm[8];
+   struct skl_wm_level uv_wm[8];
struct skl_wm_level trans_wm;
bool is_planar;
 };
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ae91c7a..8c612ae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4419,7 +4419,7 @@ static int
 skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
-   struct skl_wm_params *wp)
+   struct skl_wm_params *wp, int plane_id)
 {
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = _pstate->base;
@@ -4432,6 +4432,12 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
if (!intel_wm_plane_visible(cstate, intel_pstate))
return 0;
 
+   /* only NV12 format has two planes */
+   if (plane_id == 1 && fb->format->format != DRM_FORMAT_NV12) {
+   DRM_DEBUG_KMS("Non NV12 format have single plane\n");
+   return -EINVAL;
+   }
+
wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
  fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
  fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
@@ -4439,6 +4445,7 @@ skl_compute_plane_wm_params(const struct drm_i915_private 
*dev_priv,
wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
wp->rc_surface = fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
 fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+   wp->is_planar = fb->format->format == DRM_FORMAT_NV12;
 
if (plane->id == PLANE_CURSOR) {
wp->width = intel_pstate->base.crtc_w;
@@ -4451,7 +4458,10 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
wp->width = drm_rect_width(_pstate->base.src) >> 16;
}
 
-   wp->cpp = fb->format->cpp[0];
+   if (plane_id == 1 && wp->is_planar)
+   wp->width /= 2;
+
+   wp->cpp = fb->format->cpp[plane_id];
wp->plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate,
 intel_pstate);
 
@@ -4649,7 +4659,8 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
  struct intel_crtc_state *cstate,
  const struct intel_plane_state *intel_pstate,
  const struct skl_wm_params *wm_params,
- struct skl_plane_wm *wm)
+ struct skl_plane_wm *wm,
+ int plane_id)
 {
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_plane *plane = intel_pstate->base.plane;
@@ -4657,15 +4668,19 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
int level, max_level = ilk_wm_max_level(dev_priv);
+   enum plane_id intel_plane_id = intel_plane->id;
int ret;
 
if (WARN_ON(!intel_pstate->base.fb))
return -EINVAL;
 
-   ddb_blocks = skl_ddb_entry_size(>plane[pipe][intel_plane->id]);
+   ddb_blocks = plane_id ?
+skl_ddb_entry_size(>uv_plane[pipe][intel_plane_id]) :
+skl_ddb_entry_size(>plane[pipe][intel_plane_id]);
 

[Intel-gfx] [PATCH v13 06/17] drm/i915/skl+: pass skl_wm_level struct to wm compute func

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

This patch passes skl_wm_level structure itself to watermark
computation function skl_compute_plane_wm function (instead
of its internal parameters). It reduces number of arguments
required to be passed.

v2: Addressed review comments by Shashank Sharma

v3: Adding reviewed by tag from Shashank Sharma

Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8c612ae..90bf446 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4529,9 +4529,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
-   uint16_t *out_blocks, /* out */
-   uint8_t *out_lines, /* out */
-   bool *enabled /* out */)
+   struct skl_wm_level *result /* out */)
 {
const struct drm_plane_state *pstate = _pstate->base;
uint32_t latency = dev_priv->wm.skl_latency[level];
@@ -4545,7 +4543,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 
if (latency == 0 ||
!intel_wm_plane_visible(cstate, intel_pstate)) {
-   *enabled = false;
+   result->plane_en = false;
return 0;
}
 
@@ -4626,7 +4624,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if ((level > 0 && res_lines > 31) ||
res_blocks >= ddb_allocation ||
min_disp_buf_needed >= ddb_allocation) {
-   *enabled = false;
+   result->plane_en = false;
 
/*
 * If there are no valid level 0 watermarks, then we can't
@@ -4646,9 +4644,9 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
 
/* The number of lines are ignored for the level 0 watermark. */
-   *out_lines = level ? res_lines : 0;
-   *out_blocks = res_blocks;
-   *enabled = true;
+   result->plane_res_b = res_blocks;
+   result->plane_res_l = res_lines;
+   result->plane_en = true;
 
return 0;
 }
@@ -4688,9 +4686,7 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
   ddb_blocks,
   level,
   wm_params,
-  >plane_res_b,
-  >plane_res_l,
-  >plane_en);
+  result);
if (ret)
return ret;
}
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 16/17] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

2018-03-09 Thread Vidya Srinivas
If the fb format is YUV, enable the plane CSC mode bits
for the conversion.

v2: Addressed review comments from Shashank Sharma
Alignment issue fixed in i915_reg.h

v3: Adding Reviewed By from Shashank Sharma

v4: Rebased the patch. As part of rebasing, re-using
the color series defines which are already merged.
plane_state->base.color_encoding might not be set for
NV12. For now, just using PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709
in glk_plane_color_ctl if format is NV12.

Reviewed-by: Shashank Sharma 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 763ae1f..941f00d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3631,6 +3631,11 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
 
if (intel_format_is_yuv(fb->format->format)) {
+   if (fb->format->format == DRM_FORMAT_NV12) {
+   plane_color_ctl |=
+   PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
+   goto out;
+   }
if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
plane_color_ctl |= 
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
else
@@ -3638,8 +3643,9 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
 
if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
plane_color_ctl |= 
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
-   }
 
+   }
+out:
return plane_color_ctl;
 }
 
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 10/17] drm/i915: Set scaler mode for NV12

2018-03-09 Thread Vidya Srinivas
From: Chandra Konduru 

This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling

v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler

v3: Rebased (me)

v4: Rebased (me)

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.

v9: Rebased (me)

v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
Comments under v8 is not valid anymore.

v11: Addressed review comments by Shashank Sharma.
For Gen10+, the scaler mode to be set it planar or normal
(single bit). Changed the code to be applicable to all
Gen.

v12: Addressed review comments from Shashank Sharma
For Gen9 (apart from GLK) bits 28:29 to be programmed
in PS_CTRL for NV12. For GLK and Gen10+, bit 29 to be set
for all Planar.

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
Adding Reviewed by tag from Shashank Shamr

Tested-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_atomic.c | 14 --
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 258e86e..8e61b68 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6764,6 +6764,8 @@ enum {
 #define PS_SCALER_MODE_MASK (3 << 28)
 #define PS_SCALER_MODE_DYN  (0 << 28)
 #define PS_SCALER_MODE_HQ  (1 << 28)
+#define SKL_PS_SCALER_MODE_NV12 (2 << 28)
+#define PS_SCALER_MODE_PLANAR (1 << 29)
 #define PS_PLANE_SEL_MASK  (7 << 25)
 #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
 #define PS_FILTER_MASK (3 << 23)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index e9fb6920..bb8c168 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -328,8 +328,18 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
}
 
/* set scaler mode */
-   if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
-   scaler_state->scalers[*scaler_id].mode = 0;
+   if ((INTEL_GEN(dev_priv) >= 9) &&
+   plane_state && plane_state->base.fb &&
+   plane_state->base.fb->format->format ==
+   DRM_FORMAT_NV12) {
+   if (INTEL_GEN(dev_priv) == 9 &&
+   !IS_GEMINILAKE(dev_priv) &&
+   !IS_SKYLAKE(dev_priv))
+   scaler_state->scalers[*scaler_id].mode =
+   SKL_PS_SCALER_MODE_NV12;
+   else
+   scaler_state->scalers[*scaler_id].mode =
+   PS_SCALER_MODE_PLANAR;
} else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) 
{
/*
 * when only 1 scaler is in use on either pipe A or B,
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 17/17] drm/i915: Display WA 827

2018-03-09 Thread Vidya Srinivas
Display WA 827 applies to GEN9 (excluede GLK) and CNL.
Switching the plane format from NV12 to RGB and leaving system idle
results in display underrun and corruption.
WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL
register for the pipe in which NV12 plane is enabled.

Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_display.c | 31 +++
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8e61b68..dd8ee98 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3939,6 +3939,9 @@ enum {
 #define _CLKGATE_DIS_PSL_A 0x46520
 #define _CLKGATE_DIS_PSL_B 0x46524
 #define _CLKGATE_DIS_PSL_C 0x46528
+#define   DUPS1_GATING_DIS (1 << 15)
+#define   DUPS2_GATING_DIS (1 << 19)
+#define   DUPS3_GATING_DIS (1 << 23)
 #define   DPF_GATING_DIS   (1 << 10)
 #define   DPF_RAM_GATING_DIS   (1 << 9)
 #define   DPFR_GATING_DIS  (1 << 8)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 941f00d..f5fdf8a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -504,6 +504,21 @@ static const struct intel_limit intel_limits_bxt = {
.p2 = { .p2_slow = 1, .p2_fast = 20 },
 };
 
+static void
+skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
+{
+   if (IS_SKYLAKE(dev_priv))
+   return;
+
+   if (enable)
+   I915_WRITE(CLKGATE_DIS_PSL(pipe),
+  DUPS1_GATING_DIS | DUPS2_GATING_DIS);
+   else
+   I915_WRITE(CLKGATE_DIS_PSL(pipe),
+  I915_READ(CLKGATE_DIS_PSL(pipe)) &
+  ~(DUPS1_GATING_DIS|DUPS2_GATING_DIS));
+}
+
 static bool
 needs_modeset(const struct drm_crtc_state *state)
 {
@@ -3151,6 +3166,9 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
int ret;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
+   struct drm_i915_private *dev_priv =
+   to_i915(plane_state->base.plane->dev);
 
if (rotation & DRM_MODE_REFLECT_X &&
fb->modifier == DRM_FORMAT_MOD_LINEAR) {
@@ -3175,6 +3193,13 @@ int skl_check_plane_surface(const struct 
intel_crtc_state *crtc_state,
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
+
+   /* Display WA 827 */
+   if (INTEL_GEN(dev_priv) == 9 || IS_CANNONLAKE(dev_priv)) {
+   if (!IS_GEMINILAKE(dev_priv))
+   skl_wa_clkgate(dev_priv,
+  intel_crtc->pipe, true);
+   }
} else if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
   fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
ret = skl_check_ccs_aux_surface(plane_state);
@@ -5746,6 +5771,12 @@ static void haswell_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
intel_ddi_disable_pipe_clock(intel_crtc->config);
 
intel_encoders_post_disable(crtc, old_crtc_state, old_state);
+
+   if (INTEL_GEN(dev_priv) == 9 || IS_CANNONLAKE(dev_priv)) {
+   if (!IS_GEMINILAKE(dev_priv))
+   skl_wa_clkgate(dev_priv,
+  intel_crtc->pipe, false);
+   }
 }
 
 static void i9xx_pfit_enable(struct intel_crtc *crtc)
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 11/17] drm/i915: Update format_is_yuv() to include NV12

2018-03-09 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 to format_is_yuv() function
for sprite planes.

v2:
-Use intel_ prefix for format_is_yuv (Ville)

v3: Rebased (me)

v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to the primary plane functions".
Changed commit message - function modified for
sprite planes.

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Changed intel_format_is_yuv function from
static to non-static. We need to use it later from
other files for check.

v11: Rebased the patch. format_is_yuv has already
been renamed to intel_format_is_yuv in the color
patch series which is already merged. This function
which was previously static has already been made
non-static. So this patch after rebase just adds
NV12 to intel_format_is_yuv function.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_sprite.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e5c17f5..483f6ce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2049,6 +2049,7 @@ void skl_disable_plane(struct intel_plane *plane, struct 
intel_crtc *crtc);
 bool skl_plane_get_hw_state(struct intel_plane *plane);
 bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
   enum pipe pipe, enum plane_id plane_id);
+bool intel_format_is_yuv(uint32_t format);
 
 /* intel_tv.c */
 void intel_tv_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index dbdcf85..0652e58 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -48,6 +48,7 @@ bool intel_format_is_yuv(u32 format)
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_NV12:
return true;
default:
return false;
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v2 07/15] drm/i915/guc: Flush directly in log unregister

2018-03-09 Thread Sagar Arun Kamble



On 3/8/2018 9:16 PM, Michał Winiarski wrote:

Having both guc_flush_logs and guc_log_flush functions is confusing.
While we could just rename things, guc_flush_logs implementation is
quite simple. Let's get rid of it and move its content to unregister.

v2: s/dev_priv/i915 (Sagar)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/intel_guc_log.c | 34 ++
  1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index ee0981f5a208..5ff4b510569a 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -443,25 +443,6 @@ static void guc_log_capture_logs(struct intel_guc *guc)
intel_runtime_pm_put(dev_priv);
  }
  
-static void guc_flush_logs(struct intel_guc *guc)

-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
-   /*
-* Before initiating the forceful flush, wait for any pending/ongoing
-* flush to complete otherwise forceful flush may not actually happen.
-*/
-   flush_work(>log.runtime.flush_work);
-
-   /* Ask GuC to update the log buffer state */
-   intel_runtime_pm_get(dev_priv);
-   guc_log_flush(guc);
-   intel_runtime_pm_put(dev_priv);
-
-   /* GuC would have updated log buffer by now, so capture it */
-   guc_log_capture_logs(guc);
-}
-
  int intel_guc_log_create(struct intel_guc *guc)
  {
struct i915_vma *vma;
@@ -630,15 +611,28 @@ int intel_guc_log_register(struct intel_guc *guc)
  
  void intel_guc_log_unregister(struct intel_guc *guc)

  {
+   struct drm_i915_private *i915 = guc_to_i915(guc);
+
guc_log_flush_irq_disable(guc);
  
+	/*

+* Before initiating the forceful flush, wait for any pending/ongoing
+* flush to complete otherwise forceful flush may not actually happen.
+*/
+   flush_work(>log.runtime.flush_work);
+
/*
 * Once logging is disabled, GuC won't generate logs & send an
 * interrupt. But there could be some data in the log buffer
 * which is yet to be captured. So request GuC to update the log
 * buffer state and then collect the left over logs.
 */
-   guc_flush_logs(guc);
+   intel_runtime_pm_get(i915);
+   guc_log_flush(guc);
+   intel_runtime_pm_put(i915);
+
+   /* GuC would have updated log buffer by now, so capture it */
+   guc_log_capture_logs(guc);
  
  	mutex_lock(>log.runtime.lock);
  


--
Thanks,
Sagar

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


Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler

2018-03-09 Thread Tvrtko Ursulin


On 09/03/2018 01:38, Chris Wilson wrote:

Quoting Chris Wilson (2018-03-09 01:33:08)

  gen11_gt_engine_intr(struct drm_i915_private * const i915,
  const unsigned int bank, const unsigned int bit)
@@ -2836,10 +2798,23 @@ static void
  gen11_gt_irq_handler(struct drm_i915_private * const i915,
  const u32 master_ctl)
  {
+   static const u8 bank0_map[] = {
+   [GEN11_RCS0] = RCS,
+   [GEN11_BCS]  = BCS,



Is there a reason why its RCS0 but BCS? And the multi-instance classes
actually use VCS(x)?


I am pretty sure that naming came from the spec.

Side note - one thing I dislike a bit about the current code and this 
patch is that all engines have to be enumerated explicitly in the 
interrupt handler. I kind of thought it was handy to handle the 
multi-class engines from a loop, and so have one place less to remember 
to update after adding a new engine instance.


And in general I think too many bike-sheds on this area of code before 
we are even running it on real hw. :(


Regards,

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Do not set the eDP link rate/lane count to max

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915/dp: Do not set the eDP link rate/lane count to max
URL   : https://patchwork.freedesktop.org/series/39662/
State : failure

== Summary ==

 Possible new issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3381 pass:1778 dwarn:1   dfail:0   fail:9   skip:1591 
time:11692s
shard-hswtotal:3467 pass:1773 dwarn:1   dfail:0   fail:1   skip:1691 
time:11685s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6806s
Blacklisted hosts:
shard-kbltotal:3394 pass:1857 dwarn:2   dfail:0   fail:9   skip:1525 
time:8586s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8286/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 06/15] drm/i915/guc: Merge log relay file and channel creation

2018-03-09 Thread Sagar Arun Kamble

Hi Michal,

One comment was missed and another comment update suggested.

On 3/8/2018 9:16 PM, Michał Winiarski wrote:

We have all the information we need at relay_open call time.
Since there's no reason to split the process into relay_open and
relay_late_setup_files, let's remove the extra code.

v2: Remove obsoleted comments (Sagar)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Reviewed-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_guc_log.c | 64 +++-
  1 file changed, 5 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 4eb3ebd8d6c3..ee0981f5a208 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -121,14 +121,7 @@ static struct dentry *create_buf_file_callback(const char 
*filename,
if (!parent)
return NULL;
  
-	/*

-* Not using the channel filename passed as an argument, since for each
-* channel relay appends the corresponding CPU number to the filename
-* passed in relay_open(). This should be fine as relay just needs a
-* dentry of the file associated with the channel buffer and that file's
-* name need not be same as the filename passed as an argument.
-*/
-   buf_file = debugfs_create_file("guc_log", mode,
+   buf_file = debugfs_create_file(filename, mode,
   parent, buf, _file_operations);
return buf_file;
  }
@@ -149,43 +142,6 @@ static struct rchan_callbacks relay_callbacks = {
.remove_buf_file = remove_buf_file_callback,
  };
  
-static int guc_log_relay_file_create(struct intel_guc *guc)

-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   struct dentry *log_dir;
-   int ret;
-
-   lockdep_assert_held(>log.runtime.lock);
-
-   /* For now create the log file in /sys/kernel/debug/dri/0 dir */
-   log_dir = dev_priv->drm.primary->debugfs_root;
-
-   /*
-* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is
-* not mounted and so can't create the relay file.
-* The relay API seems to fit well with debugfs only, for availing relay
-* there are 3 requirements which can be met for debugfs file only in a
-* straightforward/clean manner :-
-* i)   Need the associated dentry pointer of the file, while opening 
the
-*  relay channel.
-* ii)  Should be able to use 'relay_file_operations' fops for the file.
-* iii) Set the 'i_private' field of file's inode to the pointer of
-*  relay channel buffer.
-*/
-   if (!log_dir) {
-   DRM_ERROR("Debugfs dir not available yet for GuC log file\n");
-   return -ENODEV;
-   }
-
-   ret = relay_late_setup_files(guc->log.runtime.relay_chan, "guc_log", 
log_dir);
-   if (ret < 0 && ret != -EEXIST) {
-   DRM_ERROR("Couldn't associate relay chan with file %d\n", ret);
-   return ret;
-   }
-
-   return 0;
-}
-
  static void guc_move_to_next_buf(struct intel_guc *guc)
  {
/*
@@ -271,7 +227,6 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
/* Get the pointer to shared GuC log buffer */
log_buf_state = src_data = guc->log.runtime.buf_addr;
  
-

/* Get the pointer to local buffer to store the logs */
log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);
  
@@ -443,8 +398,10 @@ static int guc_log_relay_create(struct intel_guc *guc)

 * the GuC firmware logs, the channel will be linked with a file
 * later on when debugfs is registered.
 */

Above comment needs to be removed/updated.

-   guc_log_relay_chan = relay_open(NULL, NULL, subbuf_size,
-   n_subbufs, _callbacks, dev_priv);
+   guc_log_relay_chan = relay_open("guc_log",
+   dev_priv->drm.primary->debugfs_root,
+   subbuf_size, n_subbufs,
+   _callbacks, dev_priv);
if (!guc_log_relay_chan) {
DRM_ERROR("Couldn't create relay chan for GuC logging\n");
  
@@ -649,11 +606,6 @@ int intel_guc_log_register(struct intel_guc *guc)
  
  	GEM_BUG_ON(guc_log_has_runtime(guc));
  
-	/*

-* If log was disabled at boot time, then setup needed to handle
-* log buffer flush interrupts would not have been done yet, so
-* do that now.
-*/

May be this comment should not have been added as part of patch 5/15

ret = guc_log_relay_create(guc);
if (ret)
goto err;

[Intel-gfx] [PATCH v13 09/17] drm/i915/skl: split skl_compute_ddb function

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.

v2: Added reviewed by tag from Shashank Sharma

Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 157 ++--
 1 file changed, 88 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6476768..2c75a0d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5059,69 +5059,16 @@ skl_ddb_add_affected_planes(struct intel_crtc_state 
*cstate)
 static int
 skl_compute_ddb(struct drm_atomic_state *state)
 {
-   struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct intel_crtc *intel_crtc;
struct skl_ddb_allocation *ddb = _state->wm_results.ddb;
-   uint32_t realloc_pipes = pipes_modified(state);
-   int ret;
-
-   /*
-* If this is our first atomic update following hardware readout,
-* we can't trust the DDB that the BIOS programmed for us.  Let's
-* pretend that all pipes switched active status so that we'll
-* ensure a full DDB recompute.
-*/
-   if (dev_priv->wm.distrust_bios_wm) {
-   ret = drm_modeset_lock(>mode_config.connection_mutex,
-  state->acquire_ctx);
-   if (ret)
-   return ret;
-
-   intel_state->active_pipe_changes = ~0;
-
-   /*
-* We usually only initialize intel_state->active_crtcs if we
-* we're doing a modeset; make sure this field is always
-* initialized during the sanitization process that happens
-* on the first commit too.
-*/
-   if (!intel_state->modeset)
-   intel_state->active_crtcs = dev_priv->active_crtcs;
-   }
-
-   /*
-* If the modeset changes which CRTC's are active, we need to
-* recompute the DDB allocation for *all* active pipes, even
-* those that weren't otherwise being modified in any way by this
-* atomic commit.  Due to the shrinking of the per-pipe allocations
-* when new active CRTC's are added, it's possible for a pipe that
-* we were already using and aren't changing at all here to suddenly
-* become invalid if its DDB needs exceeds its new allocation.
-*
-* Note that if we wind up doing a full DDB recompute, we can't let
-* any other display updates race with this transaction, so we need
-* to grab the lock on *all* CRTC's.
-*/
-   if (intel_state->active_pipe_changes) {
-   realloc_pipes = ~0;
-   intel_state->wm_results.dirty_pipes = ~0;
-   }
+   struct intel_crtc *crtc;
+   struct intel_crtc_state *cstate;
+   int ret, i;
 
-   /*
-* We're not recomputing for the pipes not included in the commit, so
-* make sure we start with the current state.
-*/
memcpy(ddb, _priv->wm.skl_hw.ddb, sizeof(*ddb));
 
-   for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
-   struct intel_crtc_state *cstate;
-
-   cstate = intel_atomic_get_crtc_state(state, intel_crtc);
-   if (IS_ERR(cstate))
-   return PTR_ERR(cstate);
-
+   for_each_new_intel_crtc_in_state(intel_state, crtc, cstate, i) {
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
@@ -5183,23 +5130,23 @@ skl_print_wm_changes(const struct drm_atomic_state 
*state)
 }
 
 static int
-skl_compute_wm(struct drm_atomic_state *state)
+skl_ddb_add_affected_pipes(struct drm_atomic_state *state, bool *changed)
 {
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *cstate;
-   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct skl_ddb_values *results = _state->wm_results;
struct drm_device *dev = state->dev;
-   struct skl_pipe_wm *pipe_wm;
-   bool changed = false;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   struct intel_crtc *intel_crtc;
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   uint32_t realloc_pipes = pipes_modified(state);
int ret, i;
 
/*
 * When we distrust bios wm we always need to recompute to set the
 * expected DDB allocations for each 

[Intel-gfx] [PATCH v13 03/17] drm/i915/skl+: add NV12 in skl_format_to_fourcc

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.

v2: Added reviewed by tag from Mika Kahola

Reviewed-by: Mika Kahola 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3310840..ca19b42 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2662,6 +2662,8 @@ static int skl_format_to_fourcc(int format, bool 
rgb_order, bool alpha)
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
return DRM_FORMAT_RGB565;
+   case PLANE_CTL_FORMAT_NV12:
+   return DRM_FORMAT_NV12;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 15/17] drm/i915: Add NV12 support to intel_framebuffer_init

2018-03-09 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.

v6: Rebased (me)

v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.

v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.

v9: Rebased (me)

v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable

v11: Addressed review comments from Shashank Sharma

v12: Adding Reviewed By from Shashank Sharma

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

Tested-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d668eff..763ae1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14201,6 +14201,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_NV12:
+   if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv)) {
+   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+ 
drm_get_format_name(mode_cmd->pixel_format,
+ _name));
+   goto err;
+   }
+   break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 01/17] drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

skl_wm_values struct contains values of pipe/plane DDB only.
so rename it for better readability of code. Similarly
skl_copy_wm_for_pipe copies DDB values.

s/skl_wm_values/skl_ddb_values
s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe

Changes since V1:
 - also change name of skl_copy_wm_for_pipe

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 16 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7eec99d7..0775e33 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1455,7 +1455,7 @@ struct skl_ddb_allocation {
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
-struct skl_wm_values {
+struct skl_ddb_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
 };
@@ -2151,7 +2151,7 @@ struct drm_i915_private {
/* current hardware state */
union {
struct ilk_wm_values hw;
-   struct skl_wm_values skl_hw;
+   struct skl_ddb_values skl_hw;
struct vlv_wm_values vlv;
struct g4x_wm_values g4x;
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..75969ce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -482,7 +482,7 @@ struct intel_atomic_state {
bool skip_intermediate_wm;
 
/* Gen9+ only */
-   struct skl_wm_values wm_results;
+   struct skl_ddb_values wm_results;
 
struct i915_sw_fence commit_ready;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6cab20c..797fe4d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5042,9 +5042,9 @@ skl_compute_ddb(struct drm_atomic_state *state)
 }
 
 static void
-skl_copy_wm_for_pipe(struct skl_wm_values *dst,
-struct skl_wm_values *src,
-enum pipe pipe)
+skl_copy_ddb_for_pipe(struct skl_ddb_values *dst,
+ struct skl_ddb_values *src,
+ enum pipe pipe)
 {
memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
   sizeof(dst->ddb.y_plane[pipe]));
@@ -5095,7 +5095,7 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc *crtc;
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct skl_wm_values *results = _state->wm_results;
+   struct skl_ddb_values *results = _state->wm_results;
struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
@@ -5197,8 +5197,8 @@ static void skl_initial_wm(struct intel_atomic_state 
*state,
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct skl_wm_values *results = >wm_results;
-   struct skl_wm_values *hw_vals = _priv->wm.skl_hw;
+   struct skl_ddb_values *results = >wm_results;
+   struct skl_ddb_values *hw_vals = _priv->wm.skl_hw;
enum pipe pipe = intel_crtc->pipe;
 
if ((results->dirty_pipes & drm_crtc_mask(_crtc->base)) == 0)
@@ -5209,7 +5209,7 @@ static void skl_initial_wm(struct intel_atomic_state 
*state,
if (cstate->base.active_changed)
skl_atomic_update_crtc_wm(state, cstate);
 
-   skl_copy_wm_for_pipe(hw_vals, results, pipe);
+   skl_copy_ddb_for_pipe(hw_vals, results, pipe);
 
mutex_unlock(_priv->wm.wm_mutex);
 }
@@ -5341,7 +5341,7 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
 void skl_wm_get_hw_state(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct skl_wm_values *hw = _priv->wm.skl_hw;
+   struct skl_ddb_values *hw = _priv->wm.skl_hw;
struct skl_ddb_allocation *ddb = _priv->wm.skl_hw.ddb;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 00/17] Add NV12 support

2018-03-09 Thread Vidya Srinivas
This patch series is adding NV12 support for Broxton display after rebasing on
latest drm-tip.
Initial series of the patches can be found here:
https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html

Previous revision history:
The first version of patches were reviewed when floated by Chandra in 2015
but currently there was a design change with respect to
- the way fb offset is handled
- the way rotation is handled
Current NV12 patch series has been ported as per the
current changes on drm-tip

Review comments from Ville (12th June 2017) have been addressed Review
comments from Clinton A Taylor (7th July 2017) have been addressed

Review comments from Clinton A Taylor (10th July 2017)
have been addressed. Had missed out tested-by/reviewed-by in the 
patches.
Fixed that error in this series.
Review comments from Ville (11th July 2017) addressed.
Review comments from Paauwe, Bob (29th July 2017) addressed.

Update from rev 28 Aug 2017
Rebased the series.
Tested with IGT for rotation, sprite and tiling combinations.
IGT Links:
https://patchwork.kernel.org/patch/9995943/
https://patchwork.kernel.org/patch/9995945/
Review comments by Maarten are addressed in this series.
NV12 enabled for Gen10.
Review comments from Shashank Sharma are addressed.
IGT debug_fs test failure fixed.
Added reviewed-by tag from Shashank Sharma for few patches
Addressed comments from Juha-Pekka Heikkila in few patches
(NV12 not to be supported for SKL)
Adding an additional patch Display WA 827 for underrun during NV12
Adding more WA implementation to see if it helps underruns

Update from previous series:
Rebased the series
Addressed review comments from Ville regarding the planar formats
Added minimum src height for yuv 420 planar formats
Added NV12 in skl_mod_supported

Chandra Konduru (6):
  drm/i915: Set scaler mode for NV12
  drm/i915: Update format_is_yuv() to include NV12
  drm/i915: Upscale scaler max scale for NV12
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init

Mahesh Kumar (9):
  drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
  drm/i915/skl+: refactor WM calculation for NV12
  drm/i915/skl+: add NV12 in skl_format_to_fourcc
  drm/i915/skl+: support verification of DDB HW state for NV12
  drm/i915/skl+: NV12 related changes for WM
  drm/i915/skl+: pass skl_wm_level struct to wm compute func
  drm/i915/skl+: make sure higher latency level has higher wm value
  drm/i915/skl+: nv12 workaround disable WM level 1-7
  drm/i915/skl: split skl_compute_ddb function

Vidya Srinivas (2):
  drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
  drm/i915: Display WA 827

 drivers/gpu/drm/i915/i915_drv.h  |  10 +-
 drivers/gpu/drm/i915/i915_reg.h  |   5 +
 drivers/gpu/drm/i915/intel_atomic.c  |  14 +-
 drivers/gpu/drm/i915/intel_display.c | 179 +++---
 drivers/gpu/drm/i915/intel_drv.h |  12 +-
 drivers/gpu/drm/i915/intel_pm.c  | 438 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  28 ++-
 7 files changed, 486 insertions(+), 200 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH v13 14/17] drm/i915: Add NV12 as supported format for sprite plane

2018-03-09 Thread Vidya Srinivas
From: Chandra Konduru 

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.

v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B

v7: Rebased (me)

v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.

v11: Addressed review comments from Shashank Sharma

v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.

v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported

Tested-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index a6e4ea5..3651fe4 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1250,6 +1250,19 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static uint32_t skl_planar_formats[] = {
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1344,6 +1357,7 @@ static bool skl_mod_supported(uint32_t format, uint64_t 
modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -1443,8 +1457,14 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
 
-   plane_formats = skl_plane_formats;
-   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+   plane_formats = skl_planar_formats;
+   num_plane_formats = ARRAY_SIZE(skl_planar_formats);
+   } else {
+   plane_formats = skl_plane_formats;
+   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+   }
 
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
modifiers = skl_plane_format_modifiers_ccs;
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 07/17] drm/i915/skl+: make sure higher latency level has higher wm value

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below the
current level. Render decompression requires level WM to be as high as
wm level-0. This patch fulfils both the requirements.

v2: Changed plane_num to plane_id in skl_compute_wm_levels

v3: Addressed review comments from Shashank Sharma
Changed the commit message "statement can be more clear,
"DDB value to be as high as level below " what is level below ?"

v4: Added reviewed by tag from Shashank Sharma

Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 90bf446..efa3367 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4529,6 +4529,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
+   const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
 {
const struct drm_plane_state *pstate = _pstate->base;
@@ -4596,6 +4597,15 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
} else {
res_blocks++;
}
+
+   /*
+* Make sure result blocks for higher latency levels are atleast
+* as high as level below the current level.
+* Assumption in DDB algorithm optimization for special cases.
+* Also covers Display WA #1125 for RC.
+*/
+   if (result_prev->plane_res_b > res_blocks)
+   res_blocks = result_prev->plane_res_b;
}
 
if (INTEL_GEN(dev_priv) >= 11) {
@@ -4679,6 +4689,13 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = plane_id ? >uv_wm[level] :
  >wm[level];
+   struct skl_wm_level *result_prev;
+
+   if (level)
+   result_prev = plane_id ? >uv_wm[level - 1] :
+ >wm[level - 1];
+   else
+   result_prev = plane_id ? >uv_wm[0] : >wm[0];
 
ret = skl_compute_plane_wm(dev_priv,
   cstate,
@@ -4686,6 +4703,7 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
   ddb_blocks,
   level,
   wm_params,
+  result_prev,
   result);
if (ret)
return ret;
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 04/17] drm/i915/skl+: support verification of DDB HW state for NV12

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Config register. Both register values
should be verified during verify_wm_state.

v2: Addressed review comments by Maarten.

v3: Addressed review comments by Shashank Sharma.

v4: Adding reviewed by tag from Shashank Sharma

Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 51 +---
 3 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ca19b42..34f7225 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2657,7 +2657,7 @@ static int i9xx_format_to_fourcc(int format)
}
 }
 
-static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
 {
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 18930ad..dffe875 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1608,6 +1608,7 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb, 
int plane,
 int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
 int i9xx_check_plane_surface(struct intel_plane_state *plane_state);
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha);
 
 /* intel_csr.c */
 void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 31ef5c8..ae91c7a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3825,6 +3825,44 @@ static void skl_ddb_entry_init_from_hw(struct 
skl_ddb_entry *entry, u32 reg)
entry->end += 1;
 }
 
+static void
+skl_ddb_get_hw_plane_state(struct drm_i915_private *dev_priv,
+  const enum pipe pipe,
+  const enum plane_id plane_id,
+  struct skl_ddb_allocation *ddb /* out */)
+{
+   u32 val, val2 = 0;
+   int fourcc, pixel_format;
+
+   /* Cursor doesn't support NV12/planar, so no extra calculation needed */
+   if (plane_id == PLANE_CURSOR) {
+   val = I915_READ(CUR_BUF_CFG(pipe));
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   return;
+   }
+
+   val = I915_READ(PLANE_CTL(pipe, plane_id));
+
+   /* No DDB allocated for disabled planes */
+   if (!(val & PLANE_CTL_ENABLE))
+   return;
+
+   pixel_format = val & PLANE_CTL_FORMAT_MASK;
+   fourcc = skl_format_to_fourcc(pixel_format,
+ val & PLANE_CTL_ORDER_RGBX,
+ val & PLANE_CTL_ALPHA_MASK);
+
+   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+   val2 = I915_READ(PLANE_NV12_BUF_CFG(pipe, plane_id));
+
+   if (fourcc == DRM_FORMAT_NV12) {
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val2);
+   skl_ddb_entry_init_from_hw(>uv_plane[pipe][plane_id], val);
+   } else {
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   }
+}
+
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */)
 {
@@ -3841,16 +3879,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
 
-   for_each_plane_id_on_crtc(crtc, plane_id) {
-   u32 val;
-
-   if (plane_id != PLANE_CURSOR)
-   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
-   else
-   val = I915_READ(CUR_BUF_CFG(pipe));
-
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], 
val);
-   }
+   for_each_plane_id_on_crtc(crtc, plane_id)
+   skl_ddb_get_hw_plane_state(dev_priv, pipe,
+  plane_id, ddb);
 
intel_display_power_put(dev_priv, power_domain);
}
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 08/17] drm/i915/skl+: nv12 workaround disable WM level 1-7

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.

v2: Addressed review comments by Maarten.

v3: Adding reviewed by tag from Shashank Sharma

Reviewed-by: Shashank Sharma 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_pm.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index efa3367..6476768 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4653,6 +4653,17 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
}
 
+   /*
+* Display WA #826 (SKL:ALL, BXT:ALL) & #1059 (CNL:A)
+* disable wm level 1-7 on NV12 planes
+*/
+   if (wp->is_planar && level >= 1 &&
+   (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
+IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))) {
+   result->plane_en = false;
+   return 0;
+   }
+
/* The number of lines are ignored for the level 0 watermark. */
result->plane_res_b = res_blocks;
result->plane_res_l = res_lines;
-- 
2.7.4

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


[Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

2018-03-09 Thread Vidya Srinivas
From: Chandra Konduru 

This patch updates scaler max limit support for NV12

v2: Rebased (me)

v3: Rebased (me)

v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series

v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Rebased (me)

v11: Addressed review comments from Shashank Sharma
Alignment issues fixed.
When call to skl_update_scaler is made, 0 was being
sent instead of pixel_format.
When crtc update scaler is called, we dont have the
fb to derive the pixel format. Added the function
parameter bool plane_scaler_check to account for this.

v12: Fixed failure in IGT debugfs_test.
fb is NULL in skl_update_scaler_plane
Due to this, accessing fb->format caused failure.
Patch checks fb before using.

v13: In the previous version there was a flaw.
In skl_update_scaler during plane_scaler_check
if the format was non-NV12, it would set need_scaling
to false. This could reset the previously set need_scaling
from a previous condition check. Patch fixes this.
Patch also adds minimum src height for YUV 420 formats
to 16 (as defined in BSpec) and adds for checking this
range.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Uma Shankar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 78 ++--
 drivers/gpu/drm/i915/intel_drv.h |  4 +-
 drivers/gpu/drm/i915/intel_sprite.c  |  3 +-
 3 files changed, 61 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 34f7225..7fd8354 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3466,6 +3466,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
case DRM_FORMAT_VYUY:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
+   case DRM_FORMAT_NV12:
+   return PLANE_CTL_FORMAT_NV12;
default:
MISSING_CASE(pixel_format);
}
@@ -4705,7 +4707,9 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
  unsigned int scaler_user, int *scaler_id,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h,
+ bool plane_scaler_check,
+ uint32_t pixel_format)
 {
struct intel_crtc_scaler_state *scaler_state =
_state->scaler_state;
@@ -4723,6 +4727,10 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
 
+   if (plane_scaler_check)
+   if (pixel_format == DRM_FORMAT_NV12)
+   need_scaling = true;
+
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
 
@@ -4763,17 +4771,32 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
}
 
/* range checks */
-   if (src_w < SKL_MIN_SRC_W || src_h < SKL_MIN_SRC_H ||
-   dst_w < SKL_MIN_DST_W || dst_h < SKL_MIN_DST_H ||
-
-   src_w > SKL_MAX_SRC_W || src_h > SKL_MAX_SRC_H ||
-   dst_w > SKL_MAX_DST_W || dst_h > SKL_MAX_DST_H) {
-   DRM_DEBUG_KMS("scaler_user index %u.%u: src %ux%u dst %ux%u "
-   "size is out of scaler range\n",
-   intel_crtc->pipe, scaler_user, src_w, src_h, dst_w, 
dst_h);
-   return -EINVAL;
-   }
-
+   if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12) {
+   if (src_h > SKL_MIN_YUV_420_SRC_H)
+   goto check_scaler_range;
+   else
+   goto failed_range;
+   } else {
+   if (src_h >= SKL_MIN_SRC_H)
+   goto check_scaler_range;
+   else
+   goto failed_range;
+   }
+check_scaler_range:
+   if (src_w >= SKL_MIN_SRC_W || dst_w >= SKL_MIN_DST_W ||
+   dst_h >= SKL_MIN_DST_H || src_w <= SKL_MAX_SRC_W ||
+   src_h <= SKL_MAX_SRC_H || dst_w <= SKL_MAX_DST_W ||
+   dst_h <= SKL_MAX_DST_H)
+   goto scaler_range_ok;
+

[Intel-gfx] [PATCH v13 02/17] drm/i915/skl+: refactor WM calculation for NV12

2018-03-09 Thread Vidya Srinivas
From: Mahesh Kumar 

Current code calculates DDB for planar formats in such a way that we
store DDB of plane-0 in plane 1 & vice-versa.
In order to make this clean this patch refactors WM/DDB calculation for
NV12 planar formats.

v2: Addressed review comments by Maarten

v3: Rebased and addressed review comments by Maarten

v4: Fixed a compilation issue of string replacement is_nv12 to
is_planar

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_drv.h  |   5 +-
 drivers/gpu/drm/i915/intel_drv.h |   1 +
 drivers/gpu/drm/i915/intel_pm.c  | 121 ---
 3 files changed, 66 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0775e33..5abbd04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1451,8 +1451,9 @@ static inline bool skl_ddb_entry_equal(const struct 
skl_ddb_entry *e1,
 }
 
 struct skl_ddb_allocation {
-   struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
packed/uv */
-   struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
+   /* packed/y */
+   struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
+   struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
 struct skl_ddb_values {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 75969ce..18930ad 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -599,6 +599,7 @@ struct intel_pipe_wm {
 struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level trans_wm;
+   bool is_planar;
 };
 
 struct skl_pipe_wm {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 797fe4d..31ef5c8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4009,9 +4009,9 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
*intel_crtc,
 static unsigned int
 skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
 const struct drm_plane_state *pstate,
-int y)
+const int plane)
 {
-   struct intel_plane *plane = to_intel_plane(pstate->plane);
+   struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
uint32_t data_rate;
uint32_t width = 0, height = 0;
@@ -4025,9 +4025,9 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
fb = pstate->fb;
format = fb->format->format;
 
-   if (plane->id == PLANE_CURSOR)
+   if (intel_plane->id == PLANE_CURSOR)
return 0;
-   if (y && format != DRM_FORMAT_NV12)
+   if (plane == 1 && format != DRM_FORMAT_NV12)
return 0;
 
/*
@@ -4038,19 +4038,14 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
width = drm_rect_width(_pstate->base.src) >> 16;
height = drm_rect_height(_pstate->base.src) >> 16;
 
-   /* for planar format */
-   if (format == DRM_FORMAT_NV12) {
-   if (y)  /* y-plane data rate */
-   data_rate = width * height *
-   fb->format->cpp[0];
-   else/* uv-plane data rate */
-   data_rate = (width / 2) * (height / 2) *
-   fb->format->cpp[1];
-   } else {
-   /* for packed formats */
-   data_rate = width * height * fb->format->cpp[0];
+   /* UV plane does 1/2 pixel sub-sampling */
+   if (plane == 1 && format == DRM_FORMAT_NV12) {
+   width /= 2;
+   height /= 2;
}
 
+   data_rate = width * height * fb->format->cpp[plane];
+
down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
 
return mul_round_up_u32_fixed16(data_rate, down_scale_amount);
@@ -4063,8 +4058,8 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
  */
 static unsigned int
 skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
-unsigned *plane_data_rate,
-unsigned *plane_y_data_rate)
+unsigned int *plane_data_rate,
+unsigned int *uv_plane_data_rate)
 {
struct drm_crtc_state *cstate = _cstate->base;
struct drm_atomic_state *state = cstate->state;
@@ -4080,17 +4075,17 @@ skl_get_total_relative_data_rate(struct 
intel_crtc_state *intel_cstate,
enum plane_id plane_id = to_intel_plane(plane)->id;
unsigned int rate;
 
-   /* packed/uv */
+   /* 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add NV12 support

2018-03-09 Thread Patchwork
== Series Details ==

Series: Add NV12 support
URL   : https://patchwork.freedesktop.org/series/39670/
State : failure

== Summary ==

Series 39670v1 Add NV12 support
https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/1/mbox/

 Possible new issues:

Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-kbl-7500u)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:511s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:495s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:483s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:473s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:402s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:409s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:0   fail:1   skip:24  
time:468s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:522s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:420s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:521s

469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC 
integration manifest
1339f9a5a27c drm/i915: Display WA 827
e2512797e0e9 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
e7310fb54287 drm/i915: Add NV12 support to intel_framebuffer_init
e2876f568d26 drm/i915: Add NV12 as supported format for sprite plane
d24eaa7f1235 drm/i915: Add NV12 as supported format for primary plane
c468bf338a68 drm/i915: Upscale scaler max scale for NV12
14093696ac0f drm/i915: Update format_is_yuv() to include NV12
b06a83b7a3e7 drm/i915: Set scaler mode for NV12
1a0fc9903d7b drm/i915/skl: split skl_compute_ddb function
a7269aacf906 drm/i915/skl+: nv12 workaround disable WM level 1-7
127974044799 drm/i915/skl+: make sure higher latency level has higher wm value
388a36b819e4 drm/i915/skl+: pass skl_wm_level struct to wm compute func
4fe6ee60c595 drm/i915/skl+: NV12 related changes for WM
febfc56105e3 drm/i915/skl+: support verification of DDB HW state for NV12
1e1f431f9e41 drm/i915/skl+: add NV12 in skl_format_to_fourcc
edc2fd014ea1 drm/i915/skl+: refactor WM calculation for NV12
c1e45b5d1766 drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8287/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove support for legacy debugfs crc interface (rev2)

2018-03-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove support for legacy debugfs crc interface (rev2)
URL   : https://patchwork.freedesktop.org/series/33053/
State : failure

== Summary ==

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> SKIP   (shard-apl)
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-snb)
Subgroup bad-nb-words-3:
pass   -> SKIP   (shard-apl)
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-snb)
Subgroup bad-pipe:
pass   -> SKIP   (shard-apl)
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-snb)
Test perf_pmu:
Subgroup multi-client-vcs0:
pass   -> FAIL   (shard-snb)

 Known issues:

Test drv_selftest:
Subgroup live_gtt:
pass   -> INCOMPLETE (shard-apl) fdo#103927
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-toggle:
pass   -> FAIL   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test perf_pmu:
Subgroup busy-start-vcs0:
fail   -> PASS   (shard-snb) fdo#105106

fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#105106 https://bugs.freedesktop.org/show_bug.cgi?id=105106

shard-apltotal:3445 pass:1798 dwarn:1   dfail:0   fail:9   skip:1635 
time:11698s
shard-hswtotal:3467 pass:1768 dwarn:1   dfail:0   fail:3   skip:1694 
time:11638s
shard-snbtotal:3467 pass:1359 dwarn:1   dfail:0   fail:3   skip:2104 
time:6893s
Blacklisted hosts:
shard-kbltotal:3381 pass:1895 dwarn:1   dfail:0   fail:9   skip:1475 
time:9040s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8276/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 00/42] drm/i915: Implement HDCP2.2

2018-03-09 Thread Daniel Vetter
On Thu, Mar 08, 2018 at 06:03:32PM +0530, Ramalingam C wrote:
> On Thursday 08 March 2018 06:00 PM, Winkler, Tomas wrote:
> > 
> > > -Original Message-
> > > From: C, Ramalingam
> > > Sent: Thursday, March 08, 2018 13:58
> > > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> > > seanp...@chromium.org; ch...@chris-wilson.co.uk; Winkler, Tomas
> > > ; jani.nik...@linux.intel.com
> > > Cc: Vivi, Rodrigo ; Sharma, Shashank
> > > ; Shankar, Uma ; C,
> > > Ramalingam 
> > > Subject: [PATCH v2 00/42] drm/i915: Implement HDCP2.2
> > > 
> > > Based on HDCP1.4 framework introduced by Sean Paul, this series
> > > implements the HDCP2.2 in I915.
> > I didn't see HDCP 1.4 framework being merged upstream? What tree is this 
> > based on?
> 
> This is based on drm-tip branch of https://cgit.freedesktop.org/drm-tip/

All the code also should be in linux-next. If it's not, then something
went wrong somewhere with the scripting.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

2018-03-09 Thread Tvrtko Ursulin


On 08/03/2018 18:46, Daniele Ceraolo Spurio wrote:

On 08/03/18 01:31, Tvrtko Ursulin wrote:


On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote:

The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're running
on in a consistent way.

Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_engine_cs.c  | 77 
+

  drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
  2 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c

index 4ba139c27fba..1dd92cac8d67 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,16 @@ static const struct engine_class_info 
intel_engine_classes[] = {

  },
  };
+#define MAX_MMIO_BASES 3
  struct engine_info {
  unsigned int hw_id;
  unsigned int uabi_id;
  u8 class;
  u8 instance;
-    u32 mmio_base;
+    struct engine_mmio_base {
+    u32 gen : 8;
+    u32 base : 24;
+    } mmio_bases[MAX_MMIO_BASES];
  unsigned irq_shift;
  };


It's not bad, but I am just wondering if it is too complicated versus 
simply duplicating the tables.


Duplicated tables would certainly be much less code and complexity, 
but what about the size of pure data?


In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES * 
sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times 
NUM_ENGINES equals 240 bytes for intel_engines[] array with this scheme.




we remove a u32 (the old mmio base) so we only grow 8 per engine, but 
the compiler rounds up to a multiple of u32 so 28 per engine, for a 
total of 224.



Separate tables per gens would be:

sizeof(struct engine_info) is 18 bytes.

For < gen6 we'd need 3 engines * 18 = 54
< gen11 = 5 engines * 18 = 90
 >= gen11 = 8 engines * 18 = 144

54 + 90 + 144 = 288 bytes

So a little bit bigger. Hm. Plus we would need to refactor so 
intel_engines[] is not indexed by engine->id but is contiguous array 
with engine->id in the elements. Code to lookup the compact array 
should be simpler than combined new code from this patch, especially 
if you add the test as Chris suggested. So separate engine info arrays 
would win I think overall - when considering size of text + size of 
data + size of source code.




Not sure. I would exclude the selftest, which is usually not compiled 
for released kernels, which leads to:


Yes, but we cannot exclude its source since selftests for separate 
tables wouldn't be needed.



add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93)
Function old new   delta
intel_engines    160 224 +64
__func__   13891   13910 +19
intel_engines_init_mmio 1247    1264 +17
intel_init_bsd_ring_buffer   142 135  -7
Total: Before=1479626, After=1479719, chg +0.01%

Total growth is 93, which is less then your estimation for the growth 
introduced by replicating the table.


But on the other hand your solution might be more future proof. So I 
don't know. Use the crystal ball to decide? :)




I think we should expect that the total engine count could grow with 
future gens. In this case to me adding a new entry to a unified table 
seems much cleaner (and uses less data) than adding a completely new 
table each time.


Okay I was off in my estimates. But in general I was coming from the 
angle of thinking that every new mmio base difference in this scheme 
grows the size for all engines. So if just VCS grows one new base, 
impact is multiplied by NUM_ENGINES. But maybe separate tables are also 
not a solution. Perhaps pulling out mmio_base arrays to outside struct 
engine_info in another set of static tables, so they could be null 
terminated would be best of both worlds?


struct engine_mmio_base {
u32 gen : 8;
u32 base : 24;
};

static const struct engine_mmio_base vcs0_mmio_bases[] = {
{ .gen = 11, .base = GEN11_BSD_RING_BASE },
{ .gen = 6, .base = GEN6_BSD_RING_BASE },
{ .gen = 4, .base = BSD_RING_BASE },
{ },
};

And then in intel_engines array, for BSD:

   {
...
.mmio_bases = _mmio_bases;
...
   },

This way we limit data growth only to engines which change their mmio 
bases frequently.


Just an idea.

Regards,

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


[Intel-gfx] [PATCH] drm/i915: Show GEM_TRACE when detecting a failed GPU idle

2018-03-09 Thread Chris Wilson
If we timeout waiting for the GPU to idle, something went seriously
wrong. We currently dump the engine state, but we can also dump the
ftrace buffer showing our last operations (when available).

In passing, note that since commit 559e040f1f08 ("drm/i915: Show the GPU
state when declaring wedged", we now show the engine state twice, once
in detecting the failed idle and then again on declaring wedged.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 11 +--
 drivers/gpu/drm/i915/i915_gem.h |  2 ++
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca53c9a0..8bd8cb7c198e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3657,16 +3657,7 @@ static int wait_for_engines(struct drm_i915_private 
*i915)
if (wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT)) {
dev_err(i915->drm.dev,
"Failed to idle engines, declaring wedged!\n");
-   if (drm_debug & DRM_UT_DRIVER) {
-   struct drm_printer p = drm_debug_printer(__func__);
-   struct intel_engine_cs *engine;
-   enum intel_engine_id id;
-
-   for_each_engine(engine, i915, id)
-   intel_engine_dump(engine, ,
- "%s\n", engine->name);
-   }
-
+   GEM_TRACE_DUMP();
i915_gem_set_wedged(i915);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index f54c4ff74ded..8fdaa08e7bfb 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -53,8 +53,10 @@
 
 #if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
 #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
+#define GEM_TRACE_DUMP() ftrace_dump()
 #else
 #define GEM_TRACE(...) do { } while (0)
+#define GEM_TRACE_DUMP() do { } while (0)
 #endif
 
 #define I915_NUM_ENGINES 8
-- 
2.16.2

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


[Intel-gfx] [PATCH v2] drm/i915: Show GEM_TRACE when detecting a failed GPU idle

2018-03-09 Thread Chris Wilson
If we timeout waiting for the GPU to idle, something went seriously
wrong. We currently dump the engine state, but we can also dump the
ftrace buffer showing our last operations (when available).

In passing, note that since commit 559e040f1f08 ("drm/i915: Show the GPU
state when declaring wedged", we now show the engine state twice, once
in detecting the failed idle and then again on declaring wedged.

v2: ftrace_dump() takes a parameter specifying whether to dump all cpu
buffers or the local cpu's.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 11 +--
 drivers/gpu/drm/i915/i915_gem.h |  2 ++
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca53c9a0..8bd8cb7c198e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3657,16 +3657,7 @@ static int wait_for_engines(struct drm_i915_private 
*i915)
if (wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT)) {
dev_err(i915->drm.dev,
"Failed to idle engines, declaring wedged!\n");
-   if (drm_debug & DRM_UT_DRIVER) {
-   struct drm_printer p = drm_debug_printer(__func__);
-   struct intel_engine_cs *engine;
-   enum intel_engine_id id;
-
-   for_each_engine(engine, i915, id)
-   intel_engine_dump(engine, ,
- "%s\n", engine->name);
-   }
-
+   GEM_TRACE_DUMP();
i915_gem_set_wedged(i915);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index f54c4ff74ded..8922344fc21b 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -53,8 +53,10 @@
 
 #if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
 #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
+#define GEM_TRACE_DUMP() ftrace_dump(DUMP_ALL)
 #else
 #define GEM_TRACE(...) do { } while (0)
+#define GEM_TRACE_DUMP() do { } while (0)
 #endif
 
 #define I915_NUM_ENGINES 8
-- 
2.16.2

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


Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

2018-03-09 Thread Tvrtko Ursulin


On 09/03/2018 13:46, Chris Wilson wrote:

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests
v3: Do an up/down ramp for individual freq request, check nothing
changes after each invalid request

Signed-off-by: Chris Wilson 
Cc: Paneri, Praveen 
Cc: Kamble, Sagar A 
Cc: Antonio Argenziano 
---
  tests/Makefile.am  |   1 +
  tests/Makefile.sources |   1 +
  tests/gem_ctx_freq.c   | 648 +
  tests/meson.build  |   1 +
  4 files changed, 651 insertions(+)
  create mode 100644 tests/gem_ctx_freq.c



[snip]


+static void check_invalid(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   const struct test {
+   uint32_t min, max;
+   } tests[] = {
+   { min - 50, max - 50 },
+   { min - 50, max },
+   { min - 50, max + 50 },
+   { min, max + 50 },
+   { min + 50, max + 50 },
+
+   { min - 50, min - 50 },
+
+   { min - 50, min },
+   { min + 50, min },
+   { min, min - 50 },
+
+   { max + 50, max },
+   { max, max + 50 },
+   { max, max - 50 },
+
+   { max + 50, max + 50 },


Is unprivileged "{ max, max }" allowed? In other words pin to max 
frequency by anyone? If so, what happens when all userspace learns about 
this and wants to use it just so to be lower latency than the other guy?


Or even on our integrated graphics, such userspace would unwisely take 
away power budget from the CPU. Or could it even harm itself by 
triggering too much thermal throttling and run slower than if it let the 
balance be controlled by the system?


Or will this be tied with the cgroup work to allow only clients allowed 
by sysadmin to do this?


Regards,

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


Re: [Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.

2018-03-09 Thread Maxime Ripard
On Fri, Mar 09, 2018 at 12:55:24PM +0100, Maarten Lankhorst wrote:
> Op 06-03-18 om 16:57 schreef Maxime Ripard:
> > Hi,
> >
> > On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote:
> >> Only try to set those values if the properties are supported.
> >> This fixes the kms_chameium tests to run on vc4 again.
> >>
> >> Reported-by: Maxime Ripard 
> >> Cc: Paul Kocialkowski 
> >> Cc: Eric Anholt 
> >> Cc: Boris Brezillon 
> >> Signed-off-by: Maarten Lankhorst 
> > This works like a charm now, thanks!
> > Tested-by: Maxime Ripard 
> >
> > Maxime
> >
> Can you upgrade this to a reviewed-by so I can apply this change?

Yep, of course:
Reviewed-by: Maxime Ripard 

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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


Re: [Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring

2018-03-09 Thread Chris Wilson
Quoting Mika Kuoppala (2018-03-09 13:38:37)
> Chris Wilson  writes:
> 
> > When wedged, we do not update the ring->tail as we submit the requests
> > causing us to leak the ring->space upon cleaning up the wedged driver.
> > We can just use the value stored in rq->tail, and keep the submission
> > backend details away from set-wedge.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/i915_request.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c 
> > b/drivers/gpu/drm/i915/i915_request.c
> > index efa9ee557f31..69b378a323fc 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -358,7 +358,7 @@ static void advance_ring(struct i915_request *request)
> >* is just about to be. Either works, if we miss the last two
> >* noops - they are safe to be replayed on a reset.
> >*/
> > - tail = READ_ONCE(request->ring->tail);
> > + tail = READ_ONCE(request->tail);
> 
> I tried to think if we need the READ_ONCE here anymore.

I tried as well to see if the comment was still correct. It still is due
to that we can retire before we see the context-switch interrupt.
 
> But as this is the safest version,
> Reviewed-by: Mika Kuoppala 
> 
> Noticed that request->tail is not cleared on i915_request_alloc.
> 
> If we would set rq->head = rq->tail = rq->ring->emit
> we could use rq->head == rq->tail to assert that
> we screw up something major during the request lifetime.

Heh, if we get a stray write here, we're going to get stray writes
everywhere :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

2018-03-09 Thread Chris Wilson
Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests
v3: Do an up/down ramp for individual freq request, check nothing
changes after each invalid request

Signed-off-by: Chris Wilson 
Cc: Paneri, Praveen 
Cc: Kamble, Sagar A 
Cc: Antonio Argenziano 
---
 tests/Makefile.am  |   1 +
 tests/Makefile.sources |   1 +
 tests/gem_ctx_freq.c   | 648 +
 tests/meson.build  |   1 +
 4 files changed, 651 insertions(+)
 create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be72..389f7fc7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4a81ac4a..3d079c42 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..f3cee838
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,648 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 7
+
+#define SAMPLE_PERIOD (USEC_PER_SEC / 10)
+
+static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   return __gem_context_set_param(fd, );
+}
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   igt_assert_eq(__set_freq(fd, ctx, min, max), 0);
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int period_us)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(period_us);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+#define N_STEPS 10
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+   igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset

2018-03-09 Thread Chris Wilson
Quoting Chris Wilson (2018-03-07 13:42:26)
> tasklet_kill() will spin waiting for the current tasklet to be executed.
> However, if tasklet_disable() has been called, then the tasklet is never
> executed but permanently put back onto the runlist until
> tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
> disable/enable pair. This is the case when we call set-wedge from inside
> i915_reset(), and another request was submitted to us concurrent to the
> reset.
> 
> Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3b44952e089f..e75af06904b7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
> *engine)
>  * Turning off the execlists->tasklet until the reset is over
>  * prevents the race.
>  */
> -   tasklet_kill(>execlists.tasklet);
> +   if (!atomic_read(>execlists.tasklet.count))
> +   tasklet_kill(>execlists.tasklet);

Note this is racy; two separate atomic operations. The only race we have
is with set-wedge vs reset, which is a rare and already contentious
issue. The upside of preventing the lockup is that we don't lose the
machine.

+* Note that this needs to be a single atomic operation on the
+* tasklet (flush existing tasks, prevent new tasks) to prevent
+* a race between reset and set-wedged. It is not, so we do the best
+* we can atm and make sure we don't lock the machine up in the more
+* common case of recursing calling set-wedged from inside i915_reset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register

2018-03-09 Thread Mahesh Kumar
This patch creates a new macro to get PORT_TX register for any given DW.
This will remove the need of defining register address for each port & DW.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_reg.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..30ef3513dc6f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1964,6 +1964,34 @@ enum i915_power_well_id {
_CNL_PORT_PCS_DW1_LN0_F)
 #define   COMMON_KEEPER_EN (1 << 26)
 
+/* CNL Port TX registers */
+#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340
+#define _CNL_PORT_TX_B_GRP_OFFSET  0x1623C0
+#define _CNL_PORT_TX_C_GRP_OFFSET  0x162B40
+#define _CNL_PORT_TX_D_GRP_OFFSET  0x162BC0
+#define _CNL_PORT_TX_F_GRP_OFFSET  0x162A40
+#define _CNL_PORT_TX_AE_LN0_OFFSET 0x162440
+#define _CNL_PORT_TX_B_LN0_OFFSET  0x162640
+#define _CNL_PORT_TX_C_LN0_OFFSET  0x162C40
+#define _CNL_PORT_TX_D_LN0_OFFSET  0x162E40
+#define _CNL_PORT_TX_F_LN0_OFFSET  0x162840
+#define CNL_PORT_TX_DW_GRP(port, dw)   (_PICK((port), \
+  _CNL_PORT_TX_AE_GRP_OFFSET, \
+  _CNL_PORT_TX_B_GRP_OFFSET, \
+  _CNL_PORT_TX_B_GRP_OFFSET, \
+  _CNL_PORT_TX_D_GRP_OFFSET, \
+  _CNL_PORT_TX_AE_GRP_OFFSET, \
+  _CNL_PORT_TX_F_GRP_OFFSET) + \
+  4*(dw))
+#define CNL_PORT_TX_DW_LN0(port, dw)   (_PICK((port), \
+  _CNL_PORT_TX_AE_LN0_OFFSET, \
+  _CNL_PORT_TX_B_LN0_OFFSET, \
+  _CNL_PORT_TX_B_LN0_OFFSET, \
+  _CNL_PORT_TX_D_LN0_OFFSET, \
+  _CNL_PORT_TX_AE_LN0_OFFSET, \
+  _CNL_PORT_TX_F_LN0_OFFSET) + \
+  4*(dw))
+
 #define _CNL_PORT_TX_DW2_GRP_AE0x162348
 #define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
 #define _CNL_PORT_TX_DW2_GRP_C 0x162B48
-- 
2.14.1

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


[Intel-gfx] [PATCH 0/3] CNL port refactoring

2018-03-09 Thread Mahesh Kumar
This series fixes CNL PORT_TX_DW5/7_LNO_D register address.
This series also introduces macros to get register address of
CNL_PORT_TX registers instead of defining for each DW instance.

changes since V1:
 completely kill _MMIO_PORT6 macro

Mahesh Kumar (3):
  drm/i915/cnl; Add macro to get PORT_TX register
  drm/i915/cnl: Replace PORT_TX register macros with new ones
  drm/i915/cnl: Kill _MMIO_PORT6 macro

 drivers/gpu/drm/i915/i915_reg.h | 147 
 1 file changed, 44 insertions(+), 103 deletions(-)

-- 
2.14.1

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


[Intel-gfx] [PATCH 2/3] drm/i915/cnl: Replace PORT_TX register macros with new ones

2018-03-09 Thread Mahesh Kumar
This patch replaces CNL_PORT_TX register macros with new macros defined
in previous patch.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_reg.h | 107 +---
 1 file changed, 11 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 30ef3513dc6f..7987a3f85d04 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1992,30 +1992,8 @@ enum i915_power_well_id {
   _CNL_PORT_TX_F_LN0_OFFSET) + \
   4*(dw))
 
-#define _CNL_PORT_TX_DW2_GRP_AE0x162348
-#define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
-#define _CNL_PORT_TX_DW2_GRP_C 0x162B48
-#define _CNL_PORT_TX_DW2_GRP_D 0x162BC8
-#define _CNL_PORT_TX_DW2_GRP_F 0x162A48
-#define _CNL_PORT_TX_DW2_LN0_AE0x162448
-#define _CNL_PORT_TX_DW2_LN0_B 0x162648
-#define _CNL_PORT_TX_DW2_LN0_C 0x162C48
-#define _CNL_PORT_TX_DW2_LN0_D 0x162E48
-#define _CNL_PORT_TX_DW2_LN0_F 0x162848
-#define CNL_PORT_TX_DW2_GRP(port)  _MMIO_PORT6(port, \
-   _CNL_PORT_TX_DW2_GRP_AE, \
-   _CNL_PORT_TX_DW2_GRP_B, \
-   _CNL_PORT_TX_DW2_GRP_C, \
-   _CNL_PORT_TX_DW2_GRP_D, \
-   _CNL_PORT_TX_DW2_GRP_AE, \
-   _CNL_PORT_TX_DW2_GRP_F)
-#define CNL_PORT_TX_DW2_LN0(port)  _MMIO_PORT6(port, \
-   _CNL_PORT_TX_DW2_LN0_AE, \
-   _CNL_PORT_TX_DW2_LN0_B, \
-   _CNL_PORT_TX_DW2_LN0_C, \
-   _CNL_PORT_TX_DW2_LN0_D, \
-   _CNL_PORT_TX_DW2_LN0_AE, \
-   _CNL_PORT_TX_DW2_LN0_F)
+#define CNL_PORT_TX_DW2_GRP(port)  _MMIO(CNL_PORT_TX_DW_GRP((port), 2))
+#define CNL_PORT_TX_DW2_LN0(port)  _MMIO(CNL_PORT_TX_DW_LN0((port), 2))
 #define   SWING_SEL_UPPER(x)   ((x >> 3) << 15)
 #define   SWING_SEL_UPPER_MASK (1 << 15)
 #define   SWING_SEL_LOWER(x)   ((x & 0x7) << 11)
@@ -2023,32 +2001,13 @@ enum i915_power_well_id {
 #define   RCOMP_SCALAR(x)  ((x) << 0)
 #define   RCOMP_SCALAR_MASK(0xFF << 0)
 
-#define _CNL_PORT_TX_DW4_GRP_AE0x162350
-#define _CNL_PORT_TX_DW4_GRP_B 0x1623D0
-#define _CNL_PORT_TX_DW4_GRP_C 0x162B50
-#define _CNL_PORT_TX_DW4_GRP_D 0x162BD0
-#define _CNL_PORT_TX_DW4_GRP_F 0x162A50
 #define _CNL_PORT_TX_DW4_LN0_AE0x162450
 #define _CNL_PORT_TX_DW4_LN1_AE0x1624D0
-#define _CNL_PORT_TX_DW4_LN0_B 0x162650
-#define _CNL_PORT_TX_DW4_LN0_C 0x162C50
-#define _CNL_PORT_TX_DW4_LN0_D 0x162E50
-#define _CNL_PORT_TX_DW4_LN0_F 0x162850
-#define CNL_PORT_TX_DW4_GRP(port)   _MMIO_PORT6(port, \
-   _CNL_PORT_TX_DW4_GRP_AE, \
-   _CNL_PORT_TX_DW4_GRP_B, \
-   _CNL_PORT_TX_DW4_GRP_C, \
-   _CNL_PORT_TX_DW4_GRP_D, \
-   _CNL_PORT_TX_DW4_GRP_AE, \
-   _CNL_PORT_TX_DW4_GRP_F)
-#define CNL_PORT_TX_DW4_LN(port, ln)   _MMIO_PORT6_LN(port, ln,\
-   _CNL_PORT_TX_DW4_LN0_AE, \
-   _CNL_PORT_TX_DW4_LN1_AE, \
-   _CNL_PORT_TX_DW4_LN0_B, \
-   _CNL_PORT_TX_DW4_LN0_C, \
-   _CNL_PORT_TX_DW4_LN0_D, \
-   _CNL_PORT_TX_DW4_LN0_AE, \
-   _CNL_PORT_TX_DW4_LN0_F)
+#define CNL_PORT_TX_DW4_GRP(port)  _MMIO(CNL_PORT_TX_DW_GRP((port), 4))
+#define CNL_PORT_TX_DW4_LN0(port)  _MMIO(CNL_PORT_TX_DW_LN0((port), 4))
+#define CNL_PORT_TX_DW4_LN(port, ln)   _MMIO(CNL_PORT_TX_DW_LN0((port), 4) + \
+(ln * (_CNL_PORT_TX_DW4_LN1_AE - \
+   _CNL_PORT_TX_DW4_LN0_AE)))
 #define   LOADGEN_SELECT   (1 << 31)
 #define   POST_CURSOR_1(x) ((x) << 12)
 #define   POST_CURSOR_1_MASK   (0x3F << 12)
@@ -2057,30 +2016,8 @@ enum 

  1   2   >