Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info

[Usyskin, Alexander]

> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, May 16, 2018 18:53
> To: Shankar, Uma ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas ;
> Usyskin, Alexander 
> Cc: Vivi, Rodrigo 
> Subject: Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP
> Pairing info
> 
> 
> 
> On Wednesday 09 May 2018 03:58 PM, Shankar, Uma wrote:
> >
> >> -Original Message-
> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> >> Behalf Of Ramalingam C
> >> Sent: Tuesday, April 3, 2018 7:27 PM
> >> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> >> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> >> jani.nik...@linux.intel.com; Winkler, Tomas
> >> ; Usyskin, Alexander
> >> 
> >> Cc: Vivi, Rodrigo 
> >> Subject: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP
> >> Pairing info
> >>
> >> Provides Pairing info to ME to store.
> >>
> >> Pairing is a process to fast track the subsequent authentication with
> >> the same HDCP sink.
> >>
> >> On Success, received HDCP pairing info is stored in non-volatile memory
> of ME.
> >>
> >> v2:
> >>   Rebased.
> >> v3:
> >>   cldev is passed as first parameter [Tomas]
> >>   Redundant comments and cast are removed [Tomas]
> >>
> >> Signed-off-by: Ramalingam C 
> >> ---
> >> drivers/misc/mei/hdcp/mei_hdcp.c | 61
> >> 
> >> include/linux/mei_hdcp.h | 10 +++
> >> 2 files changed, 71 insertions(+)
> >>
> >> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> index fa548310de7a..60afdd0cee79 100644
> >> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> @@ -244,6 +244,67 @@ int mei_verify_hprime(struct mei_cl_device
> >> *cldev, struct mei_hdcp_data *data,  }
> >> EXPORT_SYMBOL(mei_verify_hprime);
> >>
> >> +/**
> > Drop the extra *, unless you really love it :)
> ha ha. Actually I have added intentionally. But removing them across all
> patches as per your suggestions. :)

/** is a syntax for KDoc, so if you want to receive automatic code 
documentation you should use it and adhere to KDoc syntax
> >
> >> + * mei_store_pairing_info:
> >> + *Function to store pairing info received from panel
> >> + *
> >> + * @cldev : Pointer for mei client device
> >> + * @data  : Intel HW specific Data
> >> + * @pairing_info  : Pointer for AKE_Send_Pairing_Info
> >> + *
> >> + * Returns 0 on Success, <0 on Failure */
> >> +
> >> +int mei_store_pairing_info(struct mei_cl_device *cldev,
> >> + struct mei_hdcp_data *data,
> >> + struct hdcp2_ake_send_pairing_info *pairing_info)
> {
> >> +  struct wired_cmd_ake_send_pairing_info_in pairing_info_in = { { 0 }
> };
> >> +  struct wired_cmd_ake_send_pairing_info_out pairing_info_out = { {
> 0 } };
> >> +  struct device *dev;
> >> +  ssize_t byte;
> >> +
> >> +  if (!data || !pairing_info)
> >> +  return -EINVAL;
> >> +
> >> +  dev = >dev;
> >> +
> >> +  pairing_info_in.header.api_version = HDCP_API_VERSION;
> >> +  pairing_info_in.header.command_id =
> >> WIRED_AKE_SEND_PAIRING_INFO;
> >> +  pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
> >> +  pairing_info_in.header.buffer_len =
> >> +
> >>WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
> >> +
> >> +  pairing_info_in.port.integrated_port_type = data->port_type;
> >> +  pairing_info_in.port.physical_port = data->port;
> >> +
> >> +  memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> > Validate pairing_info->e_kh_km for NULL.
> As we discussed we need not check for null here.
> >
> >> + sizeof(pairing_info_in.e_kh_km));
> >> +
> >> +  byte = mei_cldev_send(cldev, (u8 *)_info_in,
> >> +sizeof(pairing_info_in));
> >> +  if (byte < 0) {
> >> +  dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
> >> +  return byte;
> >> +  }
> >> +
> >> +  byte = mei_cldev_recv(cldev, (u8 *)_info_out,
> >> +sizeof(pairing_info_out));
> >> +  if (byte < 0) {
> >> +  dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
> >> +  return byte;
> >> +  }
> >> +
> >> +  if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
> >> +  dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
> >> +  WIRED_AKE_SEND_PAIRING_INFO,
> >> +  pairing_info_out.header.status);
> >> +  return -1;
> >> +  }
> > Leave a blank line here.
> sure. I will do it in all patches. Thanks.
> 
> --Ram
> >
> >> +  return 0;
> >> +}
> >> 

Re: [Intel-gfx] [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[Usyskin, Alexander]

> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, May 16, 2018 18:20
> To: Usyskin, Alexander ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas 
> Cc: Vivi, Rodrigo 
> Subject: Re: [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx
> Session
> 
> 
> 
> On Wednesday 04 April 2018 12:15 PM, Usyskin, Alexander wrote:
> >
> >> -Original Message-
> >> From: C, Ramalingam
> >> Sent: Tuesday, April 03, 2018 16:57
> >> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> >> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> >> jani.nik...@linux.intel.com; Winkler, Tomas
> >> ; Usyskin, Alexander
> >> 
> >> Cc: Vivi, Rodrigo ; C, Ramalingam
> >> 
> >> Subject: [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx
> >> Session
> >>
> >> Request ME FW to start the HDCP2.2 session for a intel port.
> >> Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and
> sent
> >> to ME FW.
> >>
> >> On Success, ME FW will start a HDCP2.2 session for the port and
> >> provides the content for HDCP2.2 AKE_Init message.
> >>
> >> v2:
> >>Rebased.
> >> v3:
> >>cldev is add as a separate parameter [Tomas]
> >>Redundant comment and typecast are removed [Tomas]
> >>
> >> Signed-off-by: Ramalingam C 
> >> ---
> >>   drivers/misc/mei/hdcp/mei_hdcp.c | 68
> >> 
> >>   include/linux/mei_hdcp.h | 11 +++
> >>   2 files changed, 79 insertions(+)
> >>
> >> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> index 2811a25f8c57..7caee0947761 100644
> >> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> @@ -33,9 +33,77 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >> +
> >> +#include "mei_hdcp.h"
> >>
> >>   static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
> >>
> >> +/**
> >> + * mei_initiate_hdcp2_session:
> >> + *Function to start a Wired HDCP2.2 Tx Session with ME FW
> >> + *
> >> + * @cldev : Pointer for mei client device
> >> + * @data  : Intel HW specific Data
> >> + * @ake_data  : ptr to store AKE_Init
> >> + *
> >> + * Returns 0 on Success, <0 on Failure.
> >> + */
> >> +int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
> >> + struct mei_hdcp_data *data,
> >> + struct hdcp2_ake_init *ake_data) {
> >> +  struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0
> >> +}
> >> };
> >> +  struct wired_cmd_initiate_hdcp2_session_out
> >> +  session_init_out = { { 0 } };
> >> +  struct device *dev;
> >> +  ssize_t byte;
> >> +
> >> +  if (!data || !ake_data)
> >> +  return -EINVAL;
> >> +
> >> +  dev = >dev;
> >> +
> >> +  session_init_in.header.api_version = HDCP_API_VERSION;
> >> +  session_init_in.header.command_id =
> >> WIRED_INITIATE_HDCP2_SESSION;
> >> +  session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
> >> +  session_init_in.header.buffer_len =
> >> +
> >>WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
> >> +
> >> +  session_init_in.port.integrated_port_type = data->port_type;
> >> +  session_init_in.port.physical_port = data->port;
> >> +  session_init_in.protocol = (uint8_t)data->protocol;
> >> +
> >> +  byte = mei_cldev_send(cldev, (u8 *)_init_in,
> >> +sizeof(session_init_in));
> >> +  if (byte < 0) {
> >> +  dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
> > %zd don't require (int)
> Sure. Thanks
> >> +  return byte;
> >> +  }
> >> +
> >> +  byte = mei_cldev_recv(cldev, (u8 *)_init_out,
> >> +sizeof(session_init_out));
> >> +  if (byte < 0) {
> >> +  dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
> > %zd don't require (int)
> >> +  return byte;
> >> +  }
> >> +
> >> +  if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
> >> +  dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
> >> +  WIRED_INITIATE_HDCP2_SESSION,
> >> +  session_init_out.header.status);
> >> +  return -1;
> > It will be better to return some meaningful error code here.
> I dont think default error codes will match here. And at present other side
> I915 doesn't expect the reason but the failure state.
> May be we could do something like -(session_init_out.header.status). But
> error codes of ME FW is not known to I915.
> 
> So may be as of now lets keep it as some -ve return value -1?

-1 is -EPERM - that may confuse, better to use some neutral value, like -EIO

Re: [Intel-gfx] [PATCH v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev state change

[Usyskin, Alexander]

> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, May 16, 2018 16:05
> To: Usyskin, Alexander ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas 
> Cc: Vivi, Rodrigo 
> Subject: Re: [PATCH v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev
> state change
> 
> Thanks Alexander for the review. Sorry for the delay in addressing the review
> comments
> 
> 
> On Wednesday 04 April 2018 11:42 AM, Usyskin, Alexander wrote:
> >> -Original Message-
> >> From: C, Ramalingam
> >> Sent: Tuesday, April 03, 2018 16:57
> >> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> >> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> >> jani.nik...@linux.intel.com; Winkler, Tomas ;
> >> Usyskin, Alexander 
> >> Cc: Vivi, Rodrigo ; C, Ramalingam
> >> 
> >> Subject: [PATCH v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev
> state
> >> change
> >>
> >> Notifier Chain is defined to inform all its clients about the mei
> >> client device state change. Routine is defined for the clients to
> >> register and unregister for the notification on state change.
> >>
> >> v2:
> >>Rebased.
> >> v3:
> >>Notifier chain is adopted for cldev state update [Tomas]
> >>
> >> Signed-off-by: Ramalingam C 
> >> ---
> > May be I miss something, but bus subsystem already has notifier chain.
> (BUS_NOTIFY_ADD_DEVICE etc.)
> > We only ought to make mei_cl_bus_type available in header.
> We need re notification incase of binding of the mei device happened
> well before the I915 init.
> This is the case if I915 and MEI HDCP are build as modules and loaded in
> order.
> 
> So I prefer the separate notifier for mei_hdcp. Hope that is fine.
> 
> --Ram

Still miss the part how you design coupe with mei device loaded well before 
i915?
Can you explain?

> >
> >>   drivers/misc/mei/hdcp/mei_hdcp.c | 36
> +++---
> >>   include/linux/mei_hdcp.h | 48
> >> 
> >>   2 files changed, 81 insertions(+), 3 deletions(-)
> >>   create mode 100644 include/linux/mei_hdcp.h
> >>
> >> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> index b334615728a7..2811a25f8c57 100644
> >> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >> @@ -31,6 +31,32 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >> +#include 
> >> +
> >> +static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
> >> +
> >> +void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> >> enabled)
> >> +{
> >> +  if (enabled)
> >> +  blocking_notifier_call_chain(_cldev_notifier_list,
> >> +   MEI_CLDEV_ENABLED, cldev);
> >> +  else
> >> +  blocking_notifier_call_chain(_cldev_notifier_list,
> >> +   MEI_CLDEV_DISABLED, NULL);
> >> +}
> >> +
> >> +int mei_cldev_register_notify(struct notifier_block *nb)
> >> +{
> >> +  return blocking_notifier_chain_register(_cldev_notifier_list,
> >> nb);
> >> +}
> >> +EXPORT_SYMBOL_GPL(mei_cldev_register_notify);
> >> +
> >> +int mei_cldev_unregister_notify(struct notifier_block *nb)
> >> +{
> >> +  return blocking_notifier_chain_unregister(_cldev_notifier_list,
> >> nb);
> >> +}
> >> +EXPORT_SYMBOL_GPL(mei_cldev_unregister_notify);
> >>
> >>   static int mei_hdcp_probe(struct mei_cl_device *cldev,
> >>  const struct mei_cl_device_id *id)
> >> @@ -38,14 +64,18 @@ static int mei_hdcp_probe(struct mei_cl_device
> >> *cldev,
> >>int ret;
> >>
> >>ret = mei_cldev_enable(cldev);
> >> -  if (ret < 0)
> >> +  if (ret < 0) {
> >>dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
> >> +  return ret;
> >> +  }
> >>
> >> -  return ret;
> >> +  mei_cldev_state_notify_clients(cldev, true);
> >> +  return 0;
> >>   }
> >>
> >>   static int mei_hdcp_remove(struct mei_cl_device *cldev)
> >>   {
> >> +  mei_cldev_state_notify_clients(cldev, false);
> >>mei_cldev_set_drvdata(cldev, NULL);
> >>return mei_cldev_disable(cldev);
> >>   }
> >> @@ -71,4 +101,4 @@ module_mei_cl_driver(mei_hdcp_driver);
> >>
> >>   MODULE_AUTHOR("Intel Corporation");
> >>   MODULE_LICENSE("Dual BSD/GPL");
> >> -MODULE_DESCRIPTION("HDCP");
> >> +MODULE_DESCRIPTION("MEI HDCP");
> >> diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
> >> new file mode 100644
> >> index ..3b46bebde718
> >> --- /dev/null
> >> +++ b/include/linux/mei_hdcp.h
> >> @@ -0,0 +1,48 @@
> >> +/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
> >> +/*
> >> + * Copyright © 2017-2018 

Re: [Intel-gfx] [PATCH v4] gpu: drm: i915: Change return type to vm_fault_t

[Souptick Joarder]

On Thu, May 17, 2018 at 12:48 AM, Chris Wilson  wrote:
> Quoting Souptick Joarder (2018-05-16 20:12:20)
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are converted, vm_fault_t will become a distinct type.
>>
>> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>
>> Fixed one checkpatch.pl warning inside WARN_ONCE.
>>
>> Signed-off-by: Souptick Joarder 
>> ---
>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index dd89abd..732abdf 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
>>   * The current feature set supported by i915_gem_fault() and thus GTT mmaps
>>   * is exposed via I915_PARAM_MMAP_GTT_VERSION (see 
>> i915_gem_mmap_gtt_version).
>>   */
>> -int i915_gem_fault(struct vm_fault *vmf)
>> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>>  {
>>  #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
>> struct vm_area_struct *area = vmf->vma;
>> @@ -1894,7 +1894,8 @@ int i915_gem_fault(struct vm_fault *vmf)
>> struct i915_vma *vma;
>> pgoff_t page_offset;
>> unsigned int flags;
>> -   int ret;
>> +   int err;
>> +   vm_fault_t ret = VM_FAULT_SIGBUS;
>>
>> /* We don't use vmf->pgoff since that has the fake offset */
>> page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
>> @@ -2027,8 +2028,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>> ret = VM_FAULT_SIGBUS;
>> break;
>> default:
>> -   WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", 
>> ret);
>> -   ret = VM_FAULT_SIGBUS;
>> +   WARN_ONCE(ret, "unhandled error in %s: %x\n", __func__, err);
>> break;
>
> Even simpler would be to use e.g. return VM_FAULT_SIGBUS for each case
> above. No early initialisation of use-once variables allowing the
> compiler to do it's job. For a smaller patch, you can even skip the
> s/ret/err/
> -Chris

Chris,
I prefer to use return once at the end of the function rather than
writing multiple return statement (Current code is doing similar).
But if you think other way, I can make that change :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm-tip:drm-tip 711/734] drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct rcar_du_vsp_plane_state' has no member named 'alpha'

[Dave Airlie]

On 17 May 2018 at 14:42, Dave Airlie  wrote:
> On 16 May 2018 at 01:37, Laurent Pinchart
>  wrote:
>> Hello,
>>
>> On Tuesday, 15 May 2018 17:24:52 EEST kbuild test robot wrote:
>>> tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
>>> head:   c03987223c762e4a61142f0a9be6027bb181cdfa
>>> commit: 9037d4b98b255979c6636045794775f5a89cc623 [711/734] Merge branch
>>> 'drm/du/next' of git://linuxtv.org/pinchartl/media into drm-next config:
>>> arm64-defconfig (attached as .config)
>>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>>> reproduce:
>>> wget
>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
>>> ~/bin/make.cross chmod +x ~/bin/make.cross
>>> git checkout 9037d4b98b255979c6636045794775f5a89cc623
>>> # save the attached .config to linux build tree
>>> make.cross ARCH=arm64
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function
>> 'rcar_du_vsp_plane_atomic_duplicate_state':
>>> >> drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct
>>> >> rcar_du_vsp_plane_state' has no member named 'alpha'
>>>  copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
>>>  ^~
>>>drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:53: error: 'struct
>>> rcar_du_vsp_plane_state' has no member named 'alpha' copy->alpha =
>>> to_rcar_vsp_plane_state(plane->state)->alpha;
>>> ^~
>>
>> This error is caused by a conflict between commit 75a07f399cd4 (drm: rcar-du:
>> Zero-out sg_tables when duplicating plane state) present in my R-Car DU pull
>> request sent for the DRM tree and commit 301a9b8d5456 ("drm/rcar-du: Convert
>> to the new generic alpha property") present in drm-misc-next but not merged 
>> in
>> the drm tree yet.
>>
>> Dave, how would you like to handle this ? I can rebase my drm/du/next branch
>> on top of your tree once you merge drm-misc-next and send a new pull request,
>> but I'd like to avoid missing the v4.18 merge window. Another option would be
>> to handle the error in the drm-misc-next merge. If there's an easier option,
>> please let me know how I can help.
>>
>
> Is this broken in my tree now? since I seem to have both of these patches and 
> my
> local arm build succeeds.
>
> Is there a merge from somewhere else confusing things?

Turns out my arm64 builds weren't setup properly, I've fixed them up and can now
see builds failures.

I've applied both rcar-du fixes to drm-next.

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

[Intel-gfx] [PATCH] drm: Replace PRIu64 to llu to fix -Wformat compile warning on android

[jenny.q.cao]

replace PRIu64 to llu to fix -Wformat compile warning on android :
format specifies type 'unsigned long' but the argument has type
'__u64' (aka 'unsigned long long') [-Wformat]

Tests: compilation with warning clean
Signed-off-by: jenny cao 
---
 freedreno/msm/msm_ringbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/freedreno/msm/msm_ringbuffer.c b/freedreno/msm/msm_ringbuffer.c
index a87e1b9a26c0..f7ac7bcac4a2 100644
--- a/freedreno/msm/msm_ringbuffer.c
+++ b/freedreno/msm/msm_ringbuffer.c
@@ -385,7 +385,7 @@ static void dump_submit(struct msm_ringbuffer *msm_ring)
for (j = 0; j < cmd->nr_relocs; j++) {
struct drm_msm_gem_submit_reloc *r = [j];
ERROR_MSG("reloc[%d]: submit_offset=%u, or=%08x, 
shift=%d, reloc_idx=%u"
-   ", reloc_offset=%"PRIu64, j, 
r->submit_offset, r->or, r->shift,
+   ", reloc_offset=%llu", j, 
r->submit_offset, r->or, r->shift,
r->reloc_idx, r->reloc_offset);
}
}
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for gpu: drm: i915: Change return type to vm_fault_t (rev4)

[Patchwork]

== Series Details ==

Series: gpu: drm: i915: Change return type to vm_fault_t (rev4)
URL   : https://patchwork.freedesktop.org/series/41893/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193_full -> Patchwork_9023_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9023_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9023_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41893/revisions/4/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9023_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-bsd2:
  shard-kbl:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_9023_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_eio@in-flight-contexts-immediate:
  shard-hsw:  PASS -> DMESG-WARN (fdo#106523)

igt@gem_eio@in-flight-suspend:
  shard-glk:  PASS -> DMESG-WARN (fdo#106523)

igt@gem_eio@suspend:
  shard-apl:  PASS -> DMESG-WARN (fdo#106523) +1

igt@kms_cursor_crc@cursor-128x128-suspend:
  shard-snb:  PASS -> DMESG-WARN (fdo#102365)

igt@kms_flip@flip-vs-expired-vblank:
  shard-hsw:  PASS -> FAIL (fdo#105707)


 Possible fixes 

igt@gem_eio@execbuf:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS

igt@gem_eio@in-flight-internal-10ms:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +1

igt@gem_eio@in-flight-suspend:
  shard-snb:  DMESG-WARN (fdo#106523) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
  shard-glk:  FAIL (fdo#105454) -> PASS

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  FAIL (fdo#103822, fdo#104724) -> PASS +1


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9023

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9023: 17edb8f2e563eea240ac304b11939cbdf1dc397e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [drm-tip:drm-tip 711/734] drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct rcar_du_vsp_plane_state' has no member named 'alpha'

[Dave Airlie]

On 16 May 2018 at 01:37, Laurent Pinchart
 wrote:
> Hello,
>
> On Tuesday, 15 May 2018 17:24:52 EEST kbuild test robot wrote:
>> tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
>> head:   c03987223c762e4a61142f0a9be6027bb181cdfa
>> commit: 9037d4b98b255979c6636045794775f5a89cc623 [711/734] Merge branch
>> 'drm/du/next' of git://linuxtv.org/pinchartl/media into drm-next config:
>> arm64-defconfig (attached as .config)
>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> reproduce:
>> wget
>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
>> ~/bin/make.cross chmod +x ~/bin/make.cross
>> git checkout 9037d4b98b255979c6636045794775f5a89cc623
>> # save the attached .config to linux build tree
>> make.cross ARCH=arm64
>>
>> All errors (new ones prefixed by >>):
>>
>>drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function
> 'rcar_du_vsp_plane_atomic_duplicate_state':
>> >> drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct
>> >> rcar_du_vsp_plane_state' has no member named 'alpha'
>>  copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
>>  ^~
>>drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:53: error: 'struct
>> rcar_du_vsp_plane_state' has no member named 'alpha' copy->alpha =
>> to_rcar_vsp_plane_state(plane->state)->alpha;
>> ^~
>
> This error is caused by a conflict between commit 75a07f399cd4 (drm: rcar-du:
> Zero-out sg_tables when duplicating plane state) present in my R-Car DU pull
> request sent for the DRM tree and commit 301a9b8d5456 ("drm/rcar-du: Convert
> to the new generic alpha property") present in drm-misc-next but not merged in
> the drm tree yet.
>
> Dave, how would you like to handle this ? I can rebase my drm/du/next branch
> on top of your tree once you merge drm-misc-next and send a new pull request,
> but I'd like to avoid missing the v4.18 merge window. Another option would be
> to handle the error in the drm-misc-next merge. If there's an easier option,
> please let me know how I can help.
>

Is this broken in my tree now? since I seem to have both of these patches and my
local arm build succeeds.

Is there a merge from somewhere else confusing things?

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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/8] drm/i915: Remove tasklet flush before disable

[Chris Wilson]

Quoting Patchwork (2018-05-17 05:05:32)
> == Series Details ==
> 
> Series: series starting with [CI,1/8] drm/i915: Remove tasklet flush before 
> disable
> URL   : https://patchwork.freedesktop.org/series/43279/
> State : success
> 
> == Summary ==
> 
> = CI Bug Log - changes from CI_DRM_4193_full -> Patchwork_9022_full =
> 
> == Summary - WARNING ==
> 
>   Minor unknown changes coming with Patchwork_9022_full need to be verified
>   manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_9022_full, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   External URL: 
> https://patchwork.freedesktop.org/api/1.0/series/43279/revisions/1/mbox/
> 
> == Possible new issues ==
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_9022_full:
> 
>   === IGT changes ===
> 
>  Warnings 
> 
> igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-move:
>   shard-hsw:  PASS -> SKIP +1
> 
> 
> == Known issues ==
> 
>   Here are the changes found in Patchwork_9022_full that come from known 
> issues:
> 
>   === IGT changes ===
> 
>  Issues hit 
> 
> igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
>   shard-hsw:  PASS -> FAIL (fdo#102887)
> 
> igt@kms_flip@2x-plain-flip-fb-recreate:
>   shard-glk:  PASS -> FAIL (fdo#100368)
> 
> igt@kms_flip@dpms-vs-vblank-race-interruptible:
>   shard-hsw:  PASS -> FAIL (fdo#103060)
> 
> igt@kms_flip@modeset-vs-vblank-race:
>   shard-glk:  PASS -> FAIL (fdo#103060) +1
> 
> igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
>   shard-glk:  PASS -> FAIL (fdo#103167, fdo#104724)
> 
> 
>  Possible fixes 
> 
> igt@gem_eio@hibernate:
>   shard-hsw:  DMESG-WARN (fdo#106523) -> PASS +6
> 
> igt@gem_eio@in-flight-contexts-10ms:
>   shard-snb:  DMESG-WARN (fdo#106523) -> PASS +6
> 
> igt@gem_eio@in-flight-immediate:
>   shard-apl:  DMESG-WARN (fdo#106523) -> PASS +4
> 
> igt@gem_eio@in-flight-internal-immediate:
>   shard-glk:  DMESG-WARN (fdo#106523) -> PASS +6
> 
> igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
>   shard-glk:  FAIL (fdo#105703) -> PASS
> 
> igt@kms_flip@2x-plain-flip-ts-check-interruptible:
>   shard-glk:  FAIL (fdo#100368) -> PASS
> 
> igt@kms_flip@dpms-vs-vblank-race:
>   shard-hsw:  FAIL (fdo#103060) -> PASS
> 
> igt@kms_flip@flip-vs-expired-vblank:
>   shard-glk:  FAIL (fdo#105363) -> PASS
> 
> 
>   fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
>   fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
>   fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
>   fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
>   fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
>   fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
>   fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
>   fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523
> 
> 
> == Participating hosts (5 -> 4) ==
> 
>   Missing(1): shard-kbl 

Probably why CI was so happy... kbl has been sporadically failing this
series with a recovery failure in live_hangcheck, not one that's been
visible on a kbl locally. Oh well, maybe one step for 30 steps forward.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/8] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/8] drm/i915: Remove tasklet flush before 
disable
URL   : https://patchwork.freedesktop.org/series/43279/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193_full -> Patchwork_9022_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9022_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9022_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43279/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9022_full:

  === IGT changes ===

 Warnings 

igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-move:
  shard-hsw:  PASS -> SKIP +1


== Known issues ==

  Here are the changes found in Patchwork_9022_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#102887)

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@modeset-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060) +1

igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
  shard-glk:  PASS -> FAIL (fdo#103167, fdo#104724)


 Possible fixes 

igt@gem_eio@hibernate:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS +6

igt@gem_eio@in-flight-contexts-10ms:
  shard-snb:  DMESG-WARN (fdo#106523) -> PASS +6

igt@gem_eio@in-flight-immediate:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +4

igt@gem_eio@in-flight-internal-immediate:
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS +6

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#105363) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523


== Participating hosts (5 -> 4) ==

  Missing(1): shard-kbl 


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9022

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9022: 387525caae783f499df44a16617859be79befb2e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Link train Fallback on eDP only if fallback link BW can 
fit panel's native mode
URL   : https://patchwork.freedesktop.org/series/43291/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4193 -> Patchwork_9024 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9024 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9024, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43291/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9024:

  === IGT changes ===

 Possible regressions 

igt@drv_module_reload@basic-reload:
  fi-bwr-2160:PASS -> INCOMPLETE


 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9024 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_busy@basic-flip-c:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cfl-s3:  FAIL (fdo#103481) -> PASS +1

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS


  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951


== Participating hosts (41 -> 36) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9024

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9024: 8c9689628d5140ce7e4a8aeae922b4c306ed6c8f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

8c9689628d51 drm/i915/dp: Link train Fallback on eDP only if fallback link BW 
can fit panel's native mode

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Link train Fallback on eDP only if fallback link BW can 
fit panel's native mode
URL   : https://patchwork.freedesktop.org/series/43291/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8c9689628d51 drm/i915/dp: Link train Fallback on eDP only if fallback link BW 
can fit panel's native mode
-:59: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#59: FILE: drivers/gpu/drm/i915/intel_dp.c:416:
+
intel_dp->common_rates[index-1],

 ^

total: 0 errors, 0 warnings, 1 checks, 71 lines checked

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

[Intel-gfx] [PATCH] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode

[Manasi Navare]

This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp:
Do not do link training fallback or prune modes on EDP") that causes
a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350)
where first link training fails and a retraining is required by falling
back to lower link rate/lane count.
In case of some panels they advertise higher link rate/lane count
than whats required for supporting the panel's native mode.
But we always link train at highest link rate/lane count for eDP
and if that fails we can still fallback to lower link rate/lane count
as long as the fallback link BW still fits the native mode to avoid
pruning the panel's native mode yet retraining at fallback values
to recover from a blank screen.

Cc: Clinton Taylor 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Lucas De Marchi 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c   | 25 +
 drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +-
 2 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2cc58596..7f7202a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -387,6 +387,21 @@ static bool intel_dp_link_params_valid(struct intel_dp 
*intel_dp, int link_rate,
return true;
 }
 
+static bool intel_dp_can_link_train_fallback_for_edp(struct intel_dp *intel_dp,
+int link_rate,
+uint8_t lane_count)
+{
+   struct drm_display_mode *fixed_mode = 
intel_dp->attached_connector->panel.fixed_mode;
+   int mode_rate, max_rate;
+
+   mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
+   max_rate = intel_dp_max_data_rate(link_rate, lane_count);
+   if (mode_rate > max_rate)
+   return false;
+
+   return true;
+}
+
 int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
int link_rate, uint8_t lane_count)
 {
@@ -396,9 +411,19 @@ int intel_dp_get_link_train_fallback_values(struct 
intel_dp *intel_dp,
intel_dp->num_common_rates,
link_rate);
if (index > 0) {
+   if (intel_dp_is_edp(intel_dp) &&
+   !intel_dp_can_link_train_fallback_for_edp(intel_dp,
+
intel_dp->common_rates[index-1],
+ lane_count))
+   return -1;
intel_dp->max_link_rate = intel_dp->common_rates[index - 1];
intel_dp->max_link_lane_count = lane_count;
} else if (lane_count > 1) {
+   if (intel_dp_is_edp(intel_dp) &&
+   !intel_dp_can_link_train_fallback_for_edp(intel_dp,
+ 
intel_dp_max_common_rate(intel_dp),
+ lane_count >> 1))
+   return -1;
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->max_link_lane_count = lane_count >> 1;
} else {
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 3fcaa98..6673975 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -335,22 +335,14 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
return;
 
  failure_handling:
-   /* Dont fallback and prune modes if its eDP */
-   if (!intel_dp_is_edp(intel_dp)) {
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link 
rate = %d, lane count = %d",
- intel_connector->base.base.id,
- intel_connector->base.name,
- intel_dp->link_rate, intel_dp->lane_count);
-   if (!intel_dp_get_link_train_fallback_values(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);
-   } else {
-   DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate 
= %d, lane count = %d",
- intel_connector->base.base.id,
- intel_connector->base.name,
- intel_dp->link_rate, intel_dp->lane_count);
-   }
+   

[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/edp: Do not do link training fallback or prune modes 
on EDP"
URL   : https://patchwork.freedesktop.org/series/43278/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193_full -> Patchwork_9021_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9021_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9021_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43278/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9021_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-render:
  shard-kbl:  SKIP -> PASS

igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
  shard-snb:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_9021_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_eio@execbuf:
  shard-glk:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@in-flight-contexts-immediate:
  shard-hsw:  PASS -> DMESG-WARN (fdo#106523)

igt@gem_eio@suspend:
  shard-apl:  PASS -> DMESG-WARN (fdo#106523) +1

igt@kms_cursor_crc@cursor-64x64-suspend:
  shard-glk:  PASS -> INCOMPLETE (k.org#198133, fdo#103359)

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@2x-plain-flip-ts-check:
  shard-glk:  PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@gem_ctx_isolation@vecs0-s3:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@gem_eio@execbuf:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS
  shard-snb:  DMESG-WARN (fdo#106523) -> PASS

igt@gem_eio@wait-wedge-1us:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +1
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
  shard-glk:  FAIL (fdo#105454) -> PASS

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9021

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9021: 0b54952e8cb7b3bf9f4fe1ce697223e446573767 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9021/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/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Patchwork]

== Series Details ==

Series: drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
URL   : https://patchwork.freedesktop.org/series/43275/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193_full -> Patchwork_9020_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9020_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9020_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43275/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9020_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-render:
  shard-kbl:  SKIP -> PASS

igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
  shard-hsw:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_9020_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_eio@execbuf:
  shard-glk:  PASS -> DMESG-WARN (fdo#106523)

igt@gem_eio@in-flight-contexts-immediate:
  shard-hsw:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@in-flight-internal-10ms:
  shard-snb:  PASS -> DMESG-WARN (fdo#106523)

igt@gem_eio@suspend:
  shard-apl:  PASS -> DMESG-WARN (fdo#106523)

igt@kms_flip@2x-wf_vblank-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@modeset-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060) +1

igt@kms_flip@plain-flip-ts-check:
  shard-glk:  PASS -> FAIL (fdo#100368) +1

igt@kms_flip_tiling@flip-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103822)

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103167) +1


 Possible fixes 

igt@gem_eio@execbuf:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS

igt@gem_eio@in-flight-immediate:
  shard-snb:  DMESG-WARN (fdo#106523) -> PASS +1

igt@gem_eio@wait-wedge-1us:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  FAIL (fdo#104724, fdo#103822) -> PASS +1

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  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#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9020

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9020: 7ccc09d99ecac09bba1c3f9247a5511a2872d96f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9020/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 series starting with [CI,1/5] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/5] drm/i915: Remove tasklet flush before 
disable
URL   : https://patchwork.freedesktop.org/series/43267/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193_full -> Patchwork_9019_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9019_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9019_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43267/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9019_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-render:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9019_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_eio@in-flight-1us:
  shard-glk:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@in-flight-contexts-immediate:
  shard-hsw:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@suspend:
  shard-apl:  PASS -> DMESG-WARN (fdo#106523)

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  PASS -> FAIL (fdo#105703)

igt@kms_flip@plain-flip-ts-check:
  shard-glk:  PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@gem_eio@execbuf:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS

igt@gem_eio@in-flight-10ms:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS

igt@gem_eio@wait-wedge-1us:
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
  shard-glk:  FAIL (fdo#105454) -> PASS

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  FAIL (fdo#104724, fdo#103822) -> PASS

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9019

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9019: eb6601687e0855569aeca42b8138a4ce14a7f031 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/icl: Read the correct Gen11 interrupt registers

[Paulo Zanoni]

Em Qui, 2018-05-10 às 14:59 -0700, Oscar Mateo escreveu:
> Stop reading some now deprecated interrupt registers in both
> debugfs and error state. Instead, read the new equivalents in the
> Gen11 interrupt repartitioning scheme.
> 
> Note that the equivalent to the PM ISR & IIR cannot be read without
> affecting the current state of the system, so I've opted for leaving
> them out. See gen11_service_one_iir() for more info.

I can't find this function. Did you mean something else?



> 
> v2: else if !!! (Paulo)
> v3: another else if (Vinay)
> v4:
>   - Rebased
>   - Renamed patch
>   - Improved the ordering of GENs
>   - Improved the printing of per-GEN info
> v5: Avoid maybe-unitialized & add comment explaining the lack
> of PM ISR & IIR
> 
> Suggested-by: Paulo Zanoni 
> Signed-off-by: Oscar Mateo 
> Cc: Tvrtko Ursulin 
> Cc: Daniele Ceraolo Spurio 
> Cc: Sagar Arun Kamble 
> Cc: Vinay Belgaumkar 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   | 34 -
> -
>  drivers/gpu/drm/i915/i915_gpu_error.c | 11 ++-
>  drivers/gpu/drm/i915/i915_gpu_error.h |  2 +-
>  3 files changed, 35 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d663a9e0..d992dd2 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1170,19 +1170,28 @@ static int i915_frequency_info(struct
> seq_file *m, void *unused)
>  
>   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
>  
> - if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv)) {
> - pm_ier = I915_READ(GEN6_PMIER);
> - pm_imr = I915_READ(GEN6_PMIMR);
> - pm_isr = I915_READ(GEN6_PMISR);
> - pm_iir = I915_READ(GEN6_PMIIR);
> - pm_mask = I915_READ(GEN6_PMINTRMSK);
> - } else {
> + if (INTEL_GEN(dev_priv) >= 11) {
> + pm_ier =
> I915_READ(GEN11_GPM_WGBOXPERF_INTR_ENABLE);
> + pm_imr =
> I915_READ(GEN11_GPM_WGBOXPERF_INTR_MASK);
> + /*
> +  * The equivalent to the PM ISR & IIR cannot
> be read
> +  * without affecting the current state of
> the system
> +  */
> + pm_isr = 0;
> + pm_iir = 0;
> + } else if (INTEL_GEN(dev_priv) >= 8) {
>   pm_ier = I915_READ(GEN8_GT_IER(2));
>   pm_imr = I915_READ(GEN8_GT_IMR(2));
>   pm_isr = I915_READ(GEN8_GT_ISR(2));
>   pm_iir = I915_READ(GEN8_GT_IIR(2));
> - pm_mask = I915_READ(GEN6_PMINTRMSK);
> + } else {
> + pm_ier = I915_READ(GEN6_PMIER);
> + pm_imr = I915_READ(GEN6_PMIMR);
> + pm_isr = I915_READ(GEN6_PMISR);
> + pm_iir = I915_READ(GEN6_PMIIR);
>   }
> + pm_mask = I915_READ(GEN6_PMINTRMSK);
> +
>   seq_printf(m, "Video Turbo Mode: %s\n",
>  yesno(rpmodectl & GEN6_RP_MEDIA_TURBO));
>   seq_printf(m, "HW control enabled: %s\n",
> @@ -1190,8 +1199,13 @@ static int i915_frequency_info(struct seq_file
> *m, void *unused)
>   seq_printf(m, "SW control enabled: %s\n",
>  yesno((rpmodectl &
> GEN6_RP_MEDIA_MODE_MASK) ==
> GEN6_RP_MEDIA_SW_MODE));
> - seq_printf(m, "PM IER=0x%08x IMR=0x%08x ISR=0x%08x
> IIR=0x%08x, MASK=0x%08x\n",
> -pm_ier, pm_imr, pm_isr, pm_iir, pm_mask);
> +
> + seq_printf(m, "PM IER=0x%08x IMR=0x%08x,
> MASK=0x%08x\n",
> +pm_ier, pm_imr, pm_mask);
> + if (INTEL_GEN(dev_priv) < 11) {
> + seq_printf(m, "PM ISR=0x%08x IIR=0x%08x\n",
> +pm_isr, pm_iir);
> + }
>   seq_printf(m, "pm_intrmsk_mbz: 0x%08x\n",
>  rps->pm_intrmsk_mbz);
>   seq_printf(m, "GT_PERF_STATUS: 0x%08x\n",
> gt_perf_status);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index b98cd44..d9f2f69 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1675,7 +1675,16 @@ static void capture_reg_state(struct
> i915_gpu_state *error)
>   }
>  
>   /* 4: Everything else */
> - if (INTEL_GEN(dev_priv) >= 8) {
> + if (INTEL_GEN(dev_priv) >= 11) {
> + error->ier = I915_READ(GEN8_DE_MISC_IER);
> + error->gtier[0] =
> I915_READ(GEN11_RENDER_COPY_INTR_ENABLE);
> + error->gtier[1] =
> 

Re: [Intel-gfx] [PATCH] Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."

[Dhinakaran Pandiyan]

On Wed, 2018-05-16 at 11:01 +0300, Jani Nikula wrote:
> This reverts commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e.
> 
> Per the report, no matter what display mode you select with xrandr,
> the
> i915 driver will always select the alternate fixed mode. For the
> reporter this means that the display will always run at 40Hz which is
> quite annoying. This may be due to the mode comparison.
> 
> But there are some other potential issues. The choice of
> alt_fixed_mode
> seems dubious. It's the first non-preferred mode, but there are no
> guarantees that the only difference would be refresh rate. Similarly,
> there may be more than one preferred mode in the probed modes list,
> and
> the commit changes the preferred mode selection to choose the last
> one
> on the list instead of the first.
> 
> (Note that the probed modes list is the raw, unfiltered, unsorted
> list
> of modes from drm_add_edid_modes(), not the pretty result after a
> drm_helper_probe_single_connector_modes() call.)
> 
> Finally, we already have eerily similar code in place to find the
> downclock mode for DRRS that seems like could be reused here.
> 
> Back to the drawing board.
> 
> Note: This is a hand-crafted revert due to conflicts. If it fails to
> backport, please just try reverting the original commit directly.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105469
> Reported-by: Rune Petersen 
> Reported-by: Mark Spencer 
> Fixes: dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for
> eDP if available.")
> Cc: Clint Taylor 
> Cc: David Weinehall 
> Cc: Rodrigo Vivi 
> Cc: Paulo Zanoni 
> Cc: Jani Nikula 
> Cc: Chris Wilson 
> Cc: Jim Bride 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: intel-gfx@lists.freedesktop.org
> Cc:  # v4.14+
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c| 38 +---
> --
>  drivers/gpu/drm/i915/intel_drv.h   |  2 --
>  drivers/gpu/drm/i915/intel_dsi.c   |  2 +-
>  drivers/gpu/drm/i915/intel_dvo.c   |  2 +-
>  drivers/gpu/drm/i915/intel_lvds.c  |  3 +--
>  drivers/gpu/drm/i915/intel_panel.c |  6 --
>  6 files changed, 8 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..8320f0e8e3be 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1679,23 +1679,6 @@ static int intel_dp_compute_bpp(struct
> intel_dp *intel_dp,
>   return bpp;
>  }
>  
> -static bool intel_edp_compare_alt_mode(struct drm_display_mode *m1,
> -    struct drm_display_mode *m2)
> -{
> - bool bres = false;
> -
> - if (m1 && m2)
> - bres = (m1->hdisplay == m2->hdisplay &&
> - m1->hsync_start == m2->hsync_start &&
> - m1->hsync_end == m2->hsync_end &&
> - m1->htotal == m2->htotal &&
> - m1->vdisplay == m2->vdisplay &&
> - m1->vsync_start == m2->vsync_start &&
> - m1->vsync_end == m2->vsync_end &&
> - m1->vtotal == m2->vtotal);
> - return bres;
> -}
> -
>  /* Adjust link config limits based on compliance test requests. */
>  static void
>  intel_dp_adjust_compliance_config(struct intel_dp *intel_dp,
> @@ -1860,16 +1843,8 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   pipe_config->has_audio = intel_conn_state-
> >force_audio == HDMI_AUDIO_ON;
>  
>   if (intel_dp_is_edp(intel_dp) && intel_connector-
> >panel.fixed_mode) {
> - struct drm_display_mode *panel_mode =
> - intel_connector->panel.alt_fixed_mode;
> - struct drm_display_mode *req_mode = _config-
> >base.mode;
> -
> - if (!intel_edp_compare_alt_mode(req_mode,
> panel_mode))
> - panel_mode = intel_connector-
> >panel.fixed_mode;
> -
> - drm_mode_debug_printmodeline(panel_mode);
> -
> - intel_fixed_panel_mode(panel_mode, adjusted_mode);
> + intel_fixed_panel_mode(intel_connector-
> >panel.fixed_mode,
> +    adjusted_mode);
>  
>   if (INTEL_GEN(dev_priv) >= 9) {
>   int ret;
> @@ -6159,7 +6134,6 @@ static bool intel_edp_init_connector(struct
> intel_dp *intel_dp,
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct drm_connector *connector = _connector->base;
>   struct drm_display_mode *fixed_mode = NULL;
> - struct drm_display_mode *alt_fixed_mode = NULL;
>   struct drm_display_mode *downclock_mode = NULL;
>  

Re: [Intel-gfx] [PATCH] drm/i915/psr: Nuke PSR support for VLV and CHV

[Souza, Jose]

On Fri, 2018-05-11 at 16:00 -0700, Dhinakaran Pandiyan wrote:
> PSR hardware and hence the driver code for VLV and CHV deviates a lot
> from
> their DDI counterparts. While the feature has been disabled for a
> long time
> now, retaining support for these platforms is a maintenance burden.
> There
> have been multiple refactoring commits to just keep the existing code
> for
> these platforms in line with the rest. There are known issues that
> need to
> be fixed to enable PSR on these platforms, and there is no PSR
> capable
> platform in CI to ensure the code does not break again if we get
> around to
> fixing the existing issues. On account of all these reasons, let's
> nuke
> this code for now and bring it back if a need arises in the future.
> 
> Cc: Jani Nikula 
> Cc: Rodrigo Vivi 
> Cc: Ville Syrjälä 

Reviewed-by: José Roberto de Souza 

Really happy to see and review this patch :D


> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |  42 +-
>  drivers/gpu/drm/i915/i915_drv.h  |   1 -
>  drivers/gpu/drm/i915/i915_pci.c  |   2 -
>  drivers/gpu/drm/i915/intel_drv.h |   2 -
>  drivers/gpu/drm/i915/intel_frontbuffer.c |   2 -
>  drivers/gpu/drm/i915/intel_psr.c | 248 +++
> 
>  6 files changed, 27 insertions(+), 270 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 13e7b9e4a6e6..0096e209fe04 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2630,8 +2630,6 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m-
> >private);
>   u32 psrperf = 0;
> - u32 stat[3];
> - enum pipe pipe;
>   bool enabled = false;
>   bool sink_support;
>  
> @@ -2652,47 +2650,17 @@ static int i915_edp_psr_status(struct
> seq_file *m, void *data)
>   seq_printf(m, "Re-enable work scheduled: %s\n",
>  yesno(work_busy(_priv->psr.work.work)));
>  
> - if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.psr2_enabled)
> - enabled = I915_READ(EDP_PSR2_CTL) &
> EDP_PSR2_ENABLE;
> - else
> - enabled = I915_READ(EDP_PSR_CTL) &
> EDP_PSR_ENABLE;
> - } else {
> - for_each_pipe(dev_priv, pipe) {
> - enum transcoder cpu_transcoder =
> - intel_pipe_to_cpu_transcoder(dev_pri
> v, pipe);
> - enum intel_display_power_domain
> power_domain;
> -
> - power_domain =
> POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> - if
> (!intel_display_power_get_if_enabled(dev_priv,
> - powe
> r_domain))
> - continue;
> -
> - stat[pipe] = I915_READ(VLV_PSRSTAT(pipe)) &
> - VLV_EDP_PSR_CURR_STATE_MASK;
> - if ((stat[pipe] ==
> VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
> - (stat[pipe] ==
> VLV_EDP_PSR_ACTIVE_SF_UPDATE))
> - enabled = true;
> -
> - intel_display_power_put(dev_priv,
> power_domain);
> - }
> - }
> + if (dev_priv->psr.psr2_enabled)
> + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> + else
> + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
>  
>   seq_printf(m, "Main link in standby mode: %s\n",
>  yesno(dev_priv->psr.link_standby));
>  
> - seq_printf(m, "HW Enabled & Active bit: %s",
> yesno(enabled));
> -
> - if (!HAS_DDI(dev_priv))
> - for_each_pipe(dev_priv, pipe) {
> - if ((stat[pipe] ==
> VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
> - (stat[pipe] ==
> VLV_EDP_PSR_ACTIVE_SF_UPDATE))
> - seq_printf(m, " pipe %c",
> pipe_name(pipe));
> - }
> - seq_puts(m, "\n");
> + seq_printf(m, "HW Enabled & Active bit: %s\n",
> yesno(enabled));
>  
>   /*
> -  * VLV/CHV PSR has no kind of performance counter
>* SKL+ Perf counter is reset to 0 everytime DC state is
> entered
>*/
>   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 57fb3aa09db0..7e2a400d33c3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -607,7 +607,6 @@ struct i915_psr {
>   bool link_standby;
>   bool colorimetry_support;
>   bool alpm;
> - bool has_hw_tracking;
>   bool psr2_enabled;
>   u8 sink_sync_latency;
>   bool debug;
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/7] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm/i915: Remove tasklet flush before disable
URL   : https://patchwork.freedesktop.org/series/43266/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4192_full -> Patchwork_9018_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9018_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9018_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43266/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9018_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd1:
  shard-kbl:  SKIP -> PASS

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  PASS -> SKIP +2


== Known issues ==

  Here are the changes found in Patchwork_9018_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_suspend@sysfs-reader:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
  shard-glk:  PASS -> FAIL (fdo#105454, fdo#106509)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#102887, fdo#105363)

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724)

igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
  shard-glk:  PASS -> FAIL (fdo#103167, fdo#104724)

igt@perf@polling:
  shard-hsw:  PASS -> FAIL (fdo#102252)


 Possible fixes 

igt@gem_eio@execbuf:
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS +7

igt@gem_eio@in-flight-contexts-10ms:
  shard-snb:  DMESG-WARN (fdo#106523) -> PASS +5

igt@gem_eio@in-flight-contexts-immediate:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS +7

igt@gem_eio@in-flight-immediate:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +6

igt@gem_eio@in-flight-suspend:
  shard-kbl:  DMESG-WARN (fdo#106523) -> PASS +16

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_flip@2x-plain-flip-ts-check:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#105707) -> PASS

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  FAIL (fdo#104724) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS
  shard-kbl:  FAIL (fdo#99912) -> PASS

igt@kms_vblank@pipe-c-wait-busy:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103558) -> PASS +2


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4192 -> Patchwork_9018

  CI_DRM_4192: 302c1fbc4ca78140f408775ae39d32fc83ef0d41 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9018: 7514a35d14f296206d24a9fefe58d0dcb103a4de @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9018/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: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Manasi Navare]

On Wed, May 16, 2018 at 03:31:52PM -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-05-16 at 09:33 -0700, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood 
> > 
> > According to DP spec (2.9.3.1 of DP 1.4) if
> > EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
> > DPCD
> > 02200h through 0220Fh shall contain the DPRX's true capability. These
> > values will match 0h through Fh, except for DPCD_REV,
> > MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> > 
> > Read from DPCD once for all 3 values as this is an expensive
> > operation.
> > Spec mentions that all of address space 02200h through 0220Fh should
> > contain the right information however currently only 3 values can
> > differ.
> > 
> > There is no address space in the intel_dp->dpcd struct for addresses
> > 02200h through 0220Fh, and since so much of the data is a identical,
> > simply overwrite the values stored in 0h through Fh with the
> > values that can be overwritten from addresses 02200h through 0220Fh
> 
> Why overwrite all values if this is an expensive operation? From what I
> can see, you'll need to read only h - 5h
> 
> > 
> > Signed-off-by: Matt Atwood 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 14 ++
> >  include/drm/drm_dp_helper.h |  5 +++--
> >  2 files changed, 17 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index dde92e4af5d3..899ebc5cece6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3738,6 +3738,20 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
> >      sizeof(intel_dp->dpcd)) < 0)
> >     return false; /* aux transfer failed */
> >  
> > +   if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > +   DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT &&
> > +   intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14) {
> 
> The same section in the spec also says - "The Extended Receiver
> Capability registers at DPCD Addresses 02200h through 0220Fh shall
> contain the DPRX’s true capability, while the original Base Receiver
> Capability registers at DPCD Addresses 0h through Fh might
> indicate DPCD r1.1, a MAX_LINK_RATE of 2.7Gbps/lane, and no DFP to
> avoid interoperability issues ..."
> 
> Which means, intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14 is probably
> not going to be true for panels you want to read the extended
> capabilities for.

Yes thats a good point. So just check on the 
EXTENDED_EXTENDED_RECEIVER_CAP_FIELD_PRESENT
should suffice.
 
> 
> > +   uint8_t dpcd_ext[16];
> > +
> > +   if (drm_dp_dpcd_read(_dp->aux,
> > DP_DP13_DPCD_REV,
> > +   _ext, sizeof(dpcd_ext)) < 0)
> > +   return false; /* aux transfer failed */
> > +
> > +   intel_dp->dpcd[DP_DPCD_REV] = dpcd_ext[DP_DPCD_REV];
> > +   intel_dp->dpcd[DP_MAX_LINK_RATE] =
> > dpcd_ext[DP_MAX_LINK_RATE];
> > +   intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] =
> > +   dpcd_ext[DP_DOWNSTREAMPORT_PRESENT];
> > +   }
> >     DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> > intel_dp->dpcd);
> >  
> >     return intel_dp->dpcd[DP_DPCD_REV] != 0;
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index c01564991a9f..757bd5913f3d 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> 
> This should be a separate patch as it's outside i915.

And also send this patch to dri-devel M-L

Manasi

> 
> > @@ -123,8 +123,9 @@
> >  # define DP_FRAMING_CHANGE_CAP (1 << 1)
> >  # 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/* XXX 1.2? */
> > +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2?
> > */
> > +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2?
> > */
> > +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* XXX 1.2?
> > */
> >  
> >  #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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/4] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915: Remove tasklet flush before 
disable
URL   : https://patchwork.freedesktop.org/series/43265/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4192_full -> Patchwork_9017_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9017_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9017_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43265/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9017_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  PASS -> SKIP +1


== Known issues ==

  Here are the changes found in Patchwork_9017_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_suspend@sysfs-reader:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@gem_eio@execbuf:
  shard-snb:  PASS -> DMESG-WARN (fdo#106523)

igt@gem_eio@in-flight-1us:
  shard-hsw:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@in-flight-contexts-immediate:
  shard-glk:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@in-flight-suspend:
  shard-apl:  PASS -> DMESG-WARN (fdo#106523) +3

igt@kms_atomic_transition@plane-primary-toggle-with-vblank-wait:
  shard-apl:  PASS -> DMESG-WARN (fdo#105602, fdo#103558) +18

igt@kms_flip@2x-blocking-wf_vblank:
  shard-glk:  PASS -> FAIL (fdo#100368) +1

igt@kms_flip@2x-dpms-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103822)


 Possible fixes 

igt@gem_eio@execbuf:
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS +1

igt@gem_eio@suspend:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +2

igt@gem_eio@wait-wedge-1us:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS +1

igt@kms_flip@2x-plain-flip-ts-check:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#105707) -> PASS

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  FAIL (fdo#104724) -> PASS

igt@kms_vblank@pipe-c-wait-busy:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103558) -> PASS +2


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4192 -> Patchwork_9017

  CI_DRM_4192: 302c1fbc4ca78140f408775ae39d32fc83ef0d41 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9017: 7669ce457042d7dce4273c7af7f918d950ce6943 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9017/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: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Dhinakaran Pandiyan]

On Wed, 2018-05-16 at 09:33 -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
> DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values will match 0h through Fh, except for DPCD_REV,
> MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> 
> Read from DPCD once for all 3 values as this is an expensive
> operation.
> Spec mentions that all of address space 02200h through 0220Fh should
> contain the right information however currently only 3 values can
> differ.
> 
> There is no address space in the intel_dp->dpcd struct for addresses
> 02200h through 0220Fh, and since so much of the data is a identical,
> simply overwrite the values stored in 0h through Fh with the
> values that can be overwritten from addresses 02200h through 0220Fh

Why overwrite all values if this is an expensive operation? From what I
can see, you'll need to read only h - 5h

> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 14 ++
>  include/drm/drm_dp_helper.h |  5 +++--
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..899ebc5cece6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3738,6 +3738,20 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
>    sizeof(intel_dp->dpcd)) < 0)
>   return false; /* aux transfer failed */
>  
> + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT &&
> + intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14) {

The same section in the spec also says - "The Extended Receiver
Capability registers at DPCD Addresses 02200h through 0220Fh shall
contain the DPRX’s true capability, while the original Base Receiver
Capability registers at DPCD Addresses 0h through Fh might
indicate DPCD r1.1, a MAX_LINK_RATE of 2.7Gbps/lane, and no DFP to
avoid interoperability issues ..."

Which means, intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14 is probably
not going to be true for panels you want to read the extended
capabilities for. 

> + uint8_t dpcd_ext[16];
> +
> + if (drm_dp_dpcd_read(_dp->aux,
> DP_DP13_DPCD_REV,
> + _ext, sizeof(dpcd_ext)) < 0)
> + return false; /* aux transfer failed */
> +
> + intel_dp->dpcd[DP_DPCD_REV] = dpcd_ext[DP_DPCD_REV];
> + intel_dp->dpcd[DP_MAX_LINK_RATE] =
> dpcd_ext[DP_MAX_LINK_RATE];
> + intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] =
> + dpcd_ext[DP_DOWNSTREAMPORT_PRESENT];
> + }
>   DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> intel_dp->dpcd);
>  
>   return intel_dp->dpcd[DP_DPCD_REV] != 0;
> diff --git a/include/drm/drm_dp_helper.h
> b/include/drm/drm_dp_helper.h
> index c01564991a9f..757bd5913f3d 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h

This should be a separate patch as it's outside i915.

> @@ -123,8 +123,9 @@
>  # define DP_FRAMING_CHANGE_CAP   (1 << 1)
>  # 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/* XXX 1.2? */
> +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2?
> */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2?
> */
> +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* XXX 1.2?
> */
>  
>  #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

Re: [Intel-gfx] [PATCH v2 0/4] DRM helpers for Display Stream Compression PPS infoframes

[Harry Wentland]

On 2018-05-14 10:05 PM, Manasi Navare wrote:
> VESA Display Stream Compression is a specification for visually losless
> video compression over display links. The DSC standard also defines
> a picture parameter set (PPS) which encoder must communicate to decoders.
> This is done by encapsulating PPS header and payload bytes in an infoframe
> that can be sent to the display sink using secondary data packets
> as defined in DP 1.4 spec.
> 
> This patch series creates a new files drm_dsc.h and drm_dsc.c
> which define all the DSC related structures and helpers that
> can be called by drivers to form DSC PPS infoframes before
> enabling Display Stream compression on eDP/DP/MIPI
> 
> v2:
> *This is a v2 of the original patch series which adds kernel-doc
> hooks for the new dsc files in drm-kms-helpers.rst. (Daniel Vetter)
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 

With my comments for patch 2 and 3 addressed patches 1-3 are
Reviewed-by: Harry Wentland 

Patch 4 is
Acked-by: Harry Wentland 

Harry

> 
> Gaurav K Singh (1):
>   drm/dsc: Define VESA Display Stream Compression Capabilities
> 
> Manasi Navare (3):
>   drm/dp: Define payload size for DP SDP PPS packet
>   drm/dsc: Define Display Stream Compression PPS infoframe
>   drm/dsc: Add helpers for DSC picture parameter set infoframes
> 
>  Documentation/gpu/drm-kms-helpers.rst |  12 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_dsc.c | 227 ++
>  include/drm/drm_dp_helper.h   |   1 +
>  include/drm/drm_dsc.h | 564 
> ++
>  5 files changed, 805 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dsc.c
>  create mode 100644 include/drm/drm_dsc.h
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

[Dhinakaran Pandiyan]

On Wed, 2018-05-16 at 09:14 +0530, vathsala nagaraju wrote:
> On Wednesday 16 May 2018 04:33 AM, Dhinakaran Pandiyan wrote:
> > 
> > On Mon, 2018-05-14 at 09:02 +0530, vathsala nagaraju wrote:
> > > 
> > > From: Vathsala Nagaraju 
> > > 
> > > For psr block #9, the vbt description has moved to options [0-3]
> > > for
> > > TP1,TP2,TP3 Wakeup time from decimal value without any change to
> > > vbt
> > > structure. Since spec does not  mention from which VBT version
> > > this
> > > change was added to vbt.bsf file, we cannot depend on bdb-
> > > >version
> > > check
> > > to change for all the platforms.
> > > 
> > > There is RCR inplace for GOP team to  provide the version number
> > > to make generic change. Since Kabylake with bdb version 209 is
> > > having
> > > this
> > > change, limiting this change to gen9_bc and version 209+ to
> > > unblock
> > > google.
> > > 
> > > Tested on skl(bdb version 203,without options) and
> > > kabylake(bdb version 209,212) having new options.
> > > 
> > > bspec 20131
> > > 
> > > v2: (Jani and Rodrigo)
> > >  move the 165 version check to intel_bios.c
> > > v3: Jani
> > >  Move the abstraction to intel_bios.
> > > v4: Jani
> > >  Rename tp*_wakeup_time to have "us" suffix.
> > >  For values outside range[0-3],default to max 2500us.
> > >  Old decimal value was wake up time in multiples of 100us.
> > > v5: Jani and Rodrigo
> > >  Handle option 2 in default condition.
> > >  Print oustide range value.
> > >  For negetive values default to 2500us.
> > > v6: Jani
> > >  Handle default first and then fall through for case 2.
> > > v7: Rodrigo
> > >  Apply this change for IS_GEN9_BC and vbt version > 209
> > > 
> > > Cc: Rodrigo Vivi 
> > > CC: Puthikorn Voravootivat 
> > > 
> > > Signed-off-by: Maulik V Vaghela 
> > > Signed-off-by: Vathsala Nagaraju 
> > > ---
> > >   drivers/gpu/drm/i915/i915_drv.h   |  4 ++--
> > >   drivers/gpu/drm/i915/i915_reg.h   |  8 +++
> > >   drivers/gpu/drm/i915/intel_bios.c | 46
> > > +--
> > >   drivers/gpu/drm/i915/intel_psr.c  | 39 +---
> > > ---
> > > --
> > >   4 files changed, 70 insertions(+), 27 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 57fb3aa..268b059 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1078,8 +1078,8 @@ struct intel_vbt_data {
> > >   bool require_aux_wakeup;
> > >   int idle_frames;
> > >   enum psr_lines_to_wait lines_to_wait;
> > > - int tp1_wakeup_time;
> > > - int tp2_tp3_wakeup_time;
> > > + int tp1_wakeup_time_us;
> > > + int tp2_tp3_wakeup_time_us;
> > >   } psr;
> > >   
> > >   struct {
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index f11bb21..6820658 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4088,10 +4088,10 @@ enum {
> > >   #define   EDP_Y_COORDINATE_ENABLE   (1<<25) /* GLK and
> > > CNL+ */
> > >   #define   EDP_MAX_SU_DISABLE_TIME(t)((t)<<20)
> > >   #define   EDP_MAX_SU_DISABLE_TIME_MASK  (0x1f<<20)
> > > -#define   EDP_PSR2_TP2_TIME_500  (0<<8)
> > > -#define   EDP_PSR2_TP2_TIME_100  (1<<8)
> > > -#define   EDP_PSR2_TP2_TIME_2500 (2<<8)
> > > -#define   EDP_PSR2_TP2_TIME_50   (3<<8)
> > > +#define   EDP_PSR2_TP2_TIME_500us(0<<8)
> > > +#define   EDP_PSR2_TP2_TIME_100us(1<<8)
> > > +#define   EDP_PSR2_TP2_TIME_2500us   (2<<8)
> > > +#define   EDP_PSR2_TP2_TIME_50us (3<<8)
> > >   #define   EDP_PSR2_TP2_TIME_MASK(3<<8)
> > >   #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
> > >   #define   EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf<<4)
> > > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > > b/drivers/gpu/drm/i915/intel_bios.c
> > > index 54270bd..695ca73 100644
> > > --- a/drivers/gpu/drm/i915/intel_bios.c
> > > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > > @@ -688,8 +688,50 @@ static int intel_bios_ssc_frequency(struct
> > > drm_i915_private *dev_priv,
> > >   break;
> > >   }
> > >   
> > > - dev_priv->vbt.psr.tp1_wakeup_time = psr_table-
> > > > 
> > > > tp1_wakeup_time;
> > > - dev_priv->vbt.psr.tp2_tp3_wakeup_time = psr_table-
> > > > 
> > > > tp2_tp3_wakeup_time;
> > > + /*
> > > +  * New psr options 0=500us, 1=100us, 2=2500us, 3=0us
> > > +  * Old decimal value is wake up time in multiples of 100
> > > us.
> > > +  */
> > > + if (bdb->version >= 209 && IS_GEN9_BC(dev_priv)) {
> > Since this is the 'new' mapping, shouldn't this check be
> > 
> > if (version >= 209) {
> > 
> > }
> check is for bdb version.
> > 
> > i.e., what versions do BXT, GLK, CFL 

Re: [Intel-gfx] [PATCH] Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"

[Manasi Navare]

On Wed, May 16, 2018 at 10:21:10AM -0700, Lucas De Marchi wrote:
> This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677.
> 
> This fails on a Dell XPS13 9350 machine giving me just a black screen.
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> Passed at Link Rate = 54, Lane count = 4
>  [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
> Training failed at link rate = 54, lane count = 4
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> Passed at Link Rate = 54, Lane count = 4
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> Passed at Link Rate = 54, Lane count = 4
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> Passed at Link Rate = 54, Lane count = 4
>  [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
> Training failed at link rate = 54, lane count = 4
>  [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
> Training failed at link rate = 54, lane count = 4
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> Passed at Link Rate = 54, Lane count = 4
>  [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
> Training failed at link rate = 54, lane count = 4
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> Passed at Link Rate = 54, Lane count = 4
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> Passed at Link Rate = 54, Lane count = 4
>  [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
> Training failed at link rate = 54, lane count = 4
> 
> On a working kernel, previous to this commit I have:
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> failed at link rate = 54, lane count = 4
>  [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
> Passed at Link Rate = 27, Lane count = 4
> 
> Cc: Clinton Taylor 
> Cc: Jim Bride 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Cc: Manasi Navare 
> Cc: Ville Syrjala 
> Cc: Imre Deak 
> Signed-off-by: Lucas De Marchi 
> ---
> 
> I'm sending this for reference and discussion only, but it doesn't seem
> to be the right fix. Not only because it would mean IGT failing on CI,
> but also because we seem to be having several link training running
> concurrently and the last one failing leaves the panel at that state.

I just looked at the full log of the failing case and in that case it first 
tries training
at the highest link rate, lane count for eDP and passes before enabling pipe A.
But then the panel soon sends a short pulse indicating loss of signal which
causes the driver to call intel_dp_check_link_status() where 
drm_dp_channel_eq_ok() check
fails and thats why you see multiple link training attempts there which fail 
and eventually result in a
black screen.

Now in case of passing case, whats interesting is that it starts with same 
highest link rate 5.4Gbps
but fails the very first time and now the fallback code kicks in and lowers the 
link rate to 2.7Gbps.
Now in this particular case, the edp panel's native resolution of 3200 x 1800 
fits even for the lowered
link rate of 2.7Gbps and it retrains at that and passes so we get a recovered 
modeset.

So I am thinking because of such cases, we should probably not asusme that the 
native mode will not
fit the lowered fallback link rate. So I guess we should still try fallback for 
eDP as long
as its not pruning the native mode on the panel.

Alternatively I think if we start from lowest link rate and lane count like we 
do
for DP then it will pick the lowest possible link rate required for the native 
mode and we might
not run into this situation.

Jani, Ville any thoughts on which approach should be chosen?

Regards
Manasi

> 
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +++
>  1 file changed, 9 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index f59b59bb0a21..78f1fe934da3 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -330,22 +330,14 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>   return;
>  
>   failure_handling:
> - /* Dont fallback and prune modes if its eDP */
> - if (!intel_dp_is_edp(intel_dp)) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link 
> rate = %d, lane count = %d",
> -   

Re: [Intel-gfx] [PATCH v2 2/4] drm/dsc: Define Display Stream Compression PPS infoframe

[Manasi Navare]

On Wed, May 16, 2018 at 02:14:56PM -0400, Harry Wentland wrote:
> On 2018-05-14 10:05 PM, Manasi Navare wrote:
> > This patch defines a new header file for all the DSC 1.2 structures
> > and creates a structure for PPS infoframe which will be used to send
> > picture parameter set secondary data packet for display stream compression.
> > All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> > from VESA.
> > 
> > v2:
> > * Fix the comments for kernel-doc
> > 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Cc: Anusha Srivatsa 
> > Signed-off-by: Manasi Navare 
> > ---
> >  include/drm/drm_dsc.h | 437 
> > ++
> >  1 file changed, 437 insertions(+)
> >  create mode 100644 include/drm/drm_dsc.h
> > 
> > diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> > new file mode 100644
> > index 000..5ee72e8
> > --- /dev/null
> > +++ b/include/drm/drm_dsc.h
> > @@ -0,0 +1,437 @@
> > +/*
> > + * Copyright (C) 2018 Intel Corp.
> > + *
> > + * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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.
> > + *
> > + * Authors:
> > + * Manasi Navare 
> > + */
> > +
> > +#ifndef DRM_DSC_H_
> > +#define DRM_DSC_H_
> > +
> > +#include 
> > +
> > +#define DSC_NUM_BUF_RANGES 15
> > +
> > +/**
> > + * struct picture_parameter_set - Represents 128 bytes of Picture 
> > Parameter Set
> > + *
> > + * The VESA DSC standard defines picture parameter set (PPS) which display 
> > stream
> > + * compression encoders must communicate to decoders. The PPS is 
> > encapsulated
> > + * in 128 bytes (PPS 0 through PPS 127). The fields in this structure are 
> > as per
> > + * Table 4.1 in Vesa DSC specification v1.1/v1.2.
> > + * The PPS fields that span over more than a byte should be stored in Big 
> > Endian
> > + * format.
> > + */
> > +struct picture_parameter_set {
> > +   /**
> > +* @dsc_version_minor:
> > +* PPS0[3:0] - Contains Minor version of DSC
> > +*/
> > +   u8 dsc_version_minor:4;
> > +   /**
> > +* @dsc_version_major:
> > +* PPS0[7:4] - Contains major version of DSC
> > +*/
> > +   u8 dsc_version_major:4;
> > +   /**
> > +* @pps_identifier:
> > +* PPS1[7:0] - Application specific identifier that can be
> > +* used to differentiate between different PPS tables.
> > +*/
> > +   u8 pps_identifier;
> > +   /**
> > +* @pps2_reserved:
> > +* PPS2[7:0]- RESERVED Byte
> > +*/
> > +   u8 pps2_reserved;
> > +   /**
> > +* @linebuf_depth:
> > +* PPS3[3:0] - Contains linebuffer bit depth used to generate
> > +* the bitstream. (0x0 - 16 bits for DSc 1.2, 0x8 - 8 bits,
> > +* 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> > +* 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> > +*/
> > +   u8 linebuf_depth:4;
> > +   /**
> > +* @bits_per_component:
> > +* PPS3[7:4] - Bits per component fo rthe original pixels
> 
> typo: "for the"

Yes wll fix that.

> 
> > +* of the encoded picture.
> > +*/
> 
> Would it make sense to indicate in the comments what the values mean?
> 
> From the spec:
> 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2).
> 0x8 = 8bpc.
> 0xA = 10bpc.
> 0xC = 12bpc.
> 0xE = 14bpc (allowed only when dsc_version_minor = 0x2).
> All other encodings are RESERVED.
> 
> Harry

This is definitely a good point. I can add these in the block comment for
bits_per_component like I have added for linebuf_depth.

Regards
Manasi

> 
> > +   u8 bits_per_component:4;
> > +   /**
> > +* @bpp_high:
> > +* PPS4[1:0] - These are the most significant 2 bits of
> > +* compressed BPP bits_per_pixel[9:0] syntax element.
> > +*/
> > +   u8 bpp_high:2;
> > +   /**
> > 

Re: [Intel-gfx] [PATCH 14/22] drm/i915/icl: WaDisableImprovedTdlClkGating

[Oscar Mateo]

On 05/16/2018 04:05 AM, Mika Kuoppala wrote:

Oscar Mateo  writes:


Revert to the legacy implementation.

v2: GEN7_ROW_CHICKEN2 is masked
v3:
   - Rebased
   - Renamed to Wa_2006611047
   - A0 and B0 only
v4:
   - Add spaces around '<<' (and fix the surrounding code as well)
   - Mark the WA as pre-prod
v5: Rebased on top of the WA refactoring
v6: Added References (Mika)
v7: Fixed in B0

Could you recheck from bspec?
I read it like we need this for all


I was going by the HSD (#2006611047), which says this was fixed in B0...


-Mika


References: HSDES#2006611047
Signed-off-by: Oscar Mateo 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_reg.h  | 5 +++--
  drivers/gpu/drm/i915/intel_workarounds.c | 7 +++
  2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1449178..7f6f328 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8319,8 +8319,9 @@ enum {
  
  #define GEN7_ROW_CHICKEN2		_MMIO(0xe4f4)

  #define GEN7_ROW_CHICKEN2_GT2 _MMIO(0xf4f4)
-#define   DOP_CLOCK_GATING_DISABLE (1<<0)
-#define   PUSH_CONSTANT_DEREF_DISABLE  (1<<8)
+#define   DOP_CLOCK_GATING_DISABLE (1 << 0)
+#define   PUSH_CONSTANT_DEREF_DISABLE  (1 << 8)
+#define   GEN11_TDL_CLOCK_GATING_FIX_DISABLE   (1 << 1)
  
  #define HSW_ROW_CHICKEN3		_MMIO(0xe49c)

  #define  HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 5eec4ce..3913b6a 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -459,6 +459,13 @@ static int icl_ctx_workarounds_init(struct 
drm_i915_private *dev_priv)
 */
WA_SET_BIT_MASKED(ICL_HDC_MODE, HDC_FORCE_NON_COHERENT);
  
+	/* Wa_2006611047:icl (pre-prod)

+* Formerly known as WaDisableImprovedTdlClkGating
+*/
+   if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_A0))
+   WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2,
+ GEN11_TDL_CLOCK_GATING_FIX_DISABLE);
+
return 0;
  }
  
--

1.9.1


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

[Intel-gfx] ✓ Fi.CI.BAT: success for gpu: drm: i915: Change return type to vm_fault_t (rev4)

[Patchwork]

== Series Details ==

Series: gpu: drm: i915: Change return type to vm_fault_t (rev4)
URL   : https://patchwork.freedesktop.org/series/41893/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193 -> Patchwork_9023 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9023 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9023, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41893/revisions/4/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9023:

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9023 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   PASS -> DMESG-FAIL (fdo#106103, fdo#102614)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-cnl-y3:  PASS -> DMESG-WARN (fdo#104951)

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cfl-s3:  FAIL (fdo#103481) -> PASS +1

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS


  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103


== Participating hosts (41 -> 36) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9023

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9023: 17edb8f2e563eea240ac304b11939cbdf1dc397e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

17edb8f2e563 gpu: drm: i915: Change return type to vm_fault_t

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for gpu: drm: i915: Change return type to vm_fault_t (rev4)

[Patchwork]

== Series Details ==

Series: gpu: drm: i915: Change return type to vm_fault_t (rev4)
URL   : https://patchwork.freedesktop.org/series/41893/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: gpu: drm: i915: Change return type to vm_fault_t
-O:drivers/gpu/drm/i915/i915_gem.c:2080:32: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/i915_gem.c:2080:32: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem.c:2081:32: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/i915_gem.c:2081:32: warning: expression using sizeof(void)
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3663:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression 
using sizeof(void)

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

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

[Sean Paul]

Hi Dave,
A few more fixes this week, one going to stable.


drm-misc-fixes-2018-05-16:
- core: Fix regression in dev node offsets (Haneen)
- vc4: Fix memory leak on driver close (Eric)
- dumb-buffers: Prevent overflow in DIV_ROUND_UP() (Dan)

Cc: Haneen Mohammed 
Cc: Eric Anholt 
Cc: Dan Carpenter 

Cheers, Sean


The following changes since commit 9a0e9802217291e54c4dd1fc5462f189a4be14ec:

  drm/vc4: Fix scaling of uni-planar formats (2018-05-09 09:48:23 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-05-16

for you to fetch changes up to 2b6207291b7b277a5df9d1aab44b56815a292dba:

  drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl() (2018-05-16 
17:56:06 +0200)


- core: Fix regression in dev node offsets (Haneen)
- vc4: Fix memory leak on driver close (Eric)
- dumb-buffers: Prevent overflow in DIV_ROUND_UP() (Dan)

Cc: Haneen Mohammed 
Cc: Eric Anholt 
Cc: Dan Carpenter 


Dan Carpenter (1):
  drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

Eric Anholt (1):
  drm/vc4: Fix leak of the file_priv that stored the perfmon.

Haneen Mohammed (1):
  drm: Match sysfs name in link removal to link creation

 drivers/gpu/drm/drm_drv.c  | 2 +-
 drivers/gpu/drm/drm_dumb_buffers.c | 7 ---
 drivers/gpu/drm/vc4/vc4_drv.c  | 1 +
 3 files changed, 6 insertions(+), 4 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/8] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/8] drm/i915: Remove tasklet flush before 
disable
URL   : https://patchwork.freedesktop.org/series/43279/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193 -> Patchwork_9022 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9022 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9022, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43279/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9022:

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9022 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@read-crc-pipe-a:
  fi-cnl-y3:  PASS -> INCOMPLETE (fdo#105086)

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cfl-s3:  FAIL (fdo#103481) -> PASS +1

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS


  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
  fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086


== Participating hosts (41 -> 36) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9022

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9022: 387525caae783f499df44a16617859be79befb2e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

387525caae78 drm/i915: Stop parking the signaler around reset
e42da871bcce drm/i915/execlists: Flush pending preemption events during reset
144490575fd2 drm/i915/execlists: Split out CSB processing
0eeec4b1e771 drm/i915: Split execlists/guc reset preparations
ea6e4205f335 drm/i915: Move engine reset prepare/finish to backends
1679c56ac90d drm/i915/execlists: Refactor out complete_preempt_context()
4ec12cf75d13 drm/i915: Only sync tasklets once for recursive reset preparation
65dc7678895f drm/i915: Remove tasklet flush before disable

== Logs ==

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

Re: [Intel-gfx] [PATCH v4] gpu: drm: i915: Change return type to vm_fault_t

[Chris Wilson]

Quoting Souptick Joarder (2018-05-16 20:12:20)
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
> 
> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
> 
> Fixed one checkpatch.pl warning inside WARN_ONCE.
> 
> Signed-off-by: Souptick Joarder 
> ---

> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dd89abd..732abdf 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
>   * The current feature set supported by i915_gem_fault() and thus GTT mmaps
>   * is exposed via I915_PARAM_MMAP_GTT_VERSION (see 
> i915_gem_mmap_gtt_version).
>   */
> -int i915_gem_fault(struct vm_fault *vmf)
> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>  {
>  #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
> struct vm_area_struct *area = vmf->vma;
> @@ -1894,7 +1894,8 @@ int i915_gem_fault(struct vm_fault *vmf)
> struct i915_vma *vma;
> pgoff_t page_offset;
> unsigned int flags;
> -   int ret;
> +   int err;
> +   vm_fault_t ret = VM_FAULT_SIGBUS;
>  
> /* We don't use vmf->pgoff since that has the fake offset */
> page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
> @@ -2027,8 +2028,7 @@ int i915_gem_fault(struct vm_fault *vmf)
> ret = VM_FAULT_SIGBUS;
> break;
> default:
> -   WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", 
> ret);
> -   ret = VM_FAULT_SIGBUS;
> +   WARN_ONCE(ret, "unhandled error in %s: %x\n", __func__, err);
> break;

Even simpler would be to use e.g. return VM_FAULT_SIGBUS for each case
above. No early initialisation of use-once variables allowing the
compiler to do it's job. For a smaller patch, you can even skip the
s/ret/err/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] gpu: drm: i915: Change return type to vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Fixed one checkpatch.pl warning inside WARN_ONCE.

Signed-off-by: Souptick Joarder 
---
v2: Updated the change log

v3: Corrected variable name to err

v4: Fixed patchwork error by initialized ret

 drivers/gpu/drm/i915/i915_drv.h |  3 ++-
 drivers/gpu/drm/i915/i915_gem.c | 38 +++---
 2 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a42deeb..95b0d50 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_params.h"
 #include "i915_reg.h"
@@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
*dev_priv,
   unsigned int flags);
 int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
 void i915_gem_resume(struct drm_i915_private *dev_priv);
-int i915_gem_fault(struct vm_fault *vmf);
+vm_fault_t i915_gem_fault(struct vm_fault *vmf);
 int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 unsigned int flags,
 long timeout,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dd89abd..732abdf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
  * The current feature set supported by i915_gem_fault() and thus GTT mmaps
  * is exposed via I915_PARAM_MMAP_GTT_VERSION (see i915_gem_mmap_gtt_version).
  */
-int i915_gem_fault(struct vm_fault *vmf)
+vm_fault_t i915_gem_fault(struct vm_fault *vmf)
 {
 #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
struct vm_area_struct *area = vmf->vma;
@@ -1894,7 +1894,8 @@ int i915_gem_fault(struct vm_fault *vmf)
struct i915_vma *vma;
pgoff_t page_offset;
unsigned int flags;
-   int ret;
+   int err;
+   vm_fault_t ret = VM_FAULT_SIGBUS;
 
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
@@ -1906,26 +1907,26 @@ int i915_gem_fault(struct vm_fault *vmf)
 * repeat the flush holding the lock in the normal manner to catch cases
 * where we are gazumped.
 */
-   ret = i915_gem_object_wait(obj,
+   err = i915_gem_object_wait(obj,
   I915_WAIT_INTERRUPTIBLE,
   MAX_SCHEDULE_TIMEOUT,
   NULL);
-   if (ret)
+   if (err)
goto err;
 
-   ret = i915_gem_object_pin_pages(obj);
-   if (ret)
+   err = i915_gem_object_pin_pages(obj);
+   if (err)
goto err;
 
intel_runtime_pm_get(dev_priv);
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
+   err = i915_mutex_lock_interruptible(dev);
+   if (err)
goto err_rpm;
 
/* Access to snoopable pages through the GTT is incoherent. */
if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(dev_priv)) {
-   ret = -EFAULT;
+   err = -EFAULT;
goto err_unlock;
}
 
@@ -1952,25 +1953,25 @@ int i915_gem_fault(struct vm_fault *vmf)
vma = i915_gem_object_ggtt_pin(obj, , 0, 0, PIN_MAPPABLE);
}
if (IS_ERR(vma)) {
-   ret = PTR_ERR(vma);
+   err = PTR_ERR(vma);
goto err_unlock;
}
 
-   ret = i915_gem_object_set_to_gtt_domain(obj, write);
-   if (ret)
+   err = i915_gem_object_set_to_gtt_domain(obj, write);
+   if (err)
goto err_unpin;
 
-   ret = i915_vma_pin_fence(vma);
-   if (ret)
+   err = i915_vma_pin_fence(vma);
+   if (err)
goto err_unpin;
 
/* Finally, remap it using the new GTT offset */
-   ret = remap_io_mapping(area,
+   err = remap_io_mapping(area,
   area->vm_start + (vma->ggtt_view.partial.offset 
<< PAGE_SHIFT),
   (ggtt->gmadr.start + vma->node.start) >> 
PAGE_SHIFT,
   min_t(u64, vma->size, area->vm_end - 
area->vm_start),
   >iomap);
-   if (ret)
+   if (err)
goto err_fence;
 
/* Mark as being mmapped into userspace for later revocation */
@@ -1991,7 +1992,7 @@ int i915_gem_fault(struct vm_fault *vmf)
intel_runtime_pm_put(dev_priv);
i915_gem_object_unpin_pages(obj);
 err:
-   switch (ret) {
+   switch (err) {
case -EIO:
/*

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Enable fastset by default, except on initial modeset

[Patchwork]

== Series Details ==

Series: drm/i915: Enable fastset by default, except on initial modeset
URL   : https://patchwork.freedesktop.org/series/43248/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4191_full -> Patchwork_9014_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9014_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9014_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43248/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9014_full:

  === IGT changes ===

 Possible regressions 

igt@kms_rotation_crc@bad-pixel-format:
  shard-apl:  PASS -> DMESG-WARN +1

igt@kms_rotation_crc@exhaust-fences:
  shard-glk:  PASS -> DMESG-WARN

igt@kms_rotation_crc@sprite-rotation-270:
  shard-kbl:  PASS -> DMESG-WARN +2


 Warnings 

igt@kms_atomic_transition@plane-primary-toggle-with-vblank-wait:
  shard-snb:  PASS -> SKIP +1

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  SKIP -> PASS +1


== Known issues ==

  Here are the changes found in Patchwork_9014_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_eio@in-flight-10ms:
  shard-snb:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@in-flight-contexts-10ms:
  shard-glk:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@in-flight-internal-immediate:
  shard-apl:  PASS -> DMESG-WARN (fdo#106523) +1

igt@kms_flip@2x-wf_vblank-ts-check-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@plain-flip-fb-recreate:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip_tiling@flip-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724) +1

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103167)


 Possible fixes 

igt@gem_eio@in-flight-contexts-1us:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +2
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS +1

igt@gem_eio@in-flight-internal-10ms:
  shard-snb:  DMESG-WARN (fdo#106523) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_cursor_legacy@flip-vs-cursor-toggle:
  shard-hsw:  FAIL (fdo#102670) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +1

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4191 -> Patchwork_9014

  CI_DRM_4191: 70daebf1a83c2ed6eff118d2a2806086c0c89027 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4484: b7432bf309d5d5a6e07e8a0d8b522302fb0b4502 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9014: bbcc416a11672c244b7abeee11e6eda5ac2123cf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4484: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/8] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/8] drm/i915: Remove tasklet flush before 
disable
URL   : https://patchwork.freedesktop.org/series/43279/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
65dc7678895f drm/i915: Remove tasklet flush before disable
4ec12cf75d13 drm/i915: Only sync tasklets once for recursive reset preparation
1679c56ac90d drm/i915/execlists: Refactor out complete_preempt_context()
ea6e4205f335 drm/i915: Move engine reset prepare/finish to backends
0eeec4b1e771 drm/i915: Split execlists/guc reset preparations
144490575fd2 drm/i915/execlists: Split out CSB processing
-:67: WARNING:LONG_LINE: line over 100 characters
#67: FILE: drivers/gpu/drm/i915/intel_lrc.c:975:
+   (i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));

-:85: WARNING:LONG_LINE: line over 100 characters
#85: FILE: drivers/gpu/drm/i915/intel_lrc.c:989:
+   head = readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));

-:102: WARNING:LONG_LINE: line over 100 characters
#102: FILE: drivers/gpu/drm/i915/intel_lrc.c:1004:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",

-:103: WARNING:LONG_LINE: line over 100 characters
#103: FILE: drivers/gpu/drm/i915/intel_lrc.c:1005:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");

total: 0 errors, 4 warnings, 0 checks, 144 lines checked
e42da871bcce drm/i915/execlists: Flush pending preemption events during reset
387525caae78 drm/i915: Stop parking the signaler around reset

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

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Neil Armstrong]

Hi Ville,

On 16/05/2018 16:07, Ville Syrjälä wrote:
> On Wed, May 16, 2018 at 09:40:17AM +0200, Neil Armstrong wrote:
>> On 16/05/2018 09:31, Neil Armstrong wrote:
>>> Hi Ville,
>>>
>>> On 15/05/2018 17:35, Ville Syrjälä wrote:
 On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to 
> differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/i915/Kconfig  |  1 +
>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 12 
>  3 files changed, 15 insertions(+)
>
>>>
>>> [..]
>>>
>  }
>  
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct 
> intel_encoder *encoder,
>  
>  static void intel_hdmi_destroy(struct drm_connector *connector)
>  {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>   kfree(to_intel_connector(connector)->detect_edid);
>   drm_connector_cleanup(connector);
>   kfree(connector);
> @@ -2358,6 +2366,10 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>   I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>   }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);

 What are we doing with the connector name here? Those are not actually
 guaranteed to be stable, and any change in the connector probe order
 may cause the name to change.
>>>
>>> The i915 driver can expose multiple HDMI connectors, but each connected will
>>> have a different EDID and CEC physical address, so we will need a different 
>>> notifier
>>> for each connector.
>>>
>>> The connector name is DRM dependent, but user-space actually uses this name 
>>> for
>>> operations, so I supposed it was kind of stable.
>>>
>>> Anyway, is there another stable id/name/whatever that can be used to make a 
>>> name to
>>> distinguish the HDMI connectors ?
>>
>> Would "HDMI %c", port_name(port) be OK to use ?
> 
> Yeah, something like seems like a reasonable approach. That does mean
> we have to be a little careful with changing enum port or port_name()
> in the future, but I guess we could just add a small function to
> generated the name/id specifically for this thing.
> 
> We're also going to have to think what to do with enum port and
> port_name() on ICL+ though. There we won't just have A-F but also
> TC1-TC. Hmm. Looks like what we have for those ports in our
> codebase ATM is a bit wonky since we haven't even changed
> port_name() to give us the TC type names.
> 
> Also we might not want "HDMI" in the identifier since the physical
> port is not HDMI specific. There are different things we could call
> these but I think we could just go with a generic "Port A-F" and
> "Port TC1-TC" approach. I think something like that should work
> fine for current and upcoming hardware. And in theory that could
> then be used for other things as well which need a stable
> identifier.
> 
> Oh, and now I recall that input subsystem at least has some kind
> of "physical path" property on devices. So I guess what we're
> dicussing is a somewhat similar idea. I think input drivers
> generally include the pci/usb/etc. device in the path as well.
> Even though we currently only ever have the one pci device it
> would seem like decent idea to include that information in our
> identifiers as well. Or what do you think?
> 

Thanks for the clarifications !

Having a "Port " will be great indeed, no need to specify HDMI since
only HDMI connectors will get a CEC notifier anyway.

The issue is that port_name() returns a character, which is lame.
Would it be acceptable to introduce a :

const char *port_identifier(struct drm_i915_private *dev_priv,
enum port port)
{
char *id = devm_kzalloc(dev_priv->drm->dev, 16, GFP_KERNEL);

if (id)
return NULL;

snprintf("Port %c", port_name(port));

return id;
}

and use the result of this for the cec_notifier connector name ?

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

Re: [Intel-gfx] [PATCH v2 3/4] drm/dsc: Define VESA Display Stream Compression Capabilities

[Harry Wentland]

On 2018-05-14 10:05 PM, Manasi Navare wrote:
> From: Gaurav K Singh 
> 
> This defines all the DSC parameters as per the VESA DSC spec
> that will be required for DSC encoder/decoder
> 
> v2: Define this struct in DRM (From Manasi)
> * Changed the data types to u8/u16 instead of unsigned longs (Manasi)
> * Remove driver specific fields (Manasi)
> * Move this struct definition to DRM (Manasi)
> * Define DSC 1.2 parameters (Manasi)
> * Use DSC_NUM_BUF_RANGES (Manasi)
> * Call it drm_dsc_config (Manasi)
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Gaurav K Singh 
> ---
>  include/drm/drm_dsc.h | 111 
> ++
>  1 file changed, 111 insertions(+)
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> index 5ee72e8..04501e2 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -30,6 +30,117 @@
>  
>  #define DSC_NUM_BUF_RANGES   15
>  
> +/* VESA Display Stream Compression DSC 1.2 constants */
> +#define DSC_NUM_BUF_RANGES   15

Duplicate definition of previous line.

Harry

> +
> +/* Configuration for a single Rate Control model range */
> +struct dsc_rc_range_parameters {
> + /* Min Quantization Parameters allowed for this range */
> + u8 range_min_qp;
> + /* Max Quantization Parameters allowed for this range */
> + u8 range_max_qp;
> + /* Bits/group offset to apply to target for this group */
> + u8 range_bpg_offset;
> +};
> +
> +struct drm_dsc_config {
> + /* Bits / component for previous reconstructed line buffer */
> + u8 line_buf_depth;
> + /* Bits per component to code (must be 8, 10, or 12) */
> + u8 bits_per_component;
> + /*
> +  * Flag indicating to do RGB - YCoCg conversion
> +  * and back (should be 1 for RGB input)
> +  */
> + bool convert_rgb;
> + u8 slice_count;
> + /* Slice Width */
> + u16 slice_width;
> + /* Slice Height */
> + u16 slice_height;
> + /*
> +  * 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
> +  * outside of DSC encode/decode algorithm)
> +  */
> + bool enable422;
> + /* Picture Width */
> + u16 pic_width;
> + /* Picture Height */
> + u16 pic_height;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_high;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_low;
> + /* Bits/pixel target << 4 (ie., 4 fractional bits) */
> + u16 bits_per_pixel;
> + /*
> +  * Factor to determine if an edge is present based
> +  * on the bits produced
> +  */
> + u8 rc_edge_factor;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit1;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit0;
> + /* Number of pixels to delay the initial transmission */
> + u16 initial_xmit_delay;
> + /* Number of pixels to delay the VLD on the decoder,not including SSM */
> + u16  initial_dec_delay;
> + /* Block prediction enable */
> + bool block_pred_enable;
> + /* Bits/group offset to use for first line of the slice */
> + u8 first_line_bpg_offset;
> + /* Value to use for RC model offset at slice start */
> + u16 initial_offset;
> + /* Thresholds defining each of the buffer ranges */
> + u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
> + /* Parameters for each of the RC ranges */
> + struct dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> + /* Total size of RC model */
> + u16 rc_model_size;
> + /* Minimum QP where flatness information is sent */
> + u8 flatness_min_qp;
> + /* Maximum QP where flatness information is sent */
> + u8 flatness_max_qp;
> + /* Initial value for scale factor */
> + u8 initial_scale_value;
> + /* Decrement scale factor every scale_decrement_interval groups */
> + u16 scale_decrement_interval;
> + /* Increment scale factor every scale_increment_interval groups */
> + u16 scale_increment_interval;
> + /* Non-first line BPG offset to use */
> + u16 nfl_bpg_offset;
> + /* BPG offset used to enforce slice bit */
> + u16 slice_bpg_offset;
> + /* Final RC linear transformation offset value */
> + u16 final_offset;
> + /* Enable on-off VBR (ie., disable stuffing bits) */
> + bool vbr_enable;
> + /* Mux word size (in bits) for SSM mode */
> + u8 mux_word_size;
> + /*
> +  * The (max) size in bytes of the "chunks" that are
> +  * used in slice multiplexing
> +  */
> + u16 slice_chunk_size;
> + /* Rate Control buffer siz in bits */
> + 

[Intel-gfx] [CI 8/8] drm/i915: Stop parking the signaler around reset

[Chris Wilson]

We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so that the GPU doesn't emit the breadcrumb for our chosen
"guilty" request.

v2: Refactor setting STOP_RING so that we don't have the same code thrice

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michałt Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 14 
 drivers/gpu/drm/i915/intel_engine_cs.c  | 29 +
 drivers/gpu/drm/i915/intel_lrc.c|  6 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
 drivers/gpu/drm/i915/intel_uncore.c | 12 +++---
 6 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index abf661d40641..b0fe452ce17c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3015,18 +3015,6 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 */
intel_uncore_forcewake_get(engine->i915, FORCEWAKE_ALL);
 
-   /*
-* Prevent the signaler thread from updating the request
-* state (by calling dma_fence_signal) as we are processing
-* the reset. The write from the GPU of the seqno is
-* asynchronous and the signaler thread may see a different
-* value to us and declare the request complete, even though
-* the reset routine have picked that request as the active
-* (incomplete) request. This conflict is not handled
-* gracefully!
-*/
-   kthread_park(engine->breadcrumbs.signaler);
-
request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
@@ -3229,8 +3217,6 @@ void i915_gem_reset_finish_engine(struct intel_engine_cs 
*engine)
 {
engine->reset.finish(engine);
 
-   kthread_unpark(engine->breadcrumbs.signaler);
-
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 6bfd7e3ed152..d4e159ae65a6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -769,6 +769,35 @@ u64 intel_engine_get_last_batch_head(const struct 
intel_engine_cs *engine)
return bbaddr;
 }
 
+int intel_engine_stop_cs(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   const u32 base = engine->mmio_base;
+   const i915_reg_t mode = RING_MI_MODE(base);
+   int err;
+
+   if (INTEL_GEN(dev_priv) < 3)
+   return -ENODEV;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   I915_WRITE_FW(mode, _MASKED_BIT_ENABLE(STOP_RING));
+
+   err = 0;
+   if (__intel_wait_for_register_fw(dev_priv,
+mode, MODE_IDLE, MODE_IDLE,
+1000, 0,
+NULL)) {
+   GEM_TRACE("%s: timed out on STOP_RING -> IDLE\n", engine->name);
+   err = -ETIMEDOUT;
+   }
+
+   /* A final mmio read to let GPU writes be hopefully flushed to memory */
+   POSTING_READ_FW(mode);
+
+   return err;
+}
+
 const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
 {
switch (type) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3b889bb4352a..646ecf267411 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1878,6 +1878,12 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
if (request) {
unsigned long flags;
 
+   /*
+* Prevent the breadcrumb from advancing before we decide
+* which request is currently active.
+*/
+   intel_engine_stop_cs(engine);
+
spin_lock_irqsave(>timeline.lock, flags);
list_for_each_entry_from_reverse(request,
 >timeline.requests,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index af5a178366ed..6f200a747176 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -533,6 +533,8 @@ static int init_ring_common(struct intel_engine_cs *engine)
 
 static struct i915_request 

[Intel-gfx] [CI 2/8] drm/i915: Only sync tasklets once for recursive reset preparation

[Chris Wilson]

When setting up reset, we may need to recursively prepare an engine. In
which case we should only synchronously flush the tasklets on the outer
most call, the inner calls will then be inside an atomic section where
the tasklet will never be run (and so the sync will never complete).

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 drivers/gpu/drm/i915/i915_gem.h | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0dc369a9ec4d..982393907b80 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
 */
-   tasklet_disable(>execlists.tasklet);
+   __tasklet_disable_sync_once(>execlists.tasklet);
 
/*
 * We're using worker to queue preemption requests from the tasklet in
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 525920404ede..5bf24cfc218c 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -26,6 +26,7 @@
 #define __I915_GEM_H__
 
 #include 
+#include 
 
 struct drm_i915_private;
 
@@ -72,4 +73,10 @@ struct drm_i915_private;
 void i915_gem_park(struct drm_i915_private *i915);
 void i915_gem_unpark(struct drm_i915_private *i915);
 
+static inline void __tasklet_disable_sync_once(struct tasklet_struct *t)
+{
+   if (atomic_inc_return(>count) == 1)
+   tasklet_unlock_wait(t);
+}
+
 #endif /* __I915_GEM_H__ */
-- 
2.17.0

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

[Intel-gfx] [CI 5/8] drm/i915: Split execlists/guc reset preparations

[Chris Wilson]

In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 34 +
 drivers/gpu/drm/i915/intel_lrc.c| 12 ++--
 2 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index ca38ac9ff4fa..637e852888ec 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -815,6 +815,37 @@ static void guc_submission_tasklet(unsigned long data)
guc_dequeue(engine);
 }
 
+static struct i915_request *
+guc_reset_prepare(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its execlists->tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the execlists->tasklet until the reset is over
+* prevents the race.
+*/
+   __tasklet_disable_sync_once(>tasklet);
+
+   /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may still have a worker queued.
+* Let's make sure that all workers scheduled before disabling the
+* tasklet are completed before continuing with the reset.
+*/
+   if (engine->i915->guc.preempt_wq)
+   flush_workqueue(engine->i915->guc.preempt_wq);
+
+   return i915_gem_find_active_request(engine);
+}
+
 /*
  * Everything below here is concerned with setup & teardown, and is
  * therefore not part of the somewhat time-critical batch-submission
@@ -1275,6 +1306,9 @@ int intel_guc_submission_enable(struct intel_guc *guc)
>execlists;
 
execlists->tasklet.func = guc_submission_tasklet;
+
+   engine->reset.prepare = guc_reset_prepare;
+
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 67fed98abee7..f5d74df0e0d0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1844,16 +1844,6 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
 */
__tasklet_disable_sync_once(>tasklet);
 
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
return i915_gem_find_active_request(engine);
 }
 
@@ -2255,6 +2245,8 @@ static void execlists_set_default_submission(struct 
intel_engine_cs *engine)
engine->schedule = execlists_schedule;
engine->execlists.tasklet.func = execlists_submission_tasklet;
 
+   engine->reset.prepare = execlists_reset_prepare;
+
engine->park = NULL;
engine->unpark = NULL;
 
-- 
2.17.0

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

[Intel-gfx] [CI 3/8] drm/i915/execlists: Refactor out complete_preempt_context()

[Chris Wilson]

As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.

v2: And do the same for the guc.

Signed-off-by: Chris Wilson 
Cc: Jeff McGee 
Cc: Michał Winiarski 
Reviewed-by: Jeff McGee  #v1
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 26 ++---
 drivers/gpu/drm/i915/intel_lrc.c| 23 ++
 2 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 2feb65096966..ca38ac9ff4fa 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -623,6 +623,21 @@ static void wait_for_guc_preempt_report(struct 
intel_engine_cs *engine)
report->report_return_status = INTEL_GUC_REPORT_STATUS_UNKNOWN;
 }
 
+static void complete_preempt_context(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists *execlists = >execlists;
+
+   GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+   execlists_cancel_port_requests(execlists);
+   execlists_unwind_incomplete_requests(execlists);
+
+   wait_for_guc_preempt_report(engine);
+   intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
+
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
 /**
  * guc_submit() - Submit commands through GuC
  * @engine: engine associated with the commands
@@ -793,15 +808,8 @@ static void guc_submission_tasklet(unsigned long data)
 
if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) &&
intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
-   GUC_PREEMPT_FINISHED) {
-   execlists_cancel_port_requests(>execlists);
-   execlists_unwind_incomplete_requests(execlists);
-
-   wait_for_guc_preempt_report(engine);
-
-   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
-   intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
-   }
+   GUC_PREEMPT_FINISHED)
+   complete_preempt_context(engine);
 
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT))
guc_dequeue(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 15434cad5430..b2781f1bb91c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -552,8 +552,18 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
 
-   execlists_clear_active(>execlists, EXECLISTS_ACTIVE_HWACK);
-   execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
+   execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
+static void complete_preempt_context(struct intel_engine_execlists *execlists)
+{
+   GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+   execlists_cancel_port_requests(execlists);
+   execlists_unwind_incomplete_requests(execlists);
+
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
 }
 
 static bool __execlists_dequeue(struct intel_engine_cs *engine)
@@ -1063,14 +1073,7 @@ static void execlists_submission_tasklet(unsigned long 
data)
if (status & GEN8_CTX_STATUS_COMPLETE &&
buf[2*head + 1] == 
execlists->preempt_complete_status) {
GEM_TRACE("%s preempt-idle\n", engine->name);
-
-   execlists_cancel_port_requests(execlists);
-   execlists_unwind_incomplete_requests(execlists);
-
-   GEM_BUG_ON(!execlists_is_active(execlists,
-   
EXECLISTS_ACTIVE_PREEMPT));
-   execlists_clear_active(execlists,
-  
EXECLISTS_ACTIVE_PREEMPT);
+   complete_preempt_context(execlists);
continue;
}
 
-- 
2.17.0

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

[Intel-gfx] [CI 4/8] drm/i915: Move engine reset prepare/finish to backends

[Chris Wilson]

In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_gem.c | 38 +++-
 drivers/gpu/drm/i915/intel_lrc.c| 47 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 23 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 +++--
 4 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 982393907b80..abf661d40641 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3004,7 +3004,7 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 struct i915_request *
 i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
 {
-   struct i915_request *request = NULL;
+   struct i915_request *request;
 
/*
 * During the reset sequence, we must prevent the engine from
@@ -3027,31 +3027,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 */
kthread_park(engine->breadcrumbs.signaler);
 
-   /*
-* Prevent request submission to the hardware until we have
-* completed the reset in i915_gem_reset_finish(). If a request
-* is completed by one engine, it may then queue a request
-* to a second via its execlists->tasklet *just* as we are
-* calling engine->init_hw() and also writing the ELSP.
-* Turning off the execlists->tasklet until the reset is over
-* prevents the race.
-*/
-   __tasklet_disable_sync_once(>execlists.tasklet);
-
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
-   if (engine->irq_seqno_barrier)
-   engine->irq_seqno_barrier(engine);
-
-   request = i915_gem_find_active_request(engine);
+   request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
 
@@ -3202,13 +3178,8 @@ void i915_gem_reset_engine(struct intel_engine_cs 
*engine,
if (request)
request = i915_gem_reset_request(engine, request, stalled);
 
-   if (request) {
-   DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 
0x%x\n",
-engine->name, request->global_seqno);
-   }
-
/* Setup the CS to resume from the breadcrumb of the hung request */
-   engine->reset_hw(engine, request);
+   engine->reset.reset(engine, request);
 }
 
 void i915_gem_reset(struct drm_i915_private *dev_priv,
@@ -3256,7 +3227,8 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
 
 void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
 {
-   tasklet_enable(>execlists.tasklet);
+   engine->reset.finish(engine);
+
kthread_unpark(engine->breadcrumbs.signaler);
 
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b2781f1bb91c..67fed98abee7 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1826,8 +1826,39 @@ static int gen9_init_render_ring(struct intel_engine_cs 
*engine)
return 0;
 }
 
-static void reset_common_ring(struct intel_engine_cs *engine,
- struct i915_request *request)
+static struct i915_request *
+execlists_reset_prepare(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its execlists->tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the execlists->tasklet until the reset is over
+* prevents the race.
+*/
+   __tasklet_disable_sync_once(>tasklet);
+
+   /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may 

[Intel-gfx] [CI 1/8] drm/i915: Remove tasklet flush before disable

[Chris Wilson]

The idea was to try and let the existing tasklet run to completion
before we began the reset, but it involves a racy check against anything
else that tries to run the tasklet. Rather than acknowledge and ignore
the race, let it be and don't try and be too clever.

The tasklet will resume execution after reset (after spinning a bit
during reset), but before we allow it to resume we will have cleared all
the pending state.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a2070112b66..0dc369a9ec4d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3035,16 +3035,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * calling engine->init_hw() and also writing the ELSP.
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
-*
-* 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 recursively being called from set-wedged from inside
-* i915_reset.
 */
-   if (!atomic_read(>execlists.tasklet.count))
-   tasklet_kill(>execlists.tasklet);
tasklet_disable(>execlists.tasklet);
 
/*
-- 
2.17.0

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

[Intel-gfx] [CI 7/8] drm/i915/execlists: Flush pending preemption events during reset

[Chris Wilson]

Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e70d8d624899..3b889bb4352a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1843,6 +1843,7 @@ static struct i915_request *
 execlists_reset_prepare(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
+   struct i915_request *request, *active;
 
GEM_TRACE("%s\n", engine->name);
 
@@ -1857,7 +1858,40 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
 */
__tasklet_disable_sync_once(>tasklet);
 
-   return i915_gem_find_active_request(engine);
+   /*
+* We want to flush the pending context switches, having disabled
+* the tasklet above, we can assume exclusive access to the execlists.
+* For this allows us to catch up with an inflight preemption event,
+* and avoid blaming an innocent request if the stall was due to the
+* preemption itself.
+*/
+   if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
+   process_csb(engine);
+
+   /*
+* The last active request can then be no later than the last request
+* now in ELSP[0]. So search backwards from there, so that if the GPU
+* has advanced beyond the last CSB update, it will be pardoned.
+*/
+   active = NULL;
+   request = port_request(execlists->port);
+   if (request) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>timeline.lock, flags);
+   list_for_each_entry_from_reverse(request,
+>timeline.requests,
+link) {
+   if (__i915_request_completed(request,
+request->global_seqno))
+   break;
+
+   active = request;
+   }
+   spin_unlock_irqrestore(>timeline.lock, flags);
+   }
+
+   return active;
 }
 
 static void execlists_reset(struct intel_engine_cs *engine,
-- 
2.17.0

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

[Intel-gfx] [CI 6/8] drm/i915/execlists: Split out CSB processing

[Chris Wilson]

Pull the CSB event processing into its own routine so that we can reuse
it during reset to flush any missed interrupts/events.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 91 ++--
 1 file changed, 52 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f5d74df0e0d0..e70d8d624899 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -957,34 +957,14 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
local_irq_restore(flags);
 }
 
-/*
- * Check the unread Context Status Buffers and manage the submission of new
- * contexts to the ELSP accordingly.
- */
-static void execlists_submission_tasklet(unsigned long data)
+static void process_csb(struct intel_engine_cs *engine)
 {
-   struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
-   struct drm_i915_private *dev_priv = engine->i915;
+   struct drm_i915_private *i915 = engine->i915;
bool fw = false;
 
-   /*
-* We can skip acquiring intel_runtime_pm_get() here as it was taken
-* on our behalf by the request (see i915_gem_mark_busy()) and it will
-* not be relinquished until the device is idle (see
-* i915_gem_idle_work_handler()). As a precaution, we make sure
-* that all ELSP are drained i.e. we have processed the CSB,
-* before allowing ourselves to idle and calling intel_runtime_pm_put().
-*/
-   GEM_BUG_ON(!dev_priv->gt.awake);
-
-   /*
-* Prefer doing test_and_clear_bit() as a two stage operation to avoid
-* imposing the cost of a locked atomic transaction when submitting a
-* new request (outside of the context-switch interrupt).
-*/
-   while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
+   do {
/* The HWSP contains a (cacheable) mirror of the CSB */
const u32 *buf =
>status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
@@ -992,28 +972,27 @@ static void execlists_submission_tasklet(unsigned long 
data)
 
if (unlikely(execlists->csb_use_mmio)) {
buf = (u32 * __force)
-   (dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-   execlists->csb_head = -1; /* force mmio read of CSB 
ptrs */
+   (i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+   execlists->csb_head = -1; /* force mmio read of CSB */
}
 
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
smp_mb__after_atomic();
 
-   if (unlikely(execlists->csb_head == -1)) { /* following a reset 
*/
+   if (unlikely(execlists->csb_head == -1)) { /* after a reset */
if (!fw) {
-   intel_uncore_forcewake_get(dev_priv,
-  
execlists->fw_domains);
+   intel_uncore_forcewake_get(i915, 
execlists->fw_domains);
fw = true;
}
 
-   head = readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+   head = readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
tail = GEN8_CSB_WRITE_PTR(head);
head = GEN8_CSB_READ_PTR(head);
execlists->csb_head = head;
} else {
const int write_idx =
-   intel_hws_csb_write_index(dev_priv) -
+   intel_hws_csb_write_index(i915) -
I915_HWS_CSB_BUF0_INDEX;
 
head = execlists->csb_head;
@@ -1022,8 +1001,8 @@ static void execlists_submission_tasklet(unsigned long 
data)
}
GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
  engine->name,
- head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
+ head, 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/7] drm/i915: Remove tasklet flush before disable (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm/i915: Remove tasklet flush before 
disable (rev2)
URL   : https://patchwork.freedesktop.org/series/43235/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4191_full -> Patchwork_9013_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9013_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9013_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43235/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9013_full:

  === IGT changes ===

 Possible regressions 

igt@drv_selftest@live_hangcheck:
  shard-kbl:  PASS -> DMESG-FAIL

igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
  shard-glk:  PASS -> FAIL


 Warnings 

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9013_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_eio@in-flight-contexts-immediate:
  shard-glk:  PASS -> FAIL (fdo#105954)

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103822)

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724)


 Possible fixes 

igt@gem_eio@in-flight-contexts-immediate:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS +5

igt@gem_eio@in-flight-internal-immediate:
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS +7

igt@gem_eio@in-flight-suspend:
  shard-kbl:  DMESG-WARN (fdo#106523) -> PASS +13

igt@gem_eio@wait-wedge-10ms:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +6
  shard-snb:  DMESG-WARN (fdo#106523) -> PASS +5

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_cursor_legacy@flip-vs-cursor-toggle:
  shard-hsw:  FAIL (fdo#102670) -> PASS

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  FAIL (fdo#104724, fdo#103822) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103558) -> PASS +1

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#105954 https://bugs.freedesktop.org/show_bug.cgi?id=105954
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4191 -> Patchwork_9013

  CI_DRM_4191: 70daebf1a83c2ed6eff118d2a2806086c0c89027 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4484: b7432bf309d5d5a6e07e8a0d8b522302fb0b4502 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9013: 20872ea9f3ce987d4221d00c243170056a0ba62d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4484: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/4] drm/dsc: Define Display Stream Compression PPS infoframe

[Harry Wentland]

On 2018-05-14 10:05 PM, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> from VESA.
> 
> v2:
> * Fix the comments for kernel-doc
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Signed-off-by: Manasi Navare 
> ---
>  include/drm/drm_dsc.h | 437 
> ++
>  1 file changed, 437 insertions(+)
>  create mode 100644 include/drm/drm_dsc.h
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> new file mode 100644
> index 000..5ee72e8
> --- /dev/null
> +++ b/include/drm/drm_dsc.h
> @@ -0,0 +1,437 @@
> +/*
> + * Copyright (C) 2018 Intel Corp.
> + *
> + * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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.
> + *
> + * Authors:
> + * Manasi Navare 
> + */
> +
> +#ifndef DRM_DSC_H_
> +#define DRM_DSC_H_
> +
> +#include 
> +
> +#define DSC_NUM_BUF_RANGES   15
> +
> +/**
> + * struct picture_parameter_set - Represents 128 bytes of Picture Parameter 
> Set
> + *
> + * The VESA DSC standard defines picture parameter set (PPS) which display 
> stream
> + * compression encoders must communicate to decoders. The PPS is encapsulated
> + * in 128 bytes (PPS 0 through PPS 127). The fields in this structure are as 
> per
> + * Table 4.1 in Vesa DSC specification v1.1/v1.2.
> + * The PPS fields that span over more than a byte should be stored in Big 
> Endian
> + * format.
> + */
> +struct picture_parameter_set {
> + /**
> +  * @dsc_version_minor:
> +  * PPS0[3:0] - Contains Minor version of DSC
> +  */
> + u8 dsc_version_minor:4;
> + /**
> +  * @dsc_version_major:
> +  * PPS0[7:4] - Contains major version of DSC
> +  */
> + u8 dsc_version_major:4;
> + /**
> +  * @pps_identifier:
> +  * PPS1[7:0] - Application specific identifier that can be
> +  * used to differentiate between different PPS tables.
> +  */
> + u8 pps_identifier;
> + /**
> +  * @pps2_reserved:
> +  * PPS2[7:0]- RESERVED Byte
> +  */
> + u8 pps2_reserved;
> + /**
> +  * @linebuf_depth:
> +  * PPS3[3:0] - Contains linebuffer bit depth used to generate
> +  * the bitstream. (0x0 - 16 bits for DSc 1.2, 0x8 - 8 bits,
> +  * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> +  * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> +  */
> + u8 linebuf_depth:4;
> + /**
> +  * @bits_per_component:
> +  * PPS3[7:4] - Bits per component fo rthe original pixels

typo: "for the"

> +  * of the encoded picture.
> +  */

Would it make sense to indicate in the comments what the values mean?

From the spec:
0x0 = 16bpc (allowed only when dsc_version_minor = 0x2).
0x8 = 8bpc.
0xA = 10bpc.
0xC = 12bpc.
0xE = 14bpc (allowed only when dsc_version_minor = 0x2).
All other encodings are RESERVED.

Harry

> + u8 bits_per_component:4;
> + /**
> +  * @bpp_high:
> +  * PPS4[1:0] - These are the most significant 2 bits of
> +  * compressed BPP bits_per_pixel[9:0] syntax element.
> +  */
> + u8 bpp_high:2;
> + /**
> +  * @vbr_enable:
> +  * PPS4[2] - 0 = VBR disabled, 1 = VBR enabled
> +  */
> + u8 vbr_enable:1;
> + /**
> +  * @simple_422:
> +  * PPS4[3] - Indicates if decoder drops samples to
> +  * reconstruct the 4:2:2 picture.
> +  */
> + u8 simple_422:1;
> + /**
> +  * @convert_rgb:
> +  * PPS4[4] - Indicates if DSC color space conversion is active
> +  */
> + u8 convert_rgb:1;
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/edp: Do not do link training fallback or prune modes 
on EDP"
URL   : https://patchwork.freedesktop.org/series/43278/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193 -> Patchwork_9021 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9021 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9021, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43278/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9021:

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9021 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_chamelium@dp-edid-read:
  fi-kbl-7500u:   PASS -> FAIL (fdo#103841)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cfl-s3:  FAIL (fdo#103481) -> PASS +1

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS


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


== Participating hosts (41 -> 36) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9021

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9021: 0b54952e8cb7b3bf9f4fe1ce697223e446573767 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

0b54952e8cb7 Revert "drm/i915/edp: Do not do link training fallback or prune 
modes on EDP"

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9021/issues.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: Call intel_opregion_notify_encoder in intel_sanitize_encoder, v2.

[Patchwork]

== Series Details ==

Series: drm/i915: Call intel_opregion_notify_encoder in intel_sanitize_encoder, 
v2.
URL   : https://patchwork.freedesktop.org/series/43243/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4191_full -> Patchwork_9012_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9012_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9012_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43243/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9012_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-vebox:
  shard-kbl:  PASS -> SKIP

igt@kms_concurrent@pipe-b:
  shard-snb:  PASS -> SKIP +1

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9012_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_gtt:
  shard-glk:  PASS -> INCOMPLETE (k.org#198133, fdo#103359)

igt@gem_eio@in-flight-internal-10ms:
  shard-glk:  PASS -> DMESG-WARN (fdo#106523)
  shard-apl:  PASS -> DMESG-WARN (fdo#106523) +1

igt@gem_eio@wait-wedge-1us:
  shard-hsw:  PASS -> DMESG-WARN (fdo#106523)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105363)

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@blocking-wf_vblank:
  shard-glk:  PASS -> FAIL (fdo#103928)

igt@kms_flip@dpms-vs-vblank-race:
  shard-kbl:  PASS -> FAIL (fdo#103060)

igt@kms_flip@modeset-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060) +1

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_flip_tiling@flip-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724)

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103822)

igt@sw_sync@alloc_fence_invalid_timeline:
  shard-apl:  PASS -> DMESG-WARN (fdo#105602, fdo#103558) +9


 Possible fixes 

igt@gem_eio@in-flight-10ms:
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS

igt@gem_eio@in-flight-contexts-1us:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +2

igt@gem_eio@in-flight-immediate:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_cursor_legacy@flip-vs-cursor-toggle:
  shard-hsw:  FAIL (fdo#102670) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
  shard-kbl:  DMESG-WARN (fdo#105602, fdo#103558) -> PASS +1

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4191 -> Patchwork_9012

  CI_DRM_4191: 70daebf1a83c2ed6eff118d2a2806086c0c89027 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4484: b7432bf309d5d5a6e07e8a0d8b522302fb0b4502 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9012: be7fdd60410068da8816294b9d91385e4ab165c5 @ 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/edp: Do not do link training fallback or prune modes 
on EDP"
URL   : https://patchwork.freedesktop.org/series/43278/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
0b54952e8cb7 Revert "drm/i915/edp: Do not do link training fallback or prune 
modes on EDP"
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#10: 
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 54, Lane count = 4

-:34: WARNING:BAD_SIGN_OFF: Duplicate signature
#34: 
Cc: Ville Syrjala 

total: 0 errors, 2 warnings, 0 checks, 31 lines checked

___
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/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Patchwork]

== Series Details ==

Series: drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
URL   : https://patchwork.freedesktop.org/series/43275/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193 -> Patchwork_9020 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9020 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9020, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43275/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9020:

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:SKIP -> PASS

igt@kms_force_connector_basic@prune-stale-modes:
  fi-snb-2600:PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_9020 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cfl-s3:  FAIL (fdo#103481) -> PASS +1

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS


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


== Participating hosts (41 -> 36) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9020

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9020: 7ccc09d99ecac09bba1c3f9247a5511a2872d96f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

7ccc09d99eca drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

== Logs ==

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

[Intel-gfx] [PATCH] Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"

[Lucas De Marchi]

This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677.

This fails on a Dell XPS13 9350 machine giving me just a black screen.
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 54, Lane count = 4
 [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
Training failed at link rate = 54, lane count = 4
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 54, Lane count = 4
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 54, Lane count = 4
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 54, Lane count = 4
 [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
Training failed at link rate = 54, lane count = 4
 [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
Training failed at link rate = 54, lane count = 4
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 54, Lane count = 4
 [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
Training failed at link rate = 54, lane count = 4
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 54, Lane count = 4
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 54, Lane count = 4
 [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link 
Training failed at link rate = 54, lane count = 4

On a working kernel, previous to this commit I have:
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
failed at link rate = 54, lane count = 4
 [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training 
Passed at Link Rate = 27, Lane count = 4

Cc: Clinton Taylor 
Cc: Jim Bride 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Manasi Navare 
Cc: Ville Syrjala 
Cc: Imre Deak 
Signed-off-by: Lucas De Marchi 
---

I'm sending this for reference and discussion only, but it doesn't seem
to be the right fix. Not only because it would mean IGT failing on CI,
but also because we seem to be having several link training running
concurrently and the last one failing leaves the panel at that state.

 drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +++
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..78f1fe934da3 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -330,22 +330,14 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
return;
 
  failure_handling:
-   /* Dont fallback and prune modes if its eDP */
-   if (!intel_dp_is_edp(intel_dp)) {
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link 
rate = %d, lane count = %d",
- intel_connector->base.base.id,
- intel_connector->base.name,
- intel_dp->link_rate, intel_dp->lane_count);
-   if (!intel_dp_get_link_train_fallback_values(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);
-   } else {
-   DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate 
= %d, lane count = %d",
- intel_connector->base.base.id,
- intel_connector->base.name,
- intel_dp->link_rate, intel_dp->lane_count);
-   }
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = 
%d, lane count = %d",
+ intel_connector->base.base.id,
+ intel_connector->base.name,
+ intel_dp->link_rate, intel_dp->lane_count);
+   if (!intel_dp_get_link_train_fallback_values(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);
return;
 }
-- 
2.17.0

___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

[Dhinakaran Pandiyan]

On Wed, 2018-05-16 at 11:08 +0300, Jani Nikula wrote:
> On Wed, 16 May 2018, vathsala nagaraju 
> wrote:
> > 
> > On Wednesday 16 May 2018 04:33 AM, Dhinakaran Pandiyan wrote:
> > > 
> > > On Mon, 2018-05-14 at 09:02 +0530, vathsala nagaraju wrote:
> > > > 
> > > > From: Vathsala Nagaraju 
> > > > 
> > > > For psr block #9, the vbt description has moved to options [0-
> > > > 3] for
> > > > TP1,TP2,TP3 Wakeup time from decimal value without any change
> > > > to vbt
> > > > structure. Since spec does not  mention from which VBT version
> > > > this
> > > > change was added to vbt.bsf file, we cannot depend on bdb-
> > > > >version
> > > > check
> > > > to change for all the platforms.
> > > > 
> > > > There is RCR inplace for GOP team to  provide the version
> > > > number
> > > > to make generic change. Since Kabylake with bdb version 209 is
> > > > having
> > > > this
> > > > change, limiting this change to gen9_bc and version 209+ to
> > > > unblock
> > > > google.
> > > > 
> > > > Tested on skl(bdb version 203,without options) and
> > > > kabylake(bdb version 209,212) having new options.
> > > > 
> > > > bspec 20131
> > > > 
> > > > v2: (Jani and Rodrigo)
> > > >  move the 165 version check to intel_bios.c
> > > > v3: Jani
> > > >  Move the abstraction to intel_bios.
> > > > v4: Jani
> > > >  Rename tp*_wakeup_time to have "us" suffix.
> > > >  For values outside range[0-3],default to max 2500us.
> > > >  Old decimal value was wake up time in multiples of 100us.
> > > > v5: Jani and Rodrigo
> > > >  Handle option 2 in default condition.
> > > >  Print oustide range value.
> > > >  For negetive values default to 2500us.
> > > > v6: Jani
> > > >  Handle default first and then fall through for case 2.
> > > > v7: Rodrigo
> > > >  Apply this change for IS_GEN9_BC and vbt version > 209
> > > > 
> > > > Cc: Rodrigo Vivi 
> > > > CC: Puthikorn Voravootivat 
> > > > 
> > > > Signed-off-by: Maulik V Vaghela 
> > > > Signed-off-by: Vathsala Nagaraju 
> > > > ---
> > > >   drivers/gpu/drm/i915/i915_drv.h   |  4 ++--
> > > >   drivers/gpu/drm/i915/i915_reg.h   |  8 +++
> > > >   drivers/gpu/drm/i915/intel_bios.c | 46
> > > > +--
> > > >   drivers/gpu/drm/i915/intel_psr.c  | 39 +-
> > > > -
> > > > --
> > > >   4 files changed, 70 insertions(+), 27 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 57fb3aa..268b059 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -1078,8 +1078,8 @@ struct intel_vbt_data {
> > > >     bool require_aux_wakeup;
> > > >     int idle_frames;
> > > >     enum psr_lines_to_wait lines_to_wait;
> > > > -   int tp1_wakeup_time;
> > > > -   int tp2_tp3_wakeup_time;
> > > > +   int tp1_wakeup_time_us;
> > > > +   int tp2_tp3_wakeup_time_us;
> > > >     } psr;
> > > >   
> > > >     struct {
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index f11bb21..6820658 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -4088,10 +4088,10 @@ enum {
> > > >   #define   EDP_Y_COORDINATE_ENABLE (1<<25) /* GLK and
> > > > CNL+ */
> > > >   #define   EDP_MAX_SU_DISABLE_TIME(t)  ((t)<<20)
> > > >   #define   EDP_MAX_SU_DISABLE_TIME_MASK(0x1f<<20)
> > > > -#define   EDP_PSR2_TP2_TIME_500(0<<8)
> > > > -#define   EDP_PSR2_TP2_TIME_100(1<<8)
> > > > -#define   EDP_PSR2_TP2_TIME_2500   (2<<8)
> > > > -#define   EDP_PSR2_TP2_TIME_50 (3<<8)
> > > > +#define   EDP_PSR2_TP2_TIME_500us  (0<<8)
> > > > +#define   EDP_PSR2_TP2_TIME_100us  (1<<8)
> > > > +#define   EDP_PSR2_TP2_TIME_2500us (2<<8)
> > > > +#define   EDP_PSR2_TP2_TIME_50us   (3<<8)
> > > >   #define   EDP_PSR2_TP2_TIME_MASK  (3<<8)
> > > >   #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
> > > >   #define   EDP_PSR2_FRAME_BEFORE_SU_MASK   (0xf<<4)
> > > > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > > > b/drivers/gpu/drm/i915/intel_bios.c
> > > > index 54270bd..695ca73 100644
> > > > --- a/drivers/gpu/drm/i915/intel_bios.c
> > > > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > > > @@ -688,8 +688,50 @@ static int intel_bios_ssc_frequency(struct
> > > > drm_i915_private *dev_priv,
> > > >     break;
> > > >     }
> > > >   
> > > > -   dev_priv->vbt.psr.tp1_wakeup_time = psr_table-
> > > > > 
> > > > > tp1_wakeup_time;
> > > > -   dev_priv->vbt.psr.tp2_tp3_wakeup_time = psr_table-
> > > > > 
> > > > > tp2_tp3_wakeup_time;
> > > > +   /*
> > > > + 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Patchwork]

== Series Details ==

Series: drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
URL   : https://patchwork.freedesktop.org/series/43275/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
7ccc09d99eca drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
-:38: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#38: FILE: drivers/gpu/drm/i915/intel_dp.c:3747:
+   if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
+   _ext, sizeof(dpcd_ext)) < 0)

total: 0 errors, 0 warnings, 1 checks, 31 lines checked

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/5] drm/i915: Remove tasklet flush before 
disable
URL   : https://patchwork.freedesktop.org/series/43267/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4193 -> Patchwork_9019 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9019 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9019, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43267/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9019:

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9019 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@read-crc-pipe-a:
  fi-skl-guc: PASS -> FAIL (fdo#103191, fdo#104724)

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
  fi-cfl-s3:  FAIL (fdo#103481) -> PASS +1

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS


  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951


== Participating hosts (41 -> 36) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4193 -> Patchwork_9019

  CI_DRM_4193: 9322e3903ce6c89bde0c24877fe730b808427caf @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9019: eb6601687e0855569aeca42b8138a4ce14a7f031 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

eb6601687e08 drm/i915: Split execlists/guc reset preparations
461179642fee drm/i915: Move engine reset prepare/finish to backends
8c2306111458 drm/i915/execlists: Refactor out complete_preempt_context()
067e2882b0ac drm/i915: Only sync tasklets once for recursive reset preparation
e26b23448efb drm/i915: Remove tasklet flush before disable

== Logs ==

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

Re: [Intel-gfx] [PATCH 5/7] drm/vmwgfx: Stop updating plane->fb

[Deepak Singh Rawat]

> 
> On Fri, Apr 06, 2018 at 10:35:00PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 06, 2018 at 07:14:51PM +, Deepak Singh Rawat wrote:
> > > This makes sense once we got rid of plane->fb
> > >
> > > Will this go to drm-next?
> >
> > The plan is to push to drm-misc-next once we get all
> > the ducks in a row.
> >
> > > Could you please CC
> > > me so that I can do some testing myself. Thanks.
> >
> > Here's a branch if you want a head start:
> > git://github.com/vsyrjala/linux.git plane_fb_crtc_nuke_2
> >
> > I'd definitely appreciate some testing of this stuff. Wouldn't
> > want to break you stuff accidentally.
> 
> Did we get anywhere with testing this? I'd like to land the remaining
> bits, but I'd feel much safer doing that if it was tested.

Hi Ville,

I did some basic mode-setting testing by taking your patches to
vmwgfx private branch and things seems to work fine.

Thanks,
Deepak

> 
> >
> > >
> > > Reviewed-by: Deepak Rawat 
> > >
> > >
> > > >
> > > > From: Ville Syrjälä 
> > > >
> > > > We want to get rid of plane->fb on atomic drivers. Stop setting it.
> > > >
> > > > Cc: Thomas Hellstrom 
> > > > Cc: Sinclair Yeh 
> > > > Cc: VMware Graphics 
> > > > Cc: Daniel Vetter 
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 --
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 --
> > > >  2 files changed, 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > > > b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > > > index 648f8127f65a..bbd3f19b1a0b 100644
> > > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > > > @@ -525,8 +525,6 @@
> vmw_sou_primary_plane_atomic_update(struct
> > > > drm_plane *plane,
> > > >  */
> > > > if (ret != 0)
> > > > DRM_ERROR("Failed to update screen.\n");
> > > > -
> > > > -   crtc->primary->fb = plane->state->fb;
> > > > } else {
> > > > /*
> > > >  * When disabling a plane, CRTC and FB should always be
> > > > NULL
> > > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > > > b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > > > index 67331f01ef32..90445bc590cb 100644
> > > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > > > @@ -1285,8 +1285,6 @@
> vmw_stdu_primary_plane_atomic_update(struct
> > > > drm_plane *plane,
> > > >  1, 1, NULL, 
> > > > crtc);
> > > > if (ret)
> > > > DRM_ERROR("Failed to update STDU.\n");
> > > > -
> > > > -   crtc->primary->fb = plane->state->fb;
> > > > } else {
> > > > crtc = old_state->crtc;
> > > > stdu = vmw_crtc_to_stdu(crtc);
> > > > --
> > > > 2.16.1
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.freedesktop.org_mailman_listinfo_intel-
> 2Dgfx=DwIDAw=uilaK90D4TOVoH58JNXRgQ=zOOG28inJK0762SxAf-
> cyZdStnd2NQpRu98lJP2iYGw=3J7W8_yE3JhMDcN3FfZN8bWZON61wueSY
> YfSGxPNHVE=TqYFqV1NCzCnakZHMWVyJ9k42n0CUm5Kcl9xW2Cdvz4=
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."
URL   : https://patchwork.freedesktop.org/series/43239/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4191_full -> Patchwork_9011_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9011_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9011_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43239/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9011_full:

  === IGT changes ===

 Possible regressions 

igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
  shard-glk:  PASS -> FAIL


 Warnings 

igt@gem_exec_schedule@deep-bsd1:
  shard-kbl:  PASS -> SKIP

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9011_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_eio@in-flight-internal-immediate:
  shard-snb:  PASS -> DMESG-WARN (fdo#106523)

igt@gem_eio@unwedge-stress:
  shard-glk:  PASS -> DMESG-WARN (fdo#106523)
  shard-apl:  PASS -> DMESG-WARN (fdo#106523) +2

igt@gem_eio@wait-wedge-1us:
  shard-hsw:  PASS -> DMESG-WARN (fdo#106523)

igt@kms_flip@flip-vs-expired-vblank:
  shard-hsw:  PASS -> FAIL (fdo#105707)
  shard-glk:  PASS -> FAIL (fdo#102887)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#102887, fdo#105363)

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@modeset-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#103822, fdo#104724)

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-pwrite:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103167) +1


 Possible fixes 

igt@gem_eio@in-flight-contexts-1us:
  shard-apl:  DMESG-WARN (fdo#106523) -> PASS +2
  shard-glk:  DMESG-WARN (fdo#106523) -> PASS

igt@gem_eio@in-flight-immediate:
  shard-hsw:  DMESG-WARN (fdo#106523) -> PASS

igt@gem_eio@in-flight-internal-10ms:
  shard-snb:  DMESG-WARN (fdo#106523) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_cursor_legacy@flip-vs-cursor-toggle:
  shard-hsw:  FAIL (fdo#102670) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#102887) -> PASS

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
  shard-kbl:  DMESG-WARN (fdo#103558, fdo#105602) -> PASS +1


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106523 https://bugs.freedesktop.org/show_bug.cgi?id=106523


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4191 -> Patchwork_9011

  CI_DRM_4191: 70daebf1a83c2ed6eff118d2a2806086c0c89027 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4484: b7432bf309d5d5a6e07e8a0d8b522302fb0b4502 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9011: 364be7a8171d6875e83da63f4bbaecda3438d215 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4484: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9011/shards.html

Re: [Intel-gfx] [PATCH v3 18/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session

[Ramalingam C]

On Wednesday 09 May 2018 07:32 PM, Shankar, Uma wrote:



-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [Intel-gfx] [PATCH v3 18/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx
Session

Request the ME to terminate the HDCP2.2 session for a port.

On Success, ME FW will mark the intel port as Deauthenticated and terminate the
wired HDCP2.2 Tx session started due to the cmd
WIRED_INITIATE_HDCP2_SESSION.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 55

include/linux/mei_hdcp.h |  7 +
2 files changed, 62 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index b5d1da41f1d9..ed402f1f2f64 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -686,6 +686,61 @@ int mei_enable_hdcp_authentication(struct
mei_cl_device *cldev,  }  EXPORT_SYMBOL(mei_enable_hdcp_authentication);

+/**
+ * me_close_hdcp_session:

Typo in me. Should be mei.

Thank you for catching it.

--Ram



+ * Function to close the Wired HDCP Tx session of ME FW.
+ * This also disables the authenticated state of the port.
+ *
+ * @data   : Intel HW specific Data
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_close_hdcp_session(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data)
+{
+   struct wired_cmd_close_session_in session_close_in = { { 0 } };
+   struct wired_cmd_close_session_out session_close_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data)
+   return -EINVAL;
+
+   dev = >dev;
+
+   session_close_in.header.api_version = HDCP_API_VERSION;
+   session_close_in.header.command_id = WIRED_CLOSE_SESSION;
+   session_close_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   session_close_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_CLOSE_SESSION_IN;
+
+   session_close_in.port.integrated_port_type = data->port_type;
+   session_close_in.port.physical_port = data->port;
+
+
+   byte = mei_cldev_send(cldev, (u8 *)_close_in,
+ sizeof(session_close_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_close_out,
+ sizeof(session_close_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (session_close_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "Session Close Failed. status: 0x%X\n",
+   session_close_out.header.status);
+   return -1;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(mei_close_hdcp_session);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
2366d0741abe..55cbde890571 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -138,6 +138,8 @@ int mei_verify_mprime(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,
  struct hdcp2_rep_stream_ready *stream_ready);  int
mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
   struct mei_hdcp_data *data);
+int mei_close_hdcp_session(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)  { @@ -216,5
+218,10 @@ static inline int mei_enable_hdcp_authentication(struct
mei_cl_device *cldev,  {
return -ENODEV;
}
+static inline int mei_close_hdcp_session(struct mei_cl_device *cldev,
+struct mei_hdcp_data *data)
+{
+   return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */  #endif /* defined
(_LINUX_MEI_HDCP_H) */
--
2.7.4

___
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 v3 17/40] misc/mei/hdcp: Enabling the HDCP authentication

[Ramalingam C]

On Wednesday 09 May 2018 07:25 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 17/40] misc/mei/hdcp: Enabling the HDCP authentication

Request to ME to configure a port as authenticated.

On Success, ME FW will mark th eport as authenticated and provides HDCP chipper

Rectify "the". Also it should be HDCP cipher.


of the port with the encryption keys.

Enabling the Authentication can be requested once the all stages of HDCP2.2
authentication is completed by interating with ME FW.

Typo in interacting.

Will fix it.

--Ram



Only after this stage, driver can enable the HDCP encryption for the port, 
through
HW registers.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 54

include/linux/mei_hdcp.h |  7 ++
2 files changed, 61 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 68eb5267a8e7..b5d1da41f1d9 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -632,6 +632,60 @@ int mei_verify_mprime(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,  }  EXPORT_SYMBOL(mei_verify_mprime);

+/**
+ * mei_enable_hdcp_authentication:
+ * Function to request ME FW to mark a port as authenticated.
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data)
+{
+   struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
+   struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data)
+   return -EINVAL;
+
+   dev = >dev;
+
+   enable_auth_in.header.api_version = HDCP_API_VERSION;
+   enable_auth_in.header.command_id = WIRED_ENABLE_AUTH;
+   enable_auth_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   enable_auth_in.header.buffer_len =
WIRED_CMD_BUF_LEN_ENABLE_AUTH_IN;
+
+   enable_auth_in.port.integrated_port_type = data->port_type;
+   enable_auth_in.port.physical_port = data->port;
+   enable_auth_in.stream_type = data->streams[0].stream_type;

Check for data->streams.


+
+   byte = mei_cldev_send(cldev, (u8 *)_auth_in,
+ sizeof(enable_auth_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_auth_out,
+ sizeof(enable_auth_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (enable_auth_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_ENABLE_AUTH,
enable_auth_out.header.status);
+   return -1;
+   }

Leave a blank line here.


+   return 0;
+}
+EXPORT_SYMBOL(mei_enable_hdcp_authentication);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
dbc216e13f97..2366d0741abe 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -136,6 +136,8 @@ mei_repeater_check_flow_prepare_ack(struct
mei_cl_device *cldev,
struct hdcp2_rep_send_ack *rep_send_ack);
int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
  struct hdcp2_rep_stream_ready *stream_ready);
+int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)  { @@ -209,5
+211,10 @@ int mei_verify_mprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,  {
return -ENODEV;
}
+static inline int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
+struct mei_hdcp_data *data)
+{
+   return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */  #endif /* defined
(_LINUX_MEI_HDCP_H) */
--
2.7.4

___

Re: [Intel-gfx] [PATCH v3 15/40] misc/mei/hdcp: Repeater topology verifcation and ack

[Ramalingam C]

On Wednesday 09 May 2018 04:34 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 15/40] misc/mei/hdcp: Repeater topology verifcation and ack

Typo in verification.


Request ot ME to verify the downatream topology information received.

"To" misspelled. Also typo in downstream.

ok. Will fix it.



ME FW will validate the Repeaters receiver id list and downstream topology.

On Success ME FW will provide the Least Significant 128bits of VPrime, which
forms the repeater ack.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 75

include/linux/mei_hdcp.h | 15 
2 files changed, 90 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index abfcc57863b8..64fcecfa5b10 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -478,6 +478,81 @@ int mei_get_session_key(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,  }  EXPORT_SYMBOL(mei_get_session_key);

+/**
+ * mei_repeater_check_flow_prepare_ack:
+ * Function to validate the Downstream topology and prepare rep_ack.
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @rep_topology   : Pointer for Receiver Id List to be validated.
+ * @rep_send_ack   : Pointer for repeater ack
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+
+int
+mei_repeater_check_flow_prepare_ack(struct mei_cl_device *cldev,
+   struct mei_hdcp_data *data,
+   struct hdcp2_rep_send_receiverid_list
+   *rep_topology,
+   struct hdcp2_rep_send_ack *rep_send_ack) {
+   struct wired_cmd_verify_repeater_in verify_repeater_in = { { 0 } };
+   struct wired_cmd_verify_repeater_out verify_repeater_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!rep_topology || !rep_send_ack || !data)
+   return -EINVAL;
+
+   dev = >dev;
+
+   verify_repeater_in.header.api_version = HDCP_API_VERSION;
+   verify_repeater_in.header.command_id = WIRED_VERIFY_REPEATER;
+   verify_repeater_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_repeater_in.header.buffer_len =
+
WIRED_CMD_BUF_LEN_VERIFY_REPEATER_IN;
+
+   verify_repeater_in.port.integrated_port_type = data->port_type;
+   verify_repeater_in.port.physical_port = data->port;
+
+   memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
+  HDCP_2_2_RXINFO_LEN);
+   memcpy(verify_repeater_in.seq_num_v, rep_topology->seq_num_v,
+  HDCP_2_2_SEQ_NUM_LEN);
+   memcpy(verify_repeater_in.v_prime, rep_topology->v_prime,
+  HDCP_2_2_LPRIME_HALF_LEN);
+   memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
+  HDCP_2_2_RECEIVER_IDS_MAX_LEN);

Check for validity of rep_topology->... pointers.


+
+   byte = mei_cldev_send(cldev, (u8 *)_repeater_in,
+ sizeof(verify_repeater_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_repeater_out,
+ sizeof(verify_repeater_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (verify_repeater_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_VERIFY_REPEATER,
+   verify_repeater_out.header.status);
+   return -1;
+   }
+
+   memcpy(rep_send_ack->v, verify_repeater_out.v,

Same as above.


+  HDCP_2_2_LPRIME_HALF_LEN);
+   rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;

Leave a blank line here.

Ok.

--Ram



+   return 0;
+}
+EXPORT_SYMBOL(mei_repeater_check_flow_prepare_ack);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
534170d746af..46e2dc295d03 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -128,6 +128,12 @@ int 

Re: [Intel-gfx] [PATCH v3 16/40] misc/mei/hdcp: Verify M_prime

[Ramalingam C]

On Wednesday 09 May 2018 07:20 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 16/40] misc/mei/hdcp: Verify M_prime

Request to ME to verify the M_Prime received from the HDCP sink.

ME FW will calculate the M and compare with M_prime received as part of
RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.

On successful completion of this stage, downstream propagation of the stream
management info is completed.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 79

include/linux/mei_hdcp.h |  8 
2 files changed, 87 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 64fcecfa5b10..68eb5267a8e7 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -553,6 +553,85 @@ mei_repeater_check_flow_prepare_ack(struct
mei_cl_device *cldev,  }
EXPORT_SYMBOL(mei_repeater_check_flow_prepare_ack);

+static inline void reverse_endianness(u8 *dest, size_t dst_sz, u8 *src)

Function with loop ideally should not be inline.

Thanks for catching it.



+{
+   u32 index;
+
+   if (dest != NULL && dst_sz != 0) {

Good to check for src as well. Also this function will not do anything if these
check fails with caller not even been aware of the failure. Atleast return an
error or make sure no parameter validation happens here and its done by calling
function.

bit rewriting this function. Thanks

--Ram



+   for (index = 0; index < dst_sz && index < sizeof(u32);
+index++) {
+   dest[dst_sz - index - 1] = src[index];
+   }
+   }
+}
+
+/**
+ * mei_verify_mprime:
+ * Function to verify mprime.
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @stream_ready   : pointer for RepeaterAuth_Stream_Ready message.
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
+ struct hdcp2_rep_stream_ready *stream_ready) {
+   struct wired_cmd_repeater_auth_stream_req_in
+   verify_mprime_in = { { 0 } };
+   struct wired_cmd_repeater_auth_stream_req_out
+   verify_mprime_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!stream_ready || !data)
+   return -EINVAL;
+
+   dev = >dev;
+
+   verify_mprime_in.header.api_version = HDCP_API_VERSION;
+   verify_mprime_in.header.command_id =
WIRED_REPEATER_AUTH_STREAM_REQ;
+   verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_mprime_in.header.buffer_len =
+
WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
+
+   verify_mprime_in.port.integrated_port_type = data->port_type;
+   verify_mprime_in.port.physical_port = data->port;
+
+   memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,

Validate stream_ready->m_prime.


+  HDCP_2_2_MPRIME_LEN);
+   reverse_endianness((u8 *)_mprime_in.seq_num_m,
+  HDCP_2_2_SEQ_NUM_LEN, (u8 *)

seq_num_m);

+   memcpy(verify_mprime_in.streams, data->streams,

Validate data->streams.


+  (data->k * sizeof(struct hdcp2_streamid_type)));
+
+   verify_mprime_in.k = __swab16(data->k);
+
+   byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
+ sizeof(verify_mprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_mprime_out,
+ sizeof(verify_mprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (verify_mprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_REPEATER_AUTH_STREAM_REQ,
+   verify_mprime_out.header.status);
+   return -1;
+   }

Leave a blank line here.


+   return 0;
+}
+EXPORT_SYMBOL(mei_verify_mprime);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git 

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Use offsetofend() rather than offsetof + sizeof

[Chris Wilson]

Quoting Mika Kuoppala (2017-03-16 09:37:44)
> Chris Wilson  writes:
> 
> > Compute the offset of the end of the crc32 field using offsetofend()
> > rather than open-coding.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Zhenyu Wang 
> > Cc: Zhi Wang 
> 
> Reviewed-by: Mika Kuoppala 

This still applies...

> > ---
> >  drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
> > b/drivers/gpu/drm/i915/gvt/firmware.c
> > index 933a7c211a1c..3a5a81fcb406 100644
> > --- a/drivers/gpu/drm/i915/gvt/firmware.c
> > +++ b/drivers/gpu/drm/i915/gvt/firmware.c
> > @@ -159,7 +159,7 @@ static int verify_firmware(struct intel_gvt *gvt,
> >  
> >   h = (struct gvt_firmware_header *)fw->data;
> >  
> > - crc32_start = offsetof(struct gvt_firmware_header, crc32) + 4;
> > + crc32_start = offsetofend(struct gvt_firmware_header, crc32);
> >   mem = fw->data + crc32_start;
> >  
> >  #define VERIFY(s, a, b) do { \
> > -- 
> > 2.11.0
> >
> > ___
> > 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] [PATCH] drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[matthew . s . atwood]

From: Matt Atwood 

According to DP spec (2.9.3.1 of DP 1.4) if
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
02200h through 0220Fh shall contain the DPRX's true capability. These
values will match 0h through Fh, except for DPCD_REV,
MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.

Read from DPCD once for all 3 values as this is an expensive operation.
Spec mentions that all of address space 02200h through 0220Fh should
contain the right information however currently only 3 values can
differ.

There is no address space in the intel_dp->dpcd struct for addresses
02200h through 0220Fh, and since so much of the data is a identical,
simply overwrite the values stored in 0h through Fh with the
values that can be overwritten from addresses 02200h through 0220Fh

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/i915/intel_dp.c | 14 ++
 include/drm/drm_dp_helper.h |  5 +++--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dde92e4af5d3..899ebc5cece6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3738,6 +3738,20 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
 sizeof(intel_dp->dpcd)) < 0)
return false; /* aux transfer failed */
 
+   if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+   DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT &&
+   intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14) {
+   uint8_t dpcd_ext[16];
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
+   _ext, sizeof(dpcd_ext)) < 0)
+   return false; /* aux transfer failed */
+
+   intel_dp->dpcd[DP_DPCD_REV] = dpcd_ext[DP_DPCD_REV];
+   intel_dp->dpcd[DP_MAX_LINK_RATE] = dpcd_ext[DP_MAX_LINK_RATE];
+   intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] =
+   dpcd_ext[DP_DOWNSTREAMPORT_PRESENT];
+   }
DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
intel_dp->dpcd);
 
return intel_dp->dpcd[DP_DPCD_REV] != 0;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c01564991a9f..757bd5913f3d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -123,8 +123,9 @@
 # define DP_FRAMING_CHANGE_CAP (1 << 1)
 # 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/* XXX 1.2? */
+#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
+# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* XXX 1.2? */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH v3 14/40] misc/mei/hdcp: Prepare Session Key

[Ramalingam C]

On Wednesday 09 May 2018 04:29 PM, Shankar, Uma wrote:



-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [Intel-gfx] [PATCH v3 14/40] misc/mei/hdcp: Prepare Session Key

Request to ME to prepare the encrypted session key.

On Success, ME provides Encrypted session key. Functions populates the HDCP2.2

Drop "s" from function.

ok. Thanks.



authentication msg SKE_Send_Eks.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 58

include/linux/mei_hdcp.h |  8 ++
2 files changed, 66 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index ea84177311b7..abfcc57863b8 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -420,6 +420,64 @@ int mei_verify_lprime(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,  }  EXPORT_SYMBOL(mei_verify_lprime);

+/**
+ * mei_get_session_key:
+ * Function to prepare SKE_Send_Eks.
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @ske_data   : Pointer for SKE_Send_Eks.
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
+   struct hdcp2_ske_send_eks *ske_data) {
+   struct wired_cmd_get_session_key_in get_skey_in = { { 0 } };
+   struct wired_cmd_get_session_key_out get_skey_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !ske_data)
+   return -EINVAL;
+
+   dev = >dev;
+
+   get_skey_in.header.api_version = HDCP_API_VERSION;
+   get_skey_in.header.command_id = WIRED_GET_SESSION_KEY;
+   get_skey_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   get_skey_in.header.buffer_len =
WIRED_CMD_BUF_LEN_GET_SESSION_KEY_IN;
+
+   get_skey_in.port.integrated_port_type = data->port_type;
+   get_skey_in.port.physical_port = data->port;
+
+   byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_skey_out,
+sizeof(get_skey_out));
+
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (get_skey_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_GET_SESSION_KEY,
get_skey_out.header.status);
+   return -1;
+   }
+
+   ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
+   memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,

Check for validity of ske_data->e_dkey_ks.


+  HDCP_2_2_E_DKEY_KS_LEN);
+   memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);

Again check  for ske_data->riv. Also leave a blank line here.

New line will be added

--Ram



+   return 0;
+}
+EXPORT_SYMBOL(mei_get_session_key);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
792143563c46..534170d746af 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -126,6 +126,8 @@ int mei_initiate_locality_check(struct mei_cl_device
*cldev,
struct hdcp2_lc_init *lc_init_data);  int
mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
  struct hdcp2_lc_send_lprime *rx_lprime);
+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
+   struct hdcp2_ske_send_eks *ske_data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)  { @@ -178,5
+180,11 @@ int mei_verify_lprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,  {
return -ENODEV;
}
+static inline
+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
*data,
+   struct hdcp2_ske_send_eks *ske_data) {
+   return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */  #endif /* defined
(_LINUX_MEI_HDCP_H) */
--
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH v3 13/40] misc/mei/hdcp: Verify L_prime

[Ramalingam C]

On Wednesday 09 May 2018 04:06 PM, Shankar, Uma wrote:



-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [Intel-gfx] [PATCH v3 13/40] misc/mei/hdcp: Verify L_prime

Request to ME to verify the LPrime received from HDCP sink.

On Success, ME FW will verify the received Lprime by calculating and comparing
with L.

This represents the completion of Locality Check.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 59

include/linux/mei_hdcp.h |  8 ++
2 files changed, 67 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 9bd7e66a91e4..ea84177311b7 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -361,6 +361,65 @@ int mei_initiate_locality_check(struct mei_cl_device
*cldev,  }  EXPORT_SYMBOL(mei_initiate_locality_check);

+/**
+ * mei_verify_lprime:
+ * Function to verify lprime.
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @rx_lprime  : Pointer for LC_Send_L_prime
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_lc_send_lprime *rx_lprime) {
+   struct wired_cmd_validate_locality_in verify_lprime_in = { { 0 } };
+   struct wired_cmd_validate_locality_out verify_lprime_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !rx_lprime)
+   return -EINVAL;
+
+   dev = >dev;
+
+   verify_lprime_in.header.api_version = HDCP_API_VERSION;
+   verify_lprime_in.header.command_id = WIRED_VALIDATE_LOCALITY;
+   verify_lprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_lprime_in.header.buffer_len =
+
WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
+
+   verify_lprime_in.port.integrated_port_type = data->port_type;
+   verify_lprime_in.port.physical_port = data->port;
+
+   memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,

Validate rx_lprime->l_prime for NULL


+  sizeof(rx_lprime->l_prime));
+
+   byte = mei_cldev_send(cldev, (u8 *)_lprime_in,
+ sizeof(verify_lprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_lprime_out,
+ sizeof(verify_lprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (verify_lprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_VALIDATE_LOCALITY,
+   verify_lprime_out.header.status);
+   return -1;
+   }

Leave a blank line.

Ok sure.
--Ram



+   return 0;
+}
+EXPORT_SYMBOL(mei_verify_lprime);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
d9c4cac0b276..792143563c46 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -124,6 +124,8 @@ int mei_store_pairing_info(struct mei_cl_device *cldev,
int mei_initiate_locality_check(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,
struct hdcp2_lc_init *lc_init_data);
+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_lc_send_lprime *rx_lprime);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)  { @@ -170,5
+172,11 @@ int mei_initiate_locality_check(struct mei_cl_device *cldev,  {
return -ENODEV;
}
+static inline
+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_lc_send_lprime *rx_lprime) {
+   return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */  #endif /* defined
(_LINUX_MEI_HDCP_H) */
--
2.7.4

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


___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH v3 12/40] misc/mei/hdcp: Initiate Locality check

[Ramalingam C]

On Wednesday 09 May 2018 04:01 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 12/40] misc/mei/hdcp: Initiate Locality check

Requests ME to start the second stage of HDCP2.2 authentication, called Locality
Check.

On Success, ME FW will provide LC_Init message to send to hdcp sink.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 56

include/linux/mei_hdcp.h | 10 +++
2 files changed, 66 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 60afdd0cee79..9bd7e66a91e4 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -305,6 +305,62 @@ int mei_store_pairing_info(struct mei_cl_device *cldev,
}  EXPORT_SYMBOL(mei_store_pairing_info);

+/**
+ * mei_initiate_locality_check:
+ * Function to prepare LC_Init.
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @hdcp2_lc_init  : Pointer for storing LC_Init
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_initiate_locality_check(struct mei_cl_device *cldev,
+   struct mei_hdcp_data *data,
+   struct hdcp2_lc_init *lc_init_data) {
+   struct wired_cmd_init_locality_check_in lc_init_in = { { 0 } };
+   struct wired_cmd_init_locality_check_out lc_init_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !lc_init_data)
+   return -EINVAL;
+
+   dev = >dev;
+
+   lc_init_in.header.api_version = HDCP_API_VERSION;
+   lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
+   lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   lc_init_in.header.buffer_len =
+WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
+
+   lc_init_in.port.integrated_port_type = data->port_type;
+   lc_init_in.port.physical_port = data->port;
+
+   byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_init_out, sizeof(lc_init_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (lc_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. status: 0x%X\n",
+   WIRED_INIT_LOCALITY_CHECK,
lc_init_out.header.status);
+   return -1;
+   }
+
+   lc_init_data->msg_id = HDCP_2_2_LC_INIT;
+   memcpy(lc_init_data->r_n, lc_init_out.r_n, HDCP_2_2_RN_LEN);

Check for validity of lc_init_data->r_n.
Also, leave a blank line.

ok

--Ram



+   return 0;
+}
+EXPORT_SYMBOL(mei_initiate_locality_check);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
be16e49d8018..d9c4cac0b276 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -121,6 +121,9 @@ int mei_verify_hprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,  int mei_store_pairing_info(struct mei_cl_device *cldev,
   struct mei_hdcp_data *data,
   struct hdcp2_ake_send_pairing_info *pairing_info);
+int mei_initiate_locality_check(struct mei_cl_device *cldev,
+   struct mei_hdcp_data *data,
+   struct hdcp2_lc_init *lc_init_data);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)  { @@ -160,5
+163,12 @@ int mei_store_pairing_info(struct mei_cl_device *cldev,  {
return -ENODEV;
}
+static inline
+int mei_initiate_locality_check(struct mei_cl_device *cldev,
+   struct mei_hdcp_data *data,
+   struct hdcp2_lc_init *lc_init_data) {
+   return -ENODEV;
+}
#endif /* defined (CONFIG_INTEL_MEI_HDCP) */  #endif /* defined
(_LINUX_MEI_HDCP_H) */
--
2.7.4

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


___
Intel-gfx mailing list

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm/i915: Remove tasklet flush before disable
URL   : https://patchwork.freedesktop.org/series/43266/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4192 -> Patchwork_9018 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9018 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9018, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43266/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9018:

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_9018 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-cnl-y3:  PASS -> DMESG-FAIL (fdo#103191, fdo#104724)


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


== Participating hosts (42 -> 35) ==

  Missing(7): fi-ilk-m540 fi-byt-j1900 fi-byt-squawks fi-bsw-cyan 
fi-snb-2520m fi-ctg-p8600 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4192 -> Patchwork_9018

  CI_DRM_4192: 302c1fbc4ca78140f408775ae39d32fc83ef0d41 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9018: 7514a35d14f296206d24a9fefe58d0dcb103a4de @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

7514a35d14f2 drm/i915: Stop parking the signaler around reset
c1180f81daa9 drm/i915/execlists: Flush pending preemption events during reset
3534fd5c5b56 drm/i915/execlists: Split out CSB processing
8b09105ec2fa drm/i915: Split execlists/guc reset preparations
10be65911411 drm/i915/execlists: Refactor out complete_preempt_context()
c805538685f8 drm/i915: Only sync tasklets once for recursive reset preparation
918420a1f591 drm/i915: Remove tasklet flush before disable

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info

[Ramalingam C]

On Wednesday 09 May 2018 03:58 PM, Shankar, Uma wrote:



-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info

Provides Pairing info to ME to store.

Pairing is a process to fast track the subsequent authentication with the same
HDCP sink.

On Success, received HDCP pairing info is stored in non-volatile memory of ME.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 61

include/linux/mei_hdcp.h | 10 +++
2 files changed, 71 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index fa548310de7a..60afdd0cee79 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -244,6 +244,67 @@ int mei_verify_hprime(struct mei_cl_device *cldev,
struct mei_hdcp_data *data,  }  EXPORT_SYMBOL(mei_verify_hprime);

+/**

Drop the extra *, unless you really love it :)
ha ha. Actually I have added intentionally. But removing them across all 
patches

as per your suggestions. :)



+ * mei_store_pairing_info:
+ * Function to store pairing info received from panel
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @pairing_info   : Pointer for AKE_Send_Pairing_Info
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+
+int mei_store_pairing_info(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data,
+  struct hdcp2_ake_send_pairing_info *pairing_info) {
+   struct wired_cmd_ake_send_pairing_info_in pairing_info_in = { { 0 } };
+   struct wired_cmd_ake_send_pairing_info_out pairing_info_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !pairing_info)
+   return -EINVAL;
+
+   dev = >dev;
+
+   pairing_info_in.header.api_version = HDCP_API_VERSION;
+   pairing_info_in.header.command_id =
WIRED_AKE_SEND_PAIRING_INFO;
+   pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   pairing_info_in.header.buffer_len =
+
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
+
+   pairing_info_in.port.integrated_port_type = data->port_type;
+   pairing_info_in.port.physical_port = data->port;
+
+   memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,

Validate pairing_info->e_kh_km for NULL.

As we discussed we need not check for null here.



+  sizeof(pairing_info_in.e_kh_km));
+
+   byte = mei_cldev_send(cldev, (u8 *)_info_in,
+ sizeof(pairing_info_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_info_out,
+ sizeof(pairing_info_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
+   WIRED_AKE_SEND_PAIRING_INFO,
+   pairing_info_out.header.status);
+   return -1;
+   }

Leave a blank line here.

sure. I will do it in all patches. Thanks.

--Ram



+   return 0;
+}
+EXPORT_SYMBOL(mei_store_pairing_info);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
00bfde251ba4..be16e49d8018 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -118,6 +118,9 @@ mei_verify_receiver_cert_prepare_km(struct
mei_cl_device *cldev,
size_t *msg_sz);
int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
  struct hdcp2_ake_send_hprime *rx_hprime);
+int mei_store_pairing_info(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data,
+  struct hdcp2_ake_send_pairing_info *pairing_info);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)  { @@ -150,5
+153,12 @@ int mei_verify_hprime(struct mei_cl_device *cldev, struct
mei_hdcp_data *data,  {
return -ENODEV;
}
+static inline
+int mei_store_pairing_info(struct 

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-16 16:40:55)
> 
> On 15/05/2018 10:05, Tvrtko Ursulin wrote:
> > 
> > On 14/05/2018 16:56, Lionel Landwerlin wrote:
> >> From: Chris Wilson 
> >>
> >> We want to allow userspace to reconfigure the subslice configuration for
> >> its own use case. To do so, we expose a context parameter to allow
> >> adjustment of the RPCS register stored within the context image (and
> >> currently not accessible via LRI). If the context is adjusted before
> >> first use, the adjustment is for "free"; otherwise if the context is
> >> active we flush the context off the GPU (stalling all users) and forcing
> >> the GPU to save the context to memory where we can modify it and so
> >> ensure that the register is reloaded on next execution.
> >>
> >> The overhead of managing additional EU subslices can be significant,
> >> especially in multi-context workloads. Non-GPGPU contexts should
> >> preferably disable the subslices it is not using, and others should
> >> fine-tune the number to match their workload.
> >>
> >> We expose complete control over the RPCS register, allowing
> >> configuration of slice/subslice, via masks packed into a u64 for
> >> simplicity. For example,
> >>
> >> struct drm_i915_gem_context_param arg;
> >> struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
> >>     .instance = 0, };
> >>
> >> memset(, 0, sizeof(arg));
> >> arg.ctx_id = ctx;
> >> arg.param = I915_CONTEXT_PARAM_SSEU;
> >> arg.value = (uintptr_t) 
> >> if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
> >>     sseu.packed.subslice_mask = 0;
> >>
> >>     drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
> >> }
> >>
> >> could be used to disable all subslices where supported.
> >>
> >> v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() 
> >> (Lionel)
> >>
> >> v3: Add ability to program this per engine (Chris)
> >>
> >> v4: Move most get_sseu() into i915_gem_context.c (Lionel)
> >>
> >> v5: Validate sseu configuration against the device's capabilities 
> >> (Lionel)
> >>
> >> v6: Change context powergating settings through MI_SDM on kernel 
> >> context (Chris)
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
> >> Signed-off-by: Chris Wilson 
> >> Signed-off-by: Lionel Landwerlin 
> >> c: Dmitry Rogozhkin 
> >> CC: Tvrtko Ursulin 
> >> CC: Zhipeng Gong 
> >> CC: Joonas Lahtinen 
> >> ---
> >>   drivers/gpu/drm/i915/i915_gem_context.c | 169 
> >>   drivers/gpu/drm/i915/intel_lrc.c    | 103 ++-
> >>   drivers/gpu/drm/i915/intel_ringbuffer.c |   2 +
> >>   drivers/gpu/drm/i915/intel_ringbuffer.h |   4 +
> >>   include/uapi/drm/i915_drm.h |  38 ++
> >>   5 files changed, 281 insertions(+), 35 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> >> b/drivers/gpu/drm/i915/i915_gem_context.c
> >> index 01310c99e032..0b72a771c3f3 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> >> @@ -734,6 +734,110 @@ int i915_gem_context_destroy_ioctl(struct 
> >> drm_device *dev, void *data,
> >>   return 0;
> >>   }
> >> +static int
> >> +intel_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
> >> +  const struct drm_i915_gem_context_param_sseu *user_sseu,
> >> +  union intel_sseu *ctx_sseu)
> >> +{
> >> +    if ((user_sseu->slice_mask & ~sseu->slice_mask) != 0 ||
> >> +    user_sseu->slice_mask == 0)
> >> +    return -EINVAL;
> >> +
> >> +    if ((user_sseu->subslice_mask & ~sseu->subslice_mask[0]) != 0 ||
> >> +    user_sseu->subslice_mask == 0)
> >> +    return -EINVAL;
> >> +
> >> +    if (user_sseu->min_eus_per_subslice > sseu->max_eus_per_subslice)
> >> +    return -EINVAL;
> >> +
> >> +    if (user_sseu->max_eus_per_subslice > sseu->max_eus_per_subslice ||
> >> +    user_sseu->max_eus_per_subslice < 
> >> user_sseu->min_eus_per_subslice ||
> >> +    user_sseu->max_eus_per_subslice == 0)
> >> +    return -EINVAL;
> >> +
> >> +    ctx_sseu->slice_mask = user_sseu->slice_mask;
> >> +    ctx_sseu->subslice_mask = user_sseu->subslice_mask;
> >> +    ctx_sseu->min_eus_per_subslice = user_sseu->min_eus_per_subslice;
> >> +    ctx_sseu->max_eus_per_subslice = user_sseu->max_eus_per_subslice;
> >> +
> >> +    return 0;
> >> +}
> >> +
> >> +static int
> >> +i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
> >> +  struct intel_engine_cs *engine,
> >> +  union intel_sseu sseu)
> >> +{
> >> +    struct drm_i915_private *dev_priv = ctx->i915;
> >> +    struct i915_timeline *timeline;
> >> +    struct i915_request *rq;
> >> +    union 

Re: [Intel-gfx] [PATCH v3 10/40] misc/mei/hdcp: Verify H_prime

[Ramalingam C]

On Wednesday 09 May 2018 03:46 PM, Shankar, Uma wrote:



-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [Intel-gfx] [PATCH v3 10/40] misc/mei/hdcp: Verify H_prime

Requests for the verifcation of AKE_Send_H_prime.

Typo in verification.

thanks :)



ME will calculation the H and comparing it with received H_Prime.

Change to "calculate". Also change "comparing" to "compares".


Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.

v2:
  Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 58

include/linux/mei_hdcp.h |  8 ++
2 files changed, 66 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 181994529058..fa548310de7a 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -186,6 +186,64 @@ mei_verify_receiver_cert_prepare_km(struct
mei_cl_device *cldev,  }
EXPORT_SYMBOL(mei_verify_receiver_cert_prepare_km);

+/**
+ * mei_verify_hprime:
+ * Function to verify AKE_Send_H_prime received
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @rx_hprime  : Pointer for AKE_Send_H_prime
+ * @hprime_sz  : Input buffer size
+ *
+ * Returns 0 on Success, <0 on Failure
+ */
+int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_hprime *rx_hprime) {
+   struct wired_cmd_ake_send_hprime_in send_hprime_in = { { 0 } };
+   struct wired_cmd_ake_send_hprime_out send_hprime_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !rx_hprime)
+   return -EINVAL;
+
+   dev = >dev;
+
+   send_hprime_in.header.api_version = HDCP_API_VERSION;
+   send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
+   send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   send_hprime_in.header.buffer_len =
+WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
+
+   send_hprime_in.port.integrated_port_type = data->port_type;
+   send_hprime_in.port.physical_port = data->port;
+
+   memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,

Need to validate rx_hprime->h_prime for NULL.
h_prime is statically allocated array within rx_hprime. So we need not 
check .

+  sizeof(rx_hprime->h_prime));
+
+   byte = mei_cldev_send(cldev, (u8 *)_hprime_in,
+ sizeof(send_hprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_hprime_out,
+ sizeof(send_hprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_AKE_SEND_HPRIME,
send_hprime_out.header.status);
+   return -1;
+   }

Leave a blank line here.

Sure.

+   return 0;

One clarification required - the h prime value sent and received are not 
compared here. So, whether
hw matches them and returns success only if they match or it just returns the H 
prime value
and driver should compare ?
This shows that commit message need an edit :). Yes, ME FW calculate the 
hprime and compare it with the received hprime.

Returns the comparition result at send_hprime_out.header.status.

--Ram



+}
+EXPORT_SYMBOL(mei_verify_hprime);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
314b15f6afc0..00bfde251ba4 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -116,6 +116,8 @@ mei_verify_receiver_cert_prepare_km(struct
mei_cl_device *cldev,
bool *km_stored,
struct hdcp2_ake_no_stored_km
*ek_pub_km,
size_t *msg_sz);
+int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
+ struct hdcp2_ake_send_hprime *rx_hprime);
#else
static int mei_cldev_register_notify(struct notifier_block *nb)  { @@ -142,5
+144,11 @@ 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm/i915: Remove tasklet flush before disable
URL   : https://patchwork.freedesktop.org/series/43266/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
918420a1f591 drm/i915: Remove tasklet flush before disable
c805538685f8 drm/i915: Only sync tasklets once for recursive reset preparation
10be65911411 drm/i915/execlists: Refactor out complete_preempt_context()
8b09105ec2fa drm/i915: Split execlists/guc reset preparations
3534fd5c5b56 drm/i915/execlists: Split out CSB processing
-:67: WARNING:LONG_LINE: line over 100 characters
#67: FILE: drivers/gpu/drm/i915/intel_lrc.c:975:
+   (i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));

-:85: WARNING:LONG_LINE: line over 100 characters
#85: FILE: drivers/gpu/drm/i915/intel_lrc.c:989:
+   head = readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));

-:102: WARNING:LONG_LINE: line over 100 characters
#102: FILE: drivers/gpu/drm/i915/intel_lrc.c:1004:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",

-:103: WARNING:LONG_LINE: line over 100 characters
#103: FILE: drivers/gpu/drm/i915/intel_lrc.c:1005:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");

total: 0 errors, 4 warnings, 0 checks, 144 lines checked
c1180f81daa9 drm/i915/execlists: Flush pending preemption events during reset
7514a35d14f2 drm/i915: Stop parking the signaler around reset

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Remove tasklet flush before disable

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915: Remove tasklet flush before 
disable
URL   : https://patchwork.freedesktop.org/series/43265/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4192 -> Patchwork_9017 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43265/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_9017 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS


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


== Participating hosts (42 -> 36) ==

  Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-snb-2520m 
fi-ctg-p8600 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4192 -> Patchwork_9017

  CI_DRM_4192: 302c1fbc4ca78140f408775ae39d32fc83ef0d41 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9017: 7669ce457042d7dce4273c7af7f918d950ce6943 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4485: 62ef6b0db8967e7021fd3e0b57d03ff164b984fe @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

7669ce457042 drm/i915: Split execlists/guc reset preparations
f8ac5d1c59da drm/i915/execlists: Refactor out complete_preempt_context()
d34066ad981d drm/i915: Only sync tasklets once for recursive reset preparation
a922ad85546a drm/i915: Remove tasklet flush before disable

== Logs ==

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

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Lionel Landwerlin]

On 16/05/18 16:40, Tvrtko Ursulin wrote:


On 15/05/2018 10:05, Tvrtko Ursulin wrote:


On 14/05/2018 16:56, Lionel Landwerlin wrote:

From: Chris Wilson 

We want to allow userspace to reconfigure the subslice configuration 
for

its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and 
forcing

the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.

The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.

We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,

struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
    .instance = 0, };

memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) 
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
    sseu.packed.subslice_mask = 0;

    drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}

could be used to disable all subslices where supported.

v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() 
(Lionel)


v3: Add ability to program this per engine (Chris)

v4: Move most get_sseu() into i915_gem_context.c (Lionel)

v5: Validate sseu configuration against the device's capabilities 
(Lionel)


v6: Change context powergating settings through MI_SDM on kernel 
context (Chris)


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
c: Dmitry Rogozhkin 
CC: Tvrtko Ursulin 
CC: Zhipeng Gong 
CC: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem_context.c | 169 


  drivers/gpu/drm/i915/intel_lrc.c    | 103 ++-
  drivers/gpu/drm/i915/intel_ringbuffer.c |   2 +
  drivers/gpu/drm/i915/intel_ringbuffer.h |   4 +
  include/uapi/drm/i915_drm.h |  38 ++
  5 files changed, 281 insertions(+), 35 deletions(-)

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

index 01310c99e032..0b72a771c3f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -734,6 +734,110 @@ int i915_gem_context_destroy_ioctl(struct 
drm_device *dev, void *data,

  return 0;
  }
+static int
+intel_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
+  const struct drm_i915_gem_context_param_sseu *user_sseu,
+  union intel_sseu *ctx_sseu)
+{
+    if ((user_sseu->slice_mask & ~sseu->slice_mask) != 0 ||
+    user_sseu->slice_mask == 0)
+    return -EINVAL;
+
+    if ((user_sseu->subslice_mask & ~sseu->subslice_mask[0]) != 0 ||
+    user_sseu->subslice_mask == 0)
+    return -EINVAL;
+
+    if (user_sseu->min_eus_per_subslice > sseu->max_eus_per_subslice)
+    return -EINVAL;
+
+    if (user_sseu->max_eus_per_subslice > 
sseu->max_eus_per_subslice ||
+    user_sseu->max_eus_per_subslice < 
user_sseu->min_eus_per_subslice ||

+    user_sseu->max_eus_per_subslice == 0)
+    return -EINVAL;
+
+    ctx_sseu->slice_mask = user_sseu->slice_mask;
+    ctx_sseu->subslice_mask = user_sseu->subslice_mask;
+    ctx_sseu->min_eus_per_subslice = user_sseu->min_eus_per_subslice;
+    ctx_sseu->max_eus_per_subslice = user_sseu->max_eus_per_subslice;
+
+    return 0;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+  struct intel_engine_cs *engine,
+  union intel_sseu sseu)
+{
+    struct drm_i915_private *dev_priv = ctx->i915;
+    struct i915_timeline *timeline;
+    struct i915_request *rq;
+    union intel_sseu actual_sseu;
+    enum intel_engine_id id;
+    int ret;
+
+    /*
+ * First notify user when this capability is not available so 
that it

+ * can be detected with any valid input.
+ */
+    if (!engine->emit_rpcs_config)
+    return -ENODEV;
+
+    if (to_intel_context(ctx, engine)->sseu.value == sseu.value)


Are there other uses for the value union in the series? Think whether 
it could be dropped and memcmp used here for simplicity.



+    return 0;
+
+    lockdep_assert_held(_priv->drm.struct_mutex);
+
+    

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Tvrtko Ursulin]

On 15/05/2018 10:05, Tvrtko Ursulin wrote:


On 14/05/2018 16:56, Lionel Landwerlin wrote:

From: Chris Wilson 

We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.

The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.

We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,

struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
    .instance = 0, };

memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) 
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
    sseu.packed.subslice_mask = 0;

    drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}

could be used to disable all subslices where supported.

v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() 
(Lionel)


v3: Add ability to program this per engine (Chris)

v4: Move most get_sseu() into i915_gem_context.c (Lionel)

v5: Validate sseu configuration against the device's capabilities 
(Lionel)


v6: Change context powergating settings through MI_SDM on kernel 
context (Chris)


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
c: Dmitry Rogozhkin 
CC: Tvrtko Ursulin 
CC: Zhipeng Gong 
CC: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem_context.c | 169 
  drivers/gpu/drm/i915/intel_lrc.c    | 103 ++-
  drivers/gpu/drm/i915/intel_ringbuffer.c |   2 +
  drivers/gpu/drm/i915/intel_ringbuffer.h |   4 +
  include/uapi/drm/i915_drm.h |  38 ++
  5 files changed, 281 insertions(+), 35 deletions(-)

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

index 01310c99e032..0b72a771c3f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -734,6 +734,110 @@ int i915_gem_context_destroy_ioctl(struct 
drm_device *dev, void *data,

  return 0;
  }
+static int
+intel_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
+  const struct drm_i915_gem_context_param_sseu *user_sseu,
+  union intel_sseu *ctx_sseu)
+{
+    if ((user_sseu->slice_mask & ~sseu->slice_mask) != 0 ||
+    user_sseu->slice_mask == 0)
+    return -EINVAL;
+
+    if ((user_sseu->subslice_mask & ~sseu->subslice_mask[0]) != 0 ||
+    user_sseu->subslice_mask == 0)
+    return -EINVAL;
+
+    if (user_sseu->min_eus_per_subslice > sseu->max_eus_per_subslice)
+    return -EINVAL;
+
+    if (user_sseu->max_eus_per_subslice > sseu->max_eus_per_subslice ||
+    user_sseu->max_eus_per_subslice < 
user_sseu->min_eus_per_subslice ||

+    user_sseu->max_eus_per_subslice == 0)
+    return -EINVAL;
+
+    ctx_sseu->slice_mask = user_sseu->slice_mask;
+    ctx_sseu->subslice_mask = user_sseu->subslice_mask;
+    ctx_sseu->min_eus_per_subslice = user_sseu->min_eus_per_subslice;
+    ctx_sseu->max_eus_per_subslice = user_sseu->max_eus_per_subslice;
+
+    return 0;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+  struct intel_engine_cs *engine,
+  union intel_sseu sseu)
+{
+    struct drm_i915_private *dev_priv = ctx->i915;
+    struct i915_timeline *timeline;
+    struct i915_request *rq;
+    union intel_sseu actual_sseu;
+    enum intel_engine_id id;
+    int ret;
+
+    /*
+ * First notify user when this capability is not available so 
that it

+ * can be detected with any valid input.
+ */
+    if (!engine->emit_rpcs_config)
+    return -ENODEV;
+
+    if (to_intel_context(ctx, engine)->sseu.value == sseu.value)


Are there other uses for the value union in the series? Think whether it 
could be dropped and memcmp used here for simplicity.



+    return 0;
+
+    lockdep_assert_held(_priv->drm.struct_mutex);
+
+    i915_retire_requests(dev_priv);
+
+    /* Now use 

Re: [Intel-gfx] [PATCH 6/7] drm/i915/execlists: Flush pending preemption events during reset

[Tvrtko Ursulin]

On 16/05/2018 16:12, Chris Wilson wrote:

Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c | 36 +++-
  1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e70d8d624899..3b889bb4352a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1843,6 +1843,7 @@ static struct i915_request *
  execlists_reset_prepare(struct intel_engine_cs *engine)
  {
struct intel_engine_execlists * const execlists = >execlists;
+   struct i915_request *request, *active;
  
  	GEM_TRACE("%s\n", engine->name);
  
@@ -1857,7 +1858,40 @@ execlists_reset_prepare(struct intel_engine_cs *engine)

 */
__tasklet_disable_sync_once(>tasklet);
  
-	return i915_gem_find_active_request(engine);

+   /*
+* We want to flush the pending context switches, having disabled
+* the tasklet above, we can assume exclusive access to the execlists.
+* For this allows us to catch up with an inflight preemption event,
+* and avoid blaming an innocent request if the stall was due to the
+* preemption itself.
+*/
+   if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
+   process_csb(engine);
+
+   /*
+* The last active request can then be no later than the last request
+* now in ELSP[0]. So search backwards from there, so that if the GPU
+* has advanced beyond the last CSB update, it will be pardoned.
+*/
+   active = NULL;
+   request = port_request(execlists->port);
+   if (request) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>timeline.lock, flags);
+   list_for_each_entry_from_reverse(request,
+>timeline.requests,
+link) {
+   if (__i915_request_completed(request,
+request->global_seqno))
+   break;
+
+   active = request;
+   }
+   spin_unlock_irqrestore(>timeline.lock, flags);
+   }
+
+   return active;
  }
  
  static void execlists_reset(struct intel_engine_cs *engine,




Sounds sensible to me, just don't ask me to describe preemption and 
reset flow where things go bad without it. :)


Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[Ramalingam C]

On Wednesday 09 May 2018 03:43 PM, Shankar, Uma wrote:



-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [Intel-gfx] [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx
Session

Request ME FW to start the HDCP2.2 session for a intel port.

Change "a" to "an".


Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent to

"sent" to "sends"


ME FW.

On Success, ME FW will start a HDCP2.2 session for the port and provides the
content for HDCP2.2 AKE_Init message.

v2:
  Rebased.
v3:
  cldev is add as a separate parameter [Tomas]
  Redundant comment and typecast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
drivers/misc/mei/hdcp/mei_hdcp.c | 68

include/linux/mei_hdcp.h | 11 +++
2 files changed, 79 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 2811a25f8c57..7caee0947761 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -33,9 +33,77 @@
#include 
#include 
#include 
+#include 
+
+#include "mei_hdcp.h"

static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);

+/**
+ * mei_initiate_hdcp2_session:
+ * Function to start a Wired HDCP2.2 Tx Session with ME FW
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @ake_data   : ptr to store AKE_Init
+ *
+ * Returns 0 on Success, <0 on Failure.
+ */
+int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data,
+  struct hdcp2_ake_init *ake_data) {
+   struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
+   struct wired_cmd_initiate_hdcp2_session_out
+   session_init_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !ake_data)
+   return -EINVAL;
+
+   dev = >dev;
+
+   session_init_in.header.api_version = HDCP_API_VERSION;
+   session_init_in.header.command_id =
WIRED_INITIATE_HDCP2_SESSION;
+   session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   session_init_in.header.buffer_len =
+
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
+
+   session_init_in.port.integrated_port_type = data->port_type;
+   session_init_in.port.physical_port = data->port;
+   session_init_in.protocol = (uint8_t)data->protocol;
+
+   byte = mei_cldev_send(cldev, (u8 *)_init_in,
+ sizeof(session_init_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_init_out,
+ sizeof(session_init_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
+   return byte;
+   }
+
+   if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_INITIATE_HDCP2_SESSION,
+   session_init_out.header.status);
+   return -1;
+   }
+
+   ake_data->msg_id = HDCP_2_2_AKE_INIT;
+   ake_data->tx_caps = session_init_out.tx_caps;
+   memcpy(ake_data->r_tx, session_init_out.r_tx,

We should check for ake_data->r_tx for NULL as well before attempting this copy.
r_tx is statically allocated array within struct ake_data. So I guess 
once ptr ake_data is valid

we need not check for r_tx.

--Ram



+  sizeof(session_init_out.r_tx));
+
+   return 0;
+}
+EXPORT_SYMBOL(mei_initiate_hdcp2_session);
+
void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)  
{
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
634c1a5bdf1e..bb4f27d3abcb 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -28,6 +28,7 @@
#define _LINUX_MEI_HDCP_H

#include 
+#include 

enum mei_cldev_state {
MEI_CLDEV_DISABLED,
@@ -105,6 +106,9 @@ struct mei_hdcp_data {  #ifdef
CONFIG_INTEL_MEI_HDCP  int mei_cldev_register_notify(struct notifier_block
*nb);  int mei_cldev_unregister_notify(struct notifier_block *nb);
+int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data,
+  struct hdcp2_ake_init *ake_data);
#else
static int 

Re: [Intel-gfx] [CI 1/5] drm/i915: Remove tasklet flush before disable

[Chris Wilson]

Quoting Chris Wilson (2018-05-16 16:30:13)
> The idea was to try and let the existing tasklet run to completion
> before we began the reset, but it involves a racy check against anything
> else that tries to run the tasklet. Rather than acknowledge and ignore
> the race, let it be and don't try and be too clever.
> 
> The tasklet will resume execution after reset (after spinning a bit
> during reset), but before we allow it to resume we will have cleared all
> the pending state.
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Reviewed-by: Mika Kuoppala 

Apologies for the noise, accidentally squashed a patch during rebasing
and need to recover it for CI.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 3/5] drm/i915/execlists: Refactor out complete_preempt_context()

[Chris Wilson]

As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.

v2: And do the same for the guc.

Signed-off-by: Chris Wilson 
Cc: Jeff McGee 
Cc: Michał Winiarski 
Reviewed-by: Jeff McGee  #v1
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 26 ++---
 drivers/gpu/drm/i915/intel_lrc.c| 23 ++
 2 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 2feb65096966..ca38ac9ff4fa 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -623,6 +623,21 @@ static void wait_for_guc_preempt_report(struct 
intel_engine_cs *engine)
report->report_return_status = INTEL_GUC_REPORT_STATUS_UNKNOWN;
 }
 
+static void complete_preempt_context(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists *execlists = >execlists;
+
+   GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+   execlists_cancel_port_requests(execlists);
+   execlists_unwind_incomplete_requests(execlists);
+
+   wait_for_guc_preempt_report(engine);
+   intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
+
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
 /**
  * guc_submit() - Submit commands through GuC
  * @engine: engine associated with the commands
@@ -793,15 +808,8 @@ static void guc_submission_tasklet(unsigned long data)
 
if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) &&
intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
-   GUC_PREEMPT_FINISHED) {
-   execlists_cancel_port_requests(>execlists);
-   execlists_unwind_incomplete_requests(execlists);
-
-   wait_for_guc_preempt_report(engine);
-
-   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
-   intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
-   }
+   GUC_PREEMPT_FINISHED)
+   complete_preempt_context(engine);
 
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT))
guc_dequeue(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 15434cad5430..b2781f1bb91c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -552,8 +552,18 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
 
-   execlists_clear_active(>execlists, EXECLISTS_ACTIVE_HWACK);
-   execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
+   execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
+static void complete_preempt_context(struct intel_engine_execlists *execlists)
+{
+   GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+   execlists_cancel_port_requests(execlists);
+   execlists_unwind_incomplete_requests(execlists);
+
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
 }
 
 static bool __execlists_dequeue(struct intel_engine_cs *engine)
@@ -1063,14 +1073,7 @@ static void execlists_submission_tasklet(unsigned long 
data)
if (status & GEN8_CTX_STATUS_COMPLETE &&
buf[2*head + 1] == 
execlists->preempt_complete_status) {
GEM_TRACE("%s preempt-idle\n", engine->name);
-
-   execlists_cancel_port_requests(execlists);
-   execlists_unwind_incomplete_requests(execlists);
-
-   GEM_BUG_ON(!execlists_is_active(execlists,
-   
EXECLISTS_ACTIVE_PREEMPT));
-   execlists_clear_active(execlists,
-  
EXECLISTS_ACTIVE_PREEMPT);
+   complete_preempt_context(execlists);
continue;
}
 
-- 
2.17.0

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

[Intel-gfx] [CI 4/5] drm/i915: Move engine reset prepare/finish to backends

[Chris Wilson]

In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_gem.c | 38 +++
 drivers/gpu/drm/i915/i915_gem.h |  5 +++
 drivers/gpu/drm/i915/intel_lrc.c| 50 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 23 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 -
 5 files changed, 84 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 982393907b80..abf661d40641 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3004,7 +3004,7 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 struct i915_request *
 i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
 {
-   struct i915_request *request = NULL;
+   struct i915_request *request;
 
/*
 * During the reset sequence, we must prevent the engine from
@@ -3027,31 +3027,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 */
kthread_park(engine->breadcrumbs.signaler);
 
-   /*
-* Prevent request submission to the hardware until we have
-* completed the reset in i915_gem_reset_finish(). If a request
-* is completed by one engine, it may then queue a request
-* to a second via its execlists->tasklet *just* as we are
-* calling engine->init_hw() and also writing the ELSP.
-* Turning off the execlists->tasklet until the reset is over
-* prevents the race.
-*/
-   __tasklet_disable_sync_once(>execlists.tasklet);
-
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
-   if (engine->irq_seqno_barrier)
-   engine->irq_seqno_barrier(engine);
-
-   request = i915_gem_find_active_request(engine);
+   request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
 
@@ -3202,13 +3178,8 @@ void i915_gem_reset_engine(struct intel_engine_cs 
*engine,
if (request)
request = i915_gem_reset_request(engine, request, stalled);
 
-   if (request) {
-   DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 
0x%x\n",
-engine->name, request->global_seqno);
-   }
-
/* Setup the CS to resume from the breadcrumb of the hung request */
-   engine->reset_hw(engine, request);
+   engine->reset.reset(engine, request);
 }
 
 void i915_gem_reset(struct drm_i915_private *dev_priv,
@@ -3256,7 +3227,8 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
 
 void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
 {
-   tasklet_enable(>execlists.tasklet);
+   engine->reset.finish(engine);
+
kthread_unpark(engine->breadcrumbs.signaler);
 
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5bf24cfc218c..ddb3dca384b8 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -79,4 +79,9 @@ static inline void __tasklet_disable_sync_once(struct 
tasklet_struct *t)
tasklet_unlock_wait(t);
 }
 
+static inline bool __tasklet_is_enabled(struct tasklet_struct *t)
+{
+   return !atomic_read(>count);
+}
+
 #endif /* __I915_GEM_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b2781f1bb91c..c5b083b4a308 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1826,8 +1826,39 @@ static int gen9_init_render_ring(struct intel_engine_cs 
*engine)
return 0;
 }
 
-static void reset_common_ring(struct intel_engine_cs *engine,
- struct i915_request *request)
+static struct i915_request *
+execlists_reset_prepare(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is 

[Intel-gfx] [CI 5/5] drm/i915: Split execlists/guc reset preparations

[Chris Wilson]

In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 34 +
 drivers/gpu/drm/i915/intel_lrc.c| 12 ++--
 2 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index ca38ac9ff4fa..637e852888ec 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -815,6 +815,37 @@ static void guc_submission_tasklet(unsigned long data)
guc_dequeue(engine);
 }
 
+static struct i915_request *
+guc_reset_prepare(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its execlists->tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the execlists->tasklet until the reset is over
+* prevents the race.
+*/
+   __tasklet_disable_sync_once(>tasklet);
+
+   /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may still have a worker queued.
+* Let's make sure that all workers scheduled before disabling the
+* tasklet are completed before continuing with the reset.
+*/
+   if (engine->i915->guc.preempt_wq)
+   flush_workqueue(engine->i915->guc.preempt_wq);
+
+   return i915_gem_find_active_request(engine);
+}
+
 /*
  * Everything below here is concerned with setup & teardown, and is
  * therefore not part of the somewhat time-critical batch-submission
@@ -1275,6 +1306,9 @@ int intel_guc_submission_enable(struct intel_guc *guc)
>execlists;
 
execlists->tasklet.func = guc_submission_tasklet;
+
+   engine->reset.prepare = guc_reset_prepare;
+
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c5b083b4a308..5e6b1f0e4220 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1844,16 +1844,6 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
 */
__tasklet_disable_sync_once(>tasklet);
 
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
return i915_gem_find_active_request(engine);
 }
 
@@ -2258,6 +2248,8 @@ static void execlists_set_default_submission(struct 
intel_engine_cs *engine)
engine->schedule = execlists_schedule;
engine->execlists.tasklet.func = execlists_submission_tasklet;
 
+   engine->reset.prepare = execlists_reset_prepare;
+
engine->park = NULL;
engine->unpark = NULL;
 
-- 
2.17.0

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

[Intel-gfx] [CI 1/5] drm/i915: Remove tasklet flush before disable

[Chris Wilson]

The idea was to try and let the existing tasklet run to completion
before we began the reset, but it involves a racy check against anything
else that tries to run the tasklet. Rather than acknowledge and ignore
the race, let it be and don't try and be too clever.

The tasklet will resume execution after reset (after spinning a bit
during reset), but before we allow it to resume we will have cleared all
the pending state.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a2070112b66..0dc369a9ec4d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3035,16 +3035,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * calling engine->init_hw() and also writing the ELSP.
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
-*
-* 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 recursively being called from set-wedged from inside
-* i915_reset.
 */
-   if (!atomic_read(>execlists.tasklet.count))
-   tasklet_kill(>execlists.tasklet);
tasklet_disable(>execlists.tasklet);
 
/*
-- 
2.17.0

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

[Intel-gfx] [CI 2/5] drm/i915: Only sync tasklets once for recursive reset preparation

[Chris Wilson]

When setting up reset, we may need to recursively prepare an engine. In
which case we should only synchronously flush the tasklets on the outer
most call, the inner calls will then be inside an atomic section where
the tasklet will never be run (and so the sync will never complete).

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 drivers/gpu/drm/i915/i915_gem.h | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0dc369a9ec4d..982393907b80 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
 */
-   tasklet_disable(>execlists.tasklet);
+   __tasklet_disable_sync_once(>execlists.tasklet);
 
/*
 * We're using worker to queue preemption requests from the tasklet in
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 525920404ede..5bf24cfc218c 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -26,6 +26,7 @@
 #define __I915_GEM_H__
 
 #include 
+#include 
 
 struct drm_i915_private;
 
@@ -72,4 +73,10 @@ struct drm_i915_private;
 void i915_gem_park(struct drm_i915_private *i915);
 void i915_gem_unpark(struct drm_i915_private *i915);
 
+static inline void __tasklet_disable_sync_once(struct tasklet_struct *t)
+{
+   if (atomic_inc_return(>count) == 1)
+   tasklet_unlock_wait(t);
+}
+
 #endif /* __I915_GEM_H__ */
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH 5/7] drm/i915/execlists: Split out CSB processing

[Tvrtko Ursulin]

On 16/05/2018 16:12, Chris Wilson wrote:

Pull the CSB event processing into its own routine so that we can reuse
it during reset to flush any missed interrupts/events.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c | 91 ++--
  1 file changed, 52 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f5d74df0e0d0..e70d8d624899 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -957,34 +957,14 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
local_irq_restore(flags);
  }
  
-/*

- * Check the unread Context Status Buffers and manage the submission of new
- * contexts to the ELSP accordingly.
- */
-static void execlists_submission_tasklet(unsigned long data)
+static void process_csb(struct intel_engine_cs *engine)
  {
-   struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
-   struct drm_i915_private *dev_priv = engine->i915;
+   struct drm_i915_private *i915 = engine->i915;
bool fw = false;
  
-	/*

-* We can skip acquiring intel_runtime_pm_get() here as it was taken
-* on our behalf by the request (see i915_gem_mark_busy()) and it will
-* not be relinquished until the device is idle (see
-* i915_gem_idle_work_handler()). As a precaution, we make sure
-* that all ELSP are drained i.e. we have processed the CSB,
-* before allowing ourselves to idle and calling intel_runtime_pm_put().
-*/
-   GEM_BUG_ON(!dev_priv->gt.awake);
-
-   /*
-* Prefer doing test_and_clear_bit() as a two stage operation to avoid
-* imposing the cost of a locked atomic transaction when submitting a
-* new request (outside of the context-switch interrupt).
-*/
-   while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
+   do {
/* The HWSP contains a (cacheable) mirror of the CSB */
const u32 *buf =
>status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
@@ -992,28 +972,27 @@ static void execlists_submission_tasklet(unsigned long 
data)
  
  		if (unlikely(execlists->csb_use_mmio)) {

buf = (u32 * __force)
-   (dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-   execlists->csb_head = -1; /* force mmio read of CSB 
ptrs */
+   (i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+   execlists->csb_head = -1; /* force mmio read of CSB */
}
  
  		/* Clear before reading to catch new interrupts */

clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
smp_mb__after_atomic();
  
-		if (unlikely(execlists->csb_head == -1)) { /* following a reset */

+   if (unlikely(execlists->csb_head == -1)) { /* after a reset */
if (!fw) {
-   intel_uncore_forcewake_get(dev_priv,
-  
execlists->fw_domains);
+   intel_uncore_forcewake_get(i915, 
execlists->fw_domains);
fw = true;
}
  
-			head = readl(dev_priv->regs + i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));

+   head = readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
tail = GEN8_CSB_WRITE_PTR(head);
head = GEN8_CSB_READ_PTR(head);
execlists->csb_head = head;
} else {
const int write_idx =
-   intel_hws_csb_write_index(dev_priv) -
+   intel_hws_csb_write_index(i915) -
I915_HWS_CSB_BUF0_INDEX;
  
  			head = execlists->csb_head;

@@ -1022,8 +1001,8 @@ static void execlists_submission_tasklet(unsigned long 
data)
}
GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
  engine->name,
- head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
+ head, GEN8_CSB_READ_PTR(readl(i915->regs + 

[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC, HuC Loading Support for Geminilake

[Patchwork]

== Series Details ==

Series: GuC, HuC Loading Support for Geminilake
URL   : https://patchwork.freedesktop.org/series/42437/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4192 -> Patchwork_9016 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9016 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9016, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42437/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9016:

  === IGT changes ===

 Possible regressions 

igt@drv_module_reload@basic-no-display:
  fi-elk-e7500:   PASS -> DMESG-FAIL +2
  fi-ivb-3520m:   PASS -> DMESG-FAIL +2
  fi-pnv-d510:PASS -> DMESG-FAIL +2
  fi-glk-j4005:   PASS -> DMESG-FAIL +2
  fi-bdw-5557u:   PASS -> DMESG-FAIL +2
  fi-hsw-peppy:   PASS -> DMESG-FAIL +2
  fi-hsw-4770r:   PASS -> DMESG-FAIL +2

igt@drv_module_reload@basic-reload:
  fi-bdw-gvtdvm:  PASS -> DMESG-FAIL +2
  fi-gdg-551: PASS -> DMESG-FAIL +2
  fi-hsw-4770:PASS -> DMESG-FAIL +2
  fi-ilk-650: PASS -> DMESG-FAIL +2
  fi-bsw-n3050:   PASS -> DMESG-FAIL +2
  fi-ivb-3770:PASS -> DMESG-FAIL +2
  fi-blb-e6850:   PASS -> DMESG-FAIL +2
  fi-snb-2600:PASS -> INCOMPLETE

igt@drv_module_reload@basic-reload-inject:
  fi-byt-j1900:   PASS -> DMESG-FAIL +2
  fi-cnl-y3:  PASS -> DMESG-FAIL +2
  fi-hsw-4200u:   PASS -> DMESG-FAIL +2
  fi-byt-n2820:   PASS -> DMESG-FAIL +2
  fi-bwr-2160:PASS -> DMESG-FAIL +2


 Warnings 

igt@drv_getparams_basic@basic-subslice-total:
  fi-snb-2600:PASS -> SKIP +231

igt@drv_hangman@error-state-basic:
  fi-elk-e7500:   PASS -> SKIP +212

igt@drv_module_reload@basic-no-display:
  fi-cnl-psr: DMESG-WARN (fdo#105395) -> DMESG-FAIL +2

igt@gem_ctx_param@basic:
  fi-cnl-psr: PASS -> SKIP +245

igt@gem_exec_basic@basic-blt:
  fi-ivb-3770:PASS -> SKIP +238

igt@gem_exec_basic@gtt-default:
  fi-byt-n2820:   PASS -> SKIP +232

igt@gem_exec_flush@basic-uc-rw-default:
  fi-byt-j1900:   PASS -> SKIP +236

igt@gem_exec_reloc@basic-write-gtt-noreloc:
  fi-ivb-3520m:   PASS -> SKIP +242

igt@gem_flink_basic@bad-open:
  fi-cnl-y3:  PASS -> SKIP +245

igt@gem_flink_basic@basic:
  fi-gdg-551: PASS -> SKIP +162

igt@gem_mmap_gtt@basic-read-write-distinct:
  fi-hsw-4770:PASS -> SKIP +244

igt@gem_mmap_gtt@basic-wc:
  fi-pnv-d510:PASS -> SKIP +206

igt@gem_mmap_gtt@basic-write-gtt:
  fi-blb-e6850:   PASS -> SKIP +206

igt@gem_mmap_gtt@basic-write-read:
  fi-bwr-2160:PASS -> SKIP +166

igt@gem_render_linear_blits@basic:
  fi-hsw-peppy:   PASS -> SKIP +244

igt@gem_wait@basic-busy-all:
  fi-hsw-4770r:   PASS -> SKIP +244

igt@kms_addfb_basic@addfb25-bad-modifier:
  fi-bdw-gvtdvm:  PASS -> SKIP +247

igt@kms_addfb_basic@too-high:
  fi-glk-j4005:   PASS -> SKIP +242

igt@kms_addfb_basic@unused-modifier:
  fi-bdw-5557u:   PASS -> SKIP +250

igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
  fi-bsw-n3050:   PASS -> SKIP +225

igt@kms_flip@basic-flip-vs-dpms:
  fi-ilk-650: PASS -> SKIP +211

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-hsw-4200u:   PASS -> SKIP +245


== Known issues ==

  Here are the changes found in Patchwork_9016 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> SKIP

igt@gem_ringfill@basic-default-hang:
  fi-blb-e6850:   DMESG-WARN (fdo#101600) -> SKIP
  fi-pnv-d510:DMESG-WARN (fdo#101600) -> SKIP

igt@kms_psr_sink_crc@basic:
  fi-hsw-4200u:   FAIL (fdo#106346) -> SKIP


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


== Participating hosts (42 -> 36) ==

  Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-snb-2520m 
fi-ctg-p8600 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4192 -> Patchwork_9016

  CI_DRM_4192: 302c1fbc4ca78140f408775ae39d32fc83ef0d41 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4485: eccae1360d6d01e73c6af2bd97122cef708207ef @ 

Re: [Intel-gfx] [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[Ramalingam C]

On Wednesday 04 April 2018 12:15 PM, Usyskin, Alexander wrote:



-Original Message-
From: C, Ramalingam
Sent: Tuesday, April 03, 2018 16:57
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo ; C, Ramalingam

Subject: [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

Request ME FW to start the HDCP2.2 session for a intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent
to ME FW.

On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for HDCP2.2 AKE_Init message.

v2:
   Rebased.
v3:
   cldev is add as a separate parameter [Tomas]
   Redundant comment and typecast are removed [Tomas]

Signed-off-by: Ramalingam C 
---
  drivers/misc/mei/hdcp/mei_hdcp.c | 68

  include/linux/mei_hdcp.h | 11 +++
  2 files changed, 79 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 2811a25f8c57..7caee0947761 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -33,9 +33,77 @@
  #include 
  #include 
  #include 
+#include 
+
+#include "mei_hdcp.h"

  static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);

+/**
+ * mei_initiate_hdcp2_session:
+ * Function to start a Wired HDCP2.2 Tx Session with ME FW
+ *
+ * @cldev  : Pointer for mei client device
+ * @data   : Intel HW specific Data
+ * @ake_data   : ptr to store AKE_Init
+ *
+ * Returns 0 on Success, <0 on Failure.
+ */
+int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
+  struct mei_hdcp_data *data,
+  struct hdcp2_ake_init *ake_data)
+{
+   struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 }
};
+   struct wired_cmd_initiate_hdcp2_session_out
+   session_init_out = { { 0 } };
+   struct device *dev;
+   ssize_t byte;
+
+   if (!data || !ake_data)
+   return -EINVAL;
+
+   dev = >dev;
+
+   session_init_in.header.api_version = HDCP_API_VERSION;
+   session_init_in.header.command_id =
WIRED_INITIATE_HDCP2_SESSION;
+   session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   session_init_in.header.buffer_len =
+
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
+
+   session_init_in.port.integrated_port_type = data->port_type;
+   session_init_in.port.physical_port = data->port;
+   session_init_in.protocol = (uint8_t)data->protocol;
+
+   byte = mei_cldev_send(cldev, (u8 *)_init_in,
+ sizeof(session_init_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);

%zd don't require (int)

Sure. Thanks

+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_init_out,
+ sizeof(session_init_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);

%zd don't require (int)

+   return byte;
+   }
+
+   if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_INITIATE_HDCP2_SESSION,
+   session_init_out.header.status);
+   return -1;

It will be better to return some meaningful error code here.
I dont think default error codes will match here. And at present other 
side I915 doesn't expect the reason but the failure state.
May be we could do something like -(session_init_out.header.status). But 
error codes of ME FW is not known to I915.


So may be as of now lets keep it as some -ve return value -1?

--Ram

+   }
+
+   ake_data->msg_id = HDCP_2_2_AKE_INIT;
+   ake_data->tx_caps = session_init_out.tx_caps;
+   memcpy(ake_data->r_tx, session_init_out.r_tx,
+  sizeof(session_init_out.r_tx));
+
+   return 0;
+}
+EXPORT_SYMBOL(mei_initiate_hdcp2_session);
+
  void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
enabled)
  {
if (enabled)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
index 634c1a5bdf1e..bb4f27d3abcb 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -28,6 +28,7 @@
  #define _LINUX_MEI_HDCP_H

  #include 
+#include 

  enum mei_cldev_state {
MEI_CLDEV_DISABLED,
@@ -105,6 +106,9 @@ struct mei_hdcp_data {
  #ifdef CONFIG_INTEL_MEI_HDCP
  int mei_cldev_register_notify(struct notifier_block *nb);
  int mei_cldev_unregister_notify(struct notifier_block *nb);
+int mei_initiate_hdcp2_session(struct 

[Intel-gfx] [PATCH 7/7] drm/i915: Stop parking the signaler around reset

[Chris Wilson]

We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so that the GPU doesn't emit the breadcrumb for our chosen
"guilty" request.

v2: Refactor setting STOP_RING so that we don't have the same code thrice

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michałt Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 14 
 drivers/gpu/drm/i915/intel_engine_cs.c  | 29 +
 drivers/gpu/drm/i915/intel_lrc.c|  6 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
 drivers/gpu/drm/i915/intel_uncore.c | 12 +++---
 6 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index abf661d40641..b0fe452ce17c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3015,18 +3015,6 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 */
intel_uncore_forcewake_get(engine->i915, FORCEWAKE_ALL);
 
-   /*
-* Prevent the signaler thread from updating the request
-* state (by calling dma_fence_signal) as we are processing
-* the reset. The write from the GPU of the seqno is
-* asynchronous and the signaler thread may see a different
-* value to us and declare the request complete, even though
-* the reset routine have picked that request as the active
-* (incomplete) request. This conflict is not handled
-* gracefully!
-*/
-   kthread_park(engine->breadcrumbs.signaler);
-
request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
@@ -3229,8 +3217,6 @@ void i915_gem_reset_finish_engine(struct intel_engine_cs 
*engine)
 {
engine->reset.finish(engine);
 
-   kthread_unpark(engine->breadcrumbs.signaler);
-
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 6bfd7e3ed152..d4e159ae65a6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -769,6 +769,35 @@ u64 intel_engine_get_last_batch_head(const struct 
intel_engine_cs *engine)
return bbaddr;
 }
 
+int intel_engine_stop_cs(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   const u32 base = engine->mmio_base;
+   const i915_reg_t mode = RING_MI_MODE(base);
+   int err;
+
+   if (INTEL_GEN(dev_priv) < 3)
+   return -ENODEV;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   I915_WRITE_FW(mode, _MASKED_BIT_ENABLE(STOP_RING));
+
+   err = 0;
+   if (__intel_wait_for_register_fw(dev_priv,
+mode, MODE_IDLE, MODE_IDLE,
+1000, 0,
+NULL)) {
+   GEM_TRACE("%s: timed out on STOP_RING -> IDLE\n", engine->name);
+   err = -ETIMEDOUT;
+   }
+
+   /* A final mmio read to let GPU writes be hopefully flushed to memory */
+   POSTING_READ_FW(mode);
+
+   return err;
+}
+
 const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
 {
switch (type) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3b889bb4352a..646ecf267411 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1878,6 +1878,12 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
if (request) {
unsigned long flags;
 
+   /*
+* Prevent the breadcrumb from advancing before we decide
+* which request is currently active.
+*/
+   intel_engine_stop_cs(engine);
+
spin_lock_irqsave(>timeline.lock, flags);
list_for_each_entry_from_reverse(request,
 >timeline.requests,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index af5a178366ed..6f200a747176 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -533,6 +533,8 @@ static int init_ring_common(struct intel_engine_cs *engine)
 
 static struct i915_request 

[Intel-gfx] [PATCH 3/7] drm/i915/execlists: Refactor out complete_preempt_context()

[Chris Wilson]

As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.

v2: And do the same for the guc.

Signed-off-by: Chris Wilson 
Cc: Jeff McGee 
Cc: Michał Winiarski 
Reviewed-by: Jeff McGee  #v1
---
 drivers/gpu/drm/i915/i915_gem.c | 38 ++-
 drivers/gpu/drm/i915/intel_guc_submission.c | 26 +---
 drivers/gpu/drm/i915/intel_lrc.c| 70 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 23 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 ++-
 5 files changed, 106 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 982393907b80..abf661d40641 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3004,7 +3004,7 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 struct i915_request *
 i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
 {
-   struct i915_request *request = NULL;
+   struct i915_request *request;
 
/*
 * During the reset sequence, we must prevent the engine from
@@ -3027,31 +3027,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 */
kthread_park(engine->breadcrumbs.signaler);
 
-   /*
-* Prevent request submission to the hardware until we have
-* completed the reset in i915_gem_reset_finish(). If a request
-* is completed by one engine, it may then queue a request
-* to a second via its execlists->tasklet *just* as we are
-* calling engine->init_hw() and also writing the ELSP.
-* Turning off the execlists->tasklet until the reset is over
-* prevents the race.
-*/
-   __tasklet_disable_sync_once(>execlists.tasklet);
-
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
-   if (engine->irq_seqno_barrier)
-   engine->irq_seqno_barrier(engine);
-
-   request = i915_gem_find_active_request(engine);
+   request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
 
@@ -3202,13 +3178,8 @@ void i915_gem_reset_engine(struct intel_engine_cs 
*engine,
if (request)
request = i915_gem_reset_request(engine, request, stalled);
 
-   if (request) {
-   DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 
0x%x\n",
-engine->name, request->global_seqno);
-   }
-
/* Setup the CS to resume from the breadcrumb of the hung request */
-   engine->reset_hw(engine, request);
+   engine->reset.reset(engine, request);
 }
 
 void i915_gem_reset(struct drm_i915_private *dev_priv,
@@ -3256,7 +3227,8 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
 
 void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
 {
-   tasklet_enable(>execlists.tasklet);
+   engine->reset.finish(engine);
+
kthread_unpark(engine->breadcrumbs.signaler);
 
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 2feb65096966..ca38ac9ff4fa 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -623,6 +623,21 @@ static void wait_for_guc_preempt_report(struct 
intel_engine_cs *engine)
report->report_return_status = INTEL_GUC_REPORT_STATUS_UNKNOWN;
 }
 
+static void complete_preempt_context(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists *execlists = >execlists;
+
+   GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+   execlists_cancel_port_requests(execlists);
+   execlists_unwind_incomplete_requests(execlists);
+
+   wait_for_guc_preempt_report(engine);
+   intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
+
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
 /**
  * guc_submit() - Submit commands through GuC
  * @engine: engine associated with the commands
@@ -793,15 +808,8 @@ static void guc_submission_tasklet(unsigned long data)
 
if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) &&
intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
-  

[Intel-gfx] [PATCH 6/7] drm/i915/execlists: Flush pending preemption events during reset

[Chris Wilson]

Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e70d8d624899..3b889bb4352a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1843,6 +1843,7 @@ static struct i915_request *
 execlists_reset_prepare(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
+   struct i915_request *request, *active;
 
GEM_TRACE("%s\n", engine->name);
 
@@ -1857,7 +1858,40 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
 */
__tasklet_disable_sync_once(>tasklet);
 
-   return i915_gem_find_active_request(engine);
+   /*
+* We want to flush the pending context switches, having disabled
+* the tasklet above, we can assume exclusive access to the execlists.
+* For this allows us to catch up with an inflight preemption event,
+* and avoid blaming an innocent request if the stall was due to the
+* preemption itself.
+*/
+   if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
+   process_csb(engine);
+
+   /*
+* The last active request can then be no later than the last request
+* now in ELSP[0]. So search backwards from there, so that if the GPU
+* has advanced beyond the last CSB update, it will be pardoned.
+*/
+   active = NULL;
+   request = port_request(execlists->port);
+   if (request) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>timeline.lock, flags);
+   list_for_each_entry_from_reverse(request,
+>timeline.requests,
+link) {
+   if (__i915_request_completed(request,
+request->global_seqno))
+   break;
+
+   active = request;
+   }
+   spin_unlock_irqrestore(>timeline.lock, flags);
+   }
+
+   return active;
 }
 
 static void execlists_reset(struct intel_engine_cs *engine,
-- 
2.17.0

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

[Intel-gfx] [PATCH 4/7] drm/i915: Split execlists/guc reset preparations

[Chris Wilson]

In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 34 +
 drivers/gpu/drm/i915/intel_lrc.c| 12 ++--
 2 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index ca38ac9ff4fa..637e852888ec 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -815,6 +815,37 @@ static void guc_submission_tasklet(unsigned long data)
guc_dequeue(engine);
 }
 
+static struct i915_request *
+guc_reset_prepare(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its execlists->tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the execlists->tasklet until the reset is over
+* prevents the race.
+*/
+   __tasklet_disable_sync_once(>tasklet);
+
+   /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may still have a worker queued.
+* Let's make sure that all workers scheduled before disabling the
+* tasklet are completed before continuing with the reset.
+*/
+   if (engine->i915->guc.preempt_wq)
+   flush_workqueue(engine->i915->guc.preempt_wq);
+
+   return i915_gem_find_active_request(engine);
+}
+
 /*
  * Everything below here is concerned with setup & teardown, and is
  * therefore not part of the somewhat time-critical batch-submission
@@ -1275,6 +1306,9 @@ int intel_guc_submission_enable(struct intel_guc *guc)
>execlists;
 
execlists->tasklet.func = guc_submission_tasklet;
+
+   engine->reset.prepare = guc_reset_prepare;
+
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 67fed98abee7..f5d74df0e0d0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1844,16 +1844,6 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
 */
__tasklet_disable_sync_once(>tasklet);
 
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
return i915_gem_find_active_request(engine);
 }
 
@@ -2255,6 +2245,8 @@ static void execlists_set_default_submission(struct 
intel_engine_cs *engine)
engine->schedule = execlists_schedule;
engine->execlists.tasklet.func = execlists_submission_tasklet;
 
+   engine->reset.prepare = execlists_reset_prepare;
+
engine->park = NULL;
engine->unpark = NULL;
 
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH v3 07/40] linux/mei: Header for mei_hdcp driver interface

[Ramalingam C]

On Wednesday 09 May 2018 03:38 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 07/40] linux/mei: Header for mei_hdcp driver interface

Data structures and Enum for the I915-MEI_HDCP interface are defined at


v2:
  Rebased.
v3:
  mei_cl_device is removed from mei_hdcp_data [Tomas]

Signed-off-by: Ramalingam C 
---
include/linux/mei_hdcp.h | 70

1 file changed, 70 insertions(+)

diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
3b46bebde718..634c1a5bdf1e 100644
--- a/include/linux/mei_hdcp.h
+++ b/include/linux/mei_hdcp.h
@@ -27,11 +27,81 @@
#ifndef _LINUX_MEI_HDCP_H
#define _LINUX_MEI_HDCP_H

+#include 
+
enum mei_cldev_state {
MEI_CLDEV_DISABLED,
MEI_CLDEV_ENABLED
};

+/*
+ * Enumeration of the physical DDI available on the platform  */ enum
+hdcp_physical_port {
+   INVALID_PORT = 0x00,/* Not a valid port */
+
+   DDI_RANGE_BEGIN = 0x01, /* Beginning of the valid DDI port range
*/
+   DDI_B   = 0x01, /* Port DDI B */
+   DDI_C   = 0x02, /* Port DDI C */
+   DDI_D   = 0x03, /* Port DDI D */
+   DDI_E   = 0x04, /* Port DDI E */
+   DDI_F   = 0x05, /* Port DDI F */
+   DDI_A   = 0x07, /* Port DDI A */

Why A is made as 0x7. In I915, enum port defines A as 0. Any special reason to
deviate from that ?

ME FW represent the ports with similar enum. So we have no choice but
translate our port representation to this enum values.



+   DDI_RANGE_END   = DDI_A,/* End of the valid DDI port range */
+};
+
+/* The types of HDCP 2.2 ports supported */ enum
+hdcp_integrated_port_type {
+   HDCP_INVALID_TYPE   = 0x00,
+
+   /* HDCP 2.x ports that are integrated into Intel HW */
+   INTEGRATED  = 0x01,
+
+   /* HDCP2.2 discrete wired Tx port with LSPCON (HDMI 2.0) solution */
+   LSPCON  = 0x02,
+
+   /* HDCP2.2 discrete wired Tx port using the CPDP (DP 1.3) solution */
+   CPDP= 0x03,
+};
+
+/**

Drop an extra *


+ * wired_protocol: Supported integrated wired HDCP protocol.
+ * Based on this value, Minor differenceneeded between wired

"Add space after differences"

Sure.

--Ram



+specifications
+ * are handled.
+ */
+enum hdcp_protocol {
+   HDCP_PROTOCOL_INVALID,
+   HDCP_PROTOCOL_HDMI,
+   HDCP_PROTOCOL_DP
+};
+
+/**
+ * mei_hdcp_data: Input data to the mei_hdcp APIs.
+ */
+struct mei_hdcp_data {
+   enum hdcp_physical_port port;
+   enum hdcp_integrated_port_type port_type;
+   enum hdcp_protocol protocol;
+
+   /*
+* No of streams transmitted on a port.
+* In case of HDMI & DP SST, single stream will be
+* transmitted on a port.
+*/
+   uint16_t k;
+
+   /*
+* Count of RepeaterAuth_Stream_Manage msg propagated.
+* Initialized to 0 on AKE_INIT. Incremented after every successful
+* transmission of RepeaterAuth_Stream_Manage message. When it rolls
+* over re-Auth has to be triggered.
+*/
+   uint32_t seq_num_m;
+
+   /* k(No of Streams per port) x structure of wired_streamid_type */
+   struct hdcp2_streamid_type *streams;
+};
+
#ifdef CONFIG_INTEL_MEI_HDCP
int mei_cldev_register_notify(struct notifier_block *nb);  int
mei_cldev_unregister_notify(struct notifier_block *nb);
--
2.7.4

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


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

[Intel-gfx] [PATCH 5/7] drm/i915/execlists: Split out CSB processing

[Chris Wilson]

Pull the CSB event processing into its own routine so that we can reuse
it during reset to flush any missed interrupts/events.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 91 ++--
 1 file changed, 52 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f5d74df0e0d0..e70d8d624899 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -957,34 +957,14 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
local_irq_restore(flags);
 }
 
-/*
- * Check the unread Context Status Buffers and manage the submission of new
- * contexts to the ELSP accordingly.
- */
-static void execlists_submission_tasklet(unsigned long data)
+static void process_csb(struct intel_engine_cs *engine)
 {
-   struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
-   struct drm_i915_private *dev_priv = engine->i915;
+   struct drm_i915_private *i915 = engine->i915;
bool fw = false;
 
-   /*
-* We can skip acquiring intel_runtime_pm_get() here as it was taken
-* on our behalf by the request (see i915_gem_mark_busy()) and it will
-* not be relinquished until the device is idle (see
-* i915_gem_idle_work_handler()). As a precaution, we make sure
-* that all ELSP are drained i.e. we have processed the CSB,
-* before allowing ourselves to idle and calling intel_runtime_pm_put().
-*/
-   GEM_BUG_ON(!dev_priv->gt.awake);
-
-   /*
-* Prefer doing test_and_clear_bit() as a two stage operation to avoid
-* imposing the cost of a locked atomic transaction when submitting a
-* new request (outside of the context-switch interrupt).
-*/
-   while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
+   do {
/* The HWSP contains a (cacheable) mirror of the CSB */
const u32 *buf =
>status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
@@ -992,28 +972,27 @@ static void execlists_submission_tasklet(unsigned long 
data)
 
if (unlikely(execlists->csb_use_mmio)) {
buf = (u32 * __force)
-   (dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-   execlists->csb_head = -1; /* force mmio read of CSB 
ptrs */
+   (i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+   execlists->csb_head = -1; /* force mmio read of CSB */
}
 
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
smp_mb__after_atomic();
 
-   if (unlikely(execlists->csb_head == -1)) { /* following a reset 
*/
+   if (unlikely(execlists->csb_head == -1)) { /* after a reset */
if (!fw) {
-   intel_uncore_forcewake_get(dev_priv,
-  
execlists->fw_domains);
+   intel_uncore_forcewake_get(i915, 
execlists->fw_domains);
fw = true;
}
 
-   head = readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+   head = readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
tail = GEN8_CSB_WRITE_PTR(head);
head = GEN8_CSB_READ_PTR(head);
execlists->csb_head = head;
} else {
const int write_idx =
-   intel_hws_csb_write_index(dev_priv) -
+   intel_hws_csb_write_index(i915) -
I915_HWS_CSB_BUF0_INDEX;
 
head = execlists->csb_head;
@@ -1022,8 +1001,8 @@ static void execlists_submission_tasklet(unsigned long 
data)
}
GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
  engine->name,
- head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
+ head, GEN8_CSB_READ_PTR(readl(i915->regs + 

[Intel-gfx] [PATCH 1/7] drm/i915: Remove tasklet flush before disable

[Chris Wilson]

The idea was to try and let the existing tasklet run to completion
before we began the reset, but it involves a racy check against anything
else that tries to run the tasklet. Rather than acknowledge and ignore
the race, let it be and don't try and be too clever.

The tasklet will resume execution after reset (after spinning a bit
during reset), but before we allow it to resume we will have cleared all
the pending state.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a2070112b66..0dc369a9ec4d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3035,16 +3035,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * calling engine->init_hw() and also writing the ELSP.
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
-*
-* 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 recursively being called from set-wedged from inside
-* i915_reset.
 */
-   if (!atomic_read(>execlists.tasklet.count))
-   tasklet_kill(>execlists.tasklet);
tasklet_disable(>execlists.tasklet);
 
/*
-- 
2.17.0

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

[Intel-gfx] [PATCH 2/7] drm/i915: Only sync tasklets once for recursive reset preparation

[Chris Wilson]

When setting up reset, we may need to recursively prepare an engine. In
which case we should only synchronously flush the tasklets on the outer
most call, the inner calls will then be inside an atomic section where
the tasklet will never be run (and so the sync will never complete).

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 drivers/gpu/drm/i915/i915_gem.h | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0dc369a9ec4d..982393907b80 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
 */
-   tasklet_disable(>execlists.tasklet);
+   __tasklet_disable_sync_once(>execlists.tasklet);
 
/*
 * We're using worker to queue preemption requests from the tasklet in
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 525920404ede..5bf24cfc218c 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -26,6 +26,7 @@
 #define __I915_GEM_H__
 
 #include 
+#include 
 
 struct drm_i915_private;
 
@@ -72,4 +73,10 @@ struct drm_i915_private;
 void i915_gem_park(struct drm_i915_private *i915);
 void i915_gem_unpark(struct drm_i915_private *i915);
 
+static inline void __tasklet_disable_sync_once(struct tasklet_struct *t)
+{
+   if (atomic_inc_return(>count) == 1)
+   tasklet_unlock_wait(t);
+}
+
 #endif /* __I915_GEM_H__ */
-- 
2.17.0

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

[Intel-gfx] [CI 3/4] drm/i915/execlists: Refactor out complete_preempt_context()

[Chris Wilson]

As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.

v2: And do the same for the guc.

Signed-off-by: Chris Wilson 
Cc: Jeff McGee 
Cc: Michał Winiarski 
Reviewed-by: Jeff McGee  #v1
---
 drivers/gpu/drm/i915/i915_gem.c | 38 ++-
 drivers/gpu/drm/i915/intel_guc_submission.c | 26 +---
 drivers/gpu/drm/i915/intel_lrc.c| 70 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 23 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 ++-
 5 files changed, 106 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 982393907b80..abf661d40641 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3004,7 +3004,7 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 struct i915_request *
 i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
 {
-   struct i915_request *request = NULL;
+   struct i915_request *request;
 
/*
 * During the reset sequence, we must prevent the engine from
@@ -3027,31 +3027,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 */
kthread_park(engine->breadcrumbs.signaler);
 
-   /*
-* Prevent request submission to the hardware until we have
-* completed the reset in i915_gem_reset_finish(). If a request
-* is completed by one engine, it may then queue a request
-* to a second via its execlists->tasklet *just* as we are
-* calling engine->init_hw() and also writing the ELSP.
-* Turning off the execlists->tasklet until the reset is over
-* prevents the race.
-*/
-   __tasklet_disable_sync_once(>execlists.tasklet);
-
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
-   if (engine->irq_seqno_barrier)
-   engine->irq_seqno_barrier(engine);
-
-   request = i915_gem_find_active_request(engine);
+   request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
 
@@ -3202,13 +3178,8 @@ void i915_gem_reset_engine(struct intel_engine_cs 
*engine,
if (request)
request = i915_gem_reset_request(engine, request, stalled);
 
-   if (request) {
-   DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 
0x%x\n",
-engine->name, request->global_seqno);
-   }
-
/* Setup the CS to resume from the breadcrumb of the hung request */
-   engine->reset_hw(engine, request);
+   engine->reset.reset(engine, request);
 }
 
 void i915_gem_reset(struct drm_i915_private *dev_priv,
@@ -3256,7 +3227,8 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
 
 void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
 {
-   tasklet_enable(>execlists.tasklet);
+   engine->reset.finish(engine);
+
kthread_unpark(engine->breadcrumbs.signaler);
 
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 2feb65096966..ca38ac9ff4fa 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -623,6 +623,21 @@ static void wait_for_guc_preempt_report(struct 
intel_engine_cs *engine)
report->report_return_status = INTEL_GUC_REPORT_STATUS_UNKNOWN;
 }
 
+static void complete_preempt_context(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists *execlists = >execlists;
+
+   GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+   execlists_cancel_port_requests(execlists);
+   execlists_unwind_incomplete_requests(execlists);
+
+   wait_for_guc_preempt_report(engine);
+   intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
+
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
 /**
  * guc_submit() - Submit commands through GuC
  * @engine: engine associated with the commands
@@ -793,15 +808,8 @@ static void guc_submission_tasklet(unsigned long data)
 
if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) &&
intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
-  

[Intel-gfx] [CI 1/4] drm/i915: Remove tasklet flush before disable

[Chris Wilson]

The idea was to try and let the existing tasklet run to completion
before we began the reset, but it involves a racy check against anything
else that tries to run the tasklet. Rather than acknowledge and ignore
the race, let it be and don't try and be too clever.

The tasklet will resume execution after reset (after spinning a bit
during reset), but before we allow it to resume we will have cleared all
the pending state.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a2070112b66..0dc369a9ec4d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3035,16 +3035,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * calling engine->init_hw() and also writing the ELSP.
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
-*
-* 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 recursively being called from set-wedged from inside
-* i915_reset.
 */
-   if (!atomic_read(>execlists.tasklet.count))
-   tasklet_kill(>execlists.tasklet);
tasklet_disable(>execlists.tasklet);
 
/*
-- 
2.17.0

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

[Intel-gfx] [CI 2/4] drm/i915: Only sync tasklets once for recursive reset preparation

[Chris Wilson]

When setting up reset, we may need to recursively prepare an engine. In
which case we should only synchronously flush the tasklets on the outer
most call, the inner calls will then be inside an atomic section where
the tasklet will never be run (and so the sync will never complete).

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 drivers/gpu/drm/i915/i915_gem.h | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0dc369a9ec4d..982393907b80 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
 */
-   tasklet_disable(>execlists.tasklet);
+   __tasklet_disable_sync_once(>execlists.tasklet);
 
/*
 * We're using worker to queue preemption requests from the tasklet in
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 525920404ede..5bf24cfc218c 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -26,6 +26,7 @@
 #define __I915_GEM_H__
 
 #include 
+#include 
 
 struct drm_i915_private;
 
@@ -72,4 +73,10 @@ struct drm_i915_private;
 void i915_gem_park(struct drm_i915_private *i915);
 void i915_gem_unpark(struct drm_i915_private *i915);
 
+static inline void __tasklet_disable_sync_once(struct tasklet_struct *t)
+{
+   if (atomic_inc_return(>count) == 1)
+   tasklet_unlock_wait(t);
+}
+
 #endif /* __I915_GEM_H__ */
-- 
2.17.0

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

[Intel-gfx] [CI 4/4] drm/i915: Split execlists/guc reset preparations

[Chris Wilson]

In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 34 +
 drivers/gpu/drm/i915/intel_lrc.c| 12 ++--
 2 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index ca38ac9ff4fa..637e852888ec 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -815,6 +815,37 @@ static void guc_submission_tasklet(unsigned long data)
guc_dequeue(engine);
 }
 
+static struct i915_request *
+guc_reset_prepare(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its execlists->tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the execlists->tasklet until the reset is over
+* prevents the race.
+*/
+   __tasklet_disable_sync_once(>tasklet);
+
+   /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may still have a worker queued.
+* Let's make sure that all workers scheduled before disabling the
+* tasklet are completed before continuing with the reset.
+*/
+   if (engine->i915->guc.preempt_wq)
+   flush_workqueue(engine->i915->guc.preempt_wq);
+
+   return i915_gem_find_active_request(engine);
+}
+
 /*
  * Everything below here is concerned with setup & teardown, and is
  * therefore not part of the somewhat time-critical batch-submission
@@ -1275,6 +1306,9 @@ int intel_guc_submission_enable(struct intel_guc *guc)
>execlists;
 
execlists->tasklet.func = guc_submission_tasklet;
+
+   engine->reset.prepare = guc_reset_prepare;
+
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 67fed98abee7..f5d74df0e0d0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1844,16 +1844,6 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
 */
__tasklet_disable_sync_once(>tasklet);
 
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
return i915_gem_find_active_request(engine);
 }
 
@@ -2255,6 +2245,8 @@ static void execlists_set_default_submission(struct 
intel_engine_cs *engine)
engine->schedule = execlists_schedule;
engine->execlists.tasklet.func = execlists_submission_tasklet;
 
+   engine->reset.prepare = execlists_reset_prepare;
+
engine->park = NULL;
engine->unpark = NULL;
 
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev state change

[Ramalingam C]

On Tuesday 03 April 2018 09:00 PM, Daniel Vetter wrote:

On Tue, Apr 03, 2018 at 07:27:18PM +0530, Ramalingam C wrote:

Notifier Chain is defined to inform all its clients about the mei
client device state change. Routine is defined for the clients to
register and unregister for the notification on state change.

v2:
   Rebased.
v3:
   Notifier chain is adopted for cldev state update [Tomas]

Signed-off-by: Ramalingam C 

For managing interactions between multiple drivers notifier chains are
fairly problematic. The main reason is the locking embedded in the
notifier chain. To make things safe, that lock must be held everytime we
add/remove any part of the link, and when calling any callback. Usually
that means you get a neat deadlock sooner or later, because the
load/unload code has inverse paths compared to normal operation.

Notifiers also not not provide a clean way to handle suspend/resume
ordering.

Recording the IRC discussion here:

As Daniel Vetter suggested, with notifiers to mei client device binding 
status, I have tested
the I915 and mei_hdcp modules as inbuild and as modules at suspend and 
resume of them.


During the experiment, CONFIG_PROVE_LOCKING was enabled. No issue was 
observed due to the
usecase of the notifier here. Notifier was used here just to inform the 
I915 that mei client device is no more.
So that I915 will stop any ongoing HDCP2.2 protection and reject any 
further request.


Hence Planning to continue with same shape of the patch on v4. If any 
erroneous scenario is detected

we will work on the alternate solution.

--Ram


There's two parts to do this properly.

1. Finding the other driver. Multi-part drivers are assembled nowadays
using the component framework. We're using that already to manage the
interaction between drm/i915 and snd-hda. If not all components are ready
yet, then the driver load sequence must be aborted by returning
-EPROBE_DEFER. That's going to be lots of fun, since for the mei/i915
interaction it's probably going to be i915 that needs to abort and retry
the driver load. But we do CI test all the abort points in our driver
load, so should work well.

2. Handling the ordering restrictions for suspend/resume. For i915/snd-hda
we used a early_resume/late_suspend callback trickery, but that doesn't
really scale to multiple levels. Since we've done that device_link has
been added. As a bonus device_link can also ensure that not only
suspend/resume (including runtime suspend/resume) is ordered correctly,
but also that driver bind/unbind works correctly. Still needs the
component stuff and initial -EPROBE_DEFER, but will all least make sure
we' only reprobe once more. See device_link_add + docs in device_link.rst.

One thing I didn't check is whether we want the device linke to also
manage runtime pm for us. It would mean that we keep the ME awake as long
as anything is using the gpu (any display on or any rendering happening).
That might be too much, but could also be that it won't matter (and then
using DL_FLAG_PM_RUNTIME would simply our code).

We might also need to convert the i915/snd-hda interactions to device_link
first, since the early/late_resume/suspend hack probably doesn't interact
too well with proper device_links.

Cheers, Daniel


---
  drivers/misc/mei/hdcp/mei_hdcp.c | 36 +++---
  include/linux/mei_hdcp.h | 48 
  2 files changed, 81 insertions(+), 3 deletions(-)
  create mode 100644 include/linux/mei_hdcp.h

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b334615728a7..2811a25f8c57 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -31,6 +31,32 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+
+static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
+
+void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
+{
+   if (enabled)
+   blocking_notifier_call_chain(_cldev_notifier_list,
+MEI_CLDEV_ENABLED, cldev);
+   else
+   blocking_notifier_call_chain(_cldev_notifier_list,
+MEI_CLDEV_DISABLED, NULL);
+}
+
+int mei_cldev_register_notify(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(_cldev_notifier_list, nb);
+}
+EXPORT_SYMBOL_GPL(mei_cldev_register_notify);
+
+int mei_cldev_unregister_notify(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(_cldev_notifier_list, nb);
+}
+EXPORT_SYMBOL_GPL(mei_cldev_unregister_notify);
  
  static int mei_hdcp_probe(struct mei_cl_device *cldev,

  const struct mei_cl_device_id *id)
@@ -38,14 +64,18 @@ static int mei_hdcp_probe(struct mei_cl_device *cldev,
int ret;
  
  	ret = mei_cldev_enable(cldev);

-   if (ret < 0)
+   if (ret < 0) {
dev_err(>dev, "mei_cldev_enable 

Re: [Intel-gfx] [PATCH 6/7] drm/i915/execlists: Flush pending preemption events during reset

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-16 15:24:33)
> > + /*
> > +  * The last active request can then be no later than the last request
> > +  * now in ELSP[0]. So search backwards from there, so that if the GPU
> > +  * has advanced beyond the last CSB update, it will be pardoned.
> > +  */
> > + active = NULL;
> > + request = port_request(execlists->port);
> > + if (request) {
> 
> Assignment to request is for nothing it seems.
> 
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(>timeline.lock, flags);
> > + list_for_each_entry_from_reverse(request,

It's a 'from' list_for_each variant.

> > +  >timeline.requests,
> > +  link) {
> > + if (__i915_request_completed(request,
> > +  request->global_seqno))
> > + break;
> > +
> > + active = request;
> > + }
> > + spin_unlock_irqrestore(>timeline.lock, flags);
> > + }
> > +
> > + return active;
> >   }
> >   
> >   static void execlists_reset(struct intel_engine_cs *engine,
> > 
> 
> No other complaints and I could be bribed to look past the request to 
> split it. :)

Is not clearing the backlog so we can get onto features not enough
incentive? Chocolate? Beer? Chocolate-flavoured beer?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx