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-devel@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-...@lists.freedesktop.org; dri-devel@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: [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-devel@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-...@lists.freedesktop.org; dri-devel@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: [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-devel@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-...@lists.freedesktop.org; dri-devel@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] [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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: build failure after merge of the drm tree

[Dave Airlie]

I've applied this locally for now so I can continue arm64 builds :-)

Dave.

On 16 May 2018 at 18:09, Oded Gabbay  wrote:
> On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> After merging the drm tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function 
>> 'init_user_pages':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit 
>> declaration of function 'release_pages'; did you mean 'release_task'? 
>> [-Werror=implicit-function-declaration]
>>release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
>>^
>>release_task
>>
>> Caused by commit
>>
>>   5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
>>
>> I have applied the following patch for today:
>>
>> From: Stephen Rothwell 
>> Date: Wed, 16 May 2018 16:43:34 +1000
>> Subject: [PATCH] drm/amdgpu: include pagemap.h for release_pages()
>>
>> Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD"
>> Cc: Felix Kuehling 
>> Cc: Oded Gabbay 
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 72ab2b1ffe75..ff8fd75f7ca5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -23,6 +23,7 @@
>>  #define pr_fmt(fmt) "kfd2kgd: " fmt
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include "amdgpu_object.h"
>> --
>> 2.17.0
>>
>> --
>> Cheers,
>> Stephen Rothwell
>
> Thanks Stephen,
>
> I'll add it to amdkfd-next and send it to Dave with other fixes.
>
> Oded
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: ipp: fix image broken issue

[Inki Dae]

Fixed image broken issue while video play back with 854x480.

GScaler device of Exynos5433 has IN_ID_MAX field in GSC_IN_CON
register, which determines how much GScaler DMA has to drain
data from system memory at once.

Therefore, image size should be fixed up before IPP driver verifies
whether gem buffer is enough for it or not.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 87 +++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++
 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 12 +
 3 files changed, 100 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index e99dd1e..41cb82d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -86,6 +86,28 @@ struct gsc_scaler {
unsigned long main_vratio;
 };
 
+/**
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @limits: picture size limits array
+ * @clk_names: names of clocks needed by this variant
+ * @num_clocks: the number of clocks needed by this variant
+ * @has_in_ic_max: indicate whether GSCALER_IN_CON register has
+ * IN_IC_MAX field which means maxinum AXI
+ * read capability.
+ * @in_ic_max_shift: indicate which position IN_IC_MAX field is located.
+ * @in_ic_max_mask: A mask value to IN_IC_MAX field.
+ */
+struct gsc_driverdata {
+   const struct drm_exynos_ipp_limit *limits;
+   int num_limits;
+   const char  *clk_names[GSC_MAX_CLOCKS];
+   int num_clocks;
+   unsigned inthas_in_ic_max:1;
+   unsigned intin_ic_max_shift;
+   unsigned intin_ic_max_mask;
+};
+
 /*
  * A structure of gsc context.
  *
@@ -96,6 +118,9 @@ struct gsc_scaler {
  * @id: gsc id.
  * @irq: irq number.
  * @rotation: supports rotation of src.
+ * @align_size: A size that GSC_SRCIMG_WIDTH value of GSC_SRCIMG_SIZE
+ * register should be aligned with(in byte).
+ * @driver_data: a pointer to gsc_driverdata.
  */
 struct gsc_context {
struct exynos_drm_ipp ipp;
@@ -114,20 +139,8 @@ struct gsc_context {
int id;
int irq;
boolrotation;
-};
-
-/**
- * struct gsc_driverdata - per device type driver data for init time.
- *
- * @limits: picture size limits array
- * @clk_names: names of clocks needed by this variant
- * @num_clocks: the number of clocks needed by this variant
- */
-struct gsc_driverdata {
-   const struct drm_exynos_ipp_limit *limits;
-   int num_limits;
-   const char  *clk_names[GSC_MAX_CLOCKS];
-   int num_clocks;
+   unsigned int align_size;
+   struct gsc_driverdata *driver_data;
 };
 
 /* 8-tap Filter Coefficient */
@@ -1095,6 +1108,18 @@ static void gsc_start(struct gsc_context *ctx)
gsc_write(cfg, GSC_ENABLE);
 }
 
+static void gsc_fixup(struct exynos_drm_ipp *ipp,
+ struct exynos_drm_ipp_task *task)
+{
+   struct gsc_context *ctx = container_of(ipp, struct gsc_context, ipp);
+   struct exynos_drm_ipp_buffer *src = >src;
+
+   if (!ctx->driver_data->has_in_ic_max)
+   return;
+
+   src->buf.width = ALIGN(src->buf.width, ctx->align_size);
+}
+
 static int gsc_commit(struct exynos_drm_ipp *ipp,
  struct exynos_drm_ipp_task *task)
 {
@@ -1124,6 +1149,32 @@ static int gsc_commit(struct exynos_drm_ipp *ipp,
return 0;
 }
 
+static void gsc_get_align_size(struct gsc_context *ctx)
+{
+   u32 cfg, mask, shift;
+
+   mask = ctx->driver_data->in_ic_max_mask;
+   shift = ctx->driver_data->in_ic_max_shift;
+
+   pm_runtime_get_sync(ctx->dev);
+
+   cfg = gsc_read(GSC_IN_CON);
+
+   cfg = (cfg & mask << shift) >> shift;
+
+   if (cfg == 0)
+   ctx->align_size = 4;
+   else if (cfg == 1)
+   ctx->align_size = 8;
+   else
+   ctx->align_size = 16;
+
+   DRM_DEBUG_KMS("align_size = %d\n", ctx->align_size);
+
+   pm_runtime_mark_last_busy(ctx->dev);
+   pm_runtime_put_autosuspend(ctx->dev);
+}
+
 static void gsc_abort(struct exynos_drm_ipp *ipp,
  struct exynos_drm_ipp_task *task)
 {
@@ -1142,6 +1193,7 @@ static void gsc_abort(struct exynos_drm_ipp *ipp,
 }
 
 static struct exynos_drm_ipp_funcs ipp_funcs = {
+   .fixup = gsc_fixup,
.commit = gsc_commit,
.abort = gsc_abort,
 };
@@ -1155,6 +1207,9 @@ static int gsc_bind(struct device *dev, struct device 
*master, void *data)
ctx->drm_dev = drm_dev;
drm_iommu_attach_device(drm_dev, dev);
 
+   if (ctx->driver_data->has_in_ic_max)
+   gsc_get_align_size(ctx);
+
exynos_drm_ipp_register(drm_dev, ipp, _funcs,
DRM_EXYNOS_IPP_CAP_CROP | DRM_EXYNOS_IPP_CAP_ROTATE |
DRM_EXYNOS_IPP_CAP_SCALE | 

Re: [PATCH v2] drm/scheduler: Remove obsolete spinlock.

[zhoucm1]

Yes, every thing is clear, Acked-by: Chunming Zhou 


On 2018年05月16日 23:33, Andrey Grodzovsky wrote:

This spinlock is superfluous, any call to drm_sched_entity_push_job
should already be under a lock together with matching drm_sched_job_init
to match the order of insertion into queue with job's fence seqence
number.

v2:
Improve patch description.
Add functions documentation describing the locking considerations

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/scheduler/gpu_scheduler.c | 15 ++-
  include/drm/gpu_scheduler.h   |  1 -
  2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 1f1dd70..80dd66c 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
entity->last_scheduled = NULL;
  
  	spin_lock_init(>rq_lock);

-   spin_lock_init(>queue_lock);
spsc_queue_init(>job_queue);
  
  	atomic_set(>fence_seq, 0);

@@ -414,6 +413,10 @@ drm_sched_entity_pop_job(struct drm_sched_entity *entity)
   *
   * @sched_job The pointer to job required to submit
   *
+ * Note: To guarantee that the order of insertion to queue matches
+ * the job's fence sequence number this function should be
+ * called with drm_sched_job_init under common lock.
+ *
   * Returns 0 for success, negative error code otherwise.
   */
  void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
@@ -424,11 +427,8 @@ void drm_sched_entity_push_job(struct drm_sched_job 
*sched_job,
  
  	trace_drm_sched_job(sched_job, entity);
  
-	spin_lock(>queue_lock);

first = spsc_queue_push(>job_queue, _job->queue_node);
  
-	spin_unlock(>queue_lock);

-
/* first job wakes up scheduler */
if (first) {
/* Add the entity to the run queue */
@@ -594,7 +594,12 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler 
*sched)
  }
  EXPORT_SYMBOL(drm_sched_job_recovery);
  
-/* init a sched_job with basic field */

+/**
+ * Init a sched_job with basic field
+ *
+ * Note: Refer to drm_sched_entity_push_job documentation
+ * for locking considerations.
+ */
  int drm_sched_job_init(struct drm_sched_job *job,
   struct drm_gpu_scheduler *sched,
   struct drm_sched_entity *entity,
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
spinlock_t  rq_lock;
struct drm_gpu_scheduler*sched;
  
-	spinlock_t			queue_lock;

struct spsc_queue   job_queue;
  
  	atomic_t			fence_seq;


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

[PATCH] 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

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

[Bug 199567] [amdgpu] just a black screen irrespective of amdgpu.dc=1 or 0 at boot on kernels 4.17-rc2 and onwards

[bugzilla-daemon]

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

--- Comment #3 from Ant (untaintablean...@hotmail.co.uk) ---
Sorry for the delay. OK, so lots of news:

I did see a patch in amd-staging-drm-next 
354ee4815f52219fcd97d91269917261aac0518a ("drm/amd/display: Fix bug that causes
black screen") that sounded ideal but I couldn't apply it cleanly since it's
too out of sync.

After a git bisect, I was pleasantly surprised that the 3 main patches between
rc-1-rc2 for amd/display stuff were all fine. Looks like it's something else
entirely.

I tested out an ubuntu mainline kernel and it worked fine, so the problem is
something different in my custom .config, I guess. Something that has been fine
for 4.17-rc1 and kernels before that but suddenly needs to change for rc2
onwards.

(Bug still present on 4.17-rc5 btw)


last good: 5e747dd9be54be190dd6ebeebf4a4a01ba765625
first bad: 43838a23a05fbd13e47d750d3dfd77001536dd33

commit 43838a23a05fbd13e47d750d3dfd77001536dd33
Author: Theodore Ts'o 
Date:   Wed Apr 11 13:27:52 2018 -0400

random: fix crng_ready() test

The crng_init variable has three states:

0: The CRNG is not initialized at all
1: The CRNG has a small amount of entropy, hopefully good enough for
   early-boot, non-cryptographical use cases
2: The CRNG is fully initialized and we are sure it is safe for
   cryptographic use cases.

The crng_ready() function should only return true once we are in the
last state.  This addresses CVE-2018-1108.

Reported-by: Jann Horn 
Fixes: e192be9d9a30 ("random: replace non-blocking pool...")
Cc: sta...@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o 
Reviewed-by: Jann Horn 


I'm looking into my config options for RNG/random stuff, but this bug can
probably be bounced somewhere more appropriate now :)

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

[PATCH v2 3/3] drm/vkms: Add extra information about vkms

[Rodrigo Siqueira]

Add the following additional information: authors and description in
Kconfig.

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/Kconfig | 8 ++--
 drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0893b1d8ede7..a16efdea00fa 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -213,10 +213,14 @@ config DRM_VGEM
  If M is selected the module will be called vgem.
 
 config DRM_VKMS
-   tristate "Virtual KMS"
+   tristate "Virtual KMS (EXPERIMENTAL)"
depends on DRM
+   default n
help
- Choose this option to get a virtual kernal mode-setting driver.
+ Virtual Kernel Mode-Setting (VKMS) is used for testing or for
+ running GPU in a headless machines. Choose this option to get
+ a VKMS.
+
  If M is selected the module will be called vkms.
 
 source "drivers/gpu/drm/exynos/Kconfig"
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 070613e32934..740a4cbfed91 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -133,5 +133,7 @@ static void __exit vkms_exit(void)
 module_init(vkms_init);
 module_exit(vkms_exit);
 
+MODULE_AUTHOR("Haneen Mohammed ");
+MODULE_AUTHOR("Rodrigo Siqueira ");
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
-- 
2.17.0

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

[PATCH v2 2/3] drm/vkms: Add basic CRTC initialization

[Rodrigo Siqueira]

This commit adds the essential infrastructure for around CRTCs which
is composed of: a new data struct for output data information, a
function for creating planes, and a simple encoder attached to the
connector. Finally, due to the introduction of a new initialization
function, connectors were moved from vkms_drv.c to vkms_display.c.

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vkms/Makefile  |  2 +-
 drivers/gpu/drm/vkms/vkms_crtc.c   | 35 
 drivers/gpu/drm/vkms/vkms_drv.c| 60 ++--
 drivers/gpu/drm/vkms/vkms_drv.h| 24 +++-
 drivers/gpu/drm/vkms/vkms_output.c | 91 ++
 drivers/gpu/drm/vkms/vkms_plane.c  | 46 +++
 6 files changed, 211 insertions(+), 47 deletions(-)
 create mode 100644 drivers/gpu/drm/vkms/vkms_crtc.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_output.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c

diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 2aef948d3a34..3f774a6a9c58 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -1,3 +1,3 @@
-vkms-y := vkms_drv.o
+vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o
 
 obj-$(CONFIG_DRM_VKMS) += vkms.o
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
new file mode 100644
index ..bf76cd39ece7
--- /dev/null
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "vkms_drv.h"
+#include 
+#include 
+
+static const struct drm_crtc_funcs vkms_crtc_funcs = {
+   .set_config = drm_atomic_helper_set_config,
+   .destroy= drm_crtc_cleanup,
+   .page_flip  = drm_atomic_helper_page_flip,
+   .reset  = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
+};
+
+int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
+  struct drm_plane *primary, struct drm_plane *cursor)
+{
+   int ret;
+
+   ret = drm_crtc_init_with_planes(dev, crtc, primary, cursor,
+   _crtc_funcs, NULL);
+   if (ret) {
+   DRM_ERROR("Failed to init CRTC\n");
+   return ret;
+   }
+
+   return ret;
+}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index aec3f180f96d..070613e32934 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -6,7 +6,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -59,25 +58,24 @@ static struct drm_driver vkms_driver = {
.minor  = DRIVER_MINOR,
 };
 
-static const u32 vkms_formats[] = {
-   DRM_FORMAT_XRGB,
+static const struct drm_mode_config_funcs vkms_mode_funcs = {
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
-static void vkms_connector_destroy(struct drm_connector *connector)
+static int vkms_modeset_init(struct vkms_device *vkmsdev)
 {
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
+   struct drm_device *dev = >drm;
 
-static const struct drm_connector_funcs vkms_connector_funcs = {
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = vkms_connector_destroy,
-};
+   drm_mode_config_init(dev);
+   dev->mode_config.funcs = _mode_funcs;
+   dev->mode_config.min_width = XRES_MIN;
+   dev->mode_config.min_height = YRES_MIN;
+   dev->mode_config.max_width = XRES_MAX;
+   dev->mode_config.max_height = YRES_MAX;
 
-static const struct drm_mode_config_funcs vkms_mode_funcs = {
-   .atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
-};
+   return vkms_output_init(vkmsdev);
+}
 
 static int __init vkms_init(void)
 {
@@ -98,48 +96,24 @@ static int __init vkms_init(void)
goto out_fini;
}
 
-   drm_mode_config_init(_device->drm);
-   vkms_device->drm.mode_config.funcs = _mode_funcs;
-   vkms_device->drm.mode_config.min_width = XRES_MIN;
-   vkms_device->drm.mode_config.min_height = YRES_MIN;
-   vkms_device->drm.mode_config.max_width = XRES_MAX;
-   vkms_device->drm.mode_config.max_height = YRES_MAX;
-
-   ret = drm_connector_init(_device->drm, _device->connector,
-_connector_funcs,
-DRM_MODE_CONNECTOR_VIRTUAL);
-   if (ret < 0) {
-   DRM_ERROR("Failed to init connector\n");
- 

[PATCH v2 1/3] drm/vkms: Add mode_config initialization

[Rodrigo Siqueira]

Initialize minimum and maximum width and height of the frame buffers
with default values.

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vkms/vkms_drv.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 35517b09538e..aec3f180f96d 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "vkms_drv.h"
 
 #define DRIVER_NAME"vkms"
@@ -17,6 +18,12 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
+#define XRES_MIN32
+#define YRES_MIN32
+
+#define XRES_MAX  8192
+#define YRES_MAX  8192
+
 static struct vkms_device *vkms_device;
 
 static const struct file_operations vkms_driver_fops = {
@@ -67,6 +74,11 @@ static const struct drm_connector_funcs vkms_connector_funcs 
= {
.destroy = vkms_connector_destroy,
 };
 
+static const struct drm_mode_config_funcs vkms_mode_funcs = {
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
 static int __init vkms_init(void)
 {
int ret;
@@ -87,6 +99,11 @@ static int __init vkms_init(void)
}
 
drm_mode_config_init(_device->drm);
+   vkms_device->drm.mode_config.funcs = _mode_funcs;
+   vkms_device->drm.mode_config.min_width = XRES_MIN;
+   vkms_device->drm.mode_config.min_height = YRES_MIN;
+   vkms_device->drm.mode_config.max_width = XRES_MAX;
+   vkms_device->drm.mode_config.max_height = YRES_MAX;
 
ret = drm_connector_init(_device->drm, _device->connector,
 _connector_funcs,
-- 
2.17.0

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

[PATCH v2 0/3] Expanding the basic vkms features

[Rodrigo Siqueira]

This series of patches add a centralized initialization mechanism, a
single CRTC with a plane, an encoder, and extra module information. 

Changes in v2:
 - Remove unused definitions
 - Improve file names
 - Improve code separation
 - Remove unnecessary formats

Rodrigo Siqueira (3):
  drm/vkms: Add mode_config initialization
  drm/vkms: Add basic CRTC initialization
  drm/vkms: Add extra information about vkms

 drivers/gpu/drm/Kconfig|  8 ++-
 drivers/gpu/drm/vkms/Makefile  |  2 +-
 drivers/gpu/drm/vkms/vkms_crtc.c   | 35 
 drivers/gpu/drm/vkms/vkms_drv.c| 61 +---
 drivers/gpu/drm/vkms/vkms_drv.h| 24 +++-
 drivers/gpu/drm/vkms/vkms_output.c | 91 ++
 drivers/gpu/drm/vkms/vkms_plane.c  | 46 +++
 7 files changed, 227 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/vkms/vkms_crtc.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_output.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c

-- 
2.17.0

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

Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

[Brian Norris]

+ Kishon

Hi,

On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
> 
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() 
> follow Sean suggest
> 
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 505 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c

...

> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 000..7efd070
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cdn-dp-core.h"
> +#include "cdn-dp-reg.h"
> +
> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
> +{
> + struct cdn_dp_port *port = dp->port[dp->active_port];
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);

This is still antithetical to the PHY framework; you're assuming that
this is a particular type of PHY here.

> +
> + int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
> + u8 swing = (dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) >>
> +DP_TRAIN_VOLTAGE_SWING_SHIFT;
> + u8 pre_emphasis = (dp->train_set[0] & DP_TRAIN_PRE_EMPHASIS_MASK)
> +   >> DP_TRAIN_PRE_EMPHASIS_SHIFT;
> +
> + tcphy->typec_phy_config(port->phy, rate, dp->link.num_lanes,
> + swing, pre_emphasis);

Is this something generic that could be added as a new PHY API instead?

> +}

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

Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

[Brian Norris]

On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
> 
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() 
> follow Sean suggest
> 
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 505 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c

Please rerun checkpatch next time. You've got a bunch of whitespace
issues in cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link().

Brian

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

Re: [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-devel@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
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

Leo Li  changed:

   What|Removed |Added

 Attachment #139205|0   |1
is obsolete||
   Assignee|dri-devel@lists.freedesktop |sunpeng...@amd.com
   |.org|
 Status|NEW |ASSIGNED

--- Comment #12 from Leo Li  ---
Created attachment 139602
  --> https://bugs.freedesktop.org/attachment.cgi?id=139602=edit
Fix v1

It seems I've reproduced it by using the default modesetting DDX driver.
Please give the attached patch a shot.

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

Re: [PATCH v2 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-devel@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;
> > +   /**
> > 

[git pull] vmwgfx-fixes-4.17

[Thomas Hellstrom]

Hi, Dave,
A single fix for a recent regression.

The following changes since commit 13f149d47392782baafd96d54d4e65f3b5ca342f:

  drm/vmwgfx: Fix a buffer object leak (2018-04-26 09:59:30 +0200)

are available in the Git repository at:

  git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-4.17

for you to fetch changes up to 91ba9f28a3de97761c2b5fd5df5d88421268e507:

  drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful (2018-05-16 
08:01:20 +0200)


Deepak Rawat (1):
  drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful

 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++
 1 file changed, 2 insertions(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106547] *ERROR* ring sdma0 timeout while watching video, Raven Ridge

[bugzilla-daemon]

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

--- Comment #2 from ojab  ---
Created attachment 139601
  --> https://bugs.freedesktop.org/attachment.cgi?id=139601=edit
Xorg.0.log

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

[Bug 106547] *ERROR* ring sdma0 timeout while watching video, Raven Ridge

[bugzilla-daemon]

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

--- Comment #1 from ojab  ---
Created attachment 139600
  --> https://bugs.freedesktop.org/attachment.cgi?id=139600=edit
dmesg

dmesg can be found in the attached file, I've cut unrelated (lots of BTRFS
info/hardpss/etc) stuff.
Kernel is tainted this time, but previous time it was not, so probably it's not
related.

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

[Bug 106547] *ERROR* ring sdma0 timeout while watching video, Raven Ridge

[bugzilla-daemon]

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

Bug ID: 106547
   Summary: *ERROR* ring sdma0 timeout while watching video, Raven
Ridge
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: o...@ojab.ru

Raven Ridge APU (2400G), no external GPU, linux-4.17-rc5, libdrm-2.4.91,
mesa-18.1.0-rc1, xorg-server-1.19.6, xf86-video-amdgpu-18.0.1, libva-2.1.0,
mpv-0.28.2.

Getting this error second time, so probably there should be a report about it.

During h.264 video playback via `mpv --hwdec=vaapi --vo=vaapi` I'm getting:

[Wed May 16 19:13:48 2018] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring
sdma0 timeout, last signaled seq=15362, last emitted seq=15365
[Wed May 16 19:13:48 2018] [drm] No hardware hang detected. Did some blocks
stall?

and image is stalled, X cannot be killed. Nothing graphical is started except X
& mpv.

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

[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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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-devel@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 */
> + 

Re: [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-devel@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;
> 

Re: [PATCH] drm/etnaviv: replace license text with SPDX tags

[Christian Gmeiner]

Am Di., 8. Mai 2018 um 16:30 Uhr schrieb Lucas Stach  :

> This replaces the repetitive GPL-2.0 license text in code and header files
> with the SPDX tags. Generated hardware headers aren't changed, as any
changes
> there need to be done in the upstream rnndb repository.

> Signed-off-by: Lucas Stach 

Needed some time to think about it - I am okay with this change.

Reviewed-by: Christian Gmeiner 

> ---
> Christian, I've replaced some of your copyright statements with the
generic
> "Etnaviv Project" statements we use almost everywhere. Please NACK this
patch
> if your aren't comfortable with this.
> ---
>   drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 16 ++--
>   drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 13 +
>   drivers/gpu/drm/etnaviv/etnaviv_drv.c| 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_drv.h| 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_dump.c   | 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_dump.h   | 16 ++--
>   drivers/gpu/drm/etnaviv/etnaviv_gem.c| 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_gem.h| 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c  | 16 ++--
>   drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_hwdb.c   | 13 +
>   drivers/gpu/drm/etnaviv/etnaviv_iommu.c  | 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_iommu.h  | 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c   | 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 15 ++-
>   drivers/gpu/drm/etnaviv/etnaviv_perfmon.c| 13 +
>   drivers/gpu/drm/etnaviv/etnaviv_perfmon.h| 13 +
>   drivers/gpu/drm/etnaviv/etnaviv_sched.c  | 13 +
>   drivers/gpu/drm/etnaviv/etnaviv_sched.h  | 13 +
>   23 files changed, 40 insertions(+), 296 deletions(-)

> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index bfc6d4aa3b7c..7fea74861a87 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -1,18 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
> - * Copyright (C) 2014 Etnaviv Project
> - * Author: Christian Gmeiner 
> - *
> - * This program is free software; you can redistribute it and/or modify
it
> - * under the terms of the GNU General Public License version 2 as
published by
> - * the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License
along with
> - * this program.  If not, see .
> + * Copyright (C) 2014-2018 Etnaviv Project
>*/

>   #include "etnaviv_cmdbuf.h"
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
b/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
> index c107171b7f9e..b6c37da8ae15 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
> @@ -1,17 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
> - * Copyright (C) 2015 Etnaviv Project
> - *
> - * This program is free software; you can redistribute it and/or modify
it
> - * under the terms of the GNU General Public License version 2 as
published by
> - * the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License
along with
> - * this program.  If not, see .
> + * Copyright (C) 2015-2018 Etnaviv Project
>*/

>   #include 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index 3746827f45eb..a3c44f145c1d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -1,17 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0
>   /*
> - * Copyright (C) 2017 Etnaviv Project
> - *
> - * This program is free software; you can redistribute it and/or modify
it
> - * under the terms of the GNU General Public License 

Re: [PATCH 14/14] mm: turn on vm_fault_t type checking

[Christoph Hellwig]

On Wed, May 16, 2018 at 08:08:29AM -0700, Darrick J. Wong wrote:
> Uh, we're changing function signatures /and/ redefinining vm_fault_t?
> All in the same 90K patch?
> 
> I /was/ expecting a series of "convert X and all callers/users"
> patches followed by a trivial one to switch the definition, not a giant
> pile of change.  FWIW I don't mind so much if you make a patch
> containing a change for some super-common primitive and a hojillion
> little diff hunks tree-wide, but only one logical change at a time for a
> big patch, please...
> 
> I quite prefer seeing the whole series from start to finish all packaged
> up in one series, but wow this was overwhelming. :/

Another vote to split the change of the typedef, ok I get the message..
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: vm_fault_t conversion, for real

[Christoph Hellwig]

On Wed, May 16, 2018 at 06:22:56AM -0700, Matthew Wilcox wrote:
> Perhaps you should try being less of an arsehole if you don't want to
> get yelled at?  I don't mind when you're an arsehole towards me, but I
> do mind when you're an arsehole towards newcomers.  How are we supposed
> to attract and retain new maintainers when you're so rude?

*plonk*  The only one I'm seeing being extremely rude here is you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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-...@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support

[Sergei Shtylyov]

On 05/16/2018 04:06 PM, Ulrich Hecht wrote:

 Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.

 Signed-off-by: Ulrich Hecht 
 ---
   drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
   1 file changed, 6 insertions(+)

 diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
 b/drivers/gpu/drm/rcar-du/rcar_lvds.c
 index 3d2d3bb..58fb9f8 100644
 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
 +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
 @@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info
 rcar_lvds_r8a77970_info = {
 .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
   };
   +static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
 +   .gen = 3,
 +   .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
 +};
>>>
>>>
>>> This new structure seems to be identical to rcar_lvds_r8a77970_info.
>>
>>> Could we consolidate somehow?
>>
>>In my book, that one has 2 quirk flags. What tree are you looking at?
> 
> IIRC the other one was for the PLL, which is not supported yet.

   V3M PLL is surely supported and it's surely different from D3 one. My point 
was that r8a77970 data can't be reused...

> CU
> Uli

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

[gabbayo:private 2/2] ERROR: "amdgpu_amdkfd_gfx_7_get_functions" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

[kbuild test robot]

tree:   git://people.freedesktop.org/~gabbayo/linux private
head:   9508d7f3767467f58c0df9680de93fb2fca66bc3
commit: 9508d7f3767467f58c0df9680de93fb2fca66bc3 [2/2] drm/amdgpu: 
conditionally compile amdgpu's amdkfd files
config: x86_64-fedora-25 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 9508d7f3767467f58c0df9680de93fb2fca66bc3
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "amdgpu_amdkfd_gfx_7_get_functions" 
>> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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-...@lists.freedesktop.org; dri-devel@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-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

Re: [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-...@lists.freedesktop.org; dri-devel@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: [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-...@lists.freedesktop.org; dri-devel@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: [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-...@lists.freedesktop.org; dri-devel@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 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-...@lists.freedesktop.org; dri-devel@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-...@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-...@lists.freedesktop.org; dri-devel@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-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


___
dri-devel mailing list

Re: [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-...@lists.freedesktop.org; dri-devel@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-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list

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-...@lists.freedesktop.org; dri-devel@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 

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #11 from mikhail.v.gavri...@gmail.com ---
(In reply to Christian König from comment #10)
> Please provide the output of vainfo.

$ vainfo
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Mesa Gallium driver 18.1.0-rc3 for Radeon RX Vega
(VEGA10, DRM 3.25.0, 4.17.0-0.rc4.git2.1.fc29.x86_64, LLVM 6.0.0)
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice
  VAProfileHEVCMain10 : VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc

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

Re: [PATCH v2] drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

[Daniel Vetter]

On Wed, May 16, 2018 at 05:00:26PM +0300, Dan Carpenter wrote:
> There is a comment here which says that DIV_ROUND_UP() and that's where
> the problem comes from.  Say you pick:
> 
>   args->bpp = UINT_MAX - 7;
>   args->width = 4;
>   args->height = 1;
> 
> The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and
> because of how we picked args->width that means cpp < UINT_MAX / 4.
> 
> I've fixed it by preventing the integer overflow in DIV_ROUND_UP().  I
> removed the check for !cpp because it's not possible after this change.
> I also changed all the 0xU references to U32_MAX.
> 
> Signed-off-by: Dan Carpenter 
> ---
> v2:  additional cleanups

Thanks a lot for respinning, applied to drm-misc-fixes.
-Daniel

> 
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c 
> b/drivers/gpu/drm/drm_dumb_buffers.c
> index 39ac15ce4702..9e2ae02f31e0 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -65,12 +65,13 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
>   return -EINVAL;
>  
>   /* overflow checks for 32bit size calculations */
> - /* NOTE: DIV_ROUND_UP() can overflow */
> + if (args->bpp > U32_MAX - 8)
> + return -EINVAL;
>   cpp = DIV_ROUND_UP(args->bpp, 8);
> - if (!cpp || cpp > 0xU / args->width)
> + if (cpp > U32_MAX / args->width)
>   return -EINVAL;
>   stride = cpp * args->width;
> - if (args->height > 0xU / stride)
> + if (args->height > U32_MAX / stride)
>   return -EINVAL;
>  
>   /* test for wrap-around */
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH 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-...@lists.freedesktop.org; dri-devel@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 @@ 

Re: [PATCH 1/3] drm/vkms: Add basic CRTC initialization

[Rodrigo Siqueira]

Now I got it! I will split the patch and apply your suggestions :)
Thanks

On 05/16, Daniel Vetter wrote:
> On Wed, May 16, 2018 at 5:40 PM, Daniel Vetter  wrote:
> > On Wed, May 16, 2018 at 4:51 PM, Rodrigo Siqueira
> >  wrote:
> >> Hi Daniel,
> >>
> >> Thanks for the feedback :)
> >>
> >> You can find my comments below:
> >>
> >> On 05/16, Daniel Vetter wrote:
> >>> On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siqueira wrote:
> >>> > This commit adds the essential infrastructure for managing CRTCs which
> >>> > is composed of: a new data struct for output data information, a
> >>> > function for basic modeset initialization, and the operation to create
> >>> > planes. Due to the introduction of a new initialization function,
> >>> > connectors were moved from vkms_drv.c to vkms_display.c.
> >>> >
> >>> > Signed-off-by: Rodrigo Siqueira 
> >>> > ---
> >>> >  drivers/gpu/drm/vkms/Makefile   |   2 +-
> >>> >  drivers/gpu/drm/vkms/vkms_display.c | 108 
> >>> >  drivers/gpu/drm/vkms/vkms_drv.c |  41 +--
> >>> >  drivers/gpu/drm/vkms/vkms_drv.h |  26 ++-
> >>> >  drivers/gpu/drm/vkms/vkms_plane.c   |  46 
> >>> >  5 files changed, 180 insertions(+), 43 deletions(-)
> >>> >  create mode 100644 drivers/gpu/drm/vkms/vkms_display.c
> >>> >  create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c
> >>> >
> >>> > diff --git a/drivers/gpu/drm/vkms/Makefile 
> >>> > b/drivers/gpu/drm/vkms/Makefile
> >>> > index 2aef948d3a34..f747e2a3a6f4 100644
> >>> > --- a/drivers/gpu/drm/vkms/Makefile
> >>> > +++ b/drivers/gpu/drm/vkms/Makefile
> >>> > @@ -1,3 +1,3 @@
> >>> > -vkms-y := vkms_drv.o
> >>> > +vkms-y := vkms_drv.o vkms_plane.o vkms_display.o
> >>> >
> >>> >  obj-$(CONFIG_DRM_VKMS) += vkms.o
> >>> > diff --git a/drivers/gpu/drm/vkms/vkms_display.c 
> >>> > b/drivers/gpu/drm/vkms/vkms_display.c
> >>> > new file mode 100644
> >>> > index ..b20b41f9590b
> >>> > --- /dev/null
> >>> > +++ b/drivers/gpu/drm/vkms/vkms_display.c
> >>> > @@ -0,0 +1,108 @@
> >>> > +// SPDX-License-Identifier: GPL-2.0
> >>> > +/*
> >>> > + * This program is free software; you can redistribute it and/or modify
> >>> > + * it under the terms of the GNU General Public License as published by
> >>> > + * the Free Software Foundation; either version 2 of the License, or
> >>> > + * (at your option) any later version.
> >>> > + */
> >>> > +
> >>> > +#include "vkms_drv.h"
> >>> > +#include 
> >>> > +#include 
> >>> > +
> >>> > +#define XRES_MIN32
> >>> > +#define YRES_MIN32
> >>> > +
> >>> > +#define XRES_DEF  1024
> >>> > +#define YRES_DEF   768
> >>>
> >>> These seem unused.
> >>
> >> I created these defines because the documentation says:
> >>
> >> "[..]Once done, mode configuration must be setup by initializing the
> >> following fields."
> >> (https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#c.drm_mode_config_init)
> >>
> >> Finally, I used them in "mode_config" fields from drm_device (code below).
> >>
> >> Is it ok to not setup these values on mode_config? I looked at virtio as
> >> an inspiration for this.
> >
> > XYRES_MIN and _MAX you need, but _DEF seems unused. That's why I
> > asked, sorry for not making this clear.
> 
> btw could make sense to split this fix into a separate patch, since
> the min/max setup is indeed missing and required.
> -Daniel
> 
> > -Daniel
> >
> >>
> >>> > +static const struct drm_mode_config_funcs vkms_mode_funcs = {
> >>> > +   .atomic_check = drm_atomic_helper_check,
> >>> > +   .atomic_commit = drm_atomic_helper_commit,
> >>> > +};
> >>> > +
> >>> > +static const struct drm_crtc_funcs vkms_crtc_funcs = {
> >>> > +   .set_config = drm_atomic_helper_set_config,
> >>> > +   .destroy= drm_crtc_cleanup,
> >>> > +   .page_flip  = drm_atomic_helper_page_flip,
> >>> > +   .reset  = drm_atomic_helper_crtc_reset,
> >>> > +   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> >>> > +   .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
> >>> > +};
> >>> > +
> >>> > +static void vkms_connector_destroy(struct drm_connector *connector)
> >>> > +{
> >>> > +   drm_connector_unregister(connector);
> >>> > +   drm_connector_cleanup(connector);
> >>> > +}
> >>> > +
> >>> > +static const struct drm_connector_funcs vkms_connector_funcs = {
> >>> > +   .fill_modes = drm_helper_probe_single_connector_modes,
> >>> > +   .destroy = vkms_connector_destroy,
> >>> > +};
> >>> > +
> >>> > +static int vkms_output_init(struct vkms_device *vkmsdev)
> >>> > +{
> >>> > +   struct vkms_output *output = >output;
> >>> > +   struct drm_device *dev = >drm;
> >>> > +   struct drm_connector *connector = >connector;
> >>> > +   struct drm_crtc *crtc = >crtc;
> >>> > +   struct drm_plane *primary;
> >>> > +   int ret;
> >>> > +
> >>> > +   primary = vkms_plane_init(vkmsdev);
> >>> > +   if 

Re: [PATCH v2] drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

[Dan Carpenter]

Btw, I've looked at this some more and I'm 99% sure there is no way to
exploit it.  The "if (PAGE_ALIGN(size) == 0)" prevents the integer
overflow in __vgem_gem_create() that I was worried about.

regards,
dan carpenter


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

Re: [PATCH 1/3] drm/vkms: Add basic CRTC initialization

[Daniel Vetter]

On Wed, May 16, 2018 at 5:40 PM, Daniel Vetter  wrote:
> On Wed, May 16, 2018 at 4:51 PM, Rodrigo Siqueira
>  wrote:
>> Hi Daniel,
>>
>> Thanks for the feedback :)
>>
>> You can find my comments below:
>>
>> On 05/16, Daniel Vetter wrote:
>>> On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siqueira wrote:
>>> > This commit adds the essential infrastructure for managing CRTCs which
>>> > is composed of: a new data struct for output data information, a
>>> > function for basic modeset initialization, and the operation to create
>>> > planes. Due to the introduction of a new initialization function,
>>> > connectors were moved from vkms_drv.c to vkms_display.c.
>>> >
>>> > Signed-off-by: Rodrigo Siqueira 
>>> > ---
>>> >  drivers/gpu/drm/vkms/Makefile   |   2 +-
>>> >  drivers/gpu/drm/vkms/vkms_display.c | 108 
>>> >  drivers/gpu/drm/vkms/vkms_drv.c |  41 +--
>>> >  drivers/gpu/drm/vkms/vkms_drv.h |  26 ++-
>>> >  drivers/gpu/drm/vkms/vkms_plane.c   |  46 
>>> >  5 files changed, 180 insertions(+), 43 deletions(-)
>>> >  create mode 100644 drivers/gpu/drm/vkms/vkms_display.c
>>> >  create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c
>>> >
>>> > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
>>> > index 2aef948d3a34..f747e2a3a6f4 100644
>>> > --- a/drivers/gpu/drm/vkms/Makefile
>>> > +++ b/drivers/gpu/drm/vkms/Makefile
>>> > @@ -1,3 +1,3 @@
>>> > -vkms-y := vkms_drv.o
>>> > +vkms-y := vkms_drv.o vkms_plane.o vkms_display.o
>>> >
>>> >  obj-$(CONFIG_DRM_VKMS) += vkms.o
>>> > diff --git a/drivers/gpu/drm/vkms/vkms_display.c 
>>> > b/drivers/gpu/drm/vkms/vkms_display.c
>>> > new file mode 100644
>>> > index ..b20b41f9590b
>>> > --- /dev/null
>>> > +++ b/drivers/gpu/drm/vkms/vkms_display.c
>>> > @@ -0,0 +1,108 @@
>>> > +// SPDX-License-Identifier: GPL-2.0
>>> > +/*
>>> > + * This program is free software; you can redistribute it and/or modify
>>> > + * it under the terms of the GNU General Public License as published by
>>> > + * the Free Software Foundation; either version 2 of the License, or
>>> > + * (at your option) any later version.
>>> > + */
>>> > +
>>> > +#include "vkms_drv.h"
>>> > +#include 
>>> > +#include 
>>> > +
>>> > +#define XRES_MIN32
>>> > +#define YRES_MIN32
>>> > +
>>> > +#define XRES_DEF  1024
>>> > +#define YRES_DEF   768
>>>
>>> These seem unused.
>>
>> I created these defines because the documentation says:
>>
>> "[..]Once done, mode configuration must be setup by initializing the
>> following fields."
>> (https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#c.drm_mode_config_init)
>>
>> Finally, I used them in "mode_config" fields from drm_device (code below).
>>
>> Is it ok to not setup these values on mode_config? I looked at virtio as
>> an inspiration for this.
>
> XYRES_MIN and _MAX you need, but _DEF seems unused. That's why I
> asked, sorry for not making this clear.

btw could make sense to split this fix into a separate patch, since
the min/max setup is indeed missing and required.
-Daniel

> -Daniel
>
>>
>>> > +static const struct drm_mode_config_funcs vkms_mode_funcs = {
>>> > +   .atomic_check = drm_atomic_helper_check,
>>> > +   .atomic_commit = drm_atomic_helper_commit,
>>> > +};
>>> > +
>>> > +static const struct drm_crtc_funcs vkms_crtc_funcs = {
>>> > +   .set_config = drm_atomic_helper_set_config,
>>> > +   .destroy= drm_crtc_cleanup,
>>> > +   .page_flip  = drm_atomic_helper_page_flip,
>>> > +   .reset  = drm_atomic_helper_crtc_reset,
>>> > +   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>>> > +   .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
>>> > +};
>>> > +
>>> > +static void vkms_connector_destroy(struct drm_connector *connector)
>>> > +{
>>> > +   drm_connector_unregister(connector);
>>> > +   drm_connector_cleanup(connector);
>>> > +}
>>> > +
>>> > +static const struct drm_connector_funcs vkms_connector_funcs = {
>>> > +   .fill_modes = drm_helper_probe_single_connector_modes,
>>> > +   .destroy = vkms_connector_destroy,
>>> > +};
>>> > +
>>> > +static int vkms_output_init(struct vkms_device *vkmsdev)
>>> > +{
>>> > +   struct vkms_output *output = >output;
>>> > +   struct drm_device *dev = >drm;
>>> > +   struct drm_connector *connector = >connector;
>>> > +   struct drm_crtc *crtc = >crtc;
>>> > +   struct drm_plane *primary;
>>> > +   int ret;
>>> > +
>>> > +   primary = vkms_plane_init(vkmsdev);
>>> > +   if (IS_ERR(primary))
>>> > +   return PTR_ERR(primary);
>>> > +
>>> > +   ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL,
>>> > +   _crtc_funcs, NULL);
>>> > +   if (ret) {
>>> > +   DRM_ERROR("Failed to init CRTC\n");
>>> > +   goto err_crtc;
>>> > +   }
>>> > +   primary->crtc = crtc;
>>>
>>> If you want 

Re: [PATCH 1/3] drm/vkms: Add basic CRTC initialization

[Daniel Vetter]

On Wed, May 16, 2018 at 4:51 PM, Rodrigo Siqueira
 wrote:
> Hi Daniel,
>
> Thanks for the feedback :)
>
> You can find my comments below:
>
> On 05/16, Daniel Vetter wrote:
>> On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siqueira wrote:
>> > This commit adds the essential infrastructure for managing CRTCs which
>> > is composed of: a new data struct for output data information, a
>> > function for basic modeset initialization, and the operation to create
>> > planes. Due to the introduction of a new initialization function,
>> > connectors were moved from vkms_drv.c to vkms_display.c.
>> >
>> > Signed-off-by: Rodrigo Siqueira 
>> > ---
>> >  drivers/gpu/drm/vkms/Makefile   |   2 +-
>> >  drivers/gpu/drm/vkms/vkms_display.c | 108 
>> >  drivers/gpu/drm/vkms/vkms_drv.c |  41 +--
>> >  drivers/gpu/drm/vkms/vkms_drv.h |  26 ++-
>> >  drivers/gpu/drm/vkms/vkms_plane.c   |  46 
>> >  5 files changed, 180 insertions(+), 43 deletions(-)
>> >  create mode 100644 drivers/gpu/drm/vkms/vkms_display.c
>> >  create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c
>> >
>> > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
>> > index 2aef948d3a34..f747e2a3a6f4 100644
>> > --- a/drivers/gpu/drm/vkms/Makefile
>> > +++ b/drivers/gpu/drm/vkms/Makefile
>> > @@ -1,3 +1,3 @@
>> > -vkms-y := vkms_drv.o
>> > +vkms-y := vkms_drv.o vkms_plane.o vkms_display.o
>> >
>> >  obj-$(CONFIG_DRM_VKMS) += vkms.o
>> > diff --git a/drivers/gpu/drm/vkms/vkms_display.c 
>> > b/drivers/gpu/drm/vkms/vkms_display.c
>> > new file mode 100644
>> > index ..b20b41f9590b
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/vkms/vkms_display.c
>> > @@ -0,0 +1,108 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/*
>> > + * This program is free software; you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License as published by
>> > + * the Free Software Foundation; either version 2 of the License, or
>> > + * (at your option) any later version.
>> > + */
>> > +
>> > +#include "vkms_drv.h"
>> > +#include 
>> > +#include 
>> > +
>> > +#define XRES_MIN32
>> > +#define YRES_MIN32
>> > +
>> > +#define XRES_DEF  1024
>> > +#define YRES_DEF   768
>>
>> These seem unused.
>
> I created these defines because the documentation says:
>
> "[..]Once done, mode configuration must be setup by initializing the
> following fields."
> (https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#c.drm_mode_config_init)
>
> Finally, I used them in "mode_config" fields from drm_device (code below).
>
> Is it ok to not setup these values on mode_config? I looked at virtio as
> an inspiration for this.

XYRES_MIN and _MAX you need, but _DEF seems unused. That's why I
asked, sorry for not making this clear.
-Daniel

>
>> > +static const struct drm_mode_config_funcs vkms_mode_funcs = {
>> > +   .atomic_check = drm_atomic_helper_check,
>> > +   .atomic_commit = drm_atomic_helper_commit,
>> > +};
>> > +
>> > +static const struct drm_crtc_funcs vkms_crtc_funcs = {
>> > +   .set_config = drm_atomic_helper_set_config,
>> > +   .destroy= drm_crtc_cleanup,
>> > +   .page_flip  = drm_atomic_helper_page_flip,
>> > +   .reset  = drm_atomic_helper_crtc_reset,
>> > +   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>> > +   .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
>> > +};
>> > +
>> > +static void vkms_connector_destroy(struct drm_connector *connector)
>> > +{
>> > +   drm_connector_unregister(connector);
>> > +   drm_connector_cleanup(connector);
>> > +}
>> > +
>> > +static const struct drm_connector_funcs vkms_connector_funcs = {
>> > +   .fill_modes = drm_helper_probe_single_connector_modes,
>> > +   .destroy = vkms_connector_destroy,
>> > +};
>> > +
>> > +static int vkms_output_init(struct vkms_device *vkmsdev)
>> > +{
>> > +   struct vkms_output *output = >output;
>> > +   struct drm_device *dev = >drm;
>> > +   struct drm_connector *connector = >connector;
>> > +   struct drm_crtc *crtc = >crtc;
>> > +   struct drm_plane *primary;
>> > +   int ret;
>> > +
>> > +   primary = vkms_plane_init(vkmsdev);
>> > +   if (IS_ERR(primary))
>> > +   return PTR_ERR(primary);
>> > +
>> > +   ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL,
>> > +   _crtc_funcs, NULL);
>> > +   if (ret) {
>> > +   DRM_ERROR("Failed to init CRTC\n");
>> > +   goto err_crtc;
>> > +   }
>> > +   primary->crtc = crtc;
>>
>> If you want to split stuff up a bit, I think putting the crtc stuff into
>> vkms_crtc.c, and then renaming this file here to vkms_output.c would make
>> sense.
>
> Nice, make a lot of sense to me. I will do it on v2.
>
>> > +
>> > +   ret = drm_connector_init(dev, connector, _connector_funcs,
>> > +

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-...@lists.freedesktop.org; dri-devel@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 

[PATCH v2] drm/scheduler: Remove obsolete spinlock.

[Andrey Grodzovsky]

This spinlock is superfluous, any call to drm_sched_entity_push_job
should already be under a lock together with matching drm_sched_job_init
to match the order of insertion into queue with job's fence seqence
number.

v2:
Improve patch description.
Add functions documentation describing the locking considerations

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 15 ++-
 include/drm/gpu_scheduler.h   |  1 -
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 1f1dd70..80dd66c 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
entity->last_scheduled = NULL;
 
spin_lock_init(>rq_lock);
-   spin_lock_init(>queue_lock);
spsc_queue_init(>job_queue);
 
atomic_set(>fence_seq, 0);
@@ -414,6 +413,10 @@ drm_sched_entity_pop_job(struct drm_sched_entity *entity)
  *
  * @sched_job  The pointer to job required to submit
  *
+ * Note: To guarantee that the order of insertion to queue matches
+ * the job's fence sequence number this function should be
+ * called with drm_sched_job_init under common lock.
+ *
  * Returns 0 for success, negative error code otherwise.
  */
 void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
@@ -424,11 +427,8 @@ void drm_sched_entity_push_job(struct drm_sched_job 
*sched_job,
 
trace_drm_sched_job(sched_job, entity);
 
-   spin_lock(>queue_lock);
first = spsc_queue_push(>job_queue, _job->queue_node);
 
-   spin_unlock(>queue_lock);
-
/* first job wakes up scheduler */
if (first) {
/* Add the entity to the run queue */
@@ -594,7 +594,12 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler 
*sched)
 }
 EXPORT_SYMBOL(drm_sched_job_recovery);
 
-/* init a sched_job with basic field */
+/**
+ * Init a sched_job with basic field
+ *
+ * Note: Refer to drm_sched_entity_push_job documentation
+ * for locking considerations.
+ */
 int drm_sched_job_init(struct drm_sched_job *job,
   struct drm_gpu_scheduler *sched,
   struct drm_sched_entity *entity,
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
spinlock_t  rq_lock;
struct drm_gpu_scheduler*sched;
 
-   spinlock_t  queue_lock;
struct spsc_queue   job_queue;
 
atomic_tfence_seq;
-- 
2.7.4

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

Re: [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-...@lists.freedesktop.org; dri-devel@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 

Re: [PATCH v2] drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

[Chris Wilson]

Quoting Dan Carpenter (2018-05-16 16:15:54)
> On Wed, May 16, 2018 at 03:56:55PM +0100, Chris Wilson wrote:
> > Quoting Dan Carpenter (2018-05-16 15:52:57)
> > > On Wed, May 16, 2018 at 03:26:07PM +0100, Chris Wilson wrote:
> > > > Quoting Dan Carpenter (2018-05-16 15:00:26)
> > > > > There is a comment here which says that DIV_ROUND_UP() and that's 
> > > > > where
> > > > > the problem comes from.  Say you pick:
> > > > > 
> > > > > args->bpp = UINT_MAX - 7;
> > > > > args->width = 4;
> > > > > args->height = 1;
> > > > > 
> > > > > The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and
> > > > > because of how we picked args->width that means cpp < UINT_MAX / 4.
> > > > > 
> > > > > I've fixed it by preventing the integer overflow in DIV_ROUND_UP().  I
> > > > > removed the check for !cpp because it's not possible after this 
> > > > > change.
> > > > > I also changed all the 0xU references to U32_MAX.
> > > > > 
> > > > > Signed-off-by: Dan Carpenter 
> > > > 
> > > > I agree with Daniel that the !cpp check after DIV_ROUND_UP was
> > > > sufficient to guard the current code, but switching to a more idiomatic
> > > > style of overflow checking has its benefits too. Plus I like having
> > > > U32_MAX to compare the type ranges against.
> > > > 
> > > 
> > > I'm not totally sure what it means to say that the integer overflow is
> > > sufficient.  The overflow check is definitely buggy but if you mean that
> > > it isn't exploitable then you're probably right.  Anyway, let's say you
> > > use use the values I provided in my changelog.  Then I believe we can
> > > reach vgem_gem_dumb_create():
> > 
> > But we are talking about
> > 
> >   cpp = (U32_MAX + 8) / 8
> > 
> 
> No, no.  That's not the problem.  The problem is the - 1 subtraction.  I
> explained poorly.  The issue is when "bpp" is U32_MAX - 7.  The define
> looks like:
> 
> #define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
> 
> So "n" is (U32_MAX - 7) and "d" is 8.  "(n) + (d)" wraps to zero.  We do
> the "- 1" subtraction so that gives us U32_MAX.  And finally we divide
> by "d" to get "U32_MAX / 8".

D'oh. Thanks for spelling it out.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

[Dan Carpenter]

On Wed, May 16, 2018 at 03:56:55PM +0100, Chris Wilson wrote:
> Quoting Dan Carpenter (2018-05-16 15:52:57)
> > On Wed, May 16, 2018 at 03:26:07PM +0100, Chris Wilson wrote:
> > > Quoting Dan Carpenter (2018-05-16 15:00:26)
> > > > There is a comment here which says that DIV_ROUND_UP() and that's where
> > > > the problem comes from.  Say you pick:
> > > > 
> > > > args->bpp = UINT_MAX - 7;
> > > > args->width = 4;
> > > > args->height = 1;
> > > > 
> > > > The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and
> > > > because of how we picked args->width that means cpp < UINT_MAX / 4.
> > > > 
> > > > I've fixed it by preventing the integer overflow in DIV_ROUND_UP().  I
> > > > removed the check for !cpp because it's not possible after this change.
> > > > I also changed all the 0xU references to U32_MAX.
> > > > 
> > > > Signed-off-by: Dan Carpenter 
> > > 
> > > I agree with Daniel that the !cpp check after DIV_ROUND_UP was
> > > sufficient to guard the current code, but switching to a more idiomatic
> > > style of overflow checking has its benefits too. Plus I like having
> > > U32_MAX to compare the type ranges against.
> > > 
> > 
> > I'm not totally sure what it means to say that the integer overflow is
> > sufficient.  The overflow check is definitely buggy but if you mean that
> > it isn't exploitable then you're probably right.  Anyway, let's say you
> > use use the values I provided in my changelog.  Then I believe we can
> > reach vgem_gem_dumb_create():
> 
> But we are talking about
> 
>   cpp = (U32_MAX + 8) / 8
> 

No, no.  That's not the problem.  The problem is the - 1 subtraction.  I
explained poorly.  The issue is when "bpp" is U32_MAX - 7.  The define
looks like:

#define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))

So "n" is (U32_MAX - 7) and "d" is 8.  "(n) + (d)" wraps to zero.  We do
the "- 1" subtraction so that gives us U32_MAX.  And finally we divide
by "d" to get "U32_MAX / 8".

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

Re: [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-...@lists.freedesktop.org; dri-devel@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-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

[Bug 106544] Boot error: gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu] dce110_stream_encoder_update_hdmi_info_packets+0x20e/0x3a0 [amdgpu]

[bugzilla-daemon]

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

--- Comment #1 from burak  ---
Created attachment 139595
  --> https://bugs.freedesktop.org/attachment.cgi?id=139595=edit
xorg.log

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

[Bug 106544] Boot error: gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu] dce110_stream_encoder_update_hdmi_info_packets+0x20e/0x3a0 [amdgpu]

[bugzilla-daemon]

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

Bug ID: 106544
   Summary: Boot error:
gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
generic_reg_update_ex+0x108/0x150 [amdgpu]
dce110_stream_encoder_update_hdmi_info_packets+0x20e/0
x3a0 [amdgpu]
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bu...@linux.com

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

Every time I boot I receive below error, especially this happens also if I
attach HDMI cable during runtime as well (high speed or not always same):

WARNING: CPU: 8 PID: 284 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
generic_reg_update_ex+0x108/0x150 [amdgpu]
[7.603663] Modules linked in: amdkfd amd_iommu_v2 amdgpu(+) chash gpu_sched
drm_kms_helper hid_logitech_hidpp(+) ttm drm igb ptp crc32c_intel nvme pps_core
hid_logitech_dj nvme_core hid_microsoft dca i2c_algo_bit
[7.603668] CPU: 8 PID: 284 Comm: kworker/8:1 Tainted: GW
4.17.0-rc5-1-burak+ #4
[7.603668] Hardware name: System manufacturer System Product Name/PRIME
X399-A, BIOS 0601 03/27/2018
[7.603670] Workqueue: events work_for_cpu_fn
[7.603695] RIP: 0010:generic_reg_update_ex+0x108/0x150 [amdgpu]
[7.603696] RSP: 0018:acbdc75b3760 EFLAGS: 00010246
[7.603697] RAX: acbdc75b3780 RBX: 9a8e5fba7bc0 RCX:

[7.603697] RDX: 00012390 RSI:  RDI:
9a8e61526600
[7.603697] RBP: acbdc75b37d0 R08:  R09:

[7.603698] R10: acbdc75b37e8 R11: 0001 R12:
0001
[7.603698] R13:  R14: 9a8e5fb75800 R15:
9a8e60367400
[7.603699] FS:  () GS:9a8e7f40()
knlGS:
[7.603699] CS:  0010 DS:  ES:  CR0: 80050033
[7.603700] CR2: 7f05c8b2665e CR3: 00041b2a8000 CR4:
003406e0
[7.603700] Call Trace:
[7.603731]  dce110_stream_encoder_update_hdmi_info_packets+0x20e/0x3a0
[amdgpu]


full dmesg attached. 

gpu: R9 Fury X (UEFI rom)
(https://support.amd.com/en-us/download/gpu-firmware-download)

Kernel: 4.17-rc4

OS: Fedora 27

driver:
burak@[~/dev/git/linux]$lsmod | grep amdgpu
amdgpu   3096576  17
chash  16384  1 amdgpu
gpu_sched  28672  1 amdgpu
drm_kms_helper196608  1 amdgpu
ttm   126976  1 amdgpu
drm   458752  11 gpu_sched,drm_kms_helper,amdgpu,ttm
i2c_algo_bit   16384  2 igb,amdgpu

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

Re: [PATCH 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 

[Bug 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

--- Comment #13 from burak  ---
(In reply to Harry Wentland from comment #12)
> Hi burak,
> 
> your stack is different. See dce110_opp_program_regamma_pwl vs
> dce110_stream_encoder_update_hdmi_info_packets on the stack.
> 
> Can you open a new ticket?
> 
> Thanks,
> Harry

Thanks Harry, I am opening now

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

Re: [PATCH v2] drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

[Chris Wilson]

Quoting Dan Carpenter (2018-05-16 15:52:57)
> On Wed, May 16, 2018 at 03:26:07PM +0100, Chris Wilson wrote:
> > Quoting Dan Carpenter (2018-05-16 15:00:26)
> > > There is a comment here which says that DIV_ROUND_UP() and that's where
> > > the problem comes from.  Say you pick:
> > > 
> > > args->bpp = UINT_MAX - 7;
> > > args->width = 4;
> > > args->height = 1;
> > > 
> > > The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and
> > > because of how we picked args->width that means cpp < UINT_MAX / 4.
> > > 
> > > I've fixed it by preventing the integer overflow in DIV_ROUND_UP().  I
> > > removed the check for !cpp because it's not possible after this change.
> > > I also changed all the 0xU references to U32_MAX.
> > > 
> > > Signed-off-by: Dan Carpenter 
> > 
> > I agree with Daniel that the !cpp check after DIV_ROUND_UP was
> > sufficient to guard the current code, but switching to a more idiomatic
> > style of overflow checking has its benefits too. Plus I like having
> > U32_MAX to compare the type ranges against.
> > 
> 
> I'm not totally sure what it means to say that the integer overflow is
> sufficient.  The overflow check is definitely buggy but if you mean that
> it isn't exploitable then you're probably right.  Anyway, let's say you
> use use the values I provided in my changelog.  Then I believe we can
> reach vgem_gem_dumb_create():

But we are talking about

cpp = (U32_MAX + 8) / 8

which is 0. So the !cpp does catch the overflow.

Or am I completely off in unsigned wraparound?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

[Dan Carpenter]

On Wed, May 16, 2018 at 03:26:07PM +0100, Chris Wilson wrote:
> Quoting Dan Carpenter (2018-05-16 15:00:26)
> > There is a comment here which says that DIV_ROUND_UP() and that's where
> > the problem comes from.  Say you pick:
> > 
> > args->bpp = UINT_MAX - 7;
> > args->width = 4;
> > args->height = 1;
> > 
> > The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and
> > because of how we picked args->width that means cpp < UINT_MAX / 4.
> > 
> > I've fixed it by preventing the integer overflow in DIV_ROUND_UP().  I
> > removed the check for !cpp because it's not possible after this change.
> > I also changed all the 0xU references to U32_MAX.
> > 
> > Signed-off-by: Dan Carpenter 
> 
> I agree with Daniel that the !cpp check after DIV_ROUND_UP was
> sufficient to guard the current code, but switching to a more idiomatic
> style of overflow checking has its benefits too. Plus I like having
> U32_MAX to compare the type ranges against.
> 

I'm not totally sure what it means to say that the integer overflow is
sufficient.  The overflow check is definitely buggy but if you mean that
it isn't exploitable then you're probably right.  Anyway, let's say you
use use the values I provided in my changelog.  Then I believe we can
reach vgem_gem_dumb_create():

static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
   205  struct drm_mode_create_dumb *args)
   206  {
   207  struct drm_gem_object *gem_object;
   208  u64 pitch, size;
   209  
   210  pitch = args->width * DIV_ROUND_UP(args->bpp, 8);
  ^^
This is now:pitch = 4   * (U32_MAX / 8);

I would get a static checker warning here because of the integer
overflow in DIV_ROUND_UP().  I'll push that check soon.

   211  size = args->height * pitch;

This is now:size = 1 * U32_MAX / 2;

   212  if (size == 0)
   213  return -EINVAL;
   214  
   215  gem_object = vgem_gem_create(dev, file, >handle, size);

Then this fails because we can't allocate U32_MAX / 2 bytes.  There
are some other potential numbers we could try instead of the ones I
gave.  On 32bit arches  __vgem_gem_create() has integer overflows if
size is over U32_MAX - PAGE_SIZE so it gets a bit complicated...

   216  if (IS_ERR(gem_object))
   217  return PTR_ERR(gem_object);
   218  
   219  args->size = gem_object->size;
   220  args->pitch = pitch;
   221  
   222  DRM_DEBUG_DRIVER("Created object of size %lld\n", size);
   223  
   224  return 0;
   225  }

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

Re: [PATCH 1/3] drm/vkms: Add basic CRTC initialization

[Rodrigo Siqueira]

Hi Daniel,

Thanks for the feedback :)

You can find my comments below:

On 05/16, Daniel Vetter wrote:
> On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siqueira wrote:
> > This commit adds the essential infrastructure for managing CRTCs which
> > is composed of: a new data struct for output data information, a
> > function for basic modeset initialization, and the operation to create
> > planes. Due to the introduction of a new initialization function,
> > connectors were moved from vkms_drv.c to vkms_display.c.
> > 
> > Signed-off-by: Rodrigo Siqueira 
> > ---
> >  drivers/gpu/drm/vkms/Makefile   |   2 +-
> >  drivers/gpu/drm/vkms/vkms_display.c | 108 
> >  drivers/gpu/drm/vkms/vkms_drv.c |  41 +--
> >  drivers/gpu/drm/vkms/vkms_drv.h |  26 ++-
> >  drivers/gpu/drm/vkms/vkms_plane.c   |  46 
> >  5 files changed, 180 insertions(+), 43 deletions(-)
> >  create mode 100644 drivers/gpu/drm/vkms/vkms_display.c
> >  create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c
> > 
> > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> > index 2aef948d3a34..f747e2a3a6f4 100644
> > --- a/drivers/gpu/drm/vkms/Makefile
> > +++ b/drivers/gpu/drm/vkms/Makefile
> > @@ -1,3 +1,3 @@
> > -vkms-y := vkms_drv.o
> > +vkms-y := vkms_drv.o vkms_plane.o vkms_display.o
> >  
> >  obj-$(CONFIG_DRM_VKMS) += vkms.o
> > diff --git a/drivers/gpu/drm/vkms/vkms_display.c 
> > b/drivers/gpu/drm/vkms/vkms_display.c
> > new file mode 100644
> > index ..b20b41f9590b
> > --- /dev/null
> > +++ b/drivers/gpu/drm/vkms/vkms_display.c
> > @@ -0,0 +1,108 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include "vkms_drv.h"
> > +#include 
> > +#include 
> > +
> > +#define XRES_MIN32
> > +#define YRES_MIN32
> > +
> > +#define XRES_DEF  1024
> > +#define YRES_DEF   768
> 
> These seem unused.

I created these defines because the documentation says:

"[..]Once done, mode configuration must be setup by initializing the
following fields."
(https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#c.drm_mode_config_init)

Finally, I used them in "mode_config" fields from drm_device (code below).

Is it ok to not setup these values on mode_config? I looked at virtio as
an inspiration for this.

> > +static const struct drm_mode_config_funcs vkms_mode_funcs = {
> > +   .atomic_check = drm_atomic_helper_check,
> > +   .atomic_commit = drm_atomic_helper_commit,
> > +};
> > +
> > +static const struct drm_crtc_funcs vkms_crtc_funcs = {
> > +   .set_config = drm_atomic_helper_set_config,
> > +   .destroy= drm_crtc_cleanup,
> > +   .page_flip  = drm_atomic_helper_page_flip,
> > +   .reset  = drm_atomic_helper_crtc_reset,
> > +   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > +   .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
> > +};
> > +
> > +static void vkms_connector_destroy(struct drm_connector *connector)
> > +{
> > +   drm_connector_unregister(connector);
> > +   drm_connector_cleanup(connector);
> > +}
> > +
> > +static const struct drm_connector_funcs vkms_connector_funcs = {
> > +   .fill_modes = drm_helper_probe_single_connector_modes,
> > +   .destroy = vkms_connector_destroy,
> > +};
> > +
> > +static int vkms_output_init(struct vkms_device *vkmsdev)
> > +{
> > +   struct vkms_output *output = >output;
> > +   struct drm_device *dev = >drm;
> > +   struct drm_connector *connector = >connector;
> > +   struct drm_crtc *crtc = >crtc;
> > +   struct drm_plane *primary;
> > +   int ret;
> > +
> > +   primary = vkms_plane_init(vkmsdev);
> > +   if (IS_ERR(primary))
> > +   return PTR_ERR(primary);
> > +
> > +   ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL,
> > +   _crtc_funcs, NULL);
> > +   if (ret) {
> > +   DRM_ERROR("Failed to init CRTC\n");
> > +   goto err_crtc;
> > +   }
> > +   primary->crtc = crtc;
> 
> If you want to split stuff up a bit, I think putting the crtc stuff into
> vkms_crtc.c, and then renaming this file here to vkms_output.c would make
> sense.

Nice, make a lot of sense to me. I will do it on v2.

> > +
> > +   ret = drm_connector_init(dev, connector, _connector_funcs,
> > +DRM_MODE_CONNECTOR_VIRTUAL);
> > +   if (ret) {
> > +   DRM_ERROR("Failed to init connector\n");
> > +   goto err_connector;
> > +   }
> > +
> > +   ret = drm_connector_register(connector);
> > +   if (ret) {
> > +   DRM_ERROR("Failed to register connector\n");
> > +   goto err_connector_register;
> > +   }
> > +
> > 

Re: [PATCH v2] drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

[Chris Wilson]

Quoting Dan Carpenter (2018-05-16 15:00:26)
> There is a comment here which says that DIV_ROUND_UP() and that's where
> the problem comes from.  Say you pick:
> 
> args->bpp = UINT_MAX - 7;
> args->width = 4;
> args->height = 1;
> 
> The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and
> because of how we picked args->width that means cpp < UINT_MAX / 4.
> 
> I've fixed it by preventing the integer overflow in DIV_ROUND_UP().  I
> removed the check for !cpp because it's not possible after this change.
> I also changed all the 0xU references to U32_MAX.
> 
> Signed-off-by: Dan Carpenter 

I agree with Daniel that the !cpp check after DIV_ROUND_UP was
sufficient to guard the current code, but switching to a more idiomatic
style of overflow checking has its benefits too. Plus I like having
U32_MAX to compare the type ranges against.

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

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Andrey Grodzovsky]

On 05/16/2018 09:16 AM, Lucas Stach wrote:

Am Mittwoch, den 16.05.2018, 15:10 +0200 schrieb Christian König:

Am 16.05.2018 um 15:00 schrieb Lucas Stach:

Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König:

Am 16.05.2018 um 14:28 schrieb Lucas Stach:

Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:

Yes, exactly.

For normal user space command submission we should have tons of
locks
guaranteeing that (e.g. just the VM lock should do).

For kernel moves we have the mutex for the GTT windows which
protects
it.

The could be problems with the UVD/VCE queues to cleanup the
handles
when an application crashes.

FWIW, etnaviv is currently completely unlocked in this path, but I
believe that this isn't an issue as the sched fence seq numbers are
per
entity. So to actually end up with reversed seqnos one context has
to
preempt itself to do another submit, while the current one hasn't
returned from kernel space, which I believe is a fairly theoretical
issue. Is my understanding correct?

Yes. The problem is with the right timing this can be used to access
freed up memory.

If you then manage to place a page table in that freed up memory
taking
over the system is just a typing exercise.

Thanks. I believe we don't have this problem in etnaviv, as memory
referencing is tied to the job and will only be unreferenced on
free_job, but I'll re-check this when I've got some time.

Well that depends on how you use the sequence numbers.

If you use them for job completion check somewhere then you certainly
have a problem if job A gets the 1 and B the 2, but B completes before A.

We don't do this anymore. All the etnaviv internals are driven by the
fence signal callbacks.


At bare minimum that's still a bug we need to fix because it confuses
functions like dma_fence_is_later() and dma_fence_later().

Agreed. Also amending the documentation to state that
drm_sched_job_init() and drm_sched_entity_push_job() need to be called
under a common lock seems like a good idea.


I will respin the patch with added documentation.

Andrey


Regards,
Lucas


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

Re: [PATCH][V2] drm/i915/dp: fix spelling mistakes: "seqeuncer" and "seqeuencer"

[Jani Nikula]

On Wed, 09 May 2018, Jani Nikula  wrote:
> On Wed, 09 May 2018, Colin King  wrote:
>> From: Colin Ian King 
>>
>> Trivial fix to spelling mistakes in WARN warning message text and
>> in comments:
>>
>> "seqeuncer", "seqeuencer" -> "sequencer"
>>
>> Signed-off-by: Colin Ian King 
>
> Reviewed-by: Jani Nikula 
>
> (Waiting for the CI runs before merging.)

And pushed to dinq, thanks for the patch.

BR,
Jani.

>
>> ---
>>
>> V2: Also fix seqeuencer in comments
>>
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index dde92e4af5d3..2cc58596ff5a 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -513,7 +513,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
>>  uint32_t DP;
>>  
>>  if (WARN(I915_READ(intel_dp->output_reg) & DP_PORT_EN,
>> - "skipping pipe %c power seqeuncer kick due to port %c being 
>> active\n",
>> + "skipping pipe %c power sequencer kick due to port %c being 
>> active\n",
>>   pipe_name(pipe), port_name(intel_dig_port->base.port)))
>>  return;
>>  
>> @@ -554,7 +554,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
>>  /*
>>   * Similar magic as in intel_dp_enable_port().
>>   * We _must_ do this port enable + disable trick
>> - * to make this power seqeuencer lock onto the port.
>> + * to make this power sequencer lock onto the port.
>>   * Otherwise even VDD force bit won't work.
>>   */
>>  I915_WRITE(intel_dp->output_reg, DP);
>> @@ -3066,11 +3066,11 @@ static void vlv_detach_power_sequencer(struct 
>> intel_dp *intel_dp)
>>  edp_panel_vdd_off_sync(intel_dp);
>>  
>>  /*
>> - * VLV seems to get confused when multiple power seqeuencers
>> + * VLV seems to get confused when multiple power sequencers
>>   * have the same port selected (even if only one has power/vdd
>>   * enabled). The failure manifests as vlv_wait_port_ready() failing
>>   * CHV on the other hand doesn't seem to mind having the same port
>> - * selected in multiple power seqeuencers, but let's clear the
>> + * selected in multiple power sequencers, but let's clear the
>>   * port select always when logically disconnecting a power sequencer
>>   * from a port.
>>   */
>> @@ -5698,7 +5698,7 @@ intel_dp_init_panel_power_sequencer_registers(struct 
>> intel_dp *intel_dp,
>>  
>>  /*
>>   * On some VLV machines the BIOS can leave the VDD
>> - * enabled even on power seqeuencers which aren't
>> + * enabled even on power sequencers which aren't
>>   * hooked up to any port. This would mess up the
>>   * power domain tracking the first time we pick
>>   * one of these power sequencers for use since
>> @@ -5706,7 +5706,7 @@ intel_dp_init_panel_power_sequencer_registers(struct 
>> intel_dp *intel_dp,
>>   * already on and therefore wouldn't grab the power
>>   * domain reference. Disable VDD first to avoid this.
>>   * This also avoids spuriously turning the VDD on as
>> - * soon as the new power seqeuencer gets initialized.
>> + * soon as the new power sequencer gets initialized.
>>   */
>>  if (force_disable_vdd) {
>>  u32 pp = ironlake_get_pp_control(intel_dp);

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

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

[Ville Syrjälä]

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?

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

[PATCH v2] drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

[Dan Carpenter]

There is a comment here which says that DIV_ROUND_UP() and that's where
the problem comes from.  Say you pick:

args->bpp = UINT_MAX - 7;
args->width = 4;
args->height = 1;

The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and
because of how we picked args->width that means cpp < UINT_MAX / 4.

I've fixed it by preventing the integer overflow in DIV_ROUND_UP().  I
removed the check for !cpp because it's not possible after this change.
I also changed all the 0xU references to U32_MAX.

Signed-off-by: Dan Carpenter 
---
v2:  additional cleanups

diff --git a/drivers/gpu/drm/drm_dumb_buffers.c 
b/drivers/gpu/drm/drm_dumb_buffers.c
index 39ac15ce4702..9e2ae02f31e0 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -65,12 +65,13 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
return -EINVAL;
 
/* overflow checks for 32bit size calculations */
-   /* NOTE: DIV_ROUND_UP() can overflow */
+   if (args->bpp > U32_MAX - 8)
+   return -EINVAL;
cpp = DIV_ROUND_UP(args->bpp, 8);
-   if (!cpp || cpp > 0xU / args->width)
+   if (cpp > U32_MAX / args->width)
return -EINVAL;
stride = cpp * args->width;
-   if (args->height > 0xU / stride)
+   if (args->height > U32_MAX / stride)
return -EINVAL;
 
/* test for wrap-around */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/scheduler: fix function name prefix in comments

[Nayan Deshmukh]

That got missed while moving the files outside of amdgpu.

Signed-off-by: Nayan Deshmukh 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/scheduler/sched_fence.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
b/drivers/gpu/drm/scheduler/sched_fence.c
index 69aab086b913..786b47f15783 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -87,7 +87,7 @@ static bool drm_sched_fence_enable_signaling(struct dma_fence 
*f)
 }
 
 /**
- * amd_sched_fence_free - free up the fence memory
+ * drm_sched_fence_free - free up the fence memory
  *
  * @rcu: RCU callback head
  *
@@ -103,7 +103,7 @@ static void drm_sched_fence_free(struct rcu_head *rcu)
 }
 
 /**
- * amd_sched_fence_release_scheduled - callback that fence can be freed
+ * drm_sched_fence_release_scheduled - callback that fence can be freed
  *
  * @fence: fence
  *
@@ -118,7 +118,7 @@ static void drm_sched_fence_release_scheduled(struct 
dma_fence *f)
 }
 
 /**
- * amd_sched_fence_release_finished - drop extra reference
+ * drm_sched_fence_release_finished - drop extra reference
  *
  * @f: fence
  *
-- 
2.14.3

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

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Lucas Stach]

Am Mittwoch, den 16.05.2018, 15:10 +0200 schrieb Christian König:
> Am 16.05.2018 um 15:00 schrieb Lucas Stach:
> > Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König:
> > > Am 16.05.2018 um 14:28 schrieb Lucas Stach:
> > > > Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:
> > > > > Yes, exactly.
> > > > > 
> > > > > For normal user space command submission we should have tons of
> > > > > locks
> > > > > guaranteeing that (e.g. just the VM lock should do).
> > > > > 
> > > > > For kernel moves we have the mutex for the GTT windows which
> > > > > protects
> > > > > it.
> > > > > 
> > > > > The could be problems with the UVD/VCE queues to cleanup the
> > > > > handles
> > > > > when an application crashes.
> > > > 
> > > > FWIW, etnaviv is currently completely unlocked in this path, but I
> > > > believe that this isn't an issue as the sched fence seq numbers are
> > > > per
> > > > entity. So to actually end up with reversed seqnos one context has
> > > > to
> > > > preempt itself to do another submit, while the current one hasn't
> > > > returned from kernel space, which I believe is a fairly theoretical
> > > > issue. Is my understanding correct?
> > > 
> > > Yes. The problem is with the right timing this can be used to access
> > > freed up memory.
> > > 
> > > If you then manage to place a page table in that freed up memory
> > > taking
> > > over the system is just a typing exercise.
> > 
> > Thanks. I believe we don't have this problem in etnaviv, as memory
> > referencing is tied to the job and will only be unreferenced on
> > free_job, but I'll re-check this when I've got some time.
> 
> Well that depends on how you use the sequence numbers.
> 
> If you use them for job completion check somewhere then you certainly 
> have a problem if job A gets the 1 and B the 2, but B completes before A.

We don't do this anymore. All the etnaviv internals are driven by the
fence signal callbacks.

> At bare minimum that's still a bug we need to fix because it confuses 
> functions like dma_fence_is_later() and dma_fence_later().

Agreed. Also amending the documentation to state that
drm_sched_job_init() and drm_sched_entity_push_job() need to be called
under a common lock seems like a good idea.

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

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

[Ramalingam C]

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-...@lists.freedesktop.org; dri-devel@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



  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 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided
that
+ * the above copyright notice appear in all copies and that both that
copyright
+ * notice and this permission notice appear in supporting documentation,
and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL,
INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF 

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Christian König]

Am 16.05.2018 um 15:00 schrieb Lucas Stach:

Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König:

Am 16.05.2018 um 14:28 schrieb Lucas Stach:

Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:

Yes, exactly.

For normal user space command submission we should have tons of
locks
guaranteeing that (e.g. just the VM lock should do).

For kernel moves we have the mutex for the GTT windows which
protects
it.

The could be problems with the UVD/VCE queues to cleanup the
handles
when an application crashes.

FWIW, etnaviv is currently completely unlocked in this path, but I
believe that this isn't an issue as the sched fence seq numbers are
per
entity. So to actually end up with reversed seqnos one context has
to
preempt itself to do another submit, while the current one hasn't
returned from kernel space, which I believe is a fairly theoretical
issue. Is my understanding correct?

Yes. The problem is with the right timing this can be used to access
freed up memory.

If you then manage to place a page table in that freed up memory
taking
over the system is just a typing exercise.

Thanks. I believe we don't have this problem in etnaviv, as memory
referencing is tied to the job and will only be unreferenced on
free_job, but I'll re-check this when I've got some time.


Well that depends on how you use the sequence numbers.

If you use them for job completion check somewhere then you certainly 
have a problem if job A gets the 1 and B the 2, but B completes before A.


At bare minimum that's still a bug we need to fix because it confuses 
functions like dma_fence_is_later() and dma_fence_later().


Christian.



Regards,
Lucas


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

Re: [PATCH] drm/scheduler: fix function name prefix in comments

[Christian König]

We need a commit message here, something like: "That got missed while 
moving the files outside of amdgpu.".


Am 16.05.2018 um 15:03 schrieb Nayan Deshmukh:

Signed-off-by: Nayan Deshmukh 


Apart from the commit message the patch is Reviewed-by: Christian König 
.


Christian.


---
  drivers/gpu/drm/scheduler/sched_fence.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
b/drivers/gpu/drm/scheduler/sched_fence.c
index 69aab086b913..786b47f15783 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -87,7 +87,7 @@ static bool drm_sched_fence_enable_signaling(struct dma_fence 
*f)
  }
  
  /**

- * amd_sched_fence_free - free up the fence memory
+ * drm_sched_fence_free - free up the fence memory
   *
   * @rcu: RCU callback head
   *
@@ -103,7 +103,7 @@ static void drm_sched_fence_free(struct rcu_head *rcu)
  }
  
  /**

- * amd_sched_fence_release_scheduled - callback that fence can be freed
+ * drm_sched_fence_release_scheduled - callback that fence can be freed
   *
   * @fence: fence
   *
@@ -118,7 +118,7 @@ static void drm_sched_fence_release_scheduled(struct 
dma_fence *f)
  }
  
  /**

- * amd_sched_fence_release_finished - drop extra reference
+ * drm_sched_fence_release_finished - drop extra reference
   *
   * @f: fence
   *


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

[PATCH] drm/scheduler: fix function name prefix in comments

[Nayan Deshmukh]

Signed-off-by: Nayan Deshmukh 
---
 drivers/gpu/drm/scheduler/sched_fence.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
b/drivers/gpu/drm/scheduler/sched_fence.c
index 69aab086b913..786b47f15783 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -87,7 +87,7 @@ static bool drm_sched_fence_enable_signaling(struct dma_fence 
*f)
 }
 
 /**
- * amd_sched_fence_free - free up the fence memory
+ * drm_sched_fence_free - free up the fence memory
  *
  * @rcu: RCU callback head
  *
@@ -103,7 +103,7 @@ static void drm_sched_fence_free(struct rcu_head *rcu)
 }
 
 /**
- * amd_sched_fence_release_scheduled - callback that fence can be freed
+ * drm_sched_fence_release_scheduled - callback that fence can be freed
  *
  * @fence: fence
  *
@@ -118,7 +118,7 @@ static void drm_sched_fence_release_scheduled(struct 
dma_fence *f)
 }
 
 /**
- * amd_sched_fence_release_finished - drop extra reference
+ * drm_sched_fence_release_finished - drop extra reference
  *
  * @f: fence
  *
-- 
2.14.3

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

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Lucas Stach]

Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König:
> Am 16.05.2018 um 14:28 schrieb Lucas Stach:
> > Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:
> > > Yes, exactly.
> > > 
> > > For normal user space command submission we should have tons of
> > > locks
> > > guaranteeing that (e.g. just the VM lock should do).
> > > 
> > > For kernel moves we have the mutex for the GTT windows which
> > > protects
> > > it.
> > > 
> > > The could be problems with the UVD/VCE queues to cleanup the
> > > handles
> > > when an application crashes.
> > 
> > FWIW, etnaviv is currently completely unlocked in this path, but I
> > believe that this isn't an issue as the sched fence seq numbers are
> > per
> > entity. So to actually end up with reversed seqnos one context has
> > to
> > preempt itself to do another submit, while the current one hasn't
> > returned from kernel space, which I believe is a fairly theoretical
> > issue. Is my understanding correct?
> 
> Yes. The problem is with the right timing this can be used to access 
> freed up memory.
> 
> If you then manage to place a page table in that freed up memory
> taking 
> over the system is just a typing exercise.

Thanks. I believe we don't have this problem in etnaviv, as memory
referencing is tied to the job and will only be unreferenced on
free_job, but I'll re-check this when I've got some time.

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

Re: [PATCH 14/14] mm: turn on vm_fault_t type checking

[Christoph Hellwig]

On Wed, May 16, 2018 at 04:28:13AM -0700, Matthew Wilcox wrote:
> On Wed, May 16, 2018 at 07:43:48AM +0200, Christoph Hellwig wrote:
> > Switch vm_fault_t to point to an unsigned int with __bіtwise annotations.
> > This both catches any old ->fault or ->page_mkwrite instance with plain
> > compiler type checking, as well as finding more intricate problems with
> > sparse.
> 
> Come on, Christoph; you know better than this.  This patch is completely
> unreviewable.  Split it into one patch per maintainer tree, and in any
> event, the patch to convert vm_fault_t to an unsigned int should be
> separated from all the trivial conversions.

The whole point is that tiny split patches for mechnical translations
are totally pointless.  Switching the typedef might be worth splitting
if people really insist.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: vm_fault_t conversion, for real

[Christoph Hellwig]

On Wed, May 16, 2018 at 04:23:47AM -0700, Matthew Wilcox wrote:
> On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote:
> > this series tries to actually turn vm_fault_t into a type that can be
> > typechecked and checks the fallout instead of sprinkling random
> > annotations without context.
> 
> Yes, why should we have small tasks that newcomers can do when the mighty
> Christoph Hellwig can swoop in and take over from them?  Seriously,
> can't your talents find a better use than this?

I've spent less time on this than trying to argue to you and Souptick
that these changes are only to get ignored and yelled at as an
"asshole maintainer".  So yes, I could have done more productive things
if you hadn't forced this escalation.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/14] vgem: separate errno from VM_FAULT_* values

[Christoph Hellwig]

On Wed, May 16, 2018 at 11:53:03AM +0200, Daniel Vetter wrote:
> Reviewed-by: Daniel Vetter 
> 
> Want me to merge this through drm-misc or plan to pick it up yourself?

For now I just want a honest discussion if people really actually
want the vm_fault_t change with the whole picture in place.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Christian König]

Am 16.05.2018 um 14:28 schrieb Lucas Stach:

Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:

Yes, exactly.

For normal user space command submission we should have tons of
locks
guaranteeing that (e.g. just the VM lock should do).

For kernel moves we have the mutex for the GTT windows which protects
it.

The could be problems with the UVD/VCE queues to cleanup the handles
when an application crashes.

FWIW, etnaviv is currently completely unlocked in this path, but I
believe that this isn't an issue as the sched fence seq numbers are per
entity. So to actually end up with reversed seqnos one context has to
preempt itself to do another submit, while the current one hasn't
returned from kernel space, which I believe is a fairly theoretical
issue. Is my understanding correct?


Yes. The problem is with the right timing this can be used to access 
freed up memory.


If you then manage to place a page table in that freed up memory taking 
over the system is just a typing exercise.


Regards,
Christian.



Regards,
Lucas


Am 16.05.2018 um 13:47 schrieb Andrey Grodzovsky:

So are you saying that you expect this to  be already in code for
any
usage of drm_sched_fence_create and drm_sched_entity_push_job ?

lock()

drm_sched_fence_create()

... (some code)

drm_sched_entity_push_job()

unlock()


Andrey

On 05/16/2018 07:23 AM, Christian König wrote:

drm_sched_fence_create() assigns a sequence number to the fence
it
creates.

Now drm_sched_fence_create() is called by drm_sched_job_init()
to
initialize the jobs we want to push on the scheduler queue.

When you now call drm_sched_entity_push_job() without a
protecting
lock it can happen that you push two (or even more) job with
reversed
sequence numbers.

Since the sequence numbers are used to determine job completion
order
reversing them can seriously mess things up.

So the spin lock should be superfluous, if it isn't we have a
much
larger bug we need to fix.

Christian.

Am 16.05.2018 um 13:15 schrieb Andrey Grodzovsky:

Can you please elaborate more, maybe give an example - I don't
understand yet the problematic scenario.

Andrey


On 05/16/2018 02:50 AM, Christian König wrote:

No, that spinlock is indeed incorrect. I

See even when we protect the spsc queue with a spinlock that
doesn't make it correct. It can happen that the jobs pushed
to the
queue are reversed in their sequence order and that can
cause
severe problems in the memory management.

Christian.

Am 16.05.2018 um 05:33 schrieb Grodzovsky, Andrey:

Yeah, that what I am not sure about... It's lockless in a
sense of
single producer single consumer but not for multiple
concurrent
producers... So now I think this spinlock should stay
there... It
just looked useless to me at first sight...

Andrey


From: Zhou, David(ChunMing)
Sent: 15 May 2018 23:04:44
To: Grodzovsky, Andrey; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian
Subject: Re: [PATCH 2/2] drm/scheduler: Remove obsolete
spinlock.



On 2018年05月16日 03:31, Andrey Grodzovsky wrote:

Signed-off-by: Andrey Grodzovsky 
---
    drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
    include/drm/gpu_scheduler.h   | 1 -
    2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 1f1dd70..2569a63 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct
drm_gpu_scheduler *sched,
    entity->last_scheduled = NULL;

    spin_lock_init(>rq_lock);
- spin_lock_init(>queue_lock);
    spsc_queue_init(>job_queue);

    atomic_set(>fence_seq, 0);
@@ -424,11 +423,8 @@ void
drm_sched_entity_push_job(struct
drm_sched_job *sched_job,

    trace_drm_sched_job(sched_job, entity);

- spin_lock(>queue_lock);
    first = spsc_queue_push(>job_queue,
_job->queue_node);

- spin_unlock(>queue_lock);

Is your spsc safely to be added simultaneously?

Regards,
David Zhou

-
    /* first job wakes up scheduler */
    if (first) {
    /* Add the entity to the run queue */
diff --git a/include/drm/gpu_scheduler.h
b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
    spinlock_t  rq_lock;
    struct drm_gpu_scheduler    *sched;

- spinlock_t  queue_lock;
    struct spsc_queue   job_queue;

    atomic_t    fence_seq;

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[Bug 105990] [CI] igt@gem_eio@in-flight-immediate - fail - Failed assertion: __igt_device_drop_master(fd) == 0

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #6 from Chris Wilson  ---
commit b7432bf309d5d5a6e07e8a0d8b522302fb0b4502 (HEAD, origin/master,
origin/HEA
D)
Author: Katarzyna Dec 
Date:   Tue May 15 10:40:55 2018 +0200

lib/igt_device: Add information why cannot drop drm master

Let's add additional information to igt_device_drop_master
in case we try to run tests with e.g. x11 enabled.

v2: Changed comment and added listing clients.
v3: Changed igt_require to igt_assert.
v4: Added checking if we are master already.

References: https://bugs.freedesktop.org/show_bug.cgi?id=105990
Signed-off-by: Katarzyna Dec 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 

Will prevent it happening again, but not actually answer who went rogue.

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

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Lucas Stach]

Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:
> Yes, exactly.
> 
> For normal user space command submission we should have tons of
> locks 
> guaranteeing that (e.g. just the VM lock should do).
> 
> For kernel moves we have the mutex for the GTT windows which protects
> it.
> 
> The could be problems with the UVD/VCE queues to cleanup the handles 
> when an application crashes.

FWIW, etnaviv is currently completely unlocked in this path, but I
believe that this isn't an issue as the sched fence seq numbers are per
entity. So to actually end up with reversed seqnos one context has to
preempt itself to do another submit, while the current one hasn't
returned from kernel space, which I believe is a fairly theoretical
issue. Is my understanding correct?

Regards,
Lucas

> 
> Am 16.05.2018 um 13:47 schrieb Andrey Grodzovsky:
> > So are you saying that you expect this to  be already in code for
> > any 
> > usage of drm_sched_fence_create and drm_sched_entity_push_job ?
> > 
> > lock()
> > 
> > drm_sched_fence_create()
> > 
> > ... (some code)
> > 
> > drm_sched_entity_push_job()
> > 
> > unlock()
> > 
> > 
> > Andrey
> > 
> > On 05/16/2018 07:23 AM, Christian König wrote:
> > > drm_sched_fence_create() assigns a sequence number to the fence
> > > it 
> > > creates.
> > > 
> > > Now drm_sched_fence_create() is called by drm_sched_job_init()
> > > to 
> > > initialize the jobs we want to push on the scheduler queue.
> > > 
> > > When you now call drm_sched_entity_push_job() without a
> > > protecting 
> > > lock it can happen that you push two (or even more) job with
> > > reversed 
> > > sequence numbers.
> > > 
> > > Since the sequence numbers are used to determine job completion
> > > order 
> > > reversing them can seriously mess things up.
> > > 
> > > So the spin lock should be superfluous, if it isn't we have a
> > > much 
> > > larger bug we need to fix.
> > > 
> > > Christian.
> > > 
> > > Am 16.05.2018 um 13:15 schrieb Andrey Grodzovsky:
> > > > Can you please elaborate more, maybe give an example - I don't 
> > > > understand yet the problematic scenario.
> > > > 
> > > > Andrey
> > > > 
> > > > 
> > > > On 05/16/2018 02:50 AM, Christian König wrote:
> > > > > No, that spinlock is indeed incorrect. I
> > > > > 
> > > > > See even when we protect the spsc queue with a spinlock that 
> > > > > doesn't make it correct. It can happen that the jobs pushed
> > > > > to the 
> > > > > queue are reversed in their sequence order and that can
> > > > > cause 
> > > > > severe problems in the memory management.
> > > > > 
> > > > > Christian.
> > > > > 
> > > > > Am 16.05.2018 um 05:33 schrieb Grodzovsky, Andrey:
> > > > > > Yeah, that what I am not sure about... It's lockless in a
> > > > > > sense of 
> > > > > > single producer single consumer but not for multiple
> > > > > > concurrent 
> > > > > > producers... So now I think this spinlock should stay
> > > > > > there... It 
> > > > > > just looked useless to me at first sight...
> > > > > > 
> > > > > > Andrey
> > > > > > 
> > > > > > 
> > > > > > From: Zhou, David(ChunMing)
> > > > > > Sent: 15 May 2018 23:04:44
> > > > > > To: Grodzovsky, Andrey; amd-...@lists.freedesktop.org; 
> > > > > > dri-devel@lists.freedesktop.org
> > > > > > Cc: Koenig, Christian
> > > > > > Subject: Re: [PATCH 2/2] drm/scheduler: Remove obsolete
> > > > > > spinlock.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 2018年05月16日 03:31, Andrey Grodzovsky wrote:
> > > > > > > Signed-off-by: Andrey Grodzovsky  > > > > > > om>
> > > > > > > ---
> > > > > > >    drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
> > > > > > >    include/drm/gpu_scheduler.h   | 1 -
> > > > > > >    2 files changed, 5 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> > > > > > > b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > > > > > index 1f1dd70..2569a63 100644
> > > > > > > --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > > > > > +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > > > > > > @@ -140,7 +140,6 @@ int drm_sched_entity_init(struct 
> > > > > > > drm_gpu_scheduler *sched,
> > > > > > >    entity->last_scheduled = NULL;
> > > > > > > 
> > > > > > >    spin_lock_init(>rq_lock);
> > > > > > > - spin_lock_init(>queue_lock);
> > > > > > >    spsc_queue_init(>job_queue);
> > > > > > > 
> > > > > > >    atomic_set(>fence_seq, 0);
> > > > > > > @@ -424,11 +423,8 @@ void
> > > > > > > drm_sched_entity_push_job(struct 
> > > > > > > drm_sched_job *sched_job,
> > > > > > > 
> > > > > > >    trace_drm_sched_job(sched_job, entity);
> > > > > > > 
> > > > > > > - spin_lock(>queue_lock);
> > > > > > >    first = spsc_queue_push(>job_queue, 
> > > > > > > _job->queue_node);
> > > > > > > 
> > > > > > > - spin_unlock(>queue_lock);
> > > > > > 
> > > > > > Is your spsc safely to be added simultaneously?
> > > > > 

[RFC PATCH gabbayo] drm/amdgpu: amdgpu_amdkfd_if can be static

[kbuild test robot]

Fixes: da8a916b6b6d ("drm/amdgpu: conditionally compile amdgpu's amdkfd files")
Signed-off-by: Fengguang Wu 
---
 amdgpu_amdkfd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 930d27d..f48dca2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -41,7 +41,7 @@ static const struct amdgpu_amdkfd_if amdkfd_if = {
 #endif
 
 const struct kgd2kfd_calls *kgd2kfd;
-const struct amdgpu_amdkfd_if *amdgpu_amdkfd_if;
+static const struct amdgpu_amdkfd_if *amdgpu_amdkfd_if;
 bool (*kgd2kfd_init_p)(unsigned int, const struct kgd2kfd_calls**);
 
 static const unsigned int compute_vmid_bitmap = 0xFF00;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[gabbayo:private 43/43] drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:44:31: sparse: symbol 'amdgpu_amdkfd_if' was not declared. Should it be static?

[kbuild test robot]

tree:   git://people.freedesktop.org/~gabbayo/linux private
head:   da8a916b6b6da1142232a310ac78571701655dba
commit: da8a916b6b6da1142232a310ac78571701655dba [43/43] drm/amdgpu: 
conditionally compile amdgpu's amdkfd files
reproduce:
# apt-get install sparse
git checkout da8a916b6b6da1142232a310ac78571701655dba
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:44:31: sparse: symbol 
>> 'amdgpu_amdkfd_if' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:171:39: sparse: expression using 
sizeof(void)

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Christian König]

Yes, exactly.

For normal user space command submission we should have tons of locks 
guaranteeing that (e.g. just the VM lock should do).


For kernel moves we have the mutex for the GTT windows which protects it.

The could be problems with the UVD/VCE queues to cleanup the handles 
when an application crashes.


Christian.

Am 16.05.2018 um 13:47 schrieb Andrey Grodzovsky:
So are you saying that you expect this to  be already in code for any 
usage of drm_sched_fence_create and drm_sched_entity_push_job ?


lock()

drm_sched_fence_create()

... (some code)

drm_sched_entity_push_job()

unlock()


Andrey

On 05/16/2018 07:23 AM, Christian König wrote:
drm_sched_fence_create() assigns a sequence number to the fence it 
creates.


Now drm_sched_fence_create() is called by drm_sched_job_init() to 
initialize the jobs we want to push on the scheduler queue.


When you now call drm_sched_entity_push_job() without a protecting 
lock it can happen that you push two (or even more) job with reversed 
sequence numbers.


Since the sequence numbers are used to determine job completion order 
reversing them can seriously mess things up.


So the spin lock should be superfluous, if it isn't we have a much 
larger bug we need to fix.


Christian.

Am 16.05.2018 um 13:15 schrieb Andrey Grodzovsky:
Can you please elaborate more, maybe give an example - I don't 
understand yet the problematic scenario.


Andrey


On 05/16/2018 02:50 AM, Christian König wrote:

No, that spinlock is indeed incorrect. I

See even when we protect the spsc queue with a spinlock that 
doesn't make it correct. It can happen that the jobs pushed to the 
queue are reversed in their sequence order and that can cause 
severe problems in the memory management.


Christian.

Am 16.05.2018 um 05:33 schrieb Grodzovsky, Andrey:
Yeah, that what I am not sure about... It's lockless in a sense of 
single producer single consumer but not for multiple concurrent 
producers... So now I think this spinlock should stay there... It 
just looked useless to me at first sight...


Andrey


From: Zhou, David(ChunMing)
Sent: 15 May 2018 23:04:44
To: Grodzovsky, Andrey; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org

Cc: Koenig, Christian
Subject: Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.



On 2018年05月16日 03:31, Andrey Grodzovsky wrote:

Signed-off-by: Andrey Grodzovsky 
---
   drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
   include/drm/gpu_scheduler.h   | 1 -
   2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c

index 1f1dd70..2569a63 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct 
drm_gpu_scheduler *sched,

   entity->last_scheduled = NULL;

   spin_lock_init(>rq_lock);
- spin_lock_init(>queue_lock);
   spsc_queue_init(>job_queue);

   atomic_set(>fence_seq, 0);
@@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct 
drm_sched_job *sched_job,


   trace_drm_sched_job(sched_job, entity);

- spin_lock(>queue_lock);
   first = spsc_queue_push(>job_queue, 
_job->queue_node);


- spin_unlock(>queue_lock);

Is your spsc safely to be added simultaneously?

Regards,
David Zhou

-
   /* first job wakes up scheduler */
   if (first) {
   /* Add the entity to the run queue */
diff --git a/include/drm/gpu_scheduler.h 
b/include/drm/gpu_scheduler.h

index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
   spinlock_t  rq_lock;
   struct drm_gpu_scheduler    *sched;

- spinlock_t  queue_lock;
   struct spsc_queue   job_queue;

   atomic_t    fence_seq;




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






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

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Andrey Grodzovsky]

So are you saying that you expect this to  be already in code for any 
usage of drm_sched_fence_create and drm_sched_entity_push_job ?


lock()

drm_sched_fence_create()

... (some code)

drm_sched_entity_push_job()

unlock()


Andrey

On 05/16/2018 07:23 AM, Christian König wrote:
drm_sched_fence_create() assigns a sequence number to the fence it 
creates.


Now drm_sched_fence_create() is called by drm_sched_job_init() to 
initialize the jobs we want to push on the scheduler queue.


When you now call drm_sched_entity_push_job() without a protecting 
lock it can happen that you push two (or even more) job with reversed 
sequence numbers.


Since the sequence numbers are used to determine job completion order 
reversing them can seriously mess things up.


So the spin lock should be superfluous, if it isn't we have a much 
larger bug we need to fix.


Christian.

Am 16.05.2018 um 13:15 schrieb Andrey Grodzovsky:
Can you please elaborate more, maybe give an example - I don't 
understand yet the problematic scenario.


Andrey


On 05/16/2018 02:50 AM, Christian König wrote:

No, that spinlock is indeed incorrect. I

See even when we protect the spsc queue with a spinlock that doesn't 
make it correct. It can happen that the jobs pushed to the queue are 
reversed in their sequence order and that can cause severe problems 
in the memory management.


Christian.

Am 16.05.2018 um 05:33 schrieb Grodzovsky, Andrey:
Yeah, that what I am not sure about... It's lockless in a sense of 
single producer single consumer but not for multiple concurrent 
producers... So now I think this spinlock should stay there... It 
just looked useless to me at first sight...


Andrey


From: Zhou, David(ChunMing)
Sent: 15 May 2018 23:04:44
To: Grodzovsky, Andrey; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org

Cc: Koenig, Christian
Subject: Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.



On 2018年05月16日 03:31, Andrey Grodzovsky wrote:

Signed-off-by: Andrey Grodzovsky 
---
   drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
   include/drm/gpu_scheduler.h   | 1 -
   2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c

index 1f1dd70..2569a63 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct 
drm_gpu_scheduler *sched,

   entity->last_scheduled = NULL;

   spin_lock_init(>rq_lock);
- spin_lock_init(>queue_lock);
   spsc_queue_init(>job_queue);

   atomic_set(>fence_seq, 0);
@@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct 
drm_sched_job *sched_job,


   trace_drm_sched_job(sched_job, entity);

- spin_lock(>queue_lock);
   first = spsc_queue_push(>job_queue, 
_job->queue_node);


- spin_unlock(>queue_lock);

Is your spsc safely to be added simultaneously?

Regards,
David Zhou

-
   /* first job wakes up scheduler */
   if (first) {
   /* Add the entity to the run queue */
diff --git a/include/drm/gpu_scheduler.h 
b/include/drm/gpu_scheduler.h

index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
   spinlock_t  rq_lock;
   struct drm_gpu_scheduler    *sched;

- spinlock_t  queue_lock;
   struct spsc_queue   job_queue;

   atomic_t    fence_seq;




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




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

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Christian König]

drm_sched_fence_create() assigns a sequence number to the fence it creates.

Now drm_sched_fence_create() is called by drm_sched_job_init() to 
initialize the jobs we want to push on the scheduler queue.


When you now call drm_sched_entity_push_job() without a protecting lock 
it can happen that you push two (or even more) job with reversed 
sequence numbers.


Since the sequence numbers are used to determine job completion order 
reversing them can seriously mess things up.


So the spin lock should be superfluous, if it isn't we have a much 
larger bug we need to fix.


Christian.

Am 16.05.2018 um 13:15 schrieb Andrey Grodzovsky:
Can you please elaborate more, maybe give an example - I don't 
understand yet the problematic scenario.


Andrey


On 05/16/2018 02:50 AM, Christian König wrote:

No, that spinlock is indeed incorrect. I

See even when we protect the spsc queue with a spinlock that doesn't 
make it correct. It can happen that the jobs pushed to the queue are 
reversed in their sequence order and that can cause severe problems 
in the memory management.


Christian.

Am 16.05.2018 um 05:33 schrieb Grodzovsky, Andrey:
Yeah, that what I am not sure about... It's lockless in a sense of 
single producer single consumer but not for multiple concurrent 
producers... So now I think this spinlock should stay there... It 
just looked useless to me at first sight...


Andrey


From: Zhou, David(ChunMing)
Sent: 15 May 2018 23:04:44
To: Grodzovsky, Andrey; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org

Cc: Koenig, Christian
Subject: Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.



On 2018年05月16日 03:31, Andrey Grodzovsky wrote:

Signed-off-by: Andrey Grodzovsky 
---
   drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
   include/drm/gpu_scheduler.h   | 1 -
   2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c

index 1f1dd70..2569a63 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct 
drm_gpu_scheduler *sched,

   entity->last_scheduled = NULL;

   spin_lock_init(>rq_lock);
- spin_lock_init(>queue_lock);
   spsc_queue_init(>job_queue);

   atomic_set(>fence_seq, 0);
@@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct 
drm_sched_job *sched_job,


   trace_drm_sched_job(sched_job, entity);

- spin_lock(>queue_lock);
   first = spsc_queue_push(>job_queue, 
_job->queue_node);


- spin_unlock(>queue_lock);

Is your spsc safely to be added simultaneously?

Regards,
David Zhou

-
   /* first job wakes up scheduler */
   if (first) {
   /* Add the entity to the run queue */
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
   spinlock_t  rq_lock;
   struct drm_gpu_scheduler    *sched;

- spinlock_t  queue_lock;
   struct spsc_queue   job_queue;

   atomic_t    fence_seq;




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


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

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

[Andrey Grodzovsky]

Can you please elaborate more, maybe give an example - I don't 
understand yet the problematic scenario.


Andrey


On 05/16/2018 02:50 AM, Christian König wrote:

No, that spinlock is indeed incorrect. I

See even when we protect the spsc queue with a spinlock that doesn't 
make it correct. It can happen that the jobs pushed to the queue are 
reversed in their sequence order and that can cause severe problems in 
the memory management.


Christian.

Am 16.05.2018 um 05:33 schrieb Grodzovsky, Andrey:
Yeah, that what I am not sure about... It's lockless in a sense of 
single producer single consumer but not for multiple concurrent 
producers... So now I think this spinlock should stay there... It 
just looked useless to me at first sight...


Andrey


From: Zhou, David(ChunMing)
Sent: 15 May 2018 23:04:44
To: Grodzovsky, Andrey; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org

Cc: Koenig, Christian
Subject: Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.



On 2018年05月16日 03:31, Andrey Grodzovsky wrote:

Signed-off-by: Andrey Grodzovsky 
---
   drivers/gpu/drm/scheduler/gpu_scheduler.c | 4 
   include/drm/gpu_scheduler.h   | 1 -
   2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c

index 1f1dd70..2569a63 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct 
drm_gpu_scheduler *sched,

   entity->last_scheduled = NULL;

   spin_lock_init(>rq_lock);
- spin_lock_init(>queue_lock);
   spsc_queue_init(>job_queue);

   atomic_set(>fence_seq, 0);
@@ -424,11 +423,8 @@ void drm_sched_entity_push_job(struct 
drm_sched_job *sched_job,


   trace_drm_sched_job(sched_job, entity);

- spin_lock(>queue_lock);
   first = spsc_queue_push(>job_queue, 
_job->queue_node);


- spin_unlock(>queue_lock);

Is your spsc safely to be added simultaneously?

Regards,
David Zhou

-
   /* first job wakes up scheduler */
   if (first) {
   /* Add the entity to the run queue */
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
   spinlock_t  rq_lock;
   struct drm_gpu_scheduler    *sched;

- spinlock_t  queue_lock;
   struct spsc_queue   job_queue;

   atomic_t    fence_seq;




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

Re: [PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions

[Rafael J. Wysocki]

On Tue, May 15, 2018 at 6:04 PM, Ayan Kumar Halder  wrote:
> malidp_pm_suspend_late checks if the runtime status is not suspended
> and if so, invokes malidp_runtime_pm_suspend which disables the
> display engine/core interrupts and the clocks. It sets the runtime status
> as suspended.
>
> The difference between suspend() and suspend_late() is as follows:-
> 1. suspend() makes the device quiescent. In our case, we invoke the DRM
> helper which disables the CRTC. This would have invoked runtime pm
> suspend but the system suspend process disables runtime pm.
> 2. suspend_late() It continues the suspend operations of the drm device
> which was started by suspend(). In our case, it performs the same 
> functionality
> as runtime_suspend().
>
> The complimentary functions are resume() and resume_early(). In the case of
> resume_early(), we invoke malidp_runtime_pm_resume() which enables the clocks
> and the interrupts. It sets the runtime status as active. If the device was
> in runtime suspend mode before system suspend was called, pm_runtime_work()
> will put the device back in runtime suspended mode( after the complete system
> has been resumed).
>
> Signed-off-by: Ayan Kumar Halder 
>
> ---
> Changes in v3:-
> - Rebased on top of earlier v3 patches,
>
> Changes in v2:-
> - Removed the change id and modified the commit message
> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 82221ea..c53b46a 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -768,8 +768,25 @@ static int __maybe_unused malidp_pm_resume(struct device 
> *dev)
> return 0;
>  }
>
> +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> +{
> +   if (!pm_runtime_status_suspended(dev)) {
> +   malidp_runtime_pm_suspend(dev);
> +   pm_runtime_set_suspended(dev);
> +   }
> +   return 0;
> +}
> +
> +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> +{
> +   malidp_runtime_pm_resume(dev);
> +   pm_runtime_set_active(dev);
> +   return 0;
> +}
> +
>  static const struct dev_pm_ops malidp_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
> +   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
> malidp_pm_resume_early) \
> SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, 
> malidp_runtime_pm_resume, NULL)
>  };
>
> --

AFAICS, this should work, so please feel free to add

Reviewed-by: Rafael J. Wysocki 

to it if that helps.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

[Lucas Stach]

Am Mittwoch, den 16.05.2018, 11:42 +0200 schrieb Daniel Vetter:
> On Tue, May 15, 2018 at 01:16:30PM +0100, Chris Wilson wrote:
> > Quoting Ezequiel Garcia (2018-05-14 22:28:31)
> > > On Mon, 2018-05-14 at 18:48 +0200, Daniel Vetter wrote:
> > > > On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> > > > > Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > > > > > Change how dma_fence_add_callback() behaves, when the fence
> > > > > > has error-signaled by the time it is being add. After this commit,
> > > > > > dma_fence_add_callback() returns the fence error, if it
> > > > > > has error-signaled before dma_fence_add_callback() is called.
> > > > > 
> > > > > Why? What problem are you trying to solve? fence->error does not imply
> > > > > that the fence has yet been signaled, and the caller wants a callback
> > > > > when it is signaled.
> > > > 
> > > > On top this is incosistent, e.g. we don't do the same for any of the 
> > > > other
> > > > dma_fence interfaces. Plus there's the issue that you might alias errno
> > > > values with fence errno values.
> > > > 
> > > 
> > > Right.
> > > 
> > > > I think keeping the error codes from the functions you're calling 
> > > > distinct
> > > > from the error code of the fence itself makes a lot of sense. The first
> > > > tells you whether your request worked out (or why not), the second tells
> > > > you whether the asynchronous dma operation (gpu rendering, page flip,
> > > > whatever) that the dma_fence represents worked out (or why not). That's 
> > > > 2
> > > > distinct things imo.
> > > > 
> > > > Might be good to show us the driver code that needs this behaviour so we
> > > > can discuss how to best handle your use-case.
> > > > 
> > > 
> > > This change arose while discussing the in-fences support for video4linux.
> > > Here's the patch that calls dma_fence_add_callback 
> > > https://lkml.org/lkml/2018/5/4/766.
> > > 
> > > The code snippet currently looks something like this:
> > > 
> > > if (vb->in_fence) {
> > > ret = dma_fence_add_callback(vb->in_fence, >fence_cb,
> > > 
> > >  vb2_qbuf_fence_cb);
> > > /* is the fence signaled? */
> > > if (ret == -ENOENT) {
> > > 
> > > dma_fence_put(vb->in_fence);
> > > vb->in_fence = NULL;
> > > } else if (ret)
> > > {
> > > goto unlock;
> > > }
> > > }
> > > 
> > > In this use case, if the callback is added successfully,
> > > the video4linux core defers the activation of the buffer
> > > until the fence signals.
> > > 
> > > If the fence is signaled (currently disregarding of errors)
> > > then the buffer is assumed to be ready to be activated,
> > > and so it gets queued for hardware usage.
> > > 
> > > Giving some more thought to this, I'm not so sure what is
> > > the right action if a fence signaled with error. In this case,
> > > it appears to me that we shouldn't be using this buffer
> > > if its in-fence is in error, but perhaps I'm missing
> > > something.
> > 
> > What I have in mind for async errors is to skip the operation and
> > propagate the error onto the next fence. Mostly because those async
> > errors may include fatal errors such as unable to pin the backing
> > storage for the operation, but even "trivial" errors such as an early
> > operation failing means that this request is then subject to garbage-in,
> > garbage-out. However, for trivial errors I would just propagate the
> > error status (so the caller knows something went wrong if they care, but
> > in all likelihood no one will notice) and continue on with the glitchy
> > operation.
> 
> In general, there's not really any hard rule about propagating fence
> errors across devices. It's mostly just used by drivers internally to keep
> track of failed stuff (gpu hangs or anything else async like Chris
> describes here).
> 
> For v4l I'm not sure you want to care much about this, since right now the
> main use of fence errors is gpu hang recovery (whether it's the driver or
> hw that's hung doesn't matter here).

Yes, my understanding is that fence signal and errors are two distinct
things that should not be conflated like it is done in this patch.

In my understanding signaling a fence means the HW or SW component
which added the fence is done with the buffer and will not touch it
anymore. In case of an unrecoverable error the fence will be signaled
with error status set, so we correctly reflect the buffer status as
being free to be used by whoever is waiting for it, but may contain
garbage.

If a fence waiter cares about the buffer content and may wish to skip
its operation if the fence is signaled with an error it should do it by
explicitly checking the fence error status, instead of making this
implicit behavior.

Regards,
Lucas
___
dri-devel mailing list

Re: [PATCH v3 20/26] drm/mediatek: hdmi: provide an owner .odev device for the bridge

[Philipp Zabel]

On Wed, 2018-05-16 at 12:15 +0200, Peter Rosin wrote:
> The .of_node member is going away.
> 
> Signed-off-by: Peter Rosin 

Acked-by: Philipp Zabel 

regards
Philipp

> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 59a11026dceb..d8c7d93d0a87 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1694,8 +1694,8 @@ static int mtk_drm_hdmi_probe(struct platform_device 
> *pdev)
>  
>   mtk_hdmi_register_audio_driver(dev);
>  
> + hdmi->bridge.odev = >dev;
>   hdmi->bridge.funcs = _hdmi_bridge_funcs;
> - hdmi->bridge.of_node = pdev->dev.of_node;
>   drm_bridge_add(>bridge);
>  
>   ret = mtk_hdmi_clk_enable_audio(hdmi);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/14] vgem: separate errno from VM_FAULT_* values

[Daniel Vetter]

On Wed, May 16, 2018 at 07:43:44AM +0200, Christoph Hellwig wrote:
> And streamline the code in vgem_fault with early returns so that it is
> a little bit more readable.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 51 +++--
>  1 file changed, 23 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 2524ff116f00..a261e0aab83a 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -61,12 +61,13 @@ static void vgem_gem_free_object(struct drm_gem_object 
> *obj)
>   kfree(vgem_obj);
>  }
>  
> -static int vgem_gem_fault(struct vm_fault *vmf)
> +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
>  {
>   struct vm_area_struct *vma = vmf->vma;
>   struct drm_vgem_gem_object *obj = vma->vm_private_data;
>   /* We don't use vmf->pgoff since that has the fake offset */
>   unsigned long vaddr = vmf->address;
> + struct page *page;
>   int ret;
>   loff_t num_pages;
>   pgoff_t page_offset;
> @@ -85,35 +86,29 @@ static int vgem_gem_fault(struct vm_fault *vmf)
>   ret = 0;
>   }
>   mutex_unlock(>pages_lock);
> - if (ret) {
> - struct page *page;
> -
> - page = shmem_read_mapping_page(
> - file_inode(obj->base.filp)->i_mapping,
> - page_offset);
> - if (!IS_ERR(page)) {
> - vmf->page = page;
> - ret = 0;
> - } else switch (PTR_ERR(page)) {
> - case -ENOSPC:
> - case -ENOMEM:
> - ret = VM_FAULT_OOM;
> - break;
> - case -EBUSY:
> - ret = VM_FAULT_RETRY;
> - break;
> - case -EFAULT:
> - case -EINVAL:
> - ret = VM_FAULT_SIGBUS;
> - break;
> - default:
> - WARN_ON(PTR_ERR(page));
> - ret = VM_FAULT_SIGBUS;
> - break;
> - }
> + if (!ret)
> + return 0;
> +
> + page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
> + page_offset);
> + if (!IS_ERR(page)) {
> + vmf->page = page;
> + return 0;
> + }
>  
> + switch (PTR_ERR(page)) {
> + case -ENOSPC:
> + case -ENOMEM:
> + return VM_FAULT_OOM;
> + case -EBUSY:
> + return VM_FAULT_RETRY;
> + case -EFAULT:
> + case -EINVAL:
> + return VM_FAULT_SIGBUS;
> + default:
> + WARN_ON(PTR_ERR(page));
> + return VM_FAULT_SIGBUS;
>   }
> - return ret;

Reviewed-by: Daniel Vetter 

Want me to merge this through drm-misc or plan to pick it up yourself?
-Daniel

>  }
>  
>  static const struct vm_operations_struct vgem_gem_vm_ops = {
> -- 
> 2.17.0
> 

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

Re: [PATCH 1/3] drm/vkms: Add basic CRTC initialization

[Daniel Vetter]

On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siqueira wrote:
> This commit adds the essential infrastructure for managing CRTCs which
> is composed of: a new data struct for output data information, a
> function for basic modeset initialization, and the operation to create
> planes. Due to the introduction of a new initialization function,
> connectors were moved from vkms_drv.c to vkms_display.c.
> 
> Signed-off-by: Rodrigo Siqueira 
> ---
>  drivers/gpu/drm/vkms/Makefile   |   2 +-
>  drivers/gpu/drm/vkms/vkms_display.c | 108 
>  drivers/gpu/drm/vkms/vkms_drv.c |  41 +--
>  drivers/gpu/drm/vkms/vkms_drv.h |  26 ++-
>  drivers/gpu/drm/vkms/vkms_plane.c   |  46 
>  5 files changed, 180 insertions(+), 43 deletions(-)
>  create mode 100644 drivers/gpu/drm/vkms/vkms_display.c
>  create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c
> 
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 2aef948d3a34..f747e2a3a6f4 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -1,3 +1,3 @@
> -vkms-y := vkms_drv.o
> +vkms-y := vkms_drv.o vkms_plane.o vkms_display.o
>  
>  obj-$(CONFIG_DRM_VKMS) += vkms.o
> diff --git a/drivers/gpu/drm/vkms/vkms_display.c 
> b/drivers/gpu/drm/vkms/vkms_display.c
> new file mode 100644
> index ..b20b41f9590b
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/vkms_display.c
> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include "vkms_drv.h"
> +#include 
> +#include 
> +
> +#define XRES_MIN32
> +#define YRES_MIN32
> +
> +#define XRES_DEF  1024
> +#define YRES_DEF   768

These seem unused.

> +#define XRES_MAX  8192
> +#define YRES_MAX  8192
> +
> +static const struct drm_mode_config_funcs vkms_mode_funcs = {
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static const struct drm_crtc_funcs vkms_crtc_funcs = {
> + .set_config = drm_atomic_helper_set_config,
> + .destroy= drm_crtc_cleanup,
> + .page_flip  = drm_atomic_helper_page_flip,
> + .reset  = drm_atomic_helper_crtc_reset,
> + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> + .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
> +};
> +
> +static void vkms_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_unregister(connector);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs vkms_connector_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = vkms_connector_destroy,
> +};
> +
> +static int vkms_output_init(struct vkms_device *vkmsdev)
> +{
> + struct vkms_output *output = >output;
> + struct drm_device *dev = >drm;
> + struct drm_connector *connector = >connector;
> + struct drm_crtc *crtc = >crtc;
> + struct drm_plane *primary;
> + int ret;
> +
> + primary = vkms_plane_init(vkmsdev);
> + if (IS_ERR(primary))
> + return PTR_ERR(primary);
> +
> + ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL,
> + _crtc_funcs, NULL);
> + if (ret) {
> + DRM_ERROR("Failed to init CRTC\n");
> + goto err_crtc;
> + }
> + primary->crtc = crtc;

If you want to split stuff up a bit, I think putting the crtc stuff into
vkms_crtc.c, and then renaming this file here to vkms_output.c would make
sense.

> +
> + ret = drm_connector_init(dev, connector, _connector_funcs,
> +  DRM_MODE_CONNECTOR_VIRTUAL);
> + if (ret) {
> + DRM_ERROR("Failed to init connector\n");
> + goto err_connector;
> + }
> +
> + ret = drm_connector_register(connector);
> + if (ret) {
> + DRM_ERROR("Failed to register connector\n");
> + goto err_connector_register;
> + }
> +
> + drm_mode_config_reset(dev);
> +
> + return 0;
> +
> +err_connector_register:
> + drm_connector_cleanup(connector);
> +
> +err_connector:
> + drm_crtc_cleanup(crtc);
> +
> +err_crtc:
> + drm_plane_cleanup(primary);
> + return ret;
> +}
> +
> +int vkms_modeset_init(struct vkms_device *vkmsdev)

Plus keeping vkms_modeset_init in vkms_drv.c, vkms is 100% about
modesetting and nothing else, so splitting that out is a bit overkill imo.

> +{
> + struct drm_device *dev = >drm;
> +
> + drm_mode_config_init(dev);
> + dev->mode_config.funcs = _mode_funcs;
> + dev->mode_config.min_width = XRES_MIN;
> + 

Re: [PATCH 2/3] drm/vkms: Add encoder initialization

[Daniel Vetter]

On Wed, May 16, 2018 at 12:07:12AM -0300, Rodrigo Siqueira wrote:
> This commit adds a single and simple virtual encoder to VKMS.
> 
> Signed-off-by: Rodrigo Siqueira 

Doesn't this break bisection, i.e. between patch 1&2 vkms looks broken
(because the encoder is missing)?

If so probably better to merge this into patch 1.
-Daniel

> ---
>  drivers/gpu/drm/vkms/vkms_display.c | 25 +
>  drivers/gpu/drm/vkms/vkms_drv.h |  2 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_display.c 
> b/drivers/gpu/drm/vkms/vkms_display.c
> index b20b41f9590b..d6702128b5f7 100644
> --- a/drivers/gpu/drm/vkms/vkms_display.c
> +++ b/drivers/gpu/drm/vkms/vkms_display.c
> @@ -44,11 +44,16 @@ static const struct drm_connector_funcs 
> vkms_connector_funcs = {
>   .destroy = vkms_connector_destroy,
>  };
>  
> +static const struct drm_encoder_funcs vkms_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
>  static int vkms_output_init(struct vkms_device *vkmsdev)
>  {
>   struct vkms_output *output = >output;
>   struct drm_device *dev = >drm;
>   struct drm_connector *connector = >connector;
> + struct drm_encoder *encoder = >encoder;
>   struct drm_crtc *crtc = >crtc;
>   struct drm_plane *primary;
>   int ret;
> @@ -78,10 +83,30 @@ static int vkms_output_init(struct vkms_device *vkmsdev)
>   goto err_connector_register;
>   }
>  
> + ret = drm_encoder_init(dev, encoder, _encoder_funcs,
> +DRM_MODE_ENCODER_VIRTUAL, NULL);
> + if (ret) {
> + DRM_ERROR("Failed to init encoder\n");
> + goto err_encoder;
> + }
> + encoder->possible_crtcs = 1;
> +
> + ret = drm_mode_connector_attach_encoder(connector, encoder);
> + if (ret) {
> + DRM_ERROR("Failed to attach connector to encoder\n");
> + goto err_attach;
> + }
> +
>   drm_mode_config_reset(dev);
>  
>   return 0;
>  
> +err_attach:
> + drm_encoder_cleanup(encoder);
> +
> +err_encoder:
> + drm_connector_unregister(connector);
> +
>  err_connector_register:
>   drm_connector_cleanup(connector);
>  
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 292bdea9c785..933eedc5b25b 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -3,6 +3,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  static const u32 vkms_formats[] = {
>   DRM_FORMAT_XRGB,
> @@ -17,6 +18,7 @@ static const u32 vkms_formats[] = {
>  
>  struct vkms_output {
>   struct drm_crtc crtc;
> + struct drm_encoder encoder;
>   struct drm_connector connector;
>  };
>  
> -- 
> 2.17.0
> 

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

Re: [PATCH] drm/bridge: checkpatch strict minor updates

[Daniel Vetter]

On Tue, May 15, 2018 at 10:37:36PM +0200, Philippe Cornu wrote:
> Minor fixes detected with "scripts/checkpatch.pl --strict"
> 
> Signed-off-by: Philippe Cornu 
> ---
> Detected when merging "drm: clarify adjusted_mode documentation for bridges"

Acked-by: Daniel Vetter 
> 
>  include/drm/drm_bridge.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 9917651a7fdd..70131ab57e8f 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -97,7 +97,7 @@ struct drm_bridge_funcs {
>   /**
>* @mode_fixup:
>*
> -  * This callback is used to validate and adjust a mode. The paramater
> +  * This callback is used to validate and adjust a mode. The parameter
>* mode is the display mode that should be fed to the next element in
>* the display chain, either the final _connector or the next
>* _bridge. The parameter adjusted_mode is the input mode the bridge
> @@ -301,15 +301,15 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
> struct drm_bridge *bridge,
> struct drm_bridge *previous);
>  
>  bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode);
> +const struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode);
>  enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
>  const struct drm_display_mode *mode);
>  void drm_bridge_disable(struct drm_bridge *bridge);
>  void drm_bridge_post_disable(struct drm_bridge *bridge);
>  void drm_bridge_mode_set(struct drm_bridge *bridge,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode);
> +  struct drm_display_mode *mode,
> +  struct drm_display_mode *adjusted_mode);
>  void drm_bridge_pre_enable(struct drm_bridge *bridge);
>  void drm_bridge_enable(struct drm_bridge *bridge);
>  
> -- 
> 2.15.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

[Daniel Vetter]

On Tue, May 15, 2018 at 01:16:30PM +0100, Chris Wilson wrote:
> Quoting Ezequiel Garcia (2018-05-14 22:28:31)
> > On Mon, 2018-05-14 at 18:48 +0200, Daniel Vetter wrote:
> > > On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> > > > Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > > > > Change how dma_fence_add_callback() behaves, when the fence
> > > > > has error-signaled by the time it is being add. After this commit,
> > > > > dma_fence_add_callback() returns the fence error, if it
> > > > > has error-signaled before dma_fence_add_callback() is called.
> > > > 
> > > > Why? What problem are you trying to solve? fence->error does not imply
> > > > that the fence has yet been signaled, and the caller wants a callback
> > > > when it is signaled.
> > > 
> > > On top this is incosistent, e.g. we don't do the same for any of the other
> > > dma_fence interfaces. Plus there's the issue that you might alias errno
> > > values with fence errno values.
> > > 
> > 
> > Right.
> > 
> > > I think keeping the error codes from the functions you're calling distinct
> > > from the error code of the fence itself makes a lot of sense. The first
> > > tells you whether your request worked out (or why not), the second tells
> > > you whether the asynchronous dma operation (gpu rendering, page flip,
> > > whatever) that the dma_fence represents worked out (or why not). That's 2
> > > distinct things imo.
> > > 
> > > Might be good to show us the driver code that needs this behaviour so we
> > > can discuss how to best handle your use-case.
> > > 
> > 
> > This change arose while discussing the in-fences support for video4linux.
> > Here's the patch that calls dma_fence_add_callback 
> > https://lkml.org/lkml/2018/5/4/766.
> > 
> > The code snippet currently looks something like this:
> > 
> > if (vb->in_fence) {
> > ret = dma_fence_add_callback(vb->in_fence, >fence_cb,
> > 
> >  vb2_qbuf_fence_cb);
> > /* is the fence signaled? */
> > if (ret == -ENOENT) {
> > 
> > dma_fence_put(vb->in_fence);
> > vb->in_fence = NULL;
> > } else if (ret)
> > {
> > goto unlock;
> > }
> > }
> > 
> > In this use case, if the callback is added successfully,
> > the video4linux core defers the activation of the buffer
> > until the fence signals.
> > 
> > If the fence is signaled (currently disregarding of errors)
> > then the buffer is assumed to be ready to be activated,
> > and so it gets queued for hardware usage.
> > 
> > Giving some more thought to this, I'm not so sure what is
> > the right action if a fence signaled with error. In this case,
> > it appears to me that we shouldn't be using this buffer
> > if its in-fence is in error, but perhaps I'm missing
> > something.
> 
> What I have in mind for async errors is to skip the operation and
> propagate the error onto the next fence. Mostly because those async
> errors may include fatal errors such as unable to pin the backing
> storage for the operation, but even "trivial" errors such as an early
> operation failing means that this request is then subject to garbage-in,
> garbage-out. However, for trivial errors I would just propagate the
> error status (so the caller knows something went wrong if they care, but
> in all likelihood no one will notice) and continue on with the glitchy
> operation.

In general, there's not really any hard rule about propagating fence
errors across devices. It's mostly just used by drivers internally to keep
track of failed stuff (gpu hangs or anything else async like Chris
describes here).

For v4l I'm not sure you want to care much about this, since right now the
main use of fence errors is gpu hang recovery (whether it's the driver or
hw that's hung doesn't matter here).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rcar-du: Fix build failure

[Kieran Bingham]

Hi Laurent,

Thanks for the fix.

On 15/05/18 18:47, Laurent Pinchart wrote:
> Commit 75a07f399cd4 ("drm: rcar-du: Zero-out sg_tables when duplicating
> plane state") introduced a reference to the alpha field of struct
> rcar_du_vsp_plane_state that got removed in commit 301a9b8d5456
> ("drm/rcar-du: Convert to the new generic alpha property"). The issue
> stems from the merge of the two commits through separate branches and
> breaks compilation of the driver. Fix it.
> 
> Fixes: 75a07f399cd4 ("drm: rcar-du: Zero-out sg_tables when duplicating plane 
> state")
> Signed-off-by: Laurent Pinchart 

The kms-tests work fine on this commit.

Reviewed-by: Kieran Bingham 
Tested-by: Kieran Bingham 


> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index 27a440886b17..c59f0cfabd33 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -314,7 +314,6 @@ rcar_du_vsp_plane_atomic_duplicate_state(struct drm_plane 
> *plane)
>   return NULL;
>  
>   __drm_atomic_helper_plane_duplicate_state(plane, >state);
> - copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
>  
>   return >state;
>  }
> 



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

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Daniel Vetter]

On Tue, May 15, 2018 at 01:09:59PM +0200, Peter Rosin wrote:
> On 2018-05-15 12:22, Daniel Vetter wrote:
> > On Mon, May 14, 2018 at 10:40 PM, Peter Rosin  wrote:
> >> On 2018-05-14 18:28, Daniel Vetter wrote:
> >>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
>  On 2018-05-10 10:10, Andrzej Hajda wrote:
> > On 04.05.2018 15:52, Peter Rosin wrote:
> >> If the bridge supplier is unbound, this will bring the bridge consumer
> >> down along with the bridge. Thus, there will no longer linger any
> >> dangling pointers from the bridge consumer (the drm_device) to some
> >> non-existent bridge supplier.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/drm_bridge.c | 18 ++
> >>  include/drm/drm_bridge.h |  2 ++
> >>  2 files changed, 20 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_bridge.c 
> >> b/drivers/gpu/drm/drm_bridge.c
> >> index 78d186b6831b..0259f0a3ff27 100644
> >> --- a/drivers/gpu/drm/drm_bridge.c
> >> +++ b/drivers/gpu/drm/drm_bridge.c
> >> @@ -26,6 +26,7 @@
> >>  #include 
> >>
> >>  #include 
> >> +#include 
> >>  #include 
> >>
> >>  #include "drm_crtc_internal.h"
> >> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder 
> >> *encoder, struct drm_bridge *bridge,
> >>if (bridge->dev)
> >>return -EBUSY;
> >>
> >> +  if (encoder->dev->dev != bridge->odev) {
> >
> > I wonder why device_link_add does not handle this case (self dependency)
> > silently as noop, as it seems to be a correct behavior.
> 
>  It's kind-of a silly corner-case though, so perfectly understandable
>  that it isn't handled.
> 
> >> +  bridge->link = device_link_add(encoder->dev->dev,
> >> + bridge->odev, 0);
> >> +  if (!bridge->link) {
> >> +  dev_err(bridge->odev, "failed to link bridge to 
> >> %s\n",
> >> +  dev_name(encoder->dev->dev));
> >> +  return -EINVAL;
> >> +  }
> >> +  }
> >> +
> >>bridge->dev = encoder->dev;
> >>bridge->encoder = encoder;
> >>
> >>if (bridge->funcs->attach) {
> >>ret = bridge->funcs->attach(bridge);
> >>if (ret < 0) {
> >> +  if (bridge->link)
> >> +  device_link_del(bridge->link);
> >> +  bridge->link = NULL;
> >>bridge->dev = NULL;
> >>bridge->encoder = NULL;
> >>return ret;
> >> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >>if (bridge->funcs->detach)
> >>bridge->funcs->detach(bridge);
> >>
> >> +  if (bridge->link)
> >> +  device_link_del(bridge->link);
> >> +  bridge->link = NULL;
> >> +
> >>bridge->dev = NULL;
> >>  }
> >>
> >> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >> index b656e505d11e..804189c63a4c 100644
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> >>   * @list: to keep track of all added bridges
> >>   * @timings: the timing specification for the bridge, if any (may
> >>   * be NULL)
> >> + * @link: drm consumer <-> bridge supplier
> >
> > Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
> > to the bridge" would be better.
> 
>  I meant "<->" to indicate that the link is bidirectional, not that the
>  relationship is in any way symmetric. I wasn't aware of any implication
>  of a symmetric relationship when using "<->", do you have a reference?
>  But I guess the different arrow notations in math are somewhat overloaded
>  and that someone at some point must have used "<->" to indicate a
>  symmetric relationship...
> >>>
> >>> Yeah I agree with Andrzej here, for me <-> implies a symmetric
> >>> relationship. Spelling it out like Andrzej suggested sounds like the
> >>> better idea.
> >>> -Daniel
> >>
> >> Ok, I guess that means I have to do a v3 after all. Or can this
> >> trivial documentation update be done by the committer? I hate to
> >> spam everyone with another volley...
> >>
> >> Or perhaps I should squash patches 2-23 that are all rather similar
> >> and mechanic? I separated them to allow for easier review from
> >> individual driver maintainers, but that didn't seem to happen
> >> anyway...
> > 
> > Do another volley of the full set, or in-reply-to to just replace the
> > patch that needs to be respun (but some people don't like that).
> > 
> > When resending just make sure you're picking up all the acks/r-bs you
> > have already.
> 
> 

Re: [PATCH v3 4/4] drm/vc4: Support the case where the DSI device is disabled

[Eric Anholt]

Boris Brezillon  writes:

> Having a device with a status property != "okay" in the DT is a valid
> use case, and we should not prevent the registration of the DRM device
> when the DSI device connected to the DSI controller is disabled.
>
> Consider the ENODEV return code as a valid result and do not expose the
> DSI encoder/connector when it happens.
>
> Signed-off-by: Boris Brezillon 

Reviewed-by: Eric Anholt 


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

[Bug 106404] Hang in draw function caused by interaction of glutInitWindowPosition, glutFullScreen , glDrawBuffer(GL_FRONT)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Mesa core
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

--- Comment #4 from Michel Dänzer  ---
Doesn't look driver specific, reassigning to Mesa core.

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

Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support

[Sergei Shtylyov]

Hello!

On 5/16/2018 10:54 AM, Simon Horman wrote:


Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.

Signed-off-by: Ulrich Hecht 
---
  drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3d2d3bb..58fb9f8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info 
rcar_lvds_r8a77970_info = {
.quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
  };
  
+static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {

+   .gen = 3,
+   .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
+};


This new structure seems to be identical to rcar_lvds_r8a77970_info.

> Could we consolidate somehow?

   In my book, that one has 2 quirk flags. What tree are you looking at?

[...]

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

[PATCH] doc: how to become a drm-intel committer

[Jani Nikula]

Until now, the drm-intel commit access have been handed out ad hoc,
without transparency, consistency, or fairness. With pressure to add
more committers, this is no longer tenable, if it ever was. Document the
requirements and expectations around becoming a drm-intel committer.

The drm-intel maintainers believe that a reasonable level of experience
and track record of working on the driver, as well as actively engaging
in the community upstream, are necessary before becoming a committer.

While the requirements outlined here may seem strict in contrast with
many projects, it seems easier to start strict and relax the
requirements later on as needed than the other way round.

v2: Address some of the concerns brought up by Daniel, and try to align
the structure with the proposed igt rules.

v3: Update commit message.

Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: dim-to...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Acked-by: Dave Airlie 
Acked-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Rodrigo Vivi 
---
 commit-access.rst | 91 +++
 index.rst |  1 +
 2 files changed, 92 insertions(+)
 create mode 100644 commit-access.rst

diff --git a/commit-access.rst b/commit-access.rst
new file mode 100644
index ..54a7402714cd
--- /dev/null
+++ b/commit-access.rst
@@ -0,0 +1,91 @@
+===
+ Commit Access
+===
+
+The drm-misc and drm-intel repositories operate in a maintainer/committer model
+with a large pool committers who can push patches in accordance with the stated
+merge criteria, and maintainers handling pull requests, topic branches, merges,
+and so on.
+
+This document outlines the requirements for becoming a committer.
+
+drm-misc
+
+
+See :ref:`drm-misc`.
+
+drm-intel
+-
+
+Criteria
+
+
+Commit rights will be granted to anyone who requests them and fulfills the
+following criteria:
+
+- Has contributed at least 25 patches to i915 driver that have already been
+  merged upstream. Most of the patches must be non-trivial, not just simple
+  spelling or style fixes or code movement.
+
+- Has reviewed at least 25 patches from other developers to i915 driver that
+  have already been merged upstream. Again, most of the reviewed patches must 
be
+  non-trivial.
+
+- Are actively participating in discussions about their work and areas of
+  expertise on the project communication channels (the intel-gfx mailing list,
+  #intel-gfx freenode IRC channel, and freedesktop.org bugzilla).
+
+- Has been active in the past year (at least some commits or reviews on i915
+  driver).
+
+- Will be regularly contributing further patches. This includes regular
+  contributors to other parts of the open source graphics stack who only do the
+  occasional patch within i915 itself.
+
+- Agrees to use their commit rights in accordance with the documented merge
+  criteria, tools, and processes.
+
+The above criteria are in place to encourage and require committers are 
actively
+and broadly engaged upstream, and that they are acquainted and comfortable with
+the open collaboration model we have. To ensure the committers have enough
+experience to gauge reasonably well how much review a patch needs, and whether
+it needs acks from domain experts or maintainers before pushing.
+
+Access Request
+~~
+
+Apply for an account (and any other account change requests, including commit
+rights if you already have an account) through
+
+https://www.freedesktop.org/wiki/AccountRequests/
+
+Maintainer acks are required to confirm commit rights. Please ping the
+maintainers if your request is stuck.
+
+Maintainers may rate limit adding new committers to ensure there's enough
+bandwidth to properly support ramp-up on the tools and processes. In this case,
+the maintainers will pledge to add at least two new committers per month,
+loosely prioritized based on commits, reviews, and in-flight patches.
+
+Committers are encouraged to request their commit rights get removed when they
+no longer contribute to the project. Commit rights will be automatically 
revoked
+after a year of inactivity (no commits or reviews). Commit rights will be
+reinstated when they come back to the project.
+
+Maintainers and committers should encourage contributors to request commit
+rights.
+
+Code of Conduct
+~~~
+
+Please be aware the freedesktop.org Code of Conduct also applies to i915:
+
+https://www.freedesktop.org/wiki/CodeOfConduct/
+
+See the MAINTAINERS file for contact details of the i915 maintainers.
+
+Abuse of commit rights, like engaging in 

Re: linux-next: build failure after merge of the drm tree

[Oded Gabbay]

On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function 
> 'init_user_pages':
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit 
> declaration of function 'release_pages'; did you mean 'release_task'? 
> [-Werror=implicit-function-declaration]
>release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
>^
>release_task
>
> Caused by commit
>
>   5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell 
> Date: Wed, 16 May 2018 16:43:34 +1000
> Subject: [PATCH] drm/amdgpu: include pagemap.h for release_pages()
>
> Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD"
> Cc: Felix Kuehling 
> Cc: Oded Gabbay 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index 72ab2b1ffe75..ff8fd75f7ca5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -23,6 +23,7 @@
>  #define pr_fmt(fmt) "kfd2kgd: " fmt
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "amdgpu_object.h"
> --
> 2.17.0
>
> --
> Cheers,
> Stephen Rothwell

Thanks Stephen,

I'll add it to amdkfd-next and send it to Dave with other fixes.

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