Re: [PATCH] drm/writeback: Delete drm_writeback_cleanup_job

[Brian Starkey]

On Thu, Feb 21, 2019 at 10:19:35AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> Thank you for the patch.
> 
> On Thu, Feb 21, 2019 at 12:24:01AM +0100, Daniel Vetter wrote:
> > No implementation, no callers.
> 
> The issue here isn't that the function is declared, but that it's not
> defined. Jobs are leaked when atomic commit fails (or when using test
> commits). I'm working on a fix, please don't apply this patch in the
> meantime.

Yeah, looking at the series somehow the call to cleanup the writeback
job on failure looks like it got lost between v9 and v10. I saw a
patch internally, but looks like James didn't send it to the list yet.

@James, could you send out your patch which fixes the cleanup on
failure?

Thanks,
-Brian

> 
> > Cc: Brian Starkey 
> > Cc: Liviu Dudau 
> > Cc: Eric Anholt 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  include/drm/drm_writeback.h | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> > index 23df9d463003..f34895f7fcb1 100644
> > --- a/include/drm/drm_writeback.h
> > +++ b/include/drm/drm_writeback.h
> > @@ -125,8 +125,6 @@ int drm_writeback_connector_init(struct drm_device *dev,
> >  void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
> >  struct drm_writeback_job *job);
> >  
> > -void drm_writeback_cleanup_job(struct drm_writeback_job *job);
> > -
> >  void
> >  drm_writeback_signal_completion(struct drm_writeback_connector 
> > *wb_connector,
> > int status);
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v14 23/33] misc/mei/hdcp: Verify H_prime

[Winkler, Tomas]

> 
> Requests for the verification of AKE_Send_H_prime.
> 
> ME will calculate the H and comparing it with received H_Prime.
> The result will be returned as status.
> 
> 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]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Styles and typos fixed [Uma]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc Addition [Tomas]
>   memcpy for const length.
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM
> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 58
> +++-
>  1 file changed, 57 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 922c6a76bb9f..0a4087a2efd5 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -182,13 +182,69 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct
> device *dev,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @rx_hprime: AKE_Send_H_prime msg for ME FW verification
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_verify_hprime(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !rx_hprime)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> +
> + memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> +HDCP_2_2_H_PRIME_LEN);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_hprime_in,
> +   sizeof(send_hprime_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>   .initiate_hdcp2_session = mei_hdcp_initiate_session,
>   .verify_receiver_cert_prepare_km =
>   mei_hdcp_verify_receiver_cert_prepare_km,
> - .verify_hprime = NULL,
> + .verify_hprime = mei_hdcp_verify_hprime,
>   .store_pairing_info = NULL,
>   .initiate_locality_check = NULL,
>   .verify_lprime = NULL,
> --
> 2.7.4

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

RE: [PATCH v14 21/33] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[Winkler, Tomas]

> 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]
> v4:
>   %zd is used for size [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Spellings in commit msg is fixed [Uma]
> v5: Rebased.
> v6:
>   Collected the rb-ed by.
>   Realigning the patches in the series.
> v7:
>   Adjust to the new mei interface.
>   Fix for kdoc.
> v8:
>   K-Doc Addition.
>   memcpy for const length.
> v9:
>   s/mei_hdcp_ddi/mei_fw_ddi
>   s/i915_port/mei_i915_port [Tomas]
>   renamed func as mei_hdcp_* [Tomas]
>   Instead of macro, inline func for ddi index is used. [Tomas]
> v10:
>   Switch case for the coversion between i915_port to mei_ddi [Tomas]
>   Kernel doc fix.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
Signed-off-by: Tomas Winkler 

> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 94
> 
>  drivers/misc/mei/hdcp/mei_hdcp.h | 11 +
>  2 files changed, 105 insertions(+)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 8df069c1b0cc..952bae79dd02 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,100 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +
> +#include "mei_hdcp.h"
> +
> +static inline u8 mei_get_ddi_index(enum port port) {
> + switch (port) {
> + case PORT_A:
> + return MEI_DDI_A;
> + case PORT_B ... PORT_F:
> + return (u8)port;
> + default:
> + return MEI_DDI_INVALID_PORT;
> + }
> +}
> +
> +/**
> + * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in
> +ME FW
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @ake_data: AKE_Init msg output.
> + *
> + * Return:  0 on Success, <0 on Failure.
> + */
> +static int
> +mei_hdcp_initiate_session(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !ake_data)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> + session_init_in.protocol = data->protocol;
> +
> + byte = mei_cldev_send(cldev, (u8 *)_init_in,
> +   sizeof(session_init_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + 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, HDCP_2_2_RTX_LEN);
> +
> + return 0;
> +}
> +
> +static __attribute__((unused))
> +struct i915_hdcp_component_ops mei_hdcp_ops = {
> + .owner = THIS_MODULE,
> + .initiate_hdcp2_session = mei_hdcp_initiate_session,
> + .verify_receiver_cert_prepare_km = NULL,
> + .verify_hprime = NULL,
> + .store_pairing_info = NULL,
> + .initiate_locality_check = NULL,
> + .verify_lprime = NULL,
> + .get_session_key = NULL,
> + .repeater_check_flow_prepare_ack = NULL,
> + .verify_mprime = NULL,
> + .enable_hdcp_authentication = NULL,
> + .close_hdcp_session = NULL,
> +};
> 
>  static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id) diff --git
> a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
> index 582a7e27ae29..1eca72a9c1c2 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.h
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> @@ -363,4 +363,15 @@ 

RE: [PATCH v14 24/33] misc/mei/hdcp: Store the HDCP Pairing info

[Winkler, Tomas]

> 
> 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]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Style fixed [Uma]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc addition. [Tomas]
>   memcpy for const length.
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM

> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 60
> +++-
>  1 file changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 0a4087a2efd5..1f5514244716 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -238,6 +238,64 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> hdcp_port_data *data,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_store_pairing_info() - Store pairing info received at ME FW
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @pairing_info: AKE_Send_Pairing_Info msg input to ME FW
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_store_pairing_info(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !pairing_info)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> +
> + memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> +HDCP_2_2_E_KH_KM_LEN);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_info_in,
> +   sizeof(pairing_info_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
> @@ -245,7 +303,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .verify_receiver_cert_prepare_km =
>   mei_hdcp_verify_receiver_cert_prepare_km,
>   .verify_hprime = mei_hdcp_verify_hprime,
> - .store_pairing_info = NULL,
> + .store_pairing_info = mei_hdcp_store_pairing_info,
>   .initiate_locality_check = NULL,
>   .verify_lprime = NULL,
>   .get_session_key = NULL,
> --
> 2.7.4

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

Re: [PATCH v2 2/2] drm/qxl: kick out vgacon

[Daniel Vetter]

On Thu, Feb 21, 2019 at 02:06:23PM +0100, Gerd Hoffmann wrote:
> On Thu, Feb 21, 2019 at 01:20:11PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote:
> > > Problem:  qxl switches from native mode back into vga compatibility mode
> > > when it notices someone is accessing vga registers.  And vgacon does
> > > exactly that before fbcon takes over.  So make sure we kick out vgacon
> > > early enough that it wouldn't disturb us.
> > > 
> > > Signed-off-by: Gerd Hoffmann 
> > > ---
> > >  drivers/gpu/drm/qxl/qxl_drv.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > > index bb81e310eb..08446561aa 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > > @@ -95,6 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> > > pci_device_id *ent)
> > >   goto modeset_cleanup;
> > >  
> > >   drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> > > + drm_fb_helper_kick_out_vgacon();
> > 
> > I was thinking of checking whether pdev is a VGA class device and whether
> > it decodes vga access, and in that case automatically calling
> > kick_out_vgacon from remove_conflicting_pci_framebuffer. Since that's what
> > drivers want anyway, and those who don't can open code it.
> > 
> > Or is there an issue with that?
> 
> It'll need more careful testing to make sure we don't have unwanted side
> effects when just doing it for everyone.  And I guess most drivers don't
> care much because their hardware ignores vga port writes once they are
> switched out of vga text mode.
> 
> Dunno why i915 needs this.

The problem isn't loading, it's unloading again. If you boot with vgacon,
but no fbdev driver (which iirc also has magic code to throw out the vga
console), then when you unload your kms driver vgacon kicks back in. And a
pile of things go really sideways when that happens.

I have no idea whether it's just intel hw or maybe pci decoding or
something else, but seems like good practice to kick out all existing
drivers, to make sure they can never get at the hw again.

So don't think it'll hurt to do this for everyone. But yeah maybe we can
do that as a follow-up (and convert i915 over), dunno.
-Daniel


> In case of qxl it is more a historical leftover.  The very first qxl
> device revision had no explicit qxl command to switch from qxl native
> mode back to vga compatibility mode, vga port access was used for that
> instead.  It's long fixed, but the qxl device still has that quirk for
> compatibility with very old guest drivers.
> 
> cheers,
>   Gerd
> 
> ___
> 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 v2 2/2] drm/qxl: kick out vgacon

[Daniel Vetter]

On Thu, Feb 21, 2019 at 4:11 PM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > I was thinking of checking whether pdev is a VGA class device and whether
> > it decodes vga access, and in that case automatically calling
>
> How can I figure that?  Ok, class is easy, but decode?  pci.h offers
> functions to set vga decode but not to get that info ...

PCI_COMMAND_MEM and PCI_COMMAND_IO. There doesn't seem to be any
separate bits really. That's at least what I've gleaned from vgaarb.c.
The magic legacy vga decode bits only seem to exist on bridges, maybe
we can extract that logic from vgaarb.c (yes this is all a bit
spiralling out of control).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Koenig, Christian]

Am 21.02.19 um 07:47 schrieb Thomas Hellstrom:
> On Wed, 2019-02-20 at 19:23 +, Kuehling, Felix wrote:
>> On 2019-02-20 1:41 a.m., Thomas Hellstrom wrote:
>>> On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:
 On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
>> Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
>>> On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
 Another good question is also why the heck the acc_size
 counts
 towards
 the DMA32 zone?
>>> DMA32 TTM pages are accounted in the DMA32 zone. Other
>>> pages
>>> are
>>> not.
>> Yeah, I'm perfectly aware of this. But this is for the
>> accounting
>> size!
>>
>> We have an accounting for the stuff needed additional to the
>> pages
>> backing the BO (e.g. the page and DMA addr array).
>>
>> And from the bug description it sounds like we use the DMA32
>> zone
>> for
>> this accounting which of course is completely nonsense.
> It's actually accounted in all available zones, since it would
> be
> pretty hard to determine exactly where that memory should be
> accounted.
> In particular if it's vmalloced. It might be DMA32, it might
> not.
> Given
> the objective of stopping malicious user-space from exhausting
> the
> DMA32 zone it was, at the time the code was written, a
> reasonable
> approximation. With ever increasing memory sizes, there might
> be
> better
> solutions?
 As far as I can see, in TTM, ttm_mem_global_alloc is only used
 for
 the
 acc_size in ttm_bo_init_reserved. Other than that vmwgfx also
 seems
 to
 use it to account for a few things that are allocated with
 kmalloc.

 So would a better solution be to change ttm_mem_global_alloc to
 use
 only
 the kernel zone?

>>> IMO we need to determine what functionality to keep and then the
>>> best
>>> solution. The current code does its job, but is obviously too
>>> restrictive. Both of the solutions you suggest open up for
>>> potential
>>> DOS attacks (DMA32 and kernel zones are not mutually exclusive.
>>> They
>>> overlap).
>> On x86 with HIGHMEM there is no dma32 zone. Why do we need one on
>> x86_64? Can we make x86_64 more like HIGHMEM instead?
>>
>> Regards,
>> Felix
>>
> IIRC with x86, the kernel zone is always smaller than any dma32 zone,
> so we'd always exhaust the kernel zone before dma32 anyway.
>
> Not sure why we have dma32 on x86 without highmem, though. sounds
> superflous but harmless.

Well DMA32 denotes memory which is accessible by devices who can only do 
32bit addressing. And IIRC we can actually do DMA32 to highmem since 
something like 2.4.*.

Because of this it is actually irrelevant if you have highmem or not, 
what matters for DMA32 is if you have an IOMMU or not.

So even on x86_64 you actually do need the DMA32 zone if you don't have 
an IOMMU which remaps all memory for devices which can't directly 
address it.

Regards,
Christian.

>
> /Thomas
>
>

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

Re: [PATCH v2 1/2] drm: move i915_kick_out_vgacon to drm_fb_helper

[Gerd Hoffmann]

On Thu, Feb 21, 2019 at 03:08:39PM +0200, Jani Nikula wrote:
> On Thu, 21 Feb 2019, Gerd Hoffmann  wrote:
> > It'll be useful for other drivers too, so move it to drm_fb_helper.c
> > (and rename it of course).  Also add docs.
> >
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  include/drm/drm_fb_helper.h |  2 ++
> >  drivers/gpu/drm/drm_fb_helper.c | 39 
> > +++
> >  drivers/gpu/drm/i915/i915_drv.c | 35 +--
> >  3 files changed, 42 insertions(+), 34 deletions(-)
> >
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index bb9acea613..a401ba47ad 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -649,4 +649,6 @@ 
> > drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
> >  #endif
> >  }
> >  
> > +int drm_fb_helper_kick_out_vgacon(void);
> > +
> >  #endif
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 0e9349ff2d..a2d7e5bc51 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -35,6 +35,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -3353,3 +3354,41 @@ int __init drm_fb_helper_modinit(void)
> > return 0;
> >  }
> >  EXPORT_SYMBOL(drm_fb_helper_modinit);
> > +
> > +/**
> > + * drm_fb_helper_kick_out_vgacon - deactivate vgacon driver.
> > + *
> > + * Deactivate vgacon driver so it stops accessing vga io ports.
> > + * Should be called after
> > + * drm_fb_helper_remove_conflicting_pci_framebuffers().
> > + *
> > + * Returns:
> > + * Zero on success or negative error code on failure.
> > + */
> > +int drm_fb_helper_kick_out_vgacon(void)
> > +{
> > +#if !defined(CONFIG_VGA_CONSOLE)
> > +return 0;
> > +#elif !defined(CONFIG_DUMMY_CONSOLE)
> > +return -ENODEV;
> > +#else
> 
> Please retain the original way of keeping conditional compilation
> outside of functions.

Care to explain why that is better?

thanks,
  Gerd

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

RE: [PATCH v14 22/33] misc/mei/hdcp: Verify Receiver Cert and prepare km

[Winkler, Tomas]

> Requests for verification for receiver certification and also the preparation 
> for
> next AKE auth message with km.
> 
> On Success ME FW validate the HDCP2.2 receivers certificate and do the
> revocation check on the receiver ID. AKE_Stored_Km will be prepared if the
> receiver is already paired, else AKE_No_Stored_Km will be prepared.
> 
> Here AKE_Stored_Km and AKE_No_Stored_Km are HDCP2.2 protocol msgs.
> 
> v2: Rebased.
> v3:
>   cldev is passed as first parameter [Tomas]
>   Redundant comments and cast are removed [Tomas]
> v4:
>   %zd is used for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc Addition. [Tomas]
>   memcpy for const length.
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   Fixed the conversion of u8 to bool [Tomas]
>   K-Doc fix [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM
> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 83
> +++-
>  1 file changed, 82 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 952bae79dd02..922c6a76bb9f 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -102,11 +102,92 @@ mei_hdcp_initiate_session(struct device *dev, struct
> hdcp_port_data *data,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_verify_receiver_cert_prepare_km() - Verify the Receiver
> +Certificate
> + * AKE_Send_Cert and prepare AKE_Stored_Km/AKE_No_Stored_Km
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @rx_cert: AKE_Send_Cert for verification
> + * @km_stored: Pairing status flag output
> + * @ek_pub_km: AKE_Stored_Km/AKE_No_Stored_Km output msg
> + * @msg_sz : size of AKE_X_Km output msg
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
> +  struct hdcp_port_data *data,
> +  struct hdcp2_ake_send_cert *rx_cert,
> +  bool *km_stored,
> +  struct hdcp2_ake_no_stored_km
> + *ek_pub_km,
> +  size_t *msg_sz)
> +{
> + struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
> + struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + verify_rxcert_in.header.api_version = HDCP_API_VERSION;
> + verify_rxcert_in.header.command_id =
> WIRED_VERIFY_RECEIVER_CERT;
> + verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
> + verify_rxcert_in.header.buffer_len =
> +
>   WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
> +
> + verify_rxcert_in.port.integrated_port_type = data->port_type;
> + verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
> +
> + verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> + memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
> + memcpy(verify_rxcert_in.rx_caps, rx_cert->rx_caps,
> +HDCP_2_2_RXCAPS_LEN);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_rxcert_in,
> +   sizeof(verify_rxcert_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed: %zd\n", byte);
> + return byte;
> + }
> +
> + byte = mei_cldev_recv(cldev, (u8 *)_rxcert_out,
> +   sizeof(verify_rxcert_out));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_recv failed: %zd\n", byte);
> + return byte;
> + }
> +
> + if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
> + dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
> + WIRED_VERIFY_RECEIVER_CERT,
> + verify_rxcert_out.header.status);
> + return -EIO;
> + }
> +
> + *km_stored = !!verify_rxcert_out.km_stored;
> + if (verify_rxcert_out.km_stored) {
> + ek_pub_km->msg_id = HDCP_2_2_AKE_STORED_KM;
> + *msg_sz = sizeof(struct hdcp2_ake_stored_km);
> + } else {
> + ek_pub_km->msg_id = HDCP_2_2_AKE_NO_STORED_KM;
> + *msg_sz = sizeof(struct hdcp2_ake_no_stored_km);
> + }
> +
> + memcpy(ek_pub_km->e_kpub_km, _rxcert_out.ekm_buff,
> +sizeof(verify_rxcert_out.ekm_buff));
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops 

Re: [PATCH v2 1/2] drm: move i915_kick_out_vgacon to drm_fb_helper

[Gerd Hoffmann]

> > +int drm_fb_helper_kick_out_vgacon(void);
> > +
> 
> Don't you need a dummy version as well for this one, like how it's done
> for the other functions, to cover the case when DRM_FBDEV_EMULATION is
> not selected?

Good question.

I guess it makes sense to kick out vgacon even with CONFIG_FB=n.

But when integrating this into
drm_fb_helper_remove_conflicting_pci_framebuffers() as suggested by
Daniel this isn't going to fly ...

cheers,
  Gerd

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

Re: [PATCH v5 01/19] Revert "[media] v4l: vsp1: Supply frames to the DU continuously"

[Kieran Bingham]

Hi Laurent,

On 21/02/2019 10:31, Laurent Pinchart wrote:
> From: Kieran Bingham 
> 
> This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to
> the DU continuously")
> 
> The DU output mode does not rely on frames being supplied on the WPF as
> its pipeline is supplied from DRM. For the upcoming WPF writeback
> functionality, we will choose to enable writeback mode if there is an
> output buffer, or disable it (leaving the existing display pipeline
> unharmed) otherwise.
> 
> Signed-off-by: Kieran Bingham 

Don't forget to add your SoB or such here :)
--
Regards

Kieran



> ---
>  drivers/media/platform/vsp1/vsp1_video.c | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
> b/drivers/media/platform/vsp1/vsp1_video.c
> index 7ceaf3222145..328d686189be 100644
> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c
> @@ -307,11 +307,6 @@ static int vsp1_video_pipeline_setup_partitions(struct 
> vsp1_pipeline *pipe)
>   * This function completes the current buffer by filling its sequence number,
>   * time stamp and payload size, and hands it back to the videobuf core.
>   *
> - * When operating in DU output mode (deep pipeline to the DU through the 
> LIF),
> - * the VSP1 needs to constantly supply frames to the display. In that case, 
> if
> - * no other buffer is queued, reuse the one that has just been processed 
> instead
> - * of handing it back to the videobuf core.
> - *
>   * Return the next queued buffer or NULL if the queue is empty.
>   */
>  static struct vsp1_vb2_buffer *
> @@ -333,12 +328,6 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
>   done = list_first_entry(>irqqueue,
>   struct vsp1_vb2_buffer, queue);
>  
> - /* In DU output mode reuse the buffer if the list is singular. */
> - if (pipe->lif && list_is_singular(>irqqueue)) {
> - spin_unlock_irqrestore(>irqlock, flags);
> - return done;
> - }
> -
>   list_del(>queue);
>  
>   if (!list_empty(>irqqueue))
> 

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

Re: [PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list

[Kieran Bingham]

Hi Laurent,

On 21/02/2019 10:32, Laurent Pinchart wrote:
> One-shot entries are used as an alternative to committing a complete new
> display list when a couple of registers need to be written for one frame
> and then reset to another value for all subsequent frames. This will be
> used to implement writeback support that will need to enable writeback
> for the duration of a single frame.
> 
> Signed-off-by: Laurent Pinchart 

Thanks for adding the documentation, and the new name _oneshot() sounds
fine to me.


Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/vsp1/vsp1_dl.c | 78 +++
>  drivers/media/platform/vsp1/vsp1_dl.h |  3 ++
>  2 files changed, 81 insertions(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
> b/drivers/media/platform/vsp1/vsp1_dl.c
> index 886b3a69d329..7b4d252bfde7 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -115,6 +115,12 @@ struct vsp1_dl_body {
>  
>   unsigned int num_entries;
>   unsigned int max_entries;
> +
> + unsigned int num_patches;
> + struct {
> + struct vsp1_dl_entry *entry;
> + u32 data;
> + } patches[2];
>  };
>  
>  /**
> @@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
>   return;
>  
>   dlb->num_entries = 0;
> + dlb->num_patches = 0;
>  
>   spin_lock_irqsave(>pool->lock, flags);
>   list_add_tail(>free, >pool->free);
> @@ -388,6 +395,47 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 
> reg, u32 data)
>   dlb->num_entries++;
>  }
>  
> +/**
> + * vsp1_dl_body_write_oneshot - Write a register to a display list body for a
> + *   single frame
> + * @dlb: The body
> + * @reg: The register address
> + * @value: The register value
> + * @reset_value: The value to reset the register to at the next vblank
> + *
> + * Display lists in continuous mode are re-used by the hardware for 
> successive
> + * frames until a new display list is committed. Changing the VSP 
> configuration
> + * normally requires creating and committing a new display list. This 
> function
> + * offers an alternative race-free way by writing a @value to the @register 
> in
> + * the display list body for a single frame, specifying in @reset_value the
> + * value to reset the register to one vblank after the display list is
> + * committed.
> + *
> + * The maximum number of one-shot entries is limited to 2 per display list 
> body,
> + * and one-shot entries are counted in the total number of entries specified
> + * when the body is allocated by vsp1_dl_body_alloc().
> + */
> +void vsp1_dl_body_write_oneshot(struct vsp1_dl_body *dlb, u32 reg, u32 value,
> + u32 reset_value)
> +{
> + if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
> +   "DLB size exceeded (max %u)", dlb->max_entries))
> + return;
> +
> + if (WARN_ONCE(dlb->num_patches >= ARRAY_SIZE(dlb->patches),
> +   "DLB patches size exceeded (max %zu)",
> +   ARRAY_SIZE(dlb->patches)))
> + return;
> +
> + dlb->patches[dlb->num_patches].entry = >entries[dlb->num_entries];
> + dlb->patches[dlb->num_patches].data = reset_value;
> + dlb->num_patches++;
> +
> + dlb->entries[dlb->num_entries].addr = reg;
> + dlb->entries[dlb->num_entries].data = value;
> + dlb->num_entries++;
> +}
> +
>  /* 
> -
>   * Display List Extended Command Management
>   */
> @@ -652,6 +700,7 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
>* has at least one body, thus we reinitialise the entries list.
>*/
>   dl->body0->num_entries = 0;
> + dl->body0->num_patches = 0;
>  
>   list_add_tail(>list, >dlm->free);
>  }
> @@ -930,6 +979,35 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, 
> unsigned int dl_flags)
>   * Display List Manager
>   */
>  
> +/**
> + * vsp1_dlm_irq_display_start - Display list handler for the display start
> + *   interrupt
> + * @dlm: the display list manager
> + *
> + * Apply all one-shot patches registered for the active display list.
> + */
> +void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm)
> +{
> + struct vsp1_dl_body *dlb;
> + struct vsp1_dl_list *dl;
> + unsigned int i;
> +
> + spin_lock(>lock);
> +
> + dl = dlm->active;
> + if (!dl)
> + goto done;
> +
> + list_for_each_entry(dlb, >bodies, list) {
> + for (i = 0; i < dlb->num_patches; ++i)
> + dlb->patches[i].entry->data = dlb->patches[i].data;
> + dlb->num_patches = 0;
> + }
> +
> +done:
> + spin_unlock(>lock);
> +}
> +
>  /**
>   * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
>   * @dlm: the display list manager
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
> 

RE: [PATCH v14 26/33] misc/mei/hdcp: Verify L_prime

[Winkler, Tomas]

> 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]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Style fixed [Uma]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc addition. [Tomas]
>   memcpy for const length.
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM
> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 60
> +++-
>  1 file changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 29ef61fd21d2..869a6f22f68d 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -351,6 +351,64 @@ mei_hdcp_initiate_locality_check(struct device *dev,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_verify_lprime() - Verify lprime.
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @rx_lprime: LC_Send_L_prime msg for ME FW verification
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_verify_lprime(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !rx_lprime)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> +
> + memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
> +HDCP_2_2_L_PRIME_LEN);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_lprime_in,
> +   sizeof(verify_lprime_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
> @@ -360,7 +418,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .verify_hprime = mei_hdcp_verify_hprime,
>   .store_pairing_info = mei_hdcp_store_pairing_info,
>   .initiate_locality_check = mei_hdcp_initiate_locality_check,
> - .verify_lprime = NULL,
> + .verify_lprime = mei_hdcp_verify_lprime,
>   .get_session_key = NULL,
>   .repeater_check_flow_prepare_ack = NULL,
>   .verify_mprime = NULL,
> --
> 2.7.4

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

RE: [PATCH v14 19/33] misc/mei/hdcp: Client driver for HDCP application

[Winkler, Tomas]

> 
> ME FW contributes a vital role in HDCP2.2 authentication.
> HDCP2.2 driver needs to communicate to ME FW for each step of the
> HDCP2.2 authentication.
> 
> ME FW prepare and HDCP2.2 authentication  parameters and encrypt them as
> per spec. With such parameter Driver prepares HDCP2.2 auth messages and
> communicate with HDCP2.2 sink.
> 
> Similarly HDCP2.2 sink's response is shared with ME FW for decrypt and
> verification.
> 
> Once All the steps of HDCP2.2 authentications are complete on driver's request
> ME FW will configure the port as authenticated and supply the HDCP keys to
> the Gen HW for encryption.
> 
> Only after this stage HDCP2.2 driver can start the HDCP2.2 encryption for a
> port.
> 
> ME FW is interfaced to kernel through MEI Bus Driver. To obtain the
> HDCP2.2 services from the ME FW through MEI Bus driver MEI Client Driver is
> developed.
> 
> v2:
>   hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas]
> v3:
>   Squashed the Kbuild support [Tomas]
>   UUID renamed and Module License is modified [Tomas]
>   drv_data is set to null at remove [Tomas]
> v4:
>   Module name is changed to "MEI HDCP"
>   I915 Selects the MEI_HDCP
> v5:
>   Remove redundant text from the License header
>   Fix malformed licence
>   Removed the drv_data resetting.
> v6:
>   K-Doc addition. [Tomas]
> v7:
>   %s/UUID_LE/GUID_INIT [Tomas]
>   GPL Ver is 2.0 than 2.0+ [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Signed-off-by: Tomas Winkler 
> Acked-by: Tomas Winkler 
> ---
>  drivers/misc/mei/Kconfig |  7 +
>  drivers/misc/mei/Makefile|  2 ++
>  drivers/misc/mei/hdcp/Makefile   |  7 +
>  drivers/misc/mei/hdcp/mei_hdcp.c | 64
> 
>  4 files changed, 80 insertions(+)
>  create mode 100644 drivers/misc/mei/hdcp/Makefile  create mode 100644
> drivers/misc/mei/hdcp/mei_hdcp.c
> 
> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index
> c49e1d2269af..64a7b3483895 100644
> --- a/drivers/misc/mei/Kconfig
> +++ b/drivers/misc/mei/Kconfig
> @@ -43,3 +43,10 @@ config INTEL_MEI_TXE
> 
> Supported SoCs:
> Intel Bay Trail
> +
> +config INTEL_MEI_HDCP
> + tristate "Intel HDCP2.2 services of ME Interface"
> + select INTEL_MEI_ME
> + depends on DRM_I915
> + help
> +   MEI Support for HDCP2.2 Services on Intel platforms.

Usually we need around 4 lines of doc, 
When this should be selected? 


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

Re: [PATCH] drm: Fix writeback_job leak when state is check only or check failed

[Maarten Lankhorst]

Hey

Op 21-02-2019 om 12:14 schreef james qian wang (Arm Technology China):
> The writeback job will not be added to writeback queue if the state is
> check only or check failed, to avoid leak, need to cleanup writeback job
> in connector_destroy_state if the job existed.
>
> Signed-off-by: James Qian Wang (Arm Technology China) 
> 

Is writeback_job in the conn_state set to null somewhere? I'm worried we might 
end up freeing writeback_job twice on success.

~Maarten

>  drivers/gpu/drm/drm_atomic_state_helper.c |  4 
>  drivers/gpu/drm/drm_writeback.c   | 21 ++---
>  2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 4985384e51f6..6a8e414233de 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -407,6 +408,9 @@ 
> EXPORT_SYMBOL(drm_atomic_helper_connector_duplicate_state);
>  void
>  __drm_atomic_helper_connector_destroy_state(struct drm_connector_state 
> *state)
>  {
> + if (state->writeback_job)
> + drm_writeback_cleanup_job(state->writeback_job);
> +
>   if (state->crtc)
>   drm_connector_put(state->connector);
>  
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index c20e6fe00cb3..486121150eaa 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -268,6 +268,22 @@ void drm_writeback_queue_job(struct 
> drm_writeback_connector *wb_connector,
>  }
>  EXPORT_SYMBOL(drm_writeback_queue_job);
>  
> +/**
> + * drm_writeback_cleanup_job - cleanup a writeback job
> + * @job: The job to cleanup
> + */
> +void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> +{
> + if (job->fb)
> + drm_framebuffer_put(job->fb);
> +
> + if (job->out_fence)
> + dma_fence_put(job->out_fence);
> +
> + kfree(job);
> +}
> +EXPORT_SYMBOL(drm_writeback_cleanup_job);
> +
>  /*
>   * @cleanup_work: deferred cleanup of a writeback job
>   *
> @@ -280,11 +296,9 @@ static void cleanup_work(struct work_struct *work)
>   struct drm_writeback_job *job = container_of(work,
>struct drm_writeback_job,
>cleanup_work);
> - drm_framebuffer_put(job->fb);
> - kfree(job);
> + drm_writeback_cleanup_job(job);
>  }
>  
> -
>  /**
>   * drm_writeback_signal_completion - Signal the completion of a writeback job
>   * @wb_connector: The writeback connector whose job is complete
> @@ -319,6 +333,7 @@ drm_writeback_signal_completion(struct 
> drm_writeback_connector *wb_connector,
>   dma_fence_set_error(job->out_fence, status);
>   dma_fence_signal(job->out_fence);
>   dma_fence_put(job->out_fence);
> + job->out_fence = NULL;
>   }
>   }
>   spin_unlock_irqrestore(_connector->job_lock, flags);


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

RE: [PATCH v14 31/33] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session

[Winkler, Tomas]

> 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]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Style and typos fixed [Uma]
> v5:
>   Extra line is removed.
> v6:
>   Collected the Rb-ed by.
>   Rebased.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc addition.[Tomas]
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM
> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 55
> +++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index d8e04e0621a1..2afc7d31dacc 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -658,6 +658,59 @@ static int mei_hdcp_enable_authentication(struct
> device *dev,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_close_session() - Close the Wired HDCP Tx session of ME FW per
> port.
> + * This also disables the authenticated state of the port.
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_close_session(struct device *dev, struct hdcp_port_data *data)
> +{
> + struct wired_cmd_close_session_in session_close_in = { { 0 } };
> + struct wired_cmd_close_session_out session_close_out = { { 0 } };
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_close_in,
> +   sizeof(session_close_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
> @@ -673,7 +726,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   mei_hdcp_repeater_check_flow_prepare_ack,
>   .verify_mprime = mei_hdcp_verify_mprime,
>   .enable_hdcp_authentication = mei_hdcp_enable_authentication,
> - .close_hdcp_session = NULL,
> + .close_hdcp_session = mei_hdcp_close_session,
>  };
> 
>  static int mei_hdcp_probe(struct mei_cl_device *cldev,
> --
> 2.7.4

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

RE: [PATCH v14 30/33] misc/mei/hdcp: Enabling the HDCP authentication

[Winkler, Tomas]

> 
> Request to ME to configure a port as authenticated.
> 
> On Success, ME FW will mark the port as authenticated and provides HDCP
> cipher with the encryption keys.
> 
> Enabling the Authentication can be requested once all stages of
> HDCP2.2 authentication is completed by interacting with ME FW.
> 
> 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]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Style and typos fixed [Uma]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebased.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc addition. [Tomas]
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM

> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 55
> +++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 721376fc9bf1..d8e04e0621a1 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -605,6 +605,59 @@ static int mei_hdcp_verify_mprime(struct device
> *dev,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_enable_authentication() - Mark a port as authenticated
> + * through ME FW
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int mei_hdcp_enable_authentication(struct device *dev,
> +   struct hdcp_port_data *data)
> +{
> + struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
> + struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> + enable_auth_in.stream_type = data->streams[0].stream_type;
> +
> + byte = mei_cldev_send(cldev, (u8 *)_auth_in,
> +   sizeof(enable_auth_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
> @@ -619,7 +672,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .repeater_check_flow_prepare_ack =
>   mei_hdcp_repeater_check_flow_prepare_ack,
>   .verify_mprime = mei_hdcp_verify_mprime,
> - .enable_hdcp_authentication = NULL,
> + .enable_hdcp_authentication = mei_hdcp_enable_authentication,
>   .close_hdcp_session = NULL,
>  };
> 
> --
> 2.7.4

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

Re: [PATCH v2 1/2] drm: move i915_kick_out_vgacon to drm_fb_helper

[Jani Nikula]

On Thu, 21 Feb 2019, Gerd Hoffmann  wrote:
> On Thu, Feb 21, 2019 at 03:08:39PM +0200, Jani Nikula wrote:
>> On Thu, 21 Feb 2019, Gerd Hoffmann  wrote:
>> > It'll be useful for other drivers too, so move it to drm_fb_helper.c
>> > (and rename it of course).  Also add docs.
>> >
>> > Signed-off-by: Gerd Hoffmann 
>> > ---
>> >  include/drm/drm_fb_helper.h |  2 ++
>> >  drivers/gpu/drm/drm_fb_helper.c | 39 
>> > +++
>> >  drivers/gpu/drm/i915/i915_drv.c | 35 +--
>> >  3 files changed, 42 insertions(+), 34 deletions(-)
>> >
>> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> > index bb9acea613..a401ba47ad 100644
>> > --- a/include/drm/drm_fb_helper.h
>> > +++ b/include/drm/drm_fb_helper.h
>> > @@ -649,4 +649,6 @@ 
>> > drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
>> >  #endif
>> >  }
>> >  
>> > +int drm_fb_helper_kick_out_vgacon(void);
>> > +
>> >  #endif
>> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> > b/drivers/gpu/drm/drm_fb_helper.c
>> > index 0e9349ff2d..a2d7e5bc51 100644
>> > --- a/drivers/gpu/drm/drm_fb_helper.c
>> > +++ b/drivers/gpu/drm/drm_fb_helper.c
>> > @@ -35,6 +35,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > @@ -3353,3 +3354,41 @@ int __init drm_fb_helper_modinit(void)
>> >return 0;
>> >  }
>> >  EXPORT_SYMBOL(drm_fb_helper_modinit);
>> > +
>> > +/**
>> > + * drm_fb_helper_kick_out_vgacon - deactivate vgacon driver.
>> > + *
>> > + * Deactivate vgacon driver so it stops accessing vga io ports.
>> > + * Should be called after
>> > + * drm_fb_helper_remove_conflicting_pci_framebuffers().
>> > + *
>> > + * Returns:
>> > + * Zero on success or negative error code on failure.
>> > + */
>> > +int drm_fb_helper_kick_out_vgacon(void)
>> > +{
>> > +#if !defined(CONFIG_VGA_CONSOLE)
>> > +return 0;
>> > +#elif !defined(CONFIG_DUMMY_CONSOLE)
>> > +return -ENODEV;
>> > +#else
>> 
>> Please retain the original way of keeping conditional compilation
>> outside of functions.
>
> Care to explain why that is better?

Prevalent and documented [1] kernel coding style. It's easier to see
what happens in each branch, and the compiler throws the alternatives
away anyway.

Patches that do code movement should focus on code movement. Any
additional changes should be separate, and justified separately. The
function rename and documentation are of course okay, and they're
mentioned in the commit message as they should.

BR,
Jani.


[1] Documentation/process/coding-style.rst

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

RE: [PATCH v14 23/33] misc/mei/hdcp: Verify H_prime

[Winkler, Tomas]

> Requests for the verification of AKE_Send_H_prime.
> 
> ME will calculate the H and comparing it with received H_Prime.
> The result will be returned as status.
> 
> 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]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Styles and typos fixed [Uma]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc Addition [Tomas]
>   memcpy for const length.
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM

> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 58
> +++-
>  1 file changed, 57 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 922c6a76bb9f..0a4087a2efd5 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -182,13 +182,69 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct
> device *dev,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @rx_hprime: AKE_Send_H_prime msg for ME FW verification
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_verify_hprime(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !rx_hprime)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> +
> + memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> +HDCP_2_2_H_PRIME_LEN);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_hprime_in,
> +   sizeof(send_hprime_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>   .initiate_hdcp2_session = mei_hdcp_initiate_session,
>   .verify_receiver_cert_prepare_km =
>   mei_hdcp_verify_receiver_cert_prepare_km,
> - .verify_hprime = NULL,
> + .verify_hprime = mei_hdcp_verify_hprime,
>   .store_pairing_info = NULL,
>   .initiate_locality_check = NULL,
>   .verify_lprime = NULL,
> --
> 2.7.4

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

Re: [PATCH v4 0/7] VSP1: Display writeback support

[Daniel Vetter]

On Thu, Feb 21, 2019 at 12:19:13PM +, Brian Starkey wrote:
> Hi Laurent,
> 
> On Thu, Feb 21, 2019 at 12:02:57PM +0200, Laurent Pinchart wrote:
> > Hi Brian,
> > 
> > On Thu, Feb 21, 2019 at 09:50:19AM +, Brian Starkey wrote:
> > > On Thu, Feb 21, 2019 at 10:23:17AM +0200, Laurent Pinchart wrote:
> > > > On Mon, Feb 18, 2019 at 12:22:58PM +, Brian Starkey wrote:
> > > >> On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> > > >>> Hello,
> > > >>> 
> > > >>> This patch series implements display writeback support for the R-Car
> > > >>> Gen3 platforms in the VSP1 driver.
> > > >>> 
> > > >>> DRM/KMS provides a writeback API through a special type of writeback
> > > >>> connectors. This series takes a different approach by exposing 
> > > >>> writeback
> > > >>> as a V4L2 device. While there is nothing fundamentally wrong with
> > > >>> writeback connectors, display for R-Car Gen3 platforms relies on the
> > > >>> VSP1 driver behind the scene, which already implements V4L2 support.
> > > >>> Enabling writeback through V4L2 is thus significantly easier in this
> > > >>> case.
> > > >> 
> > > >> How does this look to an application? (I'm entirely ignorant about
> > > >> R-Car). They are interacting with the DRM device, and then need to
> > > >> open and configure a v4l2 device to get the writeback? Can the process
> > > >> which isn't controlling the DRM device independently capture the
> > > >> screen output?
> > > >> 
> > > >> I didn't see any major complication to implementing this as a
> > > >> writeback connector. If you want/need to use the vb2_queue, couldn't
> > > >> you just do that entirely from within the kernel?
> > > >> 
> > > >> Honestly (predictably?), to me it seems like a bad idea to introduce a
> > > >> second, non-compatible interface for display writeback. Any
> > > >> application interested in display writeback (e.g. compositors) will
> > > >> need to implement both in order to support all HW. drm_hwcomposer
> > > >> already supports writeback via DRM writeback connectors.
> > > >> 
> > > >> While I can see the advantages of having writeback exposed via v4l2
> > > >> for streaming use-cases, I think it would be better to have it done in
> > > >> such a way that it works for all writeback connectors, rather than
> > > >> being VSP1-specific. That would allow any application to choose
> > > >> whichever method is most appropriate for their use-case, without
> > > >> limiting themselves to a subset of hardware.
> > > > 
> > > > So I gave writeback connectors a go, and it wasn't very pretty.
> > > 
> > > Sorry you didn't have a good time :-(
> > 
> > No worries. That was to be expected with such young code :-)
> > 
> > > > There writeback support in the DRM core leaks jobs,
> > > 
> > > Is this the cleanup on check fail, or something else?
> > 
> > Yes, that's the problem. I have patches for it that I will post soon.
> > 
> > > One possible pitfall is that you must set the job in the connector
> > > state to NULL after you call drm_writeback_queue_job(). The API there
> > > could easily be changed to pass in the connector_state and clear it in
> > > drm_writeback_queue_job() instead of relying on drivers to do it.
> > 
> > I also have a patch for that :-)
> > 
> > > > and is missing support for
> > > > the equivalent of .prepare_fb()/.cleanup_fb(), which requires per-job
> > > > driver-specific data. I'm working on these issues and will submit
> > > > patches.
> > > 
> > > Hm, yes that didn't occur to me; we don't have a prepare_fb callback.
> > > 
> > > > In the meantime, I need to test my implementation, so I need a command
> > > > line application that will let me exercise the API. I assume you've
> > > > tested your code, haven't you ? :-) Could you tell me how I can test
> > > > writeback ?
> > > 
> > > Indeed, there's igts on the list which I wrote and tested:
> > > 
> > > https://patchwork.kernel.org/patch/10764975/
> > 
> > Will you get these merged ? Pushing everybody to use the writeback
> > connector API without any test is mainline isn't nice, it almost makes
> > me want to go back to V4L2.
> 
> I wasn't trying to be pushy - I only shared my opinion that I didn't
> think it was a good idea to introduce a second display writeback API,
> when we already have one. You're entirely entitled to ignore my
> opinion.
> 
> The tests have been available since the very early versions of the
> writeback series. I don't know what's blocking them from merging, I
> haven't been tracking it very closely.
> 
> If you'd be happy to provide your review and test on them, that may
> help the process along?
> 
> > 
> > igt test cases are nice to have, but what I need now is a tool to
> > execise the API manually, similar to modetest, with command line
> > parameters to configure the device, and the ability to capture frames to
> > disk using writeback. How did you perform such tests when you developed
> > writeback support ?
> > 
> 
> I used a pre-existing internal tool which 

[Bug 109714] Unable to Compile R200 driver: "Options 'r200' are not allowed..."

[bugzilla-daemon]

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

Adam Jackson  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #1 from Adam Jackson  ---
(In reply to moriel5 from comment #0)

> When attempting to compile Mesa with the R200 driver, on Solus, Meson spits
> out the following error: ERROR:  Options "r200" are not in allowed choices:
> ", auto, kmsro, radeonsi, r300, r600, nouveau, freedreno, swrast, v3d, vc4,
> etnaviv, tegra, i915, svga, virgl, swr, panfrost".

That's the list of gallium drivers. r200 is not a gallium driver, it's a
"classic" DRI driver:

datura:~/git/mesa% meson configure build | grep r200
  dri-drivers[auto][, auto, i915, i965, r100, r200, nouveau,
swrast]
List of dri drivers to build. If this is set to auto all drivers applicable
to the target OS/architecture will be built  

You want 'meson configure build -Ddri-drivers=r200'.

-- 
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 v14 29/33] misc/mei/hdcp: Verify M_prime

[Winkler, Tomas]

> 
> 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]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   endianness conversion func is moved to drm_hdcp.h [Uma]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc addition. [Tomas]
>   drm_hdcp2_u32_to_seq_num() is used for u32 to seq_num.
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
> ---


> +
> + verify_mprime_in.k = __swab16(data->k);
> +
 cpu_to_be16(data->k)

> + byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
> +   sizeof(verify_mprime_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> + return byte;

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

Re: [PATCH v4 0/7] VSP1: Display writeback support

[Brian Starkey]

On Thu, Feb 21, 2019 at 02:23:10PM +0200, Laurent Pinchart wrote:
> On Thu, Feb 21, 2019 at 12:19:13PM +, Brian Starkey wrote:

[snip]

> > 
> > I used a pre-existing internal tool which does exactly that.
> 
> Any hope of sharing the sources ?
> 

Not in a timescale or form which would be useful to you. I'm convinced
people only ask questions like this to make us look like Bad Guys.

Opening everything up is a process, and it's going to take us time.
Sure we could be doing better, but I also think there's a lot of
people who do worse.

> > I appreciate that we don't have upstream tooling for writeback. As you
> > say, it's a young API (well, not by date, but certainly by usage).
> > 
> > I also do appreciate you taking the time to consider it, identifying
> > issues which we did not, and for fixing them. The only way it stops
> > being a young API, with bugs and no tooling, is if people adopt it.
> 
> If the developers who initially pushed the API upstream without an
> open-source test tool could spend a bit of time on this issue, I'm sure
> it would help too :-)
> 

No one suggested a test test tool before. In fact, the DRM subsystem
explicitly requires that features land with something that isn't only
a test tool, hence why we did drm_hwcomposer.

That said, yes, we should be trying harder to get the igts landed. I
personally think igts are far more useful than a random example C
file, but I guess opinions differ.

Thanks,
-Brian

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

RE: [PATCH v14 25/33] misc/mei/hdcp: Initiate Locality check

[Winkler, Tomas]

> 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]
> v4:
>   %zd used for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Style fixed [Uma]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc addition. [Tomas]
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM
> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 57
> +++-
>  1 file changed, 56 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 1f5514244716..29ef61fd21d2 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -296,6 +296,61 @@ mei_hdcp_store_pairing_info(struct device *dev,
> struct hdcp_port_data *data,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_initiate_locality_check() - Prepare LC_Init
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @lc_init_data: LC_Init msg output
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_initiate_locality_check(struct device *dev,
> +  struct hdcp_port_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 mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !lc_init_data)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + 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);
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
> @@ -304,7 +359,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   mei_hdcp_verify_receiver_cert_prepare_km,
>   .verify_hprime = mei_hdcp_verify_hprime,
>   .store_pairing_info = mei_hdcp_store_pairing_info,
> - .initiate_locality_check = NULL,
> + .initiate_locality_check = mei_hdcp_initiate_locality_check,
>   .verify_lprime = NULL,
>   .get_session_key = NULL,
>   .repeater_check_flow_prepare_ack = NULL,
> --
> 2.7.4

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

Re: [PATCH v2 1/2] drm: move i915_kick_out_vgacon to drm_fb_helper

[Noralf Trønnes]

Den 21.02.2019 12.35, skrev Gerd Hoffmann:
> It'll be useful for other drivers too, so move it to drm_fb_helper.c
> (and rename it of course).  Also add docs.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_fb_helper.h |  2 ++
>  drivers/gpu/drm/drm_fb_helper.c | 39 +++
>  drivers/gpu/drm/i915/i915_drv.c | 35 +--
>  3 files changed, 42 insertions(+), 34 deletions(-)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index bb9acea613..a401ba47ad 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -649,4 +649,6 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct 
> pci_dev *pdev,
>  #endif
>  }
>  
> +int drm_fb_helper_kick_out_vgacon(void);
> +

Don't you need a dummy version as well for this one, like how it's done
for the other functions, to cover the case when DRM_FBDEV_EMULATION is
not selected?

Noralf.

>  #endif
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0e9349ff2d..a2d7e5bc51 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3353,3 +3354,41 @@ int __init drm_fb_helper_modinit(void)
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_fb_helper_modinit);
> +
> +/**
> + * drm_fb_helper_kick_out_vgacon - deactivate vgacon driver.
> + *
> + * Deactivate vgacon driver so it stops accessing vga io ports.
> + * Should be called after
> + * drm_fb_helper_remove_conflicting_pci_framebuffers().
> + *
> + * Returns:
> + * Zero on success or negative error code on failure.
> + */
> +int drm_fb_helper_kick_out_vgacon(void)
> +{
> +#if !defined(CONFIG_VGA_CONSOLE)
> +return 0;
> +#elif !defined(CONFIG_DUMMY_CONSOLE)
> +return -ENODEV;
> +#else
> +int ret = 0;
> +
> +DRM_INFO("Replacing VGA console driver\n");
> +
> +console_lock();
> +if (con_is_bound(_con))
> +ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 
> 1, 1);
> +if (ret == 0) {
> +ret = do_unregister_con_driver(_con);
> +
> +/* Ignore "already unregistered". */
> +if (ret == -ENODEV)
> +ret = 0;
> +}
> +console_unlock();
> +
> +return ret;
> +#endif
> +}
> +EXPORT_SYMBOL(drm_fb_helper_kick_out_vgacon);
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6630212f2f..3edd4d7d55 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -757,39 +757,6 @@ static int i915_kick_out_firmware_fb(struct 
> drm_i915_private *dev_priv)
>   return ret;
>  }
>  
> -#if !defined(CONFIG_VGA_CONSOLE)
> -static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> -{
> - return 0;
> -}
> -#elif !defined(CONFIG_DUMMY_CONSOLE)
> -static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> -{
> - return -ENODEV;
> -}
> -#else
> -static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> -{
> - int ret = 0;
> -
> - DRM_INFO("Replacing VGA console driver\n");
> -
> - console_lock();
> - if (con_is_bound(_con))
> - ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 
> 1);
> - if (ret == 0) {
> - ret = do_unregister_con_driver(_con);
> -
> - /* Ignore "already unregistered". */
> - if (ret == -ENODEV)
> - ret = 0;
> - }
> - console_unlock();
> -
> - return ret;
> -}
> -#endif
> -
>  static void intel_init_dpio(struct drm_i915_private *dev_priv)
>  {
>   /*
> @@ -1420,7 +1387,7 @@ static int i915_driver_init_hw(struct drm_i915_private 
> *dev_priv)
>   goto err_ggtt;
>   }
>  
> - ret = i915_kick_out_vgacon(dev_priv);
> + ret = drm_fb_helper_kick_out_vgacon();
>   if (ret) {
>   DRM_ERROR("failed to remove conflicting VGA console\n");
>   goto err_ggtt;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v14 28/33] misc/mei/hdcp: Repeater topology verification and ack

[Winkler, Tomas]

> ack
> 
> Request ME to verify the downstream topology information received.
> 
> 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]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Style and typos fixed [Uma]
> v5: Rebased.
> v6: Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc addition. [Tomas]
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 

LGTM

> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 77
> +++-
>  1 file changed, 76 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index fe5070f901e8..c06a9805ac85 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -466,6 +466,80 @@ static int mei_hdcp_get_session_key(struct device
> *dev,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_repeater_check_flow_prepare_ack() - Validate the Downstream
> +topology
> + * and prepare rep_ack.
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @rep_topology: Receiver ID List to be validated
> + * @rep_send_ack : repeater ack from ME FW.
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_hdcp_repeater_check_flow_prepare_ack(struct device *dev,
> +  struct hdcp_port_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 mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !rep_topology || !rep_send_ack || !data)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(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_V_PRIME_HALF_LEN);
> + memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
> +HDCP_2_2_RECEIVER_IDS_MAX_LEN);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_repeater_in,
> +   sizeof(verify_repeater_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + memcpy(rep_send_ack->v, verify_repeater_out.v,
> +HDCP_2_2_V_PRIME_HALF_LEN);
> + rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
> @@ -477,7 +551,8 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .initiate_locality_check = mei_hdcp_initiate_locality_check,
>   .verify_lprime = mei_hdcp_verify_lprime,
>   .get_session_key = mei_hdcp_get_session_key,
> - .repeater_check_flow_prepare_ack = NULL,
> + .repeater_check_flow_prepare_ack =
> + mei_hdcp_repeater_check_flow_prepare_ack,
>   .verify_mprime = NULL,
>   .enable_hdcp_authentication = NULL,
>   .close_hdcp_session = 

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #8 from Tom St Denis  ---
Just a follow up.  If you "chmod +s" umr as a non-root user then even if you
sudo it it won't have permissions to read the debugfs files.

Make sure you "sudo chmod +s" the binary or simply just "sudo umr".

-- 
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 1/2] drm: move i915_kick_out_vgacon to drm_fb_helper

[Daniel Vetter]

On Thu, Feb 21, 2019 at 01:39:33PM +0100, Gerd Hoffmann wrote:
> > > +/**
> > > + * drm_fb_helper_kick_out_vgacon - deactivate vgacon driver.
> > > + *
> > > + * Deactivate vgacon driver so it stops accessing vga io ports.
> > > + * Should be called after
> > > + * drm_fb_helper_remove_conflicting_pci_framebuffers().
> > 
> > Why after? i915 calls this before kicking out the fbdev drivers ...
> 
> No, it doesn't:
> 
> 
>   /*
>* WARNING: Apparently we must kick fbdev drivers before vgacon,
>* otherwise the vga fbdev driver falls over.
>*/
>   ret = i915_kick_out_firmware_fb(dev_priv);
>   if (ret) {
>   DRM_ERROR("failed to remove conflicting framebuffer drivers\n");
>   goto err_ggtt;
>   }
> 
>   ret = i915_kick_out_vgacon(dev_priv);
>   if (ret) {
>   DRM_ERROR("failed to remove conflicting VGA console\n");
>   goto err_ggtt;
>   }
> 

/me collects special prize for failing to remove blinders before replying

And indeed this has reasons:

commit 0485c9dc24ec0939b42ca5104c0373297506b555 (tag: 
drm-intel-fixes-2014-11-19)
Author: Daniel Vetter 
Date:   Fri Nov 14 10:09:49 2014 +0100

drm/i915: Kick fbdev before vgacon

It's magic, but it seems to work.

This fixes a regression introduced in

commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2
Author: Daniel Vetter 
Date:   Tue Jul 8 10:02:43 2014 +0200

drm/i915: Only unbind vgacon, not other console drivers

My best guess is that the vga fbdev driver falls over if we rip out
parts of vgacon. Hooray.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82439
Cc: sta...@vger.kernel.org (v3.16+)
Reported-and-tested-by: Lv Zheng 
Signed-off-by: Daniel Vetter 
Acked-by: Chris Wilson 
Signed-off-by: Jani Nikula 

I think given that even more reasons that the pci helper should
automatically kick out all the things, in the right order. And perhaps
cite the above commit in the commit message somewhere.
-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 v14 27/33] misc/mei/hdcp: Prepare Session Key

[Winkler, Tomas]

> 
> Request to ME to prepare the encrypted session key.
> 
> On Success, ME provides Encrypted session key. Function populates the
> HDCP2.2 authentication msg SKE_Send_Eks.
> 
> v2: Rebased.
> v3:
>   cldev is passed as first parameter [Tomas]
>   Redundant comments and cast are removed [Tomas]
> v4:
>   %zd for ssize_t [Alexander]
>   %s/return -1/return -EIO [Alexander]
>   Style fixed [Uma]
> v5: Rebased.
> v6:
>   Collected the Rb-ed by.
>   Rebasing.
> v7:
>   Adjust to the new mei interface.
>   Fix for Kdoc.
> v8:
>   K-Doc addition. [Tomas]
> v9:
>   renamed func as mei_hdcp_* [Tomas]
>   Inline function is defined for DDI index [Tomas]
> v10:
>   K-Doc fix. [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Acked-by: Tomas Winkler 
LGTM

> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 59
> +++-
>  1 file changed, 58 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 869a6f22f68d..fe5070f901e8 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -409,6 +409,63 @@ mei_hdcp_verify_lprime(struct device *dev, struct
> hdcp_port_data *data,
>   return 0;
>  }
> 
> +/**
> + * mei_hdcp_get_session_key() - Prepare SKE_Send_Eks.
> + * @dev: device corresponding to the mei_cl_device
> + * @data: Intel HW specific hdcp data
> + * @ske_data: SKE_Send_Eks msg output from ME FW.
> + *
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int mei_hdcp_get_session_key(struct device *dev,
> + struct hdcp_port_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 mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !ske_data)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(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 = mei_get_ddi_index(data->port);
> +
> + byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", 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. %zd\n", 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 -EIO;
> + }
> +
> + ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
> + memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,
> +HDCP_2_2_E_DKEY_KS_LEN);
> + memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);
> +
> + return 0;
> +}
> +
>  static __attribute__((unused))
>  struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
> @@ -419,7 +476,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .store_pairing_info = mei_hdcp_store_pairing_info,
>   .initiate_locality_check = mei_hdcp_initiate_locality_check,
>   .verify_lprime = mei_hdcp_verify_lprime,
> - .get_session_key = NULL,
> + .get_session_key = mei_hdcp_get_session_key,
>   .repeater_check_flow_prepare_ack = NULL,
>   .verify_mprime = NULL,
>   .enable_hdcp_authentication = NULL,
> --
> 2.7.4

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

Re: [PATCH v2 2/2] drm/qxl: kick out vgacon

[Gerd Hoffmann]

  Hi,

> I was thinking of checking whether pdev is a VGA class device and whether
> it decodes vga access, and in that case automatically calling

How can I figure that?  Ok, class is easy, but decode?  pci.h offers
functions to set vga decode but not to get that info ...

thanks,
  Gerd

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

Re: [PATCH 1/7] drm: Add a helper function for printing a debugfs_regset32.

[Daniel Vetter]

On Wed, Feb 20, 2019 at 01:03:37PM -0800, Eric Anholt wrote:
> The debugfs_regset32 is nice to use for reducing boilerplate in
> dumping a bunch of regs in debugfs, but we also want to be able to
> print to dmesg them at runtime for driver debugging.  drm_printer lets
> us format debugfs and the printk the same way.
> 
> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/drm_print.c | 16 
>  include/drm/drm_print.h |  2 ++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 0e7fc3e7dfb4..5ecc0f04cd0c 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -253,3 +253,19 @@ void drm_err(const char *format, ...)
>   va_end(args);
>  }
>  EXPORT_SYMBOL(drm_err);
> +

A bit of kerneldoc would be nice. With that:

Reviewed-by: Daniel Vetter 

> +void drm_print_regset32(struct drm_printer *p, struct debugfs_regset32 
> *regset)
> +{
> + int namelen = 0;
> + int i;
> +
> + for (i = 0; i < regset->nregs; i++)
> + namelen = max(namelen, (int)strlen(regset->regs[i].name));
> +
> + for (i = 0; i < regset->nregs; i++) {
> + drm_printf(p, "%*s = 0x%08x\n",
> +namelen, regset->regs[i].name,
> +readl(regset->base + regset->regs[i].offset));
> + }
> +}
> +EXPORT_SYMBOL(drm_print_regset32);
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index afbc3beef089..3a4247319e63 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * DOC: print
> @@ -84,6 +85,7 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
> va_format *vaf);
>  __printf(2, 3)
>  void drm_printf(struct drm_printer *p, const char *f, ...);
>  void drm_puts(struct drm_printer *p, const char *str);
> +void drm_print_regset32(struct drm_printer *p, struct debugfs_regset32 
> *regset);
>  
>  __printf(2, 0)
>  /**
> -- 
> 2.20.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] drm/writeback: Delete drm_writeback_cleanup_job

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Thu, Feb 21, 2019 at 12:24:01AM +0100, Daniel Vetter wrote:
> No implementation, no callers.

The issue here isn't that the function is declared, but that it's not
defined. Jobs are leaked when atomic commit fails (or when using test
commits). I'm working on a fix, please don't apply this patch in the
meantime.

> Cc: Brian Starkey 
> Cc: Liviu Dudau 
> Cc: Eric Anholt 
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drm_writeback.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 23df9d463003..f34895f7fcb1 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -125,8 +125,6 @@ int drm_writeback_connector_init(struct drm_device *dev,
>  void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
>struct drm_writeback_job *job);
>  
> -void drm_writeback_cleanup_job(struct drm_writeback_job *job);
> -
>  void
>  drm_writeback_signal_completion(struct drm_writeback_connector *wb_connector,
>   int status);

-- 
Regards,

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

[Bug 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu

[bugzilla-daemon]

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

--- Comment #14 from thomas.lassdiesonner...@gmx.de ---
Still there with 4.20.10

@tempel.jul...@gmail.com
I do not need a workaround thx. All works fine with 4.14.101 LTS Kernel. I just
wanted to report this regression and hope for a fix in another LTS Kernel 4.19
or supposedly 5.4.

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

Re: [PATCH v4 0/7] VSP1: Display writeback support

[Laurent Pinchart]

Hi Brian,

On Mon, Feb 18, 2019 at 12:22:58PM +, Brian Starkey wrote:
> On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series implements display writeback support for the R-Car
> > Gen3 platforms in the VSP1 driver.
> > 
> > DRM/KMS provides a writeback API through a special type of writeback
> > connectors. This series takes a different approach by exposing writeback
> > as a V4L2 device. While there is nothing fundamentally wrong with
> > writeback connectors, display for R-Car Gen3 platforms relies on the
> > VSP1 driver behind the scene, which already implements V4L2 support.
> > Enabling writeback through V4L2 is thus significantly easier in this
> > case.
> 
> How does this look to an application? (I'm entirely ignorant about
> R-Car). They are interacting with the DRM device, and then need to
> open and configure a v4l2 device to get the writeback? Can the process
> which isn't controlling the DRM device independently capture the
> screen output?
> 
> I didn't see any major complication to implementing this as a
> writeback connector. If you want/need to use the vb2_queue, couldn't
> you just do that entirely from within the kernel?
> 
> Honestly (predictably?), to me it seems like a bad idea to introduce a
> second, non-compatible interface for display writeback. Any
> application interested in display writeback (e.g. compositors) will
> need to implement both in order to support all HW. drm_hwcomposer
> already supports writeback via DRM writeback connectors.
> 
> While I can see the advantages of having writeback exposed via v4l2
> for streaming use-cases, I think it would be better to have it done in
> such a way that it works for all writeback connectors, rather than
> being VSP1-specific. That would allow any application to choose
> whichever method is most appropriate for their use-case, without
> limiting themselves to a subset of hardware.

So I gave writeback connectors a go, and it wasn't very pretty. There
writeback support in the DRM core leaks jobs, and is missing support for
the equivalent of .prepare_fb()/.cleanup_fb(), which requires per-job
driver-specific data. I'm working on these issues and will submit
patches.

In the meantime, I need to test my implementation, so I need a command
line application that will let me exercise the API. I assume you've
tested your code, haven't you ? :-) Could you tell me how I can test
writeback ?

> > The writeback pixel format is restricted to RGB, due to the VSP1
> > outputting RGB to the display and lacking a separate colour space
> > conversion unit for writeback. The resolution can be freely picked by
> > will result in cropping or composing, not scaling.
> > 
> > Writeback requests are queued to the hardware on page flip (atomic
> > flush), and complete at the next vblank. This means that a queued
> > writeback buffer will not be processed until the next page flip, but
> > once it starts being written to by the VSP, it will complete at the next
> > vblank regardless of whether another page flip occurs at that time.
> 
> This sounds the same as mali-dp, and so fits directly with the
> semantics of writeback connectors.
> 
> > The code is based on a merge of the media master branch, the drm-next
> > branch and the R-Car DT next branch. For convenience patches can be
> > found at
> > 
> > git://linuxtv.org/pinchartl/media.git v4l2/vsp1/writeback
> > 
> > Kieran Bingham (2):
> >   Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
> >   media: vsp1: Provide a writeback video device
> > 
> > Laurent Pinchart (5):
> >   media: vsp1: wpf: Fix partition configuration for display pipelines
> >   media: vsp1: Replace leftover occurrence of fragment with body
> >   media: vsp1: Fix addresses of display-related registers for VSP-DL
> >   media: vsp1: Refactor vsp1_video_complete_buffer() for later reuse
> >   media: vsp1: Replace the display list internal flag with a flags field
> > 
> >  drivers/media/platform/vsp1/vsp1_dl.c| 118 --
> >  drivers/media/platform/vsp1/vsp1_dl.h|   6 +-
> >  drivers/media/platform/vsp1/vsp1_drm.c   |  24 ++-
> >  drivers/media/platform/vsp1/vsp1_drv.c   |  17 +-
> >  drivers/media/platform/vsp1/vsp1_pipe.c  |   5 +
> >  drivers/media/platform/vsp1/vsp1_pipe.h  |   6 +
> >  drivers/media/platform/vsp1/vsp1_regs.h  |   6 +-
> >  drivers/media/platform/vsp1/vsp1_rwpf.h  |   2 +
> >  drivers/media/platform/vsp1/vsp1_video.c | 198 +++
> >  drivers/media/platform/vsp1/vsp1_video.h |   6 +
> >  drivers/media/platform/vsp1/vsp1_wpf.c   |  65 ++--
> >  11 files changed, 378 insertions(+), 75 deletions(-)

-- 
Regards,

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

Re: [PATCH] drm/writeback: Delete drm_writeback_cleanup_job

[Daniel Vetter]

On Thu, Feb 21, 2019 at 9:19 AM Laurent Pinchart
 wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Thu, Feb 21, 2019 at 12:24:01AM +0100, Daniel Vetter wrote:
> > No implementation, no callers.
>
> The issue here isn't that the function is declared, but that it's not
> defined. Jobs are leaked when atomic commit fails (or when using test
> commits). I'm working on a fix, please don't apply this patch in the
> meantime.

Hm, can't I merge this one and give you a clean slate? Function in
header but nowhere else kinda upsets my ocd :-)
-Daniel

> > Cc: Brian Starkey 
> > Cc: Liviu Dudau 
> > Cc: Eric Anholt 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  include/drm/drm_writeback.h | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> > index 23df9d463003..f34895f7fcb1 100644
> > --- a/include/drm/drm_writeback.h
> > +++ b/include/drm/drm_writeback.h
> > @@ -125,8 +125,6 @@ int drm_writeback_connector_init(struct drm_device *dev,
> >  void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
> >struct drm_writeback_job *job);
> >
> > -void drm_writeback_cleanup_job(struct drm_writeback_job *job);
> > -
> >  void
> >  drm_writeback_signal_completion(struct drm_writeback_connector 
> > *wb_connector,
> >   int status);
>
> --
> Regards,
>
> Laurent Pinchart



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] configure.ac fix build error for config.h in autotools

[Seung-Woo Kim]

After the commit 0926f0af54d6 ("meson,configure: include config.h
automatically"), there is build error for autotools because
config.h is not included. Fix the error by adding "-include
config.h" to CPPFLAGS instead of CFLAGS from configure.ac.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=106561
Signed-off-by: Seung-Woo Kim 
---
 configure.ac |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7e7c8d3..d72e84a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -541,7 +541,7 @@ else
 AC_DEFINE(HAVE_VISIBILITY, 0)
 fi
 
-CFLAGS="$CFLAGS -include config.h"
+CPPFLAGS="$CPPFLAGS -include config.h"
 
 AC_SUBST(WARN_CFLAGS)
 AC_CONFIG_FILES([
-- 
1.7.4.1

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

Re: [PATCH] drm/bochs: Fix the ID mismatch error

[kra...@redhat.com]

On Thu, Feb 21, 2019 at 12:33:03AM +, Alistair Francis wrote:
> When running RISC-V QEMU with the Bochs device attached via PCIe the
> probe of the Bochs device fails with:
> [drm:bochs_hw_init] *ERROR* ID mismatch
> 
> This was introduced by this commit:
> 7780eb9ce8 bochs: convert to drm_dev_register
> 
> To fix the error we ensure that pci_enable_device() is called before
> bochs_load().
> 
> Signed-off-by: Alistair Francis 
> Reported-by: David Abdurachmanov 

Pushed to drm-misc-fixes.

thanks,
  Gerd

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

Re: [PATCH v2 2/2] drm/qxl: kick out vgacon

[Daniel Vetter]

On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote:
> Problem:  qxl switches from native mode back into vga compatibility mode
> when it notices someone is accessing vga registers.  And vgacon does
> exactly that before fbcon takes over.  So make sure we kick out vgacon
> early enough that it wouldn't disturb us.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/qxl/qxl_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index bb81e310eb..08446561aa 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -95,6 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   goto modeset_cleanup;
>  
>   drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> + drm_fb_helper_kick_out_vgacon();

I was thinking of checking whether pdev is a VGA class device and whether
it decodes vga access, and in that case automatically calling
kick_out_vgacon from remove_conflicting_pci_framebuffer. Since that's what
drivers want anyway, and those who don't can open code it.

Or is there an issue with that?
-Daniel

>   drm_fbdev_generic_setup(>ddev, 32);
>   return 0;
>  
> -- 
> 2.9.3
> 

-- 
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 v14 20/33] misc/mei/hdcp: Define ME FW interface for HDCP2.2

[Winkler, Tomas]

> 
> Defines the HDCP specific ME FW interfaces such as Request CMDs, payload
> structure for CMDs and their response status codes.
> 
> This patch defines payload size(Excluding the Header)for each WIRED
> HDCP2.2 CMDs.
> 
> v2: Rebased.
> v3:
>   Extra comments are removed.
> v4:
>   %s/\/\*\*/\/\*
> v5:
>   Extra lines are removed.
> v6:
>   Remove redundant text from the License header
>   %s/LPRIME_HALF/V_PRIME_HALF
>   %s/uintxx_t/uxx
> v7:
>   Extra taps removed.
> 
> Signed-off-by: Ramalingam C  Acked-by Tomas
> Winkler 
> ---
>  drivers/misc/mei/hdcp/mei_hdcp.h | 366
> +++
>  1 file changed, 366 insertions(+)
>  create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
> b/drivers/misc/mei/hdcp/mei_hdcp.h
> new file mode 100644
> index ..582a7e27ae29
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> @@ -0,0 +1,366 @@
> +/* SPDX-License-Identifier: (GPL-2.0+) */
> +/*
> + * Copyright © 2017-2018 Intel Corporation
2019


> + *
> + * Authors:
> + * Ramalingam C   */
> +
> +#ifndef __MEI_HDCP_H__
> +#define __MEI_HDCP_H__
> +
> +#include 
> +
> +/* me_hdcp_status: Enumeration of all HDCP Status Codes */ enum
> +me_hdcp_status {
> + ME_HDCP_STATUS_SUCCESS  = 0x,
> +
> + /* WiDi Generic Status Codes */
> + ME_HDCP_STATUS_INTERNAL_ERROR   = 0x1000,
> + ME_HDCP_STATUS_UNKNOWN_ERROR= 0x1001,
> + ME_HDCP_STATUS_INCORRECT_API_VERSION= 0x1002,
> + ME_HDCP_STATUS_INVALID_FUNCTION = 0x1003,
> + ME_HDCP_STATUS_INVALID_BUFFER_LENGTH= 0x1004,
> + ME_HDCP_STATUS_INVALID_PARAMS   = 0x1005,
> + ME_HDCP_STATUS_AUTHENTICATION_FAILED= 0x1006,
> +
> + /* WiDi Status Codes */
> + ME_HDCP_INVALID_SESSION_STATE   = 0x6000,
> + ME_HDCP_SRM_FRAGMENT_UNEXPECTED = 0x6001,
> + ME_HDCP_SRM_INVALID_LENGTH  = 0x6002,
> + ME_HDCP_SRM_FRAGMENT_OFFSET_INVALID = 0x6003,
> + ME_HDCP_SRM_VERIFICATION_FAILED = 0x6004,
> + ME_HDCP_SRM_VERSION_TOO_OLD = 0x6005,
> + ME_HDCP_RX_CERT_VERIFICATION_FAILED = 0x6006,
> + ME_HDCP_RX_REVOKED  = 0x6007,
> + ME_HDCP_H_VERIFICATION_FAILED   = 0x6008,
> + ME_HDCP_REPEATER_CHECK_UNEXPECTED   = 0x6009,
> + ME_HDCP_TOPOLOGY_MAX_EXCEEDED   = 0x600A,
> + ME_HDCP_V_VERIFICATION_FAILED   = 0x600B,
> + ME_HDCP_L_VERIFICATION_FAILED   = 0x600C,
> + ME_HDCP_STREAM_KEY_ALLOC_FAILED = 0x600D,
> + ME_HDCP_BASE_KEY_RESET_FAILED   = 0x600E,
> + ME_HDCP_NONCE_GENERATION_FAILED = 0x600F,
> + ME_HDCP_STATUS_INVALID_E_KEY_STATE  = 0x6010,
> + ME_HDCP_STATUS_INVALID_CS_ICV   = 0x6011,
> + ME_HDCP_STATUS_INVALID_KB_KEY_STATE = 0x6012,
> + ME_HDCP_STATUS_INVALID_PAVP_MODE_ICV= 0x6013,
> + ME_HDCP_STATUS_INVALID_PAVP_MODE= 0x6014,
> + ME_HDCP_STATUS_LC_MAX_ATTEMPTS  = 0x6015,
> +
> + /* New status for HDCP 2.1 */
> + ME_HDCP_STATUS_MISMATCH_IN_M= 0x6016,
> +
> + /* New status code for HDCP 2.2 Rx */
> + ME_HDCP_STATUS_RX_PROV_NOT_ALLOWED  = 0x6017,
> + ME_HDCP_STATUS_RX_PROV_WRONG_SUBJECT= 0x6018,
> + ME_HDCP_RX_NEEDS_PROVISIONING   = 0x6019,
> + ME_HDCP_BKSV_ICV_AUTH_FAILED= 0x6020,
> + ME_HDCP_STATUS_INVALID_STREAM_ID= 0x6021,
> + ME_HDCP_STATUS_CHAIN_NOT_INITIALIZED= 0x6022,
> + ME_HDCP_FAIL_NOT_EXPECTED   = 0x6023,
> + ME_HDCP_FAIL_HDCP_OFF   = 0x6024,
> + ME_HDCP_FAIL_INVALID_PAVP_MEMORY_MODE   = 0x6025,
> + ME_HDCP_FAIL_AES_ECB_FAILURE= 0x6026,
> + ME_HDCP_FEATURE_NOT_SUPPORTED   = 0x6027,
> + ME_HDCP_DMA_READ_ERROR  = 0x6028,
> + ME_HDCP_DMA_WRITE_ERROR = 0x6029,
> + ME_HDCP_FAIL_INVALID_PACKET_SIZE= 0x6030,
> + ME_HDCP_H264_PARSING_ERROR  = 0x6031,
> + ME_HDCP_HDCP2_ERRATA_VIDEO_VIOLATION= 0x6032,
> + ME_HDCP_HDCP2_ERRATA_AUDIO_VIOLATION= 0x6033,
> + ME_HDCP_TX_ACTIVE_ERROR = 0x6034,
> + ME_HDCP_MODE_CHANGE_ERROR   = 0x6035,
> + ME_HDCP_STREAM_TYPE_ERROR   = 0x6036,
> + ME_HDCP_STREAM_MANAGE_NOT_POSSIBLE  = 0x6037,
> +
> + ME_HDCP_STATUS_PORT_INVALID_COMMAND = 0x6038,
> + ME_HDCP_STATUS_UNSUPPORTED_PROTOCOL = 0x6039,
> + ME_HDCP_STATUS_INVALID_PORT_INDEX   = 0x603a,
> + ME_HDCP_STATUS_TX_AUTH_NEEDED   = 0x603b,
> + ME_HDCP_STATUS_NOT_INTEGRATED_PORT  = 0x603c,
> + ME_HDCP_STATUS_SESSION_MAX_REACHED  = 0x603d,
> +
> + /* hdcp capable bit is not set in rx_caps(error is unique to DP) */
> + ME_HDCP_STATUS_NOT_HDCP_CAPABLE = 0x6041,
> +
> + 

[Bug 109719] [igt_runner] Collect pstore data and attach it to dmesg output when resuming or reporting

[bugzilla-daemon]

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

Martin Peres  changed:

   What|Removed |Added

Summary|Collect pstore data and |[igt_runner] Collect pstore
   |attach it to dmesg output   |data and attach it to dmesg
   |when resuming or reporting  |output when resuming or
   ||reporting

--- Comment #1 from Martin Peres  ---
We also need to empty pstore when we start a new run.

-- 
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 v4 0/7] VSP1: Display writeback support

[Laurent Pinchart]

Hi Brian,

On Thu, Feb 21, 2019 at 09:50:19AM +, Brian Starkey wrote:
> On Thu, Feb 21, 2019 at 10:23:17AM +0200, Laurent Pinchart wrote:
> > On Mon, Feb 18, 2019 at 12:22:58PM +, Brian Starkey wrote:
> >> On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> >>> Hello,
> >>> 
> >>> This patch series implements display writeback support for the R-Car
> >>> Gen3 platforms in the VSP1 driver.
> >>> 
> >>> DRM/KMS provides a writeback API through a special type of writeback
> >>> connectors. This series takes a different approach by exposing writeback
> >>> as a V4L2 device. While there is nothing fundamentally wrong with
> >>> writeback connectors, display for R-Car Gen3 platforms relies on the
> >>> VSP1 driver behind the scene, which already implements V4L2 support.
> >>> Enabling writeback through V4L2 is thus significantly easier in this
> >>> case.
> >> 
> >> How does this look to an application? (I'm entirely ignorant about
> >> R-Car). They are interacting with the DRM device, and then need to
> >> open and configure a v4l2 device to get the writeback? Can the process
> >> which isn't controlling the DRM device independently capture the
> >> screen output?
> >> 
> >> I didn't see any major complication to implementing this as a
> >> writeback connector. If you want/need to use the vb2_queue, couldn't
> >> you just do that entirely from within the kernel?
> >> 
> >> Honestly (predictably?), to me it seems like a bad idea to introduce a
> >> second, non-compatible interface for display writeback. Any
> >> application interested in display writeback (e.g. compositors) will
> >> need to implement both in order to support all HW. drm_hwcomposer
> >> already supports writeback via DRM writeback connectors.
> >> 
> >> While I can see the advantages of having writeback exposed via v4l2
> >> for streaming use-cases, I think it would be better to have it done in
> >> such a way that it works for all writeback connectors, rather than
> >> being VSP1-specific. That would allow any application to choose
> >> whichever method is most appropriate for their use-case, without
> >> limiting themselves to a subset of hardware.
> > 
> > So I gave writeback connectors a go, and it wasn't very pretty.
> 
> Sorry you didn't have a good time :-(

No worries. That was to be expected with such young code :-)

> > There writeback support in the DRM core leaks jobs,
> 
> Is this the cleanup on check fail, or something else?

Yes, that's the problem. I have patches for it that I will post soon.

> One possible pitfall is that you must set the job in the connector
> state to NULL after you call drm_writeback_queue_job(). The API there
> could easily be changed to pass in the connector_state and clear it in
> drm_writeback_queue_job() instead of relying on drivers to do it.

I also have a patch for that :-)

> > and is missing support for
> > the equivalent of .prepare_fb()/.cleanup_fb(), which requires per-job
> > driver-specific data. I'm working on these issues and will submit
> > patches.
> 
> Hm, yes that didn't occur to me; we don't have a prepare_fb callback.
> 
> > In the meantime, I need to test my implementation, so I need a command
> > line application that will let me exercise the API. I assume you've
> > tested your code, haven't you ? :-) Could you tell me how I can test
> > writeback ?
> 
> Indeed, there's igts on the list which I wrote and tested:
> 
> https://patchwork.kernel.org/patch/10764975/

Will you get these merged ? Pushing everybody to use the writeback
connector API without any test is mainline isn't nice, it almost makes
me want to go back to V4L2.

igt test cases are nice to have, but what I need now is a tool to
execise the API manually, similar to modetest, with command line
parameters to configure the device, and the ability to capture frames to
disk using writeback. How did you perform such tests when you developed
writeback support ?

> And there's support in drm_hwcomposer (though I must admit I haven't
> personally run the drm_hwc code):
> 
> https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/3

That won't help me much as I don't have an android port for the R-Car
boards.

> I'm afraid I haven't really touched any of the writeback code for a
> couple of years - Liviu picked that up. He's on holiday until Monday,
> but he should be able to help with the status of the igts.
> 
> Hope that helps,
> 
> >>> The writeback pixel format is restricted to RGB, due to the VSP1
> >>> outputting RGB to the display and lacking a separate colour space
> >>> conversion unit for writeback. The resolution can be freely picked by
> >>> will result in cropping or composing, not scaling.
> >>> 
> >>> Writeback requests are queued to the hardware on page flip (atomic
> >>> flush), and complete at the next vblank. This means that a queued
> >>> writeback buffer will not be processed until the next page flip, but
> >>> once it starts being written to by the VSP, it will 

Re: [PATCH] drm/writeback: Delete drm_writeback_cleanup_job

[Laurent Pinchart]

Hi Daniel,

On Thu, Feb 21, 2019 at 10:30:24AM +0100, Daniel Vetter wrote:
> On Thu, Feb 21, 2019 at 9:19 AM Laurent Pinchart
>  wrote:
> > Hi Daniel,
> >
> > Thank you for the patch.
> >
> > On Thu, Feb 21, 2019 at 12:24:01AM +0100, Daniel Vetter wrote:
> >> No implementation, no callers.
> >
> > The issue here isn't that the function is declared, but that it's not
> > defined. Jobs are leaked when atomic commit fails (or when using test
> > commits). I'm working on a fix, please don't apply this patch in the
> > meantime.
> 
> Hm, can't I merge this one and give you a clean slate? Function in
> header but nowhere else kinda upsets my ocd :-)

I'm afraid I've already posted the fix patches that depend on this
prototype :-)

> >> Cc: Brian Starkey 
> >> Cc: Liviu Dudau 
> >> Cc: Eric Anholt 
> >> Signed-off-by: Daniel Vetter 
> >> ---
> >>  include/drm/drm_writeback.h | 2 --
> >>  1 file changed, 2 deletions(-)
> >>
> >> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> >> index 23df9d463003..f34895f7fcb1 100644
> >> --- a/include/drm/drm_writeback.h
> >> +++ b/include/drm/drm_writeback.h
> >> @@ -125,8 +125,6 @@ int drm_writeback_connector_init(struct drm_device 
> >> *dev,
> >>  void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
> >>struct drm_writeback_job *job);
> >>
> >> -void drm_writeback_cleanup_job(struct drm_writeback_job *job);
> >> -
> >>  void
> >>  drm_writeback_signal_completion(struct drm_writeback_connector 
> >> *wb_connector,
> >>   int status);

-- 
Regards,

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

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #7 from Tom St Denis  ---
Hi from Reddit!

I don't see the attached umr output in the bugzilla report.  Though it looks
like Andrey (who is on my team) is looking at it.

It looks like an unhandled (or just bad) VM fault is locking up the GFX ring
and then a reset occurs which then brings up your lockdep.

So it's really two bugs (or 1 and a half)

1.  GPU hang due to VM fault
2.  GPU reset not working properly

The VM fault shouldn't lock up the GPU though even if it's the applications
fault (which does happen).  

The VM fault could be because of a bug in the kernel processing a CS, could be
from the UMD (mesa/etc), or could be from the application itself.

-- 
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 -next] drm/qxl: remove set but not used variable 'bo_old'

[Gerd Hoffmann]

On Mon, Feb 18, 2019 at 08:54:59AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/gpu/drm/qxl/qxl_display.c: In function 'qxl_primary_atomic_update':
> drivers/gpu/drm/qxl/qxl_display.c:538:17: warning:
>  variable 'bo_old' set but not used [-Wunused-but-set-variable]
> 
> It's not used any more after 4979904c62b9 ("drm/qxl: use shadow bo directly")

Pushed to drm-misc-next.

thanks,
  Gerd

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

[Bug 108965] [CI][BAT] igt@amdgpu_amd_basic@userptr - dmesg-warn - general protection fault: 0000 [#1] PREEMPT SMP PTI

[bugzilla-daemon]

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

--- Comment #1 from CI Bug Log  ---
A CI Bug Log filter associated to this bug has been updated:

{- VEGA M: igt@amdgpu_amd_basic@userptr - dmesg-warn - general protection
fault:  [#1] PREEMPT SMP PTI -}
{+ VEGA M: igt@amdgpu_amd_basic@(semaphore|userptr) - dmesg-warn - general
protection fault:  [#1] PREEMPT SMP PTI +}

 No new failures caught with the new filter

-- 
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 108965] [CI][BAT] igt@amdgpu_amd_basic@userptr - dmesg-warn - general protection fault: 0000 [#1] PREEMPT SMP PTI

[bugzilla-daemon]

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

--- Comment #2 from Petri Latvala  ---
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2468/fi-kbl-8809g/igt@amdgpu_amd_ba...@semaphore.html

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

[PATCH v5 02/19] media: vsp1: wpf: Fix partition configuration for display pipelines

[Laurent Pinchart]

When configuring partitions for memory-to-memory pipelines, the WPF
accesses data of the current partition through pipe->partition.
Writeback support will require full configuration of the WPF while not
providing a valid pipe->partition. Rework the configuration code to fall
back to the full image width in that case, as is already done for the
part of the configuration currently relevant for display pipelines.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_wpf.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 32bb207b2007..a07c5944b598 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -362,6 +362,7 @@ static void wpf_configure_partition(struct vsp1_entity 
*entity,
const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
unsigned int width;
unsigned int height;
+   unsigned int left;
unsigned int offset;
unsigned int flip;
unsigned int i;
@@ -371,13 +372,16 @@ static void wpf_configure_partition(struct vsp1_entity 
*entity,
 RWPF_PAD_SINK);
width = sink_format->width;
height = sink_format->height;
+   left = 0;
 
/*
 * Cropping. The partition algorithm can split the image into
 * multiple slices.
 */
-   if (pipe->partitions > 1)
+   if (pipe->partitions > 1) {
width = pipe->partition->wpf.width;
+   left = pipe->partition->wpf.left;
+   }
 
vsp1_wpf_write(wpf, dlb, VI6_WPF_HSZCLIP, VI6_WPF_SZCLIP_EN |
   (0 << VI6_WPF_SZCLIP_OFST_SHIFT) |
@@ -408,13 +412,11 @@ static void wpf_configure_partition(struct vsp1_entity 
*entity,
flip = wpf->flip.active;
 
if (flip & BIT(WPF_CTRL_HFLIP) && !wpf->flip.rotate)
-   offset = format->width - pipe->partition->wpf.left
-   - pipe->partition->wpf.width;
+   offset = format->width - left - width;
else if (flip & BIT(WPF_CTRL_VFLIP) && wpf->flip.rotate)
-   offset = format->height - pipe->partition->wpf.left
-   - pipe->partition->wpf.width;
+   offset = format->height - left - width;
else
-   offset = pipe->partition->wpf.left;
+   offset = left;
 
for (i = 0; i < format->num_planes; ++i) {
unsigned int hsub = i > 0 ? fmtinfo->hsub : 1;
@@ -436,7 +438,7 @@ static void wpf_configure_partition(struct vsp1_entity 
*entity,
 * image height.
 */
if (wpf->flip.rotate)
-   height = pipe->partition->wpf.width;
+   height = width;
else
height = format->height;
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 08/19] media: vsp1: wpf: Add writeback support

[Laurent Pinchart]

Add support for the writeback feature of the WPF, to enable capturing
frames at the WPF output for display pipelines. To enable writeback the
vsp1_rwpf structure mem field must be set to the address of the
writeback buffer and the writeback field set to true before the WPF
.configure_stream() and .configure_partition() are called. The WPF will
enable writeback in the display list for a single frame, and writeback
will then be automatically disabled.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drv.c  | 15 +++
 drivers/media/platform/vsp1/vsp1_pipe.c |  5 +++
 drivers/media/platform/vsp1/vsp1_pipe.h |  1 +
 drivers/media/platform/vsp1/vsp1_rwpf.h |  2 +
 drivers/media/platform/vsp1/vsp1_wpf.c  | 52 -
 5 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index c650e45bb0ad..22709f6f2a0c 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -63,6 +63,21 @@ static irqreturn_t vsp1_irq_handler(int irq, void *data)
vsp1_pipeline_frame_end(wpf->entity.pipe);
ret = IRQ_HANDLED;
}
+
+   /*
+* Process the display start interrupt after the frame end
+* interrupt to make sure the display list queue is correctly
+* updated when processing the display start.
+*/
+   if (wpf->has_writeback) {
+   status = vsp1_read(vsp1, VI6_DISP_IRQ_STA(i));
+   vsp1_write(vsp1, VI6_DISP_IRQ_STA(i), ~status & mask);
+
+   if (status & VI6_DISP_IRQ_STA_DST) {
+   vsp1_pipeline_display_start(wpf->entity.pipe);
+   ret = IRQ_HANDLED;
+   }
+   }
}
 
return ret;
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 54ff539ffea0..016800c45bc1 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -309,6 +309,11 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
return pipe->buffers_ready == mask;
 }
 
+void vsp1_pipeline_display_start(struct vsp1_pipeline *pipe)
+{
+   vsp1_dlm_irq_display_start(pipe->output->dlm);
+}
+
 void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
 {
unsigned int flags;
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index ae646c9ef337..801fca13fc4f 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -158,6 +158,7 @@ bool vsp1_pipeline_stopped(struct vsp1_pipeline *pipe);
 int vsp1_pipeline_stop(struct vsp1_pipeline *pipe);
 bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe);
 
+void vsp1_pipeline_display_start(struct vsp1_pipeline *pipe);
 void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe);
 
 void vsp1_pipeline_propagate_alpha(struct vsp1_pipeline *pipe,
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h 
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index 70742ecf766f..910990b27617 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -35,6 +35,7 @@ struct vsp1_rwpf {
struct v4l2_ctrl_handler ctrls;
 
struct vsp1_video *video;
+   bool has_writeback;
 
unsigned int max_width;
unsigned int max_height;
@@ -61,6 +62,7 @@ struct vsp1_rwpf {
} flip;
 
struct vsp1_rwpf_memory mem;
+   bool writeback;
 
struct vsp1_dl_manager *dlm;
 };
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 18c49e3a7875..b8bcc7968f9c 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -240,6 +240,7 @@ static void wpf_configure_stream(struct vsp1_entity *entity,
struct vsp1_device *vsp1 = wpf->entity.vsp1;
const struct v4l2_mbus_framefmt *source_format;
const struct v4l2_mbus_framefmt *sink_format;
+   unsigned int index = wpf->entity.index;
unsigned int i;
u32 outfmt = 0;
u32 srcrpf = 0;
@@ -250,8 +251,9 @@ static void wpf_configure_stream(struct vsp1_entity *entity,
source_format = vsp1_entity_get_pad_format(>entity,
   wpf->entity.config,
   RWPF_PAD_SOURCE);
+
/* Format */
-   if (!pipe->lif) {
+   if (!pipe->lif || wpf->writeback) {
const struct v4l2_pix_format_mplane *format = >format;
const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
 
@@ -276,8 +278,7 @@ static void wpf_configure_stream(struct vsp1_entity *entity,
 
vsp1_wpf_write(wpf, dlb, VI6_WPF_DSWAP, fmtinfo->swap);
 
-

[PATCH v5 03/19] media: vsp1: Replace leftover occurrence of fragment with body

[Laurent Pinchart]

Display list fragments have been renamed to bodies. Replace one last
occurrence of the word fragment in the documentation.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 26289adaf658..64af449791b0 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -699,8 +699,8 @@ struct vsp1_dl_body *vsp1_dl_list_get_body0(struct 
vsp1_dl_list *dl)
  * which bodies are added.
  *
  * Adding a body to a display list passes ownership of the body to the list. 
The
- * caller retains its reference to the fragment when adding it to the display
- * list, but is not allowed to add new entries to the body.
+ * caller retains its reference to the body when adding it to the display list,
+ * but is not allowed to add new entries to the body.
  *
  * The reference must be explicitly released by a call to vsp1_dl_body_put()
  * when the body isn't needed anymore.
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 00/19] R-Car DU display writeback support

[Laurent Pinchart]

Hello everybody,

This patch series implements display writeback support for the R-Car
Gen3 platforms in the VSP1 and DU drivers.

Patches 01/19 to 11/19 prepare the VSP1 driver for writeback support
with all the necessary plumbing, including extensions of the API between
the VSP1 and DU drivers.

Compared to v4 the major change is the move from V4L2 to DRM writeback
connectors for the userspace API. This has caused a few issues with
writeback support to be uncovered, and they are addressed by patches
12/19 to 14/19. Patch 15/19 is an unrelated drive-by fix.

Patches 16/19 to 18/19 then perform refactoring of the DU driver, to
finally add writeback support in patch 19/19.

The writeback pixel format is restricted to RGB, due to the VSP1
outputting RGB to the display and lacking a separate colour space
conversion unit for writeback. The resolution can be freely picked by
will result in cropping or composing, not scaling.

Writeback requests are queued to the hardware on page flip (atomic
flush), and complete at the next vblank. This means that a queued
writeback buffer will not be processed until the next page flip, but
once it starts being written to by the VSP, it will complete at the next
vblank regardless of whether another page flip occurs at that time.

The code is based on a merge of the media master branch, the drm-next
branch and the R-Car DT next branch. For convenience patches can be
found at

git://linuxtv.org/pinchartl/media.git v4l2/vsp1/writeback

Kieran Bingham (1):
  Revert "[media] v4l: vsp1: Supply frames to the DU continuously"

Laurent Pinchart (18):
  media: vsp1: wpf: Fix partition configuration for display pipelines
  media: vsp1: Replace leftover occurrence of fragment with body
  media: vsp1: Fix addresses of display-related registers for VSP-DL
  media: vsp1: Refactor vsp1_video_complete_buffer() for later reuse
  media: vsp1: Replace the display list internal flag with a flags field
  media: vsp1: dl: Support one-shot entries in the display list
  media: vsp1: wpf: Add writeback support
  media: vsp1: drm: Split RPF format setting to separate function
  media: vsp1: drm: Extend frame completion API to the DU driver
  media: vsp1: drm: Implement writeback support
  drm: writeback: Cleanup job ownership handling when queuing job
  drm: writeback: Fix leak of writeback job
  drm: writeback: Add job prepare and cleanup operations
  drm/msm: Remove prototypes for non-existing functions
  drm: rcar-du: Fix rcar_du_crtc structure documentation
  drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure
  drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate
functions
  drm: rcar-du: Add writeback support for R-Car Gen3

 drivers/gpu/drm/arm/malidp_mw.c |   3 +-
 drivers/gpu/drm/drm_atomic_helper.c |  11 ++
 drivers/gpu/drm/drm_atomic_state_helper.c   |   4 +
 drivers/gpu/drm/drm_atomic_uapi.c   |  31 +--
 drivers/gpu/drm/drm_writeback.c |  71 ++-
 drivers/gpu/drm/msm/msm_drv.h   |   2 -
 drivers/gpu/drm/rcar-du/Kconfig |   4 +
 drivers/gpu/drm/rcar-du/Makefile|   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  37 
 drivers/gpu/drm/rcar-du/rcar_du_kms.h   |   1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 121 ++--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  17 ++
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 203 
 drivers/gpu/drm/rcar-du/rcar_du_writeback.h |  39 
 drivers/gpu/drm/vc4/vc4_txp.c   |   2 +-
 drivers/media/platform/vsp1/vsp1_dl.c   | 127 ++--
 drivers/media/platform/vsp1/vsp1_dl.h   |   8 +-
 drivers/media/platform/vsp1/vsp1_drm.c  |  92 ++---
 drivers/media/platform/vsp1/vsp1_drm.h  |   2 +-
 drivers/media/platform/vsp1/vsp1_drv.c  |  15 ++
 drivers/media/platform/vsp1/vsp1_pipe.c |   5 +
 drivers/media/platform/vsp1/vsp1_pipe.h |   1 +
 drivers/media/platform/vsp1/vsp1_regs.h |   6 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h |   2 +
 drivers/media/platform/vsp1/vsp1_video.c|  49 +++--
 drivers/media/platform/vsp1/vsp1_wpf.c  |  68 +--
 include/drm/drm_modeset_helper_vtables.h|   7 +
 include/drm/drm_writeback.h |  30 ++-
 include/media/vsp1.h|  19 +-
 30 files changed, 790 insertions(+), 199 deletions(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.h

-- 
Regards,

Laurent Pinchart

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

[PATCH v5 16/19] drm: rcar-du: Fix rcar_du_crtc structure documentation

[Laurent Pinchart]

The rcar_du_crtc structure index field contains the CRTC hardware index,
not the hardware and software index. Update the documentation
accordingly.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index bcb35b0b7612..c478953be092 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -27,7 +27,7 @@ struct rcar_du_vsp;
  * @clock: the CRTC functional clock
  * @extclock: external pixel dot clock (optional)
  * @mmio_offset: offset of the CRTC registers in the DU MMIO block
- * @index: CRTC software and hardware index
+ * @index: CRTC hardware index
  * @initialized: whether the CRTC has been initialized and clocks enabled
  * @dsysr: cached value of the DSYSR register
  * @vblank_enable: whether vblank events are enabled on this CRTC
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 09/19] media: vsp1: drm: Split RPF format setting to separate function

[Laurent Pinchart]

The code that initializes the RPF format-related fields for display
pipelines will also be useful for the WPF to implement writeback
support. Split it from vsp1_du_atomic_update() to a new
vsp1_du_pipeline_set_rwpf_format() function.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 55 --
 1 file changed, 35 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 89773d3a916c..a0569e0d0f9e 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -566,6 +566,36 @@ static void vsp1_du_pipeline_configure(struct 
vsp1_pipeline *pipe)
vsp1_dl_list_commit(dl, dl_flags);
 }
 
+static int vsp1_du_pipeline_set_rwpf_format(struct vsp1_device *vsp1,
+   struct vsp1_rwpf *rwpf,
+   u32 pixelformat, unsigned int pitch)
+{
+   const struct vsp1_format_info *fmtinfo;
+   unsigned int chroma_hsub;
+
+   fmtinfo = vsp1_get_format_info(vsp1, pixelformat);
+   if (!fmtinfo) {
+   dev_dbg(vsp1->dev, "Unsupported pixel format %08x for RPF\n",
+   pixelformat);
+   return -EINVAL;
+   }
+
+   /*
+* Only formats with three planes can affect the chroma planes pitch.
+* All formats with two planes have a horizontal subsampling value of 2,
+* but combine U and V in a single chroma plane, which thus results in
+* the luma plane and chroma plane having the same pitch.
+*/
+   chroma_hsub = (fmtinfo->planes == 3) ? fmtinfo->hsub : 1;
+
+   rwpf->fmtinfo = fmtinfo;
+   rwpf->format.num_planes = fmtinfo->planes;
+   rwpf->format.plane_fmt[0].bytesperline = pitch;
+   rwpf->format.plane_fmt[1].bytesperline = pitch / chroma_hsub;
+
+   return 0;
+}
+
 /* 
-
  * DU Driver API
  */
@@ -773,9 +803,8 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int 
pipe_index,
 {
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
-   const struct vsp1_format_info *fmtinfo;
-   unsigned int chroma_hsub;
struct vsp1_rwpf *rpf;
+   int ret;
 
if (rpf_index >= vsp1->info->rpf_count)
return -EINVAL;
@@ -808,25 +837,11 @@ int vsp1_du_atomic_update(struct device *dev, unsigned 
int pipe_index,
 * Store the format, stride, memory buffer address, crop and compose
 * rectangles and Z-order position and for the input.
 */
-   fmtinfo = vsp1_get_format_info(vsp1, cfg->pixelformat);
-   if (!fmtinfo) {
-   dev_dbg(vsp1->dev, "Unsupported pixel format %08x for RPF\n",
-   cfg->pixelformat);
-   return -EINVAL;
-   }
+   ret = vsp1_du_pipeline_set_rwpf_format(vsp1, rpf, cfg->pixelformat,
+  cfg->pitch);
+   if (ret < 0)
+   return ret;
 
-   /*
-* Only formats with three planes can affect the chroma planes pitch.
-* All formats with two planes have a horizontal subsampling value of 2,
-* but combine U and V in a single chroma plane, which thus results in
-* the luma plane and chroma plane having the same pitch.
-*/
-   chroma_hsub = (fmtinfo->planes == 3) ? fmtinfo->hsub : 1;
-
-   rpf->fmtinfo = fmtinfo;
-   rpf->format.num_planes = fmtinfo->planes;
-   rpf->format.plane_fmt[0].bytesperline = cfg->pitch;
-   rpf->format.plane_fmt[1].bytesperline = cfg->pitch / chroma_hsub;
rpf->alpha = cfg->alpha;
 
rpf->mem.addr[0] = cfg->mem[0];
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 04/19] media: vsp1: Fix addresses of display-related registers for VSP-DL

[Laurent Pinchart]

The VSP-DL instances have two LIFs, and thus two copies of the
VI6_DISP_IRQ_ENB, VI6_DISP_IRQ_STA and VI6_WPF_WRBCK_CTRL registers. Fix
the corresponding macros accordingly.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c  | 4 ++--
 drivers/media/platform/vsp1/vsp1_regs.h | 6 +++---
 drivers/media/platform/vsp1/vsp1_wpf.c  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 8d86f618ec77..048190fd3a2d 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -700,8 +700,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
drm_pipe->du_private = cfg->callback_data;
 
/* Disable the display interrupts. */
-   vsp1_write(vsp1, VI6_DISP_IRQ_STA, 0);
-   vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0);
+   vsp1_write(vsp1, VI6_DISP_IRQ_STA(pipe_index), 0);
+   vsp1_write(vsp1, VI6_DISP_IRQ_ENB(pipe_index), 0);
 
/* Configure all entities in the pipeline. */
vsp1_du_pipeline_configure(pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
b/drivers/media/platform/vsp1/vsp1_regs.h
index f6e4157095cc..1bb1d39c60d9 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -39,12 +39,12 @@
 #define VI6_WFP_IRQ_STA_DFE(1 << 1)
 #define VI6_WFP_IRQ_STA_FRE(1 << 0)
 
-#define VI6_DISP_IRQ_ENB   0x0078
+#define VI6_DISP_IRQ_ENB(n)(0x0078 + (n) * 60)
 #define VI6_DISP_IRQ_ENB_DSTE  (1 << 8)
 #define VI6_DISP_IRQ_ENB_MAEE  (1 << 5)
 #define VI6_DISP_IRQ_ENB_LNEE(n)   (1 << (n))
 
-#define VI6_DISP_IRQ_STA   0x007c
+#define VI6_DISP_IRQ_STA(n)(0x007c + (n) * 60)
 #define VI6_DISP_IRQ_STA_DST   (1 << 8)
 #define VI6_DISP_IRQ_STA_MAE   (1 << 5)
 #define VI6_DISP_IRQ_STA_LNE(n)(1 << (n))
@@ -307,7 +307,7 @@
 #define VI6_WPF_DSTM_ADDR_C0   0x1028
 #define VI6_WPF_DSTM_ADDR_C1   0x102c
 
-#define VI6_WPF_WRBCK_CTRL 0x1034
+#define VI6_WPF_WRBCK_CTRL(n)  (0x1034 + (n) * 0x100)
 #define VI6_WPF_WRBCK_CTRL_WBMD(1 << 0)
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index a07c5944b598..18c49e3a7875 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -291,7 +291,7 @@ static void wpf_configure_stream(struct vsp1_entity *entity,
vsp1_dl_body_write(dlb, VI6_DPR_WPF_FPORCH(wpf->entity.index),
   VI6_DPR_WPF_FPORCH_FP_WPFN);
 
-   vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL, 0);
+   vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL(wpf->entity.index), 0);
 
/*
 * Sources. If the pipeline has a single input and BRx is not used,
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v5 12/19] drm: writeback: Cleanup job ownership handling when queuing job

[Laurent Pinchart]

Forgot to CC Eric, sorry about that.

On Thu, Feb 21, 2019 at 12:32:05PM +0200, Laurent Pinchart wrote:
> The drm_writeback_queue_job() function takes ownership of the passed job
> and requires the caller to manually set the connector state
> writeback_job pointer to NULL. To simplify drivers and avoid errors
> (such as the missing NULL set in the vc4 driver), pass the connector
> state pointer to the function instead of the job pointer, and set the
> writeback_job pointer to NULL internally.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/arm/malidp_mw.c |  3 +--
>  drivers/gpu/drm/drm_writeback.c | 15 ++-
>  drivers/gpu/drm/vc4/vc4_txp.c   |  2 +-
>  include/drm/drm_writeback.h |  2 +-
>  4 files changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 041a64dc7167..87627219ce3b 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -252,8 +252,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
>_state->addrs[0],
>mw_state->format);
>  
> - drm_writeback_queue_job(mw_conn, conn_state->writeback_job);
> - conn_state->writeback_job = NULL;
> + drm_writeback_queue_job(mw_conn, conn_state);
>   hwdev->hw->enable_memwrite(hwdev, mw_state->addrs,
>  mw_state->pitches, 
> mw_state->n_planes,
>  fb->width, fb->height, 
> mw_state->format,
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index c20e6fe00cb3..338b993d7c9f 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -242,11 +242,12 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
>  /**
>   * drm_writeback_queue_job - Queue a writeback job for later signalling
>   * @wb_connector: The writeback connector to queue a job on
> - * @job: The job to queue
> + * @conn_state: The connector state containing the job to queue
>   *
> - * This function adds a job to the job_queue for a writeback connector. It
> - * should be considered to take ownership of the writeback job, and so any 
> other
> - * references to the job must be cleared after calling this function.
> + * This function adds the job contained in @conn_state to the job_queue for a
> + * writeback connector. It takes ownership of the writeback job and sets the
> + * @conn_state->writeback_job to NULL, and so no access to the job may be
> + * performed by the caller after this function returns.
>   *
>   * Drivers must ensure that for a given writeback connector, jobs are queued 
> in
>   * exactly the same order as they will be completed by the hardware (and
> @@ -258,10 +259,14 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
>   * See also: drm_writeback_signal_completion()
>   */
>  void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
> -  struct drm_writeback_job *job)
> +  struct drm_connector_state *conn_state)
>  {
> + struct drm_writeback_job *job;
>   unsigned long flags;
>  
> + job = conn_state->writeback_job;
> + conn_state->writeback_job = NULL;
> +
>   spin_lock_irqsave(_connector->job_lock, flags);
>   list_add_tail(>list_entry, _connector->job_queue);
>   spin_unlock_irqrestore(_connector->job_lock, flags);
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index aa279b5b0de7..5dabd91f2d7e 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -327,7 +327,7 @@ static void vc4_txp_connector_atomic_commit(struct 
> drm_connector *conn,
>  
>   TXP_WRITE(TXP_DST_CTRL, ctrl);
>  
> - drm_writeback_queue_job(>connector, conn_state->writeback_job);
> + drm_writeback_queue_job(>connector, conn_state);
>  }
>  
>  static const struct drm_connector_helper_funcs 
> vc4_txp_connector_helper_funcs = {
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 23df9d463003..47662c362743 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -123,7 +123,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>const u32 *formats, int n_formats);
>  
>  void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
> -  struct drm_writeback_job *job);
> +  struct drm_connector_state *conn_state);
>  
>  void drm_writeback_cleanup_job(struct drm_writeback_job *job);
>  

-- 
Regards,

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

[Bug 109712] S2idle is not working on AMD Gigabyte platform

[bugzilla-daemon]

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

Bug ID: 109712
   Summary: S2idle is not working on AMD Gigabyte platform
   Product: Mesa
   Version: 18.2
  Hardware: x86-64 (AMD64)
OS: other
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: shahulhameed@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 143427
  --> https://bugs.freedesktop.org/attachment.cgi?id=143427=edit
suspend/resume error log in s2idle

I am porting Android_N and kernel 4.19.2 on  AMD Gigabyte  platform. Graphic
card is gfx9.
Porting is done successfully. Now i am working on suspend/resume.
Suspend/resume is working fine in deep mode.
But suspend/resume is not working in s2idle (Suspend to idle) mode.

during resume i found error in gpu driver.


[  105.862161] [drm:gfx_v9_0_hw_init [amdgpu]] *ERROR* KCQ enable failed
(scratch(0xC040)=0xCAFEDEAD)
[  105.862187] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of
IP block  failed -22
[  105.862210] [drm:amdgpu_device_resume [amdgpu]] *ERROR*
amdgpu_device_ip_resume failed (-22).
[  105.862215] dpm_run_callback(): pci_pm_resume+0x0/0xd6 returns -22
[  105.862345] PM: Device :03:00.0 failed to resume async: error -22

I attached complete dmesg log.

Please someone help me to resolve this issue.
Thanks and Regards,
Sk shahul.

-- 
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: [RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'

[Souptick Joarder]

Hi Ira,

On Wed, Feb 20, 2019 at 11:01 AM  wrote:
>
> From: Ira Weiny 
>
> To facilitate additional options to get_user_pages_fast() change the
> singular write parameter to be gup_flags.
>
> This patch does not change any functionality.  New functionality will
> follow in subsequent patches.
>
> Some of the get_user_pages_fast() call sites were unchanged because they
> already passed FOLL_WRITE or 0 for the write parameter.
>
> Signed-off-by: Ira Weiny 
> ---
>  arch/mips/mm/gup.c | 11 ++-
>  arch/powerpc/kvm/book3s_64_mmu_hv.c|  4 ++--
>  arch/powerpc/kvm/e500_mmu.c|  2 +-
>  arch/powerpc/mm/mmu_context_iommu.c|  4 ++--
>  arch/s390/kvm/interrupt.c  |  2 +-
>  arch/s390/mm/gup.c | 12 ++--
>  arch/sh/mm/gup.c   | 11 ++-
>  arch/sparc/mm/gup.c|  9 +
>  arch/x86/kvm/paging_tmpl.h |  2 +-
>  arch/x86/kvm/svm.c |  2 +-
>  drivers/fpga/dfl-afu-dma-region.c  |  2 +-
>  drivers/gpu/drm/via/via_dmablit.c  |  3 ++-
>  drivers/infiniband/hw/hfi1/user_pages.c|  3 ++-
>  drivers/misc/genwqe/card_utils.c   |  2 +-
>  drivers/misc/vmw_vmci/vmci_host.c  |  2 +-
>  drivers/misc/vmw_vmci/vmci_queue_pair.c|  6 --
>  drivers/platform/goldfish/goldfish_pipe.c  |  3 ++-
>  drivers/rapidio/devices/rio_mport_cdev.c   |  4 +++-
>  drivers/sbus/char/oradax.c |  2 +-
>  drivers/scsi/st.c  |  3 ++-
>  drivers/staging/gasket/gasket_page_table.c |  4 ++--
>  drivers/tee/tee_shm.c  |  2 +-
>  drivers/vfio/vfio_iommu_spapr_tce.c|  3 ++-
>  drivers/vhost/vhost.c  |  2 +-
>  drivers/video/fbdev/pvr2fb.c   |  2 +-
>  drivers/virt/fsl_hypervisor.c  |  2 +-
>  drivers/xen/gntdev.c   |  2 +-
>  fs/orangefs/orangefs-bufmap.c  |  2 +-
>  include/linux/mm.h |  4 ++--
>  kernel/futex.c |  2 +-
>  lib/iov_iter.c |  7 +--
>  mm/gup.c   | 10 +-
>  mm/util.c  |  8 
>  net/ceph/pagevec.c |  2 +-
>  net/rds/info.c |  2 +-
>  net/rds/rdma.c |  3 ++-
>  36 files changed, 81 insertions(+), 65 deletions(-)
>
> diff --git a/arch/mips/mm/gup.c b/arch/mips/mm/gup.c
> index 0d14e0d8eacf..4c2b4483683c 100644
> --- a/arch/mips/mm/gup.c
> +++ b/arch/mips/mm/gup.c
> @@ -235,7 +235,7 @@ int __get_user_pages_fast(unsigned long start, int 
> nr_pages, int write,
>   * get_user_pages_fast() - pin user pages in memory
>   * @start: starting user address
>   * @nr_pages:  number of pages from start to pin
> - * @write: whether pages will be written to
> + * @gup_flags: flags modifying pin behaviour
>   * @pages: array that receives pointers to the pages pinned.
>   * Should be at least nr_pages long.
>   *
> @@ -247,8 +247,8 @@ int __get_user_pages_fast(unsigned long start, int 
> nr_pages, int write,
>   * requested. If nr_pages is 0 or negative, returns 0. If no pages
>   * were pinned, returns -errno.
>   */
> -int get_user_pages_fast(unsigned long start, int nr_pages, int write,
> -   struct page **pages)
> +int get_user_pages_fast(unsigned long start, int nr_pages,
> +   unsigned int gup_flags, struct page **pages)
>  {
> struct mm_struct *mm = current->mm;
> unsigned long addr, len, end;
> @@ -273,7 +273,8 @@ int get_user_pages_fast(unsigned long start, int 
> nr_pages, int write,
> next = pgd_addr_end(addr, end);
> if (pgd_none(pgd))
> goto slow;
> -   if (!gup_pud_range(pgd, addr, next, write, pages, ))
> +   if (!gup_pud_range(pgd, addr, next, gup_flags & FOLL_WRITE,
> +  pages, ))
> goto slow;
> } while (pgdp++, addr = next, addr != end);
> local_irq_enable();
> @@ -289,7 +290,7 @@ int get_user_pages_fast(unsigned long start, int 
> nr_pages, int write,
> pages += nr;
>
> ret = get_user_pages_unlocked(start, (end - start) >> PAGE_SHIFT,
> - pages, write ? FOLL_WRITE : 0);
> + pages, gup_flags);
>
> /* Have to be a bit careful with return values */
> if (nr > 0) {
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
> b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index bd2dcfbf00cd..8fcb0a921e46 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -582,7 +582,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, 
> struct kvm_vcpu *vcpu,
> /* 

Re: drm bridge control from another driver

[Vinay Simha B N]

hi,

i had added one more irq control for temperature control check in adv7511,
if i call irq_proces as similar to hpd it does not work, initially if(
adv7511->alert_status == connector_status_connected) no irq works.

https://github.com/vinaysimha/kernel-msm/commit/8ee2b9104fa56765320d4846086d91b8271f5609

please suggest.

On Mon, Feb 18, 2019 at 8:49 PM Vinay Simha B N  wrote:

> added the temperature alert irq handler in adv driver , in the irq
> calling schedule_work(>hpd_work); , initially in the
> adv7511_detect , if we set status = connector_status_disconnected; later
> when irq handler calls the schedule work, hpd does not works.
> [   55.052677] [drm] Cannot find any crtc or sizes
> [   55.058786] [drm] Cannot find any crtc or sizes
>
> by default driver of adv, hpd does not works as expected, board boots
> without hdmi connected, after postboot if we connect hdmi , in irq hpd_work
> ,but to get the display we need to press ctrl+alt+backspace.
>
>
> On Thu, Feb 14, 2019 at 8:03 PM Andrzej Hajda  wrote:
>
>> On 13.02.2019 15:31, Vinay Simha B N wrote:
>> >
>> >
>> > On Wed, Feb 13, 2019 at 7:44 PM Andrzej Hajda > > > wrote:
>> >
>> > On 13.02.2019 14:40, Vinay Simha B N wrote:
>> > > Andrzej/Daniel,
>> > >
>> > > please suggest any input on the scenario for temperature control
>> and
>> > > dsi bridge enable/disable.
>> > >
>> > > On Mon, Feb 11, 2019 at 2:41 PM Vinay Simha B N
>> > mailto:simha...@gmail.com>
>> > > >> wrote:
>> > >
>> > > dsi2hdmi(adv7511) chip operating temperature range is -10 degC
>> > > to +85 degC. We want to enable/disable the bridge only when
>> > > temperature range is inbetween these range.
>> > >
>> > > We have temperature control chip to read the temp, tLow an
>> tHigh
>> > > can be set. whenever interrupt(alert) triggers we want to
>> > > enablel/disable the bridge.
>> > >
>> > > Any suggestion what is the better way to handle this scenario?
>> > >
>> >
>> > Why do you need to bother about this quite big range at all?
>> >
>> > we are looking for -10 deg C, this system will be used in a place
>> > where temp goes beyond -20 deg C... processor(apq8016/410c) can handle
>> > upto -30, but dsi2hdmi(adv7533) chip if enabled beyond -10 deg C, life
>> > of the chip goes down or it cannot operate at all.
>> >
>> >
>> > I guess the best would be to set whole platform operating
>> temperature
>> > range, and poweroff/sleep/slow down/??? whole system, not just one
>> > random chip, which probably is not the most fragile piece, am I
>> right?
>> >
>> > right now we are focused only to disable the hdmi chip if temp goes
>> > beyond -10, since this is only chip in board faces temp issue, other
>> > components are fine to go upto -30 deg C.
>> >
>> >
>> > If you really insist on handling it per chip, you can try to
>> > investigate
>> > following paths:
>> >
>> > 1. Just disable the chip, without noticing drm, other drivers, or
>> > userspace, and re-enable it if temperature become acceptable, but I
>> am
>> > not sure if this will not change behavior of other chips.
>> >
>> > dsi2hdmi tied with drm framework, i need to enable/disable the bridge.
>> > i can disable the regulators enabled for it , but this does not work
>> > as we want.
>> >
>> >
>> > 2. Disable the chip and report to the drm subsystem
>> > connector_status_disconnected - this will cause drm to stop display
>> > pipeline and userspace notification.
>> >
>> > any references/driver on how to disable and report to drm susbsystem
>> > will help to implement.
>> > connector_status_disconnected i need to call in the interrupt handler
>> > of tmp102 driver.
>>
>>
>> Look at the code of adv7511_hpd_work, it evaluates connector status
>> based on ADV7511_REG_STATUS, so you can put there temperature check
>> also, and call 'schedule_work(>hpd_work)'
>>
>> if temperature passes valid temp range.
>>
>> If you want to do it in mainline, please consult it with adv7511
>> authors/commiters.
>>
>>
>> Regards
>>
>> Andrzej
>>
>>
>> >
>> > in userspace when i tried manually  below commands, there is no impact
>> > in the display.
>> > /sys/class/drm/card0-HDMI-A-1/status
>> > echo off > status
>> > echo on > status
>> >
>> >
>> > Regards
>> >
>> > Andrzej
>> >
>> >
>> > >
>> > > regards,
>> > > vinaysimha
>> > >
>> > > On Mon, Feb 11, 2019 at 2:10 PM Daniel Vetter
>> > mailto:dan...@ffwll.ch>
>> > > >> wrote:
>> > >
>> > > On Mon, Feb 11, 2019 at 09:32:54AM +0100, Andrzej Hajda
>> > wrote:
>> > > > On 11.02.2019 07:52, Vinay Simha B N wrote:
>> > > > > hi,
>> > > > >
>> > > > > is it possible to control the drm bridge from another

Re: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest

[Frank Rowand]

On 2/18/19 2:25 PM, Frank Rowand wrote:
> On 2/15/19 2:56 AM, Brendan Higgins wrote:
>> On Thu, Feb 14, 2019 at 6:05 PM Frank Rowand  wrote:
>>>
>>> On 2/14/19 4:56 PM, Brendan Higgins wrote:
 On Thu, Feb 14, 2019 at 3:57 PM Frank Rowand  
 wrote:
>
> On 12/5/18 3:54 PM, Brendan Higgins wrote:
>> On Tue, Dec 4, 2018 at 2:58 AM Frank Rowand  
>> wrote:
>>>

< snip >

>
> It makes it harder for me to read the source of the tests and
> understand the order they will execute.  It also makes it harder
> for me to read through the actual tests (in this example the
> tests that are currently grouped in of_unittest_find_node_by_name())
> because of all the extra function headers injected into the
> existing single function to break it apart into many smaller
> functions.

< snip >

 This is not something I feel particularly strongly about, it is just
 pretty atypical from my experience to have so many unrelated test
 cases in a single file.

 Maybe you would prefer that I break up the test cases first, and then
 we split up the file as appropriate?
>>>
>>> I prefer that the test cases not be broken up arbitrarily.  There _may_

I expect that I created confusion by putting this in a reply to patch 18/19.
It is actually a comment about patch 19/19.  Sorry about that.


>>
>> I wasn't trying to break them up arbitrarily. I thought I was doing it
>> according to a pattern (breaking up the file, that is), but maybe I
>> just hadn't looked at enough examples.
> 
> This goes back to the kunit model of putting each test into a separate
> function that can be a KUNIT_CASE().  That is a model that I do not agree
> with for devicetree.

So now that I am actually talking about patch 19/19, let me give a concrete
example.  I will cut and paste (after my comments), the beginning portion
of base-test.c, after applying patch 19/19 (the "base version".  Then I
will cut and paste my alternative version which does not break the tests
down into individual functions (the "frank version").

I will also reply to this email with the base version and the frank version
as attachments, which will make it easier to save as separate versions
for easier viewing.  I'm not sure if an email with attachments will make
it through the list servers, but I am cautiously optimistic.

I am using v4 of the patch series because I never got v3 to cleanly apply
and it is not a constructive use of my time to do so since I have v4 applied.

One of the points I was trying to make is that readability suffers from the
approach taken by patches 18/19 and 19/19.

The base version contains the extra text of a function header for each
unit test.  This is visual noise and makes the file larger.  It is also
one more possible location of an error (although not likely).

The frank version has converted each of the new function headers into
a comment, using the function name with '_' converted to ' '.  The
comments are more readable than the function headers.  Note that I added
an extra blank line before each comment, which violates the kernel
coding standards, but I feel this makes the code more readable.

The base version needs to declare each of the individual test functions
in of_test_find_node_by_name_cases[]. It is possible that a test function
could be left out of of_test_find_node_by_name_cases[], in error.  This
will result in a compile warning (I think warning instead of error, but
I have not verified that) so the error might be caught or it might be
overlooked.

In the base version, the order of execution of the test code requires
bouncing back and forth between the test functions and the coding of
of_test_find_node_by_name_cases[].

In the frank version the order of execution of the test code is obvious.

It is possible that a test function could be left out of
of_test_find_node_by_name_cases[], in error.  This will result in a compile
warning (I think warning instead of error, but I have not verified that)
so it might be caught or it might be overlooked.

The base version is 265 lines.  The frank version is 208 lines, 57 lines
less.  Less is better.


## ==  base version  

// SPDX-License-Identifier: GPL-2.0
/*
 * Unit tests for functions defined in base.c.
 */
#include 

#include 

#include "test-common.h"

static void of_test_find_node_by_name_basic(struct kunit *test)
{
struct device_node *np;
const char *name;

np = of_find_node_by_path("/testcase-data");
name = kasprintf(GFP_KERNEL, "%pOF", np);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
KUNIT_EXPECT_STREQ_MSG(test, "/testcase-data", name,
   "find /testcase-data failed\n");
of_node_put(np);
kfree(name);
}

static void of_test_find_node_by_name_trailing_slash(struct kunit *test)
{
/* Test if trailing '/' works */
KUNIT_EXPECT_EQ_MSG(test, of_find_node_by_path("/testcase-data/"), NULL,

Re: [PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API

[Souptick Joarder]

On Fri, Feb 15, 2019 at 8:06 AM Souptick Joarder  wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized by creating new functions and use it across
> the drivers.
>
> vm_map_pages() is the API which could be used to map
> kernel memory/pages in drivers which has considered vm_pgoff.
>
> vm_map_pages_zero() is the API which could be used to map
> range of kernel memory/pages in drivers which has not considered
> vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
>
> We _could_ then at a later "fix" these drivers which are using
> vm_map_pages_zero() to behave according to the normal vm_pgoff
> offsetting simply by removing the _zero suffix on the function
> name and if that causes regressions, it gives us an easy way to revert.
>
> Tested on Rockchip hardware and display is working fine, including talking
> to Lima via prime.
>
> v1 -> v2:
> Few Reviewed-by.
>
> Updated the change log in [8/9]
>
> In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie'
> to select a buffer, not as a in-buffer offset by design
> and it always want to mmap a whole buffer from its beginning.
> Added additional changes after discussing with Marek and
> vm_map_pages() could be used instead of vm_map_pages_zero().
>
> v2 -> v3:
> Corrected the documentation as per review comment.
>
> As suggested in v2, renaming the interfaces to -
> *vm_insert_range() -> vm_map_pages()* and
> *vm_insert_range_buggy() -> vm_map_pages_zero()*.
> As the interface is renamed, modified the code accordingly,
> updated the change logs and modified the subject lines to use the
> new interfaces. There is no other change apart from renaming and
> using the new interface.
>
> Patch[1/9] & [4/9], Tested on Rockchip hardware.
>
> v3 -> v4:
> Fixed build warnings on patch [8/9] reported by kbuild test robot.
>
> Souptick Joarder (9):
>   mm: Introduce new vm_map_pages() and vm_map_pages_zero() API
>   arm: mm: dma-mapping: Convert to use vm_map_pages()
>   drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero()
>   drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages()
>   drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages()
>   iommu/dma-iommu.c: Convert to use vm_map_pages()
>   videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages()
>   xen/gntdev.c: Convert to use vm_map_pages()
>   xen/privcmd-buf.c: Convert to use vm_map_pages_zero()

If no further comment, is it fine to take these patches to -mm
tree for regression ?

>
>  arch/arm/mm/dma-mapping.c  | 22 ++
>  drivers/firewire/core-iso.c| 15 +---
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 17 +
>  drivers/gpu/drm/xen/xen_drm_front_gem.c| 18 ++---
>  drivers/iommu/dma-iommu.c  | 12 +---
>  drivers/media/common/videobuf2/videobuf2-core.c|  7 ++
>  .../media/common/videobuf2/videobuf2-dma-contig.c  |  6 --
>  drivers/media/common/videobuf2/videobuf2-dma-sg.c  | 22 ++
>  drivers/xen/gntdev.c   | 11 ++-
>  drivers/xen/privcmd-buf.c  |  8 +--
>  include/linux/mm.h |  4 ++
>  mm/memory.c| 81 
> ++
>  mm/nommu.c | 14 
>  13 files changed, 134 insertions(+), 103 deletions(-)
>
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm/tinydrm: Trivia typo fix

[Noralf Trønnes]

Den 19.02.2019 19.13, skrev Andy Shevchenko:
> Fix adddress -> address typo.
> 
> Signed-off-by: Andy Shevchenko 
> ---

Applied, thanks.

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

[PATCH] drm/i915: remove redundant likely/unlikely annotation

[Chengguang Xu]

unlikely has already included in IS_ERR(), so just
remove redundant likely/unlikely annotation.

Signed-off-by: Chengguang Xu 
---
 drivers/gpu/drm/i915/i915_gem.c| 4 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c882ea94172c..01c131077fc5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2603,7 +2603,7 @@ static int i915_gem_object_get_pages_gtt(struct 
drm_i915_gem_object *obj)
do {
cond_resched();
page = shmem_read_mapping_page_gfp(mapping, i, gfp);
-   if (likely(!IS_ERR(page)))
+   if (!IS_ERR(page))
break;
 
if (!*s) {
@@ -4477,7 +4477,7 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
}
 
vma = i915_vma_instance(obj, vm, view);
-   if (unlikely(IS_ERR(vma)))
+   if (IS_ERR(vma))
return vma;
 
if (i915_vma_misplaced(vma, size, alignment, flags)) {
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 485b259127c3..e40aee95af74 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -788,7 +788,7 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
}
 
vma = i915_vma_instance(obj, eb->vm, NULL);
-   if (unlikely(IS_ERR(vma))) {
+   if (IS_ERR(vma)) {
err = PTR_ERR(vma);
goto err_obj;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bd17dd1f5da5..915323c3b3d9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3826,7 +3826,7 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
}
 
ret = 0;
-   if (unlikely(IS_ERR(vma->pages))) {
+   if (IS_ERR(vma->pages)) {
ret = PTR_ERR(vma->pages);
vma->pages = NULL;
DRM_ERROR("Failed to get pages for VMA view type %u (%d)!\n",
-- 
2.20.1

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

Re: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest

[Frank Rowand]

On 2/20/19 12:44 PM, Frank Rowand wrote:
> On 2/18/19 2:25 PM, Frank Rowand wrote:
>> On 2/15/19 2:56 AM, Brendan Higgins wrote:
>>> On Thu, Feb 14, 2019 at 6:05 PM Frank Rowand  wrote:

 On 2/14/19 4:56 PM, Brendan Higgins wrote:
> On Thu, Feb 14, 2019 at 3:57 PM Frank Rowand  
> wrote:
>>
>> On 12/5/18 3:54 PM, Brendan Higgins wrote:
>>> On Tue, Dec 4, 2018 at 2:58 AM Frank Rowand  
>>> wrote:

> 
> < snip >
> 
>>
>> It makes it harder for me to read the source of the tests and
>> understand the order they will execute.  It also makes it harder
>> for me to read through the actual tests (in this example the
>> tests that are currently grouped in of_unittest_find_node_by_name())
>> because of all the extra function headers injected into the
>> existing single function to break it apart into many smaller
>> functions.
> 
> < snip >
> 
> This is not something I feel particularly strongly about, it is just
> pretty atypical from my experience to have so many unrelated test
> cases in a single file.
>
> Maybe you would prefer that I break up the test cases first, and then
> we split up the file as appropriate?

 I prefer that the test cases not be broken up arbitrarily.  There _may_
> 
> I expect that I created confusion by putting this in a reply to patch 18/19.
> It is actually a comment about patch 19/19.  Sorry about that.
> 
> 
>>>
>>> I wasn't trying to break them up arbitrarily. I thought I was doing it
>>> according to a pattern (breaking up the file, that is), but maybe I
>>> just hadn't looked at enough examples.
>>
>> This goes back to the kunit model of putting each test into a separate
>> function that can be a KUNIT_CASE().  That is a model that I do not agree
>> with for devicetree.
> 
> So now that I am actually talking about patch 19/19, let me give a concrete
> example.  I will cut and paste (after my comments), the beginning portion
> of base-test.c, after applying patch 19/19 (the "base version".  Then I
> will cut and paste my alternative version which does not break the tests
> down into individual functions (the "frank version").
> 
> I will also reply to this email with the base version and the frank version
> as attachments, which will make it easier to save as separate versions
> for easier viewing.  I'm not sure if an email with attachments will make
> it through the list servers, but I am cautiously optimistic.

base_version and frank_version attached.

-Frank


> 
> I am using v4 of the patch series because I never got v3 to cleanly apply
> and it is not a constructive use of my time to do so since I have v4 applied.
> 
> One of the points I was trying to make is that readability suffers from the
> approach taken by patches 18/19 and 19/19.
> 
> The base version contains the extra text of a function header for each
> unit test.  This is visual noise and makes the file larger.  It is also
> one more possible location of an error (although not likely).
> 
> The frank version has converted each of the new function headers into
> a comment, using the function name with '_' converted to ' '.  The
> comments are more readable than the function headers.  Note that I added
> an extra blank line before each comment, which violates the kernel
> coding standards, but I feel this makes the code more readable.
> 
> The base version needs to declare each of the individual test functions
> in of_test_find_node_by_name_cases[]. It is possible that a test function
> could be left out of of_test_find_node_by_name_cases[], in error.  This
> will result in a compile warning (I think warning instead of error, but
> I have not verified that) so the error might be caught or it might be
> overlooked.
> 
> In the base version, the order of execution of the test code requires
> bouncing back and forth between the test functions and the coding of
> of_test_find_node_by_name_cases[].
> 
> In the frank version the order of execution of the test code is obvious.
> 
> It is possible that a test function could be left out of
> of_test_find_node_by_name_cases[], in error.  This will result in a compile
> warning (I think warning instead of error, but I have not verified that)
> so it might be caught or it might be overlooked.
> 
> The base version is 265 lines.  The frank version is 208 lines, 57 lines
> less.  Less is better.
> 
> 
> ## ==  base version  
> 
> // SPDX-License-Identifier: GPL-2.0
> /*
>  * Unit tests for functions defined in base.c.
>  */
> #include 
> 
> #include 
> 
> #include "test-common.h"
> 
> static void of_test_find_node_by_name_basic(struct kunit *test)
> {
>   struct device_node *np;
>   const char *name;
> 
>   np = of_find_node_by_path("/testcase-data");
>   name = kasprintf(GFP_KERNEL, "%pOF", np);
>   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
>   KUNIT_EXPECT_STREQ_MSG(test, "/testcase-data", name,
>  "find 

[PATCH] drm/vmwgfx: remove redundant unlikely annotation

[Chengguang Xu]

unlikely has already included in IS_ERR(), so just
remove redundant unlikely annotation.

Signed-off-by: Chengguang Xu 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 14bd760a62fd..694fabafaeee 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -210,7 +210,7 @@ static int vmw_gb_context_init(struct vmw_private *dev_priv,
for (i = 0; i < SVGA_COTABLE_DX10_MAX; ++i) {
uctx->cotables[i] = vmw_cotable_alloc(dev_priv,
  >res, i);
-   if (unlikely(IS_ERR(uctx->cotables[i]))) {
+   if (IS_ERR(uctx->cotables[i])) {
ret = PTR_ERR(uctx->cotables[i]);
goto out_cotables;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 88b8178d4687..1cde07cf3067 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -638,7 +638,7 @@ vmw_cmd_res_check(struct vmw_private *dev_priv,
 
res = vmw_user_resource_noref_lookup_handle
(dev_priv, sw_context->fp->tfile, *id_loc, converter);
-   if (unlikely(IS_ERR(res))) {
+   if (IS_ERR(res)) {
DRM_ERROR("Could not find or use resource 0x%08x.\n",
  (unsigned int) *id_loc);
return PTR_ERR(res);
@@ -3799,7 +3799,7 @@ static int vmw_execbuf_tie_context(struct vmw_private 
*dev_priv,
res = vmw_user_resource_noref_lookup_handle
(dev_priv, sw_context->fp->tfile, handle,
 user_context_converter);
-   if (unlikely(IS_ERR(res))) {
+   if (IS_ERR(res)) {
DRM_ERROR("Could not find or user DX context 0x%08x.\n",
  (unsigned) handle);
return PTR_ERR(res);
-- 
2.20.1

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

[Bug 109714] Unable to Compile R200 driver: "Options 'r200' are not allowed..."

[bugzilla-daemon]

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

Bug ID: 109714
   Summary: Unable to Compile R200 driver: "Options 'r200' are not
allowed..."
   Product: Mesa
   Version: 18.3
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: emorie...@yahoo.com
QA Contact: dri-devel@lists.freedesktop.org

On Ubuntu 18.04LTS, 18.04.1LTS, and Ubuntu 18.04.2LTS, as well as Ubuntu 18.10,
and even with Oibaf's PPA for those released, the R200 driver is not included,
causing the Radeon 9000M (rv250) on my ThinkPad T42 to default to the LLVMPipe
driver.

When attempting to compile Mesa with the R200 driver, on Solus, Meson spits out
the following error: ERROR:  Options "r200" are not in allowed choices: ",
auto, kmsro, radeonsi, r300, r600, nouveau, freedreno, swrast, v3d, vc4,
etnaviv, tegra, i915, svga, virgl, swr, panfrost".

Any idea why I cannot compile the R200 driver?

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

[PATCH] drm/bochs: Fix the ID mismatch error

[Alistair Francis]

When running RISC-V QEMU with the Bochs device attached via PCIe the
probe of the Bochs device fails with:
[drm:bochs_hw_init] *ERROR* ID mismatch

This was introduced by this commit:
7780eb9ce8 bochs: convert to drm_dev_register

To fix the error we ensure that pci_enable_device() is called before
bochs_load().

Signed-off-by: Alistair Francis 
Reported-by: David Abdurachmanov 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index f3dd66ae990a..aa35007262cd 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -154,6 +154,10 @@ static int bochs_pci_probe(struct pci_dev *pdev,
if (IS_ERR(dev))
return PTR_ERR(dev);
 
+   ret = pci_enable_device(pdev);
+   if (ret)
+   goto err_free_dev;
+
dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
 
-- 
2.20.1

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

[PATCH -next] drm/nouveau/dmem: remove set but not used variable 'drm'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/nouveau/nouveau_dmem.c: In function 'nouveau_dmem_free':
drivers/gpu/drm/nouveau/nouveau_dmem.c:103:22: warning:
 variable 'drm' set but not used [-Wunused-but-set-variable]
  struct nouveau_drm *drm;
  ^

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index aa9fec80492d..900a302b7ce9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -100,12 +100,10 @@ static void
 nouveau_dmem_free(struct hmm_devmem *devmem, struct page *page)
 {
struct nouveau_dmem_chunk *chunk;
-   struct nouveau_drm *drm;
unsigned long idx;
 
chunk = (void *)hmm_devmem_page_get_drvdata(page);
idx = page_to_pfn(page) - chunk->pfn_first;
-   drm = chunk->drm;
 
/*
 * FIXME:





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

Re: [RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'

[Mike Marshall]

Hi Ira

Martin and I looked at your patch and agree that it doesn't change
functionality for Orangefs.

Reviewed-by: Mike Marshall 



On Wed, Feb 20, 2019 at 12:32 AM  wrote:
>
> From: Ira Weiny 
>
> To facilitate additional options to get_user_pages_fast() change the
> singular write parameter to be gup_flags.
>
> This patch does not change any functionality.  New functionality will
> follow in subsequent patches.
>
> Some of the get_user_pages_fast() call sites were unchanged because they
> already passed FOLL_WRITE or 0 for the write parameter.
>
> Signed-off-by: Ira Weiny 
> ---
>  arch/mips/mm/gup.c | 11 ++-
>  arch/powerpc/kvm/book3s_64_mmu_hv.c|  4 ++--
>  arch/powerpc/kvm/e500_mmu.c|  2 +-
>  arch/powerpc/mm/mmu_context_iommu.c|  4 ++--
>  arch/s390/kvm/interrupt.c  |  2 +-
>  arch/s390/mm/gup.c | 12 ++--
>  arch/sh/mm/gup.c   | 11 ++-
>  arch/sparc/mm/gup.c|  9 +
>  arch/x86/kvm/paging_tmpl.h |  2 +-
>  arch/x86/kvm/svm.c |  2 +-
>  drivers/fpga/dfl-afu-dma-region.c  |  2 +-
>  drivers/gpu/drm/via/via_dmablit.c  |  3 ++-
>  drivers/infiniband/hw/hfi1/user_pages.c|  3 ++-
>  drivers/misc/genwqe/card_utils.c   |  2 +-
>  drivers/misc/vmw_vmci/vmci_host.c  |  2 +-
>  drivers/misc/vmw_vmci/vmci_queue_pair.c|  6 --
>  drivers/platform/goldfish/goldfish_pipe.c  |  3 ++-
>  drivers/rapidio/devices/rio_mport_cdev.c   |  4 +++-
>  drivers/sbus/char/oradax.c |  2 +-
>  drivers/scsi/st.c  |  3 ++-
>  drivers/staging/gasket/gasket_page_table.c |  4 ++--
>  drivers/tee/tee_shm.c  |  2 +-
>  drivers/vfio/vfio_iommu_spapr_tce.c|  3 ++-
>  drivers/vhost/vhost.c  |  2 +-
>  drivers/video/fbdev/pvr2fb.c   |  2 +-
>  drivers/virt/fsl_hypervisor.c  |  2 +-
>  drivers/xen/gntdev.c   |  2 +-
>  fs/orangefs/orangefs-bufmap.c  |  2 +-
>  include/linux/mm.h |  4 ++--
>  kernel/futex.c |  2 +-
>  lib/iov_iter.c |  7 +--
>  mm/gup.c   | 10 +-
>  mm/util.c  |  8 
>  net/ceph/pagevec.c |  2 +-
>  net/rds/info.c |  2 +-
>  net/rds/rdma.c |  3 ++-
>  36 files changed, 81 insertions(+), 65 deletions(-)
>
> diff --git a/arch/mips/mm/gup.c b/arch/mips/mm/gup.c
> index 0d14e0d8eacf..4c2b4483683c 100644
> --- a/arch/mips/mm/gup.c
> +++ b/arch/mips/mm/gup.c
> @@ -235,7 +235,7 @@ int __get_user_pages_fast(unsigned long start, int 
> nr_pages, int write,
>   * get_user_pages_fast() - pin user pages in memory
>   * @start: starting user address
>   * @nr_pages:  number of pages from start to pin
> - * @write: whether pages will be written to
> + * @gup_flags: flags modifying pin behaviour
>   * @pages: array that receives pointers to the pages pinned.
>   * Should be at least nr_pages long.
>   *
> @@ -247,8 +247,8 @@ int __get_user_pages_fast(unsigned long start, int 
> nr_pages, int write,
>   * requested. If nr_pages is 0 or negative, returns 0. If no pages
>   * were pinned, returns -errno.
>   */
> -int get_user_pages_fast(unsigned long start, int nr_pages, int write,
> -   struct page **pages)
> +int get_user_pages_fast(unsigned long start, int nr_pages,
> +   unsigned int gup_flags, struct page **pages)
>  {
> struct mm_struct *mm = current->mm;
> unsigned long addr, len, end;
> @@ -273,7 +273,8 @@ int get_user_pages_fast(unsigned long start, int 
> nr_pages, int write,
> next = pgd_addr_end(addr, end);
> if (pgd_none(pgd))
> goto slow;
> -   if (!gup_pud_range(pgd, addr, next, write, pages, ))
> +   if (!gup_pud_range(pgd, addr, next, gup_flags & FOLL_WRITE,
> +  pages, ))
> goto slow;
> } while (pgdp++, addr = next, addr != end);
> local_irq_enable();
> @@ -289,7 +290,7 @@ int get_user_pages_fast(unsigned long start, int 
> nr_pages, int write,
> pages += nr;
>
> ret = get_user_pages_unlocked(start, (end - start) >> PAGE_SHIFT,
> - pages, write ? FOLL_WRITE : 0);
> + pages, gup_flags);
>
> /* Have to be a bit careful with return values */
> if (nr > 0) {
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
> b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index bd2dcfbf00cd..8fcb0a921e46 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ 

Re: [PATCH V5 5/8] clk: mediatek: add MUX_GATE_FLAGS_2

[mtk14994]

Dear Stephen,
> +   unsigned char mux_flags;
> 
> Why isn't it an unsigned long? Isn't this supposed to match the
> frameworks version of the clk flags?

>   it is unsigned char mux_flags ,becasuse struct clk_mux {



u8 flags;

}

it is matched when use " mux->flags = mc->mux_flags;"

Best Regards
Wangyan



On Wed, 2019-02-20 at 11:37 -0800, Stephen Boyd wrote:
> Quoting wangyan wang (2019-02-19 18:53:54)
> > From: chunhui dai 
> > 
> > Add MUX_GATE_FLAGS_2 for the clock which needs to set two falgs.
> 
> s/falgs/flags/
> 
> > Such as some mux need to set the flags of "CLK_MUX_ROUND_CLOSEST".
> > 
> > Signed-off-by: chunhui dai 
> > Signed-off-by: wangyan wang 
> > ---
> >  drivers/clk/mediatek/clk-mtk.c |  2 +-
> >  drivers/clk/mediatek/clk-mtk.h | 20 ++--
> >  2 files changed, 15 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> > index 9c0ae4278a94..2ed996404804 100644
> > --- a/drivers/clk/mediatek/clk-mtk.c
> > +++ b/drivers/clk/mediatek/clk-mtk.c
> > @@ -167,7 +167,7 @@ struct clk *mtk_clk_register_composite(const struct 
> > mtk_composite *mc,
> > mux->mask = BIT(mc->mux_width) - 1;
> > mux->shift = mc->mux_shift;
> > mux->lock = lock;
> > -
> > +   mux->flags = mc->mux_flags;
> > mux_hw = >hw;
> > mux_ops = _mux_ops;
> >  
> > diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> > index f83c2bbb677e..4b88d196d52f 100644
> > --- a/drivers/clk/mediatek/clk-mtk.h
> > +++ b/drivers/clk/mediatek/clk-mtk.h
> > @@ -81,15 +81,13 @@ struct mtk_composite {
> > signed char divider_shift;
> > signed char divider_width;
> >  
> > +   unsigned char mux_flags;
> 
> Why isn't it an unsigned long? Isn't this supposed to match the
> frameworks version of the clk flags?
> 
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


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

Re: [PATCH] drm/qxl: unbind vgacon

[Gerd Hoffmann]

> > +   /* unbind vgacon to make sure it doesn't touch our vga registers */
> > +   console_lock();
> > +   ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, true);
> > +   console_unlock();
> 
> Still seems very late, in i915 we kick out vgacon as pretty much the first
> thing in driver load. See i915_kick_out_vgacon.

So the idea isn't completely silly ...

thanks for the pointer,
  Gerd

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

RE: [PATCH] drm: add func to better detect wether swiotlb is needed

[Paul Durrant]

> -Original Message-
> From: Michael D Labriola [mailto:michael.d.labri...@gmail.com]
> Sent: 19 February 2019 23:08
> To: dri-devel@lists.freedesktop.org; Alex Deucher
> ; Christian Koenig ;
> Chunming Zhou ; amd-...@lists.freedesktop.org; Monk
> Liu 
> Cc: Juergen Gross ; Christoph Hellwig
> ; Andrew Cooper ; Paul
> Durrant ; xen-de...@lists.xen.org; Jan Beulich
> ; Konrad Rzeszutek Wilk ;
> Michael D Labriola 
> Subject: [PATCH] drm: add func to better detect wether swiotlb is needed
> 
> This commit fixes DRM failures on Xen PV systems that were introduced in
> v4.17 by the following commits:
> 
> 82626363 drm: add func to get max iomem address v2
> fd5fd480 drm/amdgpu: only enable swiotlb alloc when need v2
> 1bc3d3cc drm/radeon: only enable swiotlb path when need v2
> 
> The introduction of ->need_swiotlb to the ttm_dma_populate() conditionals
> in the radeon and amdgpu device drivers causes Gnome to immediately crash
> on Xen PV systems, returning the user to the login screen.  The following
> kernel errors get logged:
> 
> [   28.554259] radeon_dp_aux_transfer_native: 200 callbacks suppressed
> [   31.219821] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [   31.220030] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [   31.226109] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [   31.226300] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [   31.300734] gnome-shell[1935]: segfault at 88 ip 7f39151cd904 sp
> 7ffc97611ad8 error 4 in libmutter-cogl.so[7f3915178000+aa000]
> [   31.300745] Code: 5f c3 0f 1f 40 00 48 8b 47 78 48 8b 40 40 ff e0 66 0f
> 1f 44 00 00 48 8b 47 78 48 8b 40 48 ff e0 66 0f 1f 44 00 00 48 8b 47 78
> <48> 8b 80 88 00 00 00 ff e0 0f 1f 00 48 8b 47 78 48 8b 40 68 ff e0
> [   38.193302] radeon_dp_aux_transfer_native: 116 callbacks suppressed
> [   40.009317] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [   40.009488] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [   40.015114] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [   40.015297] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [   40.028302] gnome-shell[2431]: segfault at 2dadf40 ip 02dadf40
> sp 7ffcd24ea5f8 error 15
> [   40.028306] Code: 20 6e 31 00 00 00 00 00 00 00 00 37 e3 3d 2d 7f 00 00
> 80 f4 e6 3d 2d 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> <00> 00 00 00 00 00 00 00 c1 00 00 00 00 00 00 00 80 e1 d2 03 00 00
> 
> This commit renames drm_get_max_iomem() to drm_need_swiotlb(), adds a
> xen_pv_domain() check to it, and moves the bit shifting comparison that
> always follows its usage into the function (simplifying the drm driver
> code).
> 
> Signed-off-by: Michael D Labriola 
> ---
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  2 +-
>  drivers/gpu/drm/drm_memory.c   | 19 ---
>  drivers/gpu/drm/radeon/radeon_device.c |  2 +-
>  include/drm/drm_cache.h|  2 +-
>  6 files changed, 21 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index 910c4ce..6bc0266 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -1029,7 +1029,7 @@ static int gmc_v7_0_sw_init(void *handle)
>   pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
>   pr_warn("amdgpu: No coherent DMA available\n");
>   }
> - adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
> + adev->need_swiotlb = drm_need_swiotlb(dma_bits);
> 
>   r = gmc_v7_0_init_microcode(adev);
>   if (r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index 747c068..8638adf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -1155,7 +1155,7 @@ static int gmc_v8_0_sw_init(void *handle)
>   pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
>   pr_warn("amdgpu: No coherent DMA available\n");
>   }
> - adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
> + adev->need_swiotlb = drm_need_swiotlb(dma_bits);
> 
>   r = gmc_v8_0_init_microcode(adev);
>   if (r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index f35d7a5..4f67093 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -989,7 +989,7 @@ static int gmc_v9_0_sw_init(void *handle)
>   pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
>   

[Bug 109719] Collect pstore data and attach it to dmesg output when resuming or reporting

[bugzilla-daemon]

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

Bug ID: 109719
   Summary: Collect pstore data and attach it to dmesg output when
resuming or reporting
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: martin.pe...@free.fr

This will allow cibuglog filters to be more targetted for incompletes that have
a pstore (the majority of them).

-- 
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/2] drm/qxl: kick out vgacon

[Gerd Hoffmann]

On Thu, Feb 21, 2019 at 01:20:11PM +0100, Daniel Vetter wrote:
> On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote:
> > Problem:  qxl switches from native mode back into vga compatibility mode
> > when it notices someone is accessing vga registers.  And vgacon does
> > exactly that before fbcon takes over.  So make sure we kick out vgacon
> > early enough that it wouldn't disturb us.
> > 
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  drivers/gpu/drm/qxl/qxl_drv.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > index bb81e310eb..08446561aa 100644
> > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > @@ -95,6 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> > pci_device_id *ent)
> > goto modeset_cleanup;
> >  
> > drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
> > +   drm_fb_helper_kick_out_vgacon();
> 
> I was thinking of checking whether pdev is a VGA class device and whether
> it decodes vga access, and in that case automatically calling
> kick_out_vgacon from remove_conflicting_pci_framebuffer. Since that's what
> drivers want anyway, and those who don't can open code it.
> 
> Or is there an issue with that?

It'll need more careful testing to make sure we don't have unwanted side
effects when just doing it for everyone.  And I guess most drivers don't
care much because their hardware ignores vga port writes once they are
switched out of vga text mode.

Dunno why i915 needs this.

In case of qxl it is more a historical leftover.  The very first qxl
device revision had no explicit qxl command to switch from qxl native
mode back to vga compatibility mode, vga port access was used for that
instead.  It's long fixed, but the qxl device still has that quirk for
compatibility with very old guest drivers.

cheers,
  Gerd

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

Re: [PATCH v4 0/7] VSP1: Display writeback support

[Brian Starkey]

Hi Laurent,

On Thu, Feb 21, 2019 at 10:23:17AM +0200, Laurent Pinchart wrote:
> Hi Brian,
> 
> On Mon, Feb 18, 2019 at 12:22:58PM +, Brian Starkey wrote:
> > On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > This patch series implements display writeback support for the R-Car
> > > Gen3 platforms in the VSP1 driver.
> > > 
> > > DRM/KMS provides a writeback API through a special type of writeback
> > > connectors. This series takes a different approach by exposing writeback
> > > as a V4L2 device. While there is nothing fundamentally wrong with
> > > writeback connectors, display for R-Car Gen3 platforms relies on the
> > > VSP1 driver behind the scene, which already implements V4L2 support.
> > > Enabling writeback through V4L2 is thus significantly easier in this
> > > case.
> > 
> > How does this look to an application? (I'm entirely ignorant about
> > R-Car). They are interacting with the DRM device, and then need to
> > open and configure a v4l2 device to get the writeback? Can the process
> > which isn't controlling the DRM device independently capture the
> > screen output?
> > 
> > I didn't see any major complication to implementing this as a
> > writeback connector. If you want/need to use the vb2_queue, couldn't
> > you just do that entirely from within the kernel?
> > 
> > Honestly (predictably?), to me it seems like a bad idea to introduce a
> > second, non-compatible interface for display writeback. Any
> > application interested in display writeback (e.g. compositors) will
> > need to implement both in order to support all HW. drm_hwcomposer
> > already supports writeback via DRM writeback connectors.
> > 
> > While I can see the advantages of having writeback exposed via v4l2
> > for streaming use-cases, I think it would be better to have it done in
> > such a way that it works for all writeback connectors, rather than
> > being VSP1-specific. That would allow any application to choose
> > whichever method is most appropriate for their use-case, without
> > limiting themselves to a subset of hardware.
> 
> So I gave writeback connectors a go, and it wasn't very pretty.

Sorry you didn't have a good time :-(

> There writeback support in the DRM core leaks jobs,

Is this the cleanup on check fail, or something else?

One possible pitfall is that you must set the job in the connector
state to NULL after you call drm_writeback_queue_job(). The API there
could easily be changed to pass in the connector_state and clear it in
drm_writeback_queue_job() instead of relying on drivers to do it.

> and is missing support for
> the equivalent of .prepare_fb()/.cleanup_fb(), which requires per-job
> driver-specific data. I'm working on these issues and will submit
> patches.
> 

Hm, yes that didn't occur to me; we don't have a prepare_fb callback.

> In the meantime, I need to test my implementation, so I need a command
> line application that will let me exercise the API. I assume you've
> tested your code, haven't you ? :-) Could you tell me how I can test
> writeback ?

Indeed, there's igts on the list which I wrote and tested:

https://patchwork.kernel.org/patch/10764975/

And there's support in drm_hwcomposer (though I must admit I haven't
personally run the drm_hwc code):

https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/3

I'm afraid I haven't really touched any of the writeback code for a
couple of years - Liviu picked that up. He's on holiday until Monday,
but he should be able to help with the status of the igts.

Hope that helps,

-Brian

> 
> > > The writeback pixel format is restricted to RGB, due to the VSP1
> > > outputting RGB to the display and lacking a separate colour space
> > > conversion unit for writeback. The resolution can be freely picked by
> > > will result in cropping or composing, not scaling.
> > > 
> > > Writeback requests are queued to the hardware on page flip (atomic
> > > flush), and complete at the next vblank. This means that a queued
> > > writeback buffer will not be processed until the next page flip, but
> > > once it starts being written to by the VSP, it will complete at the next
> > > vblank regardless of whether another page flip occurs at that time.
> > 
> > This sounds the same as mali-dp, and so fits directly with the
> > semantics of writeback connectors.
> > 
> > > The code is based on a merge of the media master branch, the drm-next
> > > branch and the R-Car DT next branch. For convenience patches can be
> > > found at
> > > 
> > >   git://linuxtv.org/pinchartl/media.git v4l2/vsp1/writeback
> > > 
> > > Kieran Bingham (2):
> > >   Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
> > >   media: vsp1: Provide a writeback video device
> > > 
> > > Laurent Pinchart (5):
> > >   media: vsp1: wpf: Fix partition configuration for display pipelines
> > >   media: vsp1: Replace leftover occurrence of fragment with body
> > >   media: vsp1: Fix addresses of display-related 

Re: [PATCH v5 15/19] drm/msm: Remove prototypes for non-existing functions

[Laurent Pinchart]

Forgot to CC Rob, sorry about that.

On Thu, Feb 21, 2019 at 12:32:08PM +0200, Laurent Pinchart wrote:
> The msm_atomic_state_clear() and msm_atomic_state_free() functions are
> declared but never defined. Remove their prototypes.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/msm/msm_drv.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 4e0c6c2f9a86..8f0287e75efb 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -240,8 +240,6 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
> struct drm_plane_state *new_state);
>  void msm_atomic_commit_tail(struct drm_atomic_state *state);
>  struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device *dev);
> -void msm_atomic_state_clear(struct drm_atomic_state *state);
> -void msm_atomic_state_free(struct drm_atomic_state *state);
>  
>  int msm_gem_init_vma(struct msm_gem_address_space *aspace,
>   struct msm_gem_vma *vma, int npages);

-- 
Regards,

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

Re: [PATCH v2 0/2] drm/drv: Rework drm_dev_unplug() (was: Remove drm_dev_unplug())

[Noralf Trønnes]

Den 08.02.2019 15.01, skrev Noralf Trønnes:
> This series makes drm_dev_unplug() compatible with the upcoming
> devm_drm_dev_init(), fixes a double drm_dev_unregister() situation and
> simplifies the drm_device ref handling wrt to the last fd closed after
> unregister.
> 
> The first version of this patchset removed drm_dev_unplug(), see here
> for the discussion as to why it is kept for the time being:
> 
> [2/6] drm/drv: Prepare to remove drm_dev_unplug()
> https://patchwork.freedesktop.org/patch/282902/
> 
> Noralf.
> 
> Noralf Trønnes (2):
>   drm: Fix drm_release() and device unplug
>   drm/drv: drm_dev_unplug(): Move out drm_dev_put() call
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>  drivers/gpu/drm/drm_drv.c   | 5 -
>  drivers/gpu/drm/drm_file.c  | 6 ++
>  drivers/gpu/drm/udl/udl_drv.c   | 1 +
>  drivers/gpu/drm/xen/xen_drm_front.c | 1 +
>  5 files changed, 5 insertions(+), 9 deletions(-)
> 

Applied to drm-misc-next, thanks for reviewing.

Noralf.

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

Re: [PATCH] drm/i915: remove redundant likely/unlikely annotation

[Chris Wilson]

Quoting Chengguang Xu (2019-02-21 02:08:19)
> unlikely has already included in IS_ERR(), so just
> remove redundant likely/unlikely annotation.
> 
> Signed-off-by: Chengguang Xu 
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm: move i915_kick_out_vgacon to drm_fb_helper

[Daniel Vetter]

On Thu, Feb 21, 2019 at 12:35:33PM +0100, Gerd Hoffmann wrote:
> It'll be useful for other drivers too, so move it to drm_fb_helper.c
> (and rename it of course).  Also add docs.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_fb_helper.h |  2 ++
>  drivers/gpu/drm/drm_fb_helper.c | 39 +++
>  drivers/gpu/drm/i915/i915_drv.c | 35 +--
>  3 files changed, 42 insertions(+), 34 deletions(-)
> 
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index bb9acea613..a401ba47ad 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -649,4 +649,6 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct 
> pci_dev *pdev,
>  #endif
>  }
>  
> +int drm_fb_helper_kick_out_vgacon(void);
> +
>  #endif
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0e9349ff2d..a2d7e5bc51 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3353,3 +3354,41 @@ int __init drm_fb_helper_modinit(void)
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_fb_helper_modinit);
> +
> +/**
> + * drm_fb_helper_kick_out_vgacon - deactivate vgacon driver.
> + *
> + * Deactivate vgacon driver so it stops accessing vga io ports.
> + * Should be called after
> + * drm_fb_helper_remove_conflicting_pci_framebuffers().

Why after? i915 calls this before kicking out the fbdev drivers ...

Otherwise lgtm.
-Daniel

> + *
> + * Returns:
> + * Zero on success or negative error code on failure.
> + */
> +int drm_fb_helper_kick_out_vgacon(void)
> +{
> +#if !defined(CONFIG_VGA_CONSOLE)
> +return 0;
> +#elif !defined(CONFIG_DUMMY_CONSOLE)
> +return -ENODEV;
> +#else
> +int ret = 0;
> +
> +DRM_INFO("Replacing VGA console driver\n");
> +
> +console_lock();
> +if (con_is_bound(_con))
> +ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 
> 1, 1);
> +if (ret == 0) {
> +ret = do_unregister_con_driver(_con);
> +
> +/* Ignore "already unregistered". */
> +if (ret == -ENODEV)
> +ret = 0;
> +}
> +console_unlock();
> +
> +return ret;
> +#endif
> +}
> +EXPORT_SYMBOL(drm_fb_helper_kick_out_vgacon);
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6630212f2f..3edd4d7d55 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -757,39 +757,6 @@ static int i915_kick_out_firmware_fb(struct 
> drm_i915_private *dev_priv)
>   return ret;
>  }
>  
> -#if !defined(CONFIG_VGA_CONSOLE)
> -static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> -{
> - return 0;
> -}
> -#elif !defined(CONFIG_DUMMY_CONSOLE)
> -static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> -{
> - return -ENODEV;
> -}
> -#else
> -static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> -{
> - int ret = 0;
> -
> - DRM_INFO("Replacing VGA console driver\n");
> -
> - console_lock();
> - if (con_is_bound(_con))
> - ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 
> 1);
> - if (ret == 0) {
> - ret = do_unregister_con_driver(_con);
> -
> - /* Ignore "already unregistered". */
> - if (ret == -ENODEV)
> - ret = 0;
> - }
> - console_unlock();
> -
> - return ret;
> -}
> -#endif
> -
>  static void intel_init_dpio(struct drm_i915_private *dev_priv)
>  {
>   /*
> @@ -1420,7 +1387,7 @@ static int i915_driver_init_hw(struct drm_i915_private 
> *dev_priv)
>   goto err_ggtt;
>   }
>  
> - ret = i915_kick_out_vgacon(dev_priv);
> + ret = drm_fb_helper_kick_out_vgacon();
>   if (ret) {
>   DRM_ERROR("failed to remove conflicting VGA console\n");
>   goto err_ggtt;
> -- 
> 2.9.3
> 

-- 
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/qxl: unbind vgacon

[Daniel Vetter]

On Wed, Feb 20, 2019 at 03:36:40PM +0100, Gerd Hoffmann wrote:
> Problem:  qxl switches from native mode back into vga compatibility mode
> when it notices someone is accessing vga registers.  And vgacon does
> exactly that before fbcon takes over.
> 
> Before qxl switched to the generic fbdev emulation that didn't cause any
> problems.  With the generic fbdev emulation the switch to vga mode
> happens now and then, probably caused by a initialization order change
> and triggered by a printk in a bad moment.
> 
> So make sure we take vgacon out of the picture by making dummycon
> taking over the console early enough.
> 
> Not entriely happy with the approach, I'm open to better ideas.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/qxl/qxl_drv.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index bb81e310eb..88349dc13e 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -30,6 +30,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -89,6 +90,11 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>  
>   drm_kms_helper_poll_init(>ddev);
>  
> + /* unbind vgacon to make sure it doesn't touch our vga registers */
> + console_lock();
> + ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, true);
> + console_unlock();

Still seems very late, in i915 we kick out vgacon as pretty much the first
thing in driver load. See i915_kick_out_vgacon.

I wonder whether we should integrate that logic into
drm_fb_helper_remove_conflicting_pci_framebuffers, by checking whether
that pci device can decode VGA and kick out vgacon in that case. Instead
of sprinkling the same logic over all drivers.
-Daniel

> +
>   /* Complete initialization. */
>   ret = drm_dev_register(>ddev, ent->driver_data);
>   if (ret)
> -- 
> 2.9.3
> 

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

[PATCH v5 12/19] drm: writeback: Cleanup job ownership handling when queuing job

[Laurent Pinchart]

The drm_writeback_queue_job() function takes ownership of the passed job
and requires the caller to manually set the connector state
writeback_job pointer to NULL. To simplify drivers and avoid errors
(such as the missing NULL set in the vc4 driver), pass the connector
state pointer to the function instead of the job pointer, and set the
writeback_job pointer to NULL internally.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arm/malidp_mw.c |  3 +--
 drivers/gpu/drm/drm_writeback.c | 15 ++-
 drivers/gpu/drm/vc4/vc4_txp.c   |  2 +-
 include/drm/drm_writeback.h |  2 +-
 4 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 041a64dc7167..87627219ce3b 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -252,8 +252,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
 _state->addrs[0],
 mw_state->format);
 
-   drm_writeback_queue_job(mw_conn, conn_state->writeback_job);
-   conn_state->writeback_job = NULL;
+   drm_writeback_queue_job(mw_conn, conn_state);
hwdev->hw->enable_memwrite(hwdev, mw_state->addrs,
   mw_state->pitches, 
mw_state->n_planes,
   fb->width, fb->height, 
mw_state->format,
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index c20e6fe00cb3..338b993d7c9f 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -242,11 +242,12 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
 /**
  * drm_writeback_queue_job - Queue a writeback job for later signalling
  * @wb_connector: The writeback connector to queue a job on
- * @job: The job to queue
+ * @conn_state: The connector state containing the job to queue
  *
- * This function adds a job to the job_queue for a writeback connector. It
- * should be considered to take ownership of the writeback job, and so any 
other
- * references to the job must be cleared after calling this function.
+ * This function adds the job contained in @conn_state to the job_queue for a
+ * writeback connector. It takes ownership of the writeback job and sets the
+ * @conn_state->writeback_job to NULL, and so no access to the job may be
+ * performed by the caller after this function returns.
  *
  * Drivers must ensure that for a given writeback connector, jobs are queued in
  * exactly the same order as they will be completed by the hardware (and
@@ -258,10 +259,14 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
  * See also: drm_writeback_signal_completion()
  */
 void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
-struct drm_writeback_job *job)
+struct drm_connector_state *conn_state)
 {
+   struct drm_writeback_job *job;
unsigned long flags;
 
+   job = conn_state->writeback_job;
+   conn_state->writeback_job = NULL;
+
spin_lock_irqsave(_connector->job_lock, flags);
list_add_tail(>list_entry, _connector->job_queue);
spin_unlock_irqrestore(_connector->job_lock, flags);
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index aa279b5b0de7..5dabd91f2d7e 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -327,7 +327,7 @@ static void vc4_txp_connector_atomic_commit(struct 
drm_connector *conn,
 
TXP_WRITE(TXP_DST_CTRL, ctrl);
 
-   drm_writeback_queue_job(>connector, conn_state->writeback_job);
+   drm_writeback_queue_job(>connector, conn_state);
 }
 
 static const struct drm_connector_helper_funcs vc4_txp_connector_helper_funcs 
= {
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 23df9d463003..47662c362743 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -123,7 +123,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 const u32 *formats, int n_formats);
 
 void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
-struct drm_writeback_job *job);
+struct drm_connector_state *conn_state);
 
 void drm_writeback_cleanup_job(struct drm_writeback_job *job);
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 13/19] drm: writeback: Fix leak of writeback job

[Laurent Pinchart]

Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and
deleted when the jobs complete. This results in both a memory leak of
the job and a leak of the framebuffer if the atomic commit returns
before the job is queued for processing, for instance if the atomic
check fails or if the commit runs in test-only mode.

Fix this by implementing the drm_writeback_cleanup_job() function and
calling it from __drm_atomic_helper_connector_destroy_state(). As
writeback jobs are removed from the state when they're queued for
processing, any job left in the state when the state gets destroyed
needs to be cleaned up.

The existing declaration of the drm_writeback_cleanup_job() function
without an implementation hints that this problem was considered, but
never addressed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  4 
 drivers/gpu/drm/drm_writeback.c   | 13 ++---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 4985384e51f6..59ffb6b9c745 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -412,6 +413,9 @@ __drm_atomic_helper_connector_destroy_state(struct 
drm_connector_state *state)
 
if (state->commit)
drm_crtc_commit_put(state->commit);
+
+   if (state->writeback_job)
+   drm_writeback_cleanup_job(state->writeback_job);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 338b993d7c9f..afb1ae6e0ecb 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -273,6 +273,14 @@ void drm_writeback_queue_job(struct 
drm_writeback_connector *wb_connector,
 }
 EXPORT_SYMBOL(drm_writeback_queue_job);
 
+void drm_writeback_cleanup_job(struct drm_writeback_job *job)
+{
+   if (job->fb)
+   drm_framebuffer_put(job->fb);
+
+   kfree(job);
+}
+
 /*
  * @cleanup_work: deferred cleanup of a writeback job
  *
@@ -285,10 +293,9 @@ static void cleanup_work(struct work_struct *work)
struct drm_writeback_job *job = container_of(work,
 struct drm_writeback_job,
 cleanup_work);
-   drm_framebuffer_put(job->fb);
-   kfree(job);
-}
 
+   drm_writeback_cleanup_job(job);
+}
 
 /**
  * drm_writeback_signal_completion - Signal the completion of a writeback job
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 06/19] media: vsp1: Replace the display list internal flag with a flags field

[Laurent Pinchart]

To prepare for addition of more flags to the display list, replace the
'internal' flag field by a bitmask 'flags' field.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
---
Changes since v4:

- Fix check for the completed flag in vsp1_du_pipeline_frame_end()
---
 drivers/media/platform/vsp1/vsp1_dl.c| 31 +---
 drivers/media/platform/vsp1/vsp1_dl.h|  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c   |  8 --
 drivers/media/platform/vsp1/vsp1_video.c |  2 +-
 4 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 64af449791b0..886b3a69d329 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -178,7 +178,7 @@ struct vsp1_dl_cmd_pool {
  * @post_cmd: post command to be issued through extended dl header
  * @has_chain: if true, indicates that there's a partition chain
  * @chain: entry in the display list partition chain
- * @internal: whether the display list is used for internal purpose
+ * @flags: display list flags, a combination of VSP1_DL_FRAME_END_*
  */
 struct vsp1_dl_list {
struct list_head list;
@@ -197,7 +197,7 @@ struct vsp1_dl_list {
bool has_chain;
struct list_head chain;
 
-   bool internal;
+   unsigned int flags;
 };
 
 /**
@@ -861,13 +861,15 @@ static void vsp1_dl_list_commit_continuous(struct 
vsp1_dl_list *dl)
 *
 * If a display list is already pending we simply drop it as the new
 * display list is assumed to contain a more recent configuration. It is
-* an error if the already pending list has the internal flag set, as
-* there is then a process waiting for that list to complete. This
-* shouldn't happen as the waiting process should perform proper
-* locking, but warn just in case.
+* an error if the already pending list has the
+* VSP1_DL_FRAME_END_INTERNAL flag set, as there is then a process
+* waiting for that list to complete. This shouldn't happen as the
+* waiting process should perform proper locking, but warn just in
+* case.
 */
if (vsp1_dl_list_hw_update_pending(dlm)) {
-   WARN_ON(dlm->pending && dlm->pending->internal);
+   WARN_ON(dlm->pending &&
+   (dlm->pending->flags & VSP1_DL_FRAME_END_INTERNAL));
__vsp1_dl_list_put(dlm->pending);
dlm->pending = dl;
return;
@@ -897,7 +899,7 @@ static void vsp1_dl_list_commit_singleshot(struct 
vsp1_dl_list *dl)
dlm->active = dl;
 }
 
-void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool internal)
+void vsp1_dl_list_commit(struct vsp1_dl_list *dl, unsigned int dl_flags)
 {
struct vsp1_dl_manager *dlm = dl->dlm;
struct vsp1_dl_list *dl_next;
@@ -912,7 +914,7 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool 
internal)
vsp1_dl_list_fill_header(dl_next, last);
}
 
-   dl->internal = internal;
+   dl->flags = dl_flags & ~VSP1_DL_FRAME_END_COMPLETED;
 
spin_lock_irqsave(>lock, flags);
 
@@ -941,9 +943,10 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool 
internal)
  * set in single-shot mode as display list processing is then not continuous 
and
  * races never occur.
  *
- * The VSP1_DL_FRAME_END_INTERNAL flag indicates that the previous display list
- * has completed and had been queued with the internal notification flag.
- * Internal notification is only supported for continuous mode.
+ * The following flags are only supported for continuous mode.
+ *
+ * The VSP1_DL_FRAME_END_INTERNAL flag indicates that the display list that 
just
+ * became active had been queued with the internal notification flag.
  */
 unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
@@ -986,9 +989,9 @@ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager 
*dlm)
 * frame end interrupt. The display list thus becomes active.
 */
if (dlm->queued) {
-   if (dlm->queued->internal)
+   if (dlm->queued->flags & VSP1_DL_FRAME_END_INTERNAL)
flags |= VSP1_DL_FRAME_END_INTERNAL;
-   dlm->queued->internal = false;
+   dlm->queued->flags &= ~VSP1_DL_FRAME_END_INTERNAL;
 
__vsp1_dl_list_put(dlm->active);
dlm->active = dlm->queued;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index 125750dc8b5c..e0fdb145e6ed 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -61,7 +61,7 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager 
*dlm);
 void vsp1_dl_list_put(struct vsp1_dl_list *dl);
 struct vsp1_dl_body *vsp1_dl_list_get_body0(struct vsp1_dl_list *dl);
 struct vsp1_dl_ext_cmd *vsp1_dl_get_pre_cmd(struct vsp1_dl_list *dl);
-void 

[PATCH v5 18/19] drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functions

[Laurent Pinchart]

The rcar_du_vsp_plane_prepare_fb() and rcar_du_vsp_plane_cleanup_fb()
functions implement the DRM plane .prepare_fb() and .cleanup_fb()
operations. They map and unmap the framebuffer to/from the VSP
internally, which will be useful to implement writeback support. Split
the mapping and unmapping out to separate functions.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 68 ---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 17 +++
 2 files changed, 58 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 29a08f7b0761..0806a69c4679 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -173,26 +173,16 @@ static void rcar_du_vsp_plane_setup(struct 
rcar_du_vsp_plane *plane)
  plane->index, );
 }
 
-static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
-   struct drm_plane_state *state)
+int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
+  struct sg_table sg_tables[3])
 {
-   struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
-   struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
struct rcar_du_device *rcdu = vsp->dev;
unsigned int i;
int ret;
 
-   /*
-* There's no need to prepare (and unprepare) the framebuffer when the
-* plane is not visible, as it will not be displayed.
-*/
-   if (!state->visible)
-   return 0;
-
-   for (i = 0; i < rstate->format->planes; ++i) {
-   struct drm_gem_cma_object *gem =
-   drm_fb_cma_get_gem_obj(state->fb, i);
-   struct sg_table *sgt = >sg_tables[i];
+   for (i = 0; i < fb->format->num_planes; ++i) {
+   struct drm_gem_cma_object *gem = drm_fb_cma_get_gem_obj(fb, i);
+   struct sg_table *sgt = _tables[i];
 
ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr, gem->paddr,
  gem->base.size);
@@ -207,15 +197,11 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane 
*plane,
}
}
 
-   ret = drm_gem_fb_prepare_fb(plane, state);
-   if (ret)
-   goto fail;
-
return 0;
 
 fail:
while (i--) {
-   struct sg_table *sgt = >sg_tables[i];
+   struct sg_table *sgt = _tables[i];
 
vsp1_du_unmap_sg(vsp->vsp, sgt);
sg_free_table(sgt);
@@ -224,22 +210,50 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane 
*plane,
return ret;
 }
 
+static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+   struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+   int ret;
+
+   /*
+* There's no need to prepare (and unprepare) the framebuffer when the
+* plane is not visible, as it will not be displayed.
+*/
+   if (!state->visible)
+   return 0;
+
+   ret = rcar_du_vsp_map_fb(vsp, state->fb, rstate->sg_tables);
+   if (ret < 0)
+   return ret;
+
+   return drm_gem_fb_prepare_fb(plane, state);
+}
+
+void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
+ struct sg_table sg_tables[3])
+{
+   unsigned int i;
+
+   for (i = 0; i < fb->format->num_planes; ++i) {
+   struct sg_table *sgt = _tables[i];
+
+   vsp1_du_unmap_sg(vsp->vsp, sgt);
+   sg_free_table(sgt);
+   }
+}
+
 static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
 struct drm_plane_state *state)
 {
struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
-   unsigned int i;
 
if (!state->visible)
return;
 
-   for (i = 0; i < rstate->format->planes; ++i) {
-   struct sg_table *sgt = >sg_tables[i];
-
-   vsp1_du_unmap_sg(vsp->vsp, sgt);
-   sg_free_table(sgt);
-   }
+   rcar_du_vsp_unmap_fb(vsp, state->fb, rstate->sg_tables);
 }
 
 static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index db232037f24a..9b4724159378 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -12,8 +12,10 @@
 
 #include 
 
+struct drm_framebuffer;
 struct rcar_du_format_info;
 struct rcar_du_vsp;
+struct sg_table;
 
 struct rcar_du_vsp_plane {
struct drm_plane plane;
@@ -60,6 +62,10 @@ void rcar_du_vsp_enable(struct 

[PATCH v5 10/19] media: vsp1: drm: Extend frame completion API to the DU driver

[Laurent Pinchart]

The VSP1 driver will need to pass extra flags to the DU through the
frame completion API. Replace the completed bool flag by a bitmask to
support this.

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

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 76a39eee7c9c..28bfeb8c24fb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -26,14 +26,14 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
 
-static void rcar_du_vsp_complete(void *private, bool completed, u32 crc)
+static void rcar_du_vsp_complete(void *private, unsigned int status, u32 crc)
 {
struct rcar_du_crtc *crtc = private;
 
if (crtc->vblank_enable)
drm_crtc_handle_vblank(>crtc);
 
-   if (completed)
+   if (status & VSP1_DU_STATUS_COMPLETE)
rcar_du_crtc_finish_page_flip(crtc);
 
drm_crtc_add_crc_entry(>crtc, false, 0, );
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a0569e0d0f9e..e4c44d6d3116 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -34,14 +34,14 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
   unsigned int completion)
 {
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
-   bool complete = completion & VSP1_DL_FRAME_END_COMPLETED;
 
if (drm_pipe->du_complete) {
struct vsp1_entity *uif = drm_pipe->uif;
+   unsigned int status = completion & VSP1_DU_STATUS_COMPLETE;
u32 crc;
 
crc = uif ? vsp1_uif_get_crc(to_uif(>subdev)) : 0;
-   drm_pipe->du_complete(drm_pipe->du_private, complete, crc);
+   drm_pipe->du_complete(drm_pipe->du_private, status, crc);
}
 
if (completion & VSP1_DL_FRAME_END_INTERNAL) {
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 8dfd274a59e2..e85ad4366fbb 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -42,7 +42,7 @@ struct vsp1_drm_pipeline {
struct vsp1_du_crc_config crc;
 
/* Frame synchronisation */
-   void (*du_complete)(void *data, bool completed, u32 crc);
+   void (*du_complete)(void *data, unsigned int status, u32 crc);
void *du_private;
 };
 
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 1cf868360701..877496936487 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -17,6 +17,8 @@ struct device;
 
 int vsp1_du_init(struct device *dev);
 
+#define VSP1_DU_STATUS_COMPLETEBIT(0)
+
 /**
  * struct vsp1_du_lif_config - VSP LIF configuration
  * @width: output frame width
@@ -32,7 +34,7 @@ struct vsp1_du_lif_config {
unsigned int height;
bool interlaced;
 
-   void (*callback)(void *data, bool completed, u32 crc);
+   void (*callback)(void *data, unsigned int status, u32 crc);
void *callback_data;
 };
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 14/19] drm: writeback: Add job prepare and cleanup operations

[Laurent Pinchart]

As writeback jobs contain a framebuffer, drivers may need to prepare and
cleanup them the same way they can prepare and cleanup framebuffers for
planes. Add two new optional connector helper operations,
.prepare_writeback_job() and .cleanup_writeback_job() to support this.

The job prepare operation is called from
drm_atomic_helper_prepare_planes() to avoid a new atomic commit helper
that would need to be called by all drivers not using
drm_atomic_helper_commit(). The job cleanup operation is called from the
existing drm_writeback_cleanup_job() function, invoked both when
destroying the job as part of a aborted commit, or when the job
completes.

The drm_writeback_job structure is extended with a priv field to let
drivers store per-job data, such as mappings related to the writeback
framebuffer.

For internal plumbing reasons the drm_writeback_job structure needs to
store a back-pointer to the drm_writeback_connector. To avoid pushing
too much writeback-specific knowledge to drm_atomic_uapi.c, create a
drm_writeback_set_fb() function, move the writeback job setup code
there, and set the connector backpointer. The prepare_signaling()
function doesn't need to allocate writeback jobs and can ignore
connectors without a job, as it is called after the writeback jobs are
allocated to store framebuffers, and a writeback fence with a
framebuffer is an invalid configuration that gets rejected by the commit
check.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_atomic_helper.c  | 11 ++
 drivers/gpu/drm/drm_atomic_uapi.c| 31 +
 drivers/gpu/drm/drm_writeback.c  | 43 
 include/drm/drm_modeset_helper_vtables.h |  7 
 include/drm/drm_writeback.h  | 28 ++-
 5 files changed, 96 insertions(+), 24 deletions(-)

This patch is currently missing documentation for the
.prepare_writeback_job() and .cleanup_writeback_job() operations. I plan
to fix this, but first wanted feedback on the direction taken. I'm not
entirely happy with the priv pointer in the drm_writeback_job structure,
but adding a full state duplicate/destroy machinery for that structure
was equally unappealing to me.

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 6fe2303fccd9..70a4886c6e65 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2245,10 +2245,21 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
 int drm_atomic_helper_prepare_planes(struct drm_device *dev,
 struct drm_atomic_state *state)
 {
+   struct drm_connector *connector;
+   struct drm_connector_state *new_conn_state;
struct drm_plane *plane;
struct drm_plane_state *new_plane_state;
int ret, i, j;
 
+   for_each_new_connector_in_state(state, connector, new_conn_state, i) {
+   if (!new_conn_state->writeback_job)
+   continue;
+
+   ret = drm_writeback_prepare_job(new_conn_state->writeback_job);
+   if (ret < 0)
+   return ret;
+   }
+
for_each_new_plane_in_state(state, plane, new_plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c40889888a16..e802152a01ad 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -647,28 +647,15 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
return 0;
 }
 
-static struct drm_writeback_job *
-drm_atomic_get_writeback_job(struct drm_connector_state *conn_state)
-{
-   WARN_ON(conn_state->connector->connector_type != 
DRM_MODE_CONNECTOR_WRITEBACK);
-
-   if (!conn_state->writeback_job)
-   conn_state->writeback_job =
-   kzalloc(sizeof(*conn_state->writeback_job), GFP_KERNEL);
-
-   return conn_state->writeback_job;
-}
-
 static int drm_atomic_set_writeback_fb_for_connector(
struct drm_connector_state *conn_state,
struct drm_framebuffer *fb)
 {
-   struct drm_writeback_job *job =
-   drm_atomic_get_writeback_job(conn_state);
-   if (!job)
-   return -ENOMEM;
+   int ret;
 
-   drm_framebuffer_assign(>fb, fb);
+   ret = drm_writeback_set_fb(conn_state, fb);
+   if (ret < 0)
+   return ret;
 
if (fb)
DRM_DEBUG_ATOMIC("Set [FB:%d] for connector state %p\n",
@@ -1158,19 +1145,17 @@ static int prepare_signaling(struct drm_device *dev,
 
for_each_new_connector_in_state(state, conn, conn_state, i) {
struct drm_writeback_connector *wb_conn;
-   struct drm_writeback_job *job;
struct drm_out_fence_state *f;
struct dma_fence *fence;
s32 __user *fence_ptr;
 
+   if (!conn_state->writeback_job)
+

[PATCH v5 11/19] media: vsp1: drm: Implement writeback support

[Laurent Pinchart]

Extend the vsp1_du_atomic_flush() API with writeback support by adding
format, pitch and memory addresses of the writeback framebuffer.
Writeback completion is reported through the existing frame completion
callback with a new VSP1_DU_STATUS_WRITEBACK status flag.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c  | 14 ++
 drivers/media/platform/vsp1/vsp1_dl.h  |  3 ++-
 drivers/media/platform/vsp1/vsp1_drm.c | 25 -
 include/media/vsp1.h   | 15 +++
 4 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 7b4d252bfde7..dad7fa548642 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -1025,6 +1025,9 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager 
*dlm)
  *
  * The VSP1_DL_FRAME_END_INTERNAL flag indicates that the display list that 
just
  * became active had been queued with the internal notification flag.
+ *
+ * The VSP1_DL_FRAME_END_WRITEBACK flag indicates that the previously active
+ * display list had been queued with the writeback flag.
  */
 unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
@@ -1062,6 +1065,17 @@ unsigned int vsp1_dlm_irq_frame_end(struct 
vsp1_dl_manager *dlm)
if (status & VI6_STATUS_FLD_STD(dlm->index))
goto done;
 
+   /*
+* If the active display list has the writeback flag set, the frame
+* completion marks the end of the writeback capture. Return the
+* VSP1_DL_FRAME_END_WRITEBACK flag and reset the display list's
+* writeback flag.
+*/
+   if (dlm->active && (dlm->active->flags & VSP1_DL_FRAME_END_WRITEBACK)) {
+   flags |= VSP1_DL_FRAME_END_WRITEBACK;
+   dlm->active->flags &= ~VSP1_DL_FRAME_END_WRITEBACK;
+   }
+
/*
 * The device starts processing the queued display list right after the
 * frame end interrupt. The display list thus becomes active.
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index f845607abc4c..3a34b37df79a 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -18,7 +18,8 @@ struct vsp1_dl_list;
 struct vsp1_dl_manager;
 
 #define VSP1_DL_FRAME_END_COMPLETEDBIT(0)
-#define VSP1_DL_FRAME_END_INTERNAL BIT(1)
+#define VSP1_DL_FRAME_END_WRITEBACKBIT(1)
+#define VSP1_DL_FRAME_END_INTERNAL BIT(2)
 
 /**
  * struct vsp1_dl_ext_cmd - Extended Display command
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index e4c44d6d3116..f1d8e2039ce8 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -37,7 +37,9 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
 
if (drm_pipe->du_complete) {
struct vsp1_entity *uif = drm_pipe->uif;
-   unsigned int status = completion & VSP1_DU_STATUS_COMPLETE;
+   unsigned int status = completion
+   & (VSP1_DU_STATUS_COMPLETE |
+  VSP1_DU_STATUS_WRITEBACK);
u32 crc;
 
crc = uif ? vsp1_uif_get_crc(to_uif(>subdev)) : 0;
@@ -541,6 +543,8 @@ static void vsp1_du_pipeline_configure(struct vsp1_pipeline 
*pipe)
 
if (drm_pipe->force_brx_release)
dl_flags |= VSP1_DL_FRAME_END_INTERNAL;
+   if (pipe->output->writeback)
+   dl_flags |= VSP1_DL_FRAME_END_WRITEBACK;
 
dl = vsp1_dl_list_get(pipe->output->dlm);
dlb = vsp1_dl_list_get_body0(dl);
@@ -870,12 +874,31 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
int pipe_index,
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
struct vsp1_pipeline *pipe = _pipe->pipe;
+   int ret;
 
drm_pipe->crc = cfg->crc;
 
mutex_lock(>drm->lock);
+
+   if (pipe->output->has_writeback && cfg->writeback.pixelformat) {
+   const struct vsp1_du_writeback_config *wb_cfg = >writeback;
+
+   ret = vsp1_du_pipeline_set_rwpf_format(vsp1, pipe->output,
+  wb_cfg->pixelformat,
+  wb_cfg->pitch);
+   if (WARN_ON(ret < 0))
+   goto done;
+
+   pipe->output->mem.addr[0] = wb_cfg->mem[0];
+   pipe->output->mem.addr[1] = wb_cfg->mem[1];
+   pipe->output->mem.addr[2] = wb_cfg->mem[2];
+   pipe->output->writeback = true;
+   }
+
vsp1_du_pipeline_setup_inputs(vsp1, pipe);
vsp1_du_pipeline_configure(pipe);
+
+done:
mutex_unlock(>drm->lock);
 }
 

[PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list

[Laurent Pinchart]

One-shot entries are used as an alternative to committing a complete new
display list when a couple of registers need to be written for one frame
and then reset to another value for all subsequent frames. This will be
used to implement writeback support that will need to enable writeback
for the duration of a single frame.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 78 +++
 drivers/media/platform/vsp1/vsp1_dl.h |  3 ++
 2 files changed, 81 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 886b3a69d329..7b4d252bfde7 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -115,6 +115,12 @@ struct vsp1_dl_body {
 
unsigned int num_entries;
unsigned int max_entries;
+
+   unsigned int num_patches;
+   struct {
+   struct vsp1_dl_entry *entry;
+   u32 data;
+   } patches[2];
 };
 
 /**
@@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
return;
 
dlb->num_entries = 0;
+   dlb->num_patches = 0;
 
spin_lock_irqsave(>pool->lock, flags);
list_add_tail(>free, >pool->free);
@@ -388,6 +395,47 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, 
u32 data)
dlb->num_entries++;
 }
 
+/**
+ * vsp1_dl_body_write_oneshot - Write a register to a display list body for a
+ * single frame
+ * @dlb: The body
+ * @reg: The register address
+ * @value: The register value
+ * @reset_value: The value to reset the register to at the next vblank
+ *
+ * Display lists in continuous mode are re-used by the hardware for successive
+ * frames until a new display list is committed. Changing the VSP configuration
+ * normally requires creating and committing a new display list. This function
+ * offers an alternative race-free way by writing a @value to the @register in
+ * the display list body for a single frame, specifying in @reset_value the
+ * value to reset the register to one vblank after the display list is
+ * committed.
+ *
+ * The maximum number of one-shot entries is limited to 2 per display list 
body,
+ * and one-shot entries are counted in the total number of entries specified
+ * when the body is allocated by vsp1_dl_body_alloc().
+ */
+void vsp1_dl_body_write_oneshot(struct vsp1_dl_body *dlb, u32 reg, u32 value,
+   u32 reset_value)
+{
+   if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
+ "DLB size exceeded (max %u)", dlb->max_entries))
+   return;
+
+   if (WARN_ONCE(dlb->num_patches >= ARRAY_SIZE(dlb->patches),
+ "DLB patches size exceeded (max %zu)",
+ ARRAY_SIZE(dlb->patches)))
+   return;
+
+   dlb->patches[dlb->num_patches].entry = >entries[dlb->num_entries];
+   dlb->patches[dlb->num_patches].data = reset_value;
+   dlb->num_patches++;
+
+   dlb->entries[dlb->num_entries].addr = reg;
+   dlb->entries[dlb->num_entries].data = value;
+   dlb->num_entries++;
+}
+
 /* 
-
  * Display List Extended Command Management
  */
@@ -652,6 +700,7 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
 * has at least one body, thus we reinitialise the entries list.
 */
dl->body0->num_entries = 0;
+   dl->body0->num_patches = 0;
 
list_add_tail(>list, >dlm->free);
 }
@@ -930,6 +979,35 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, unsigned 
int dl_flags)
  * Display List Manager
  */
 
+/**
+ * vsp1_dlm_irq_display_start - Display list handler for the display start
+ * interrupt
+ * @dlm: the display list manager
+ *
+ * Apply all one-shot patches registered for the active display list.
+ */
+void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm)
+{
+   struct vsp1_dl_body *dlb;
+   struct vsp1_dl_list *dl;
+   unsigned int i;
+
+   spin_lock(>lock);
+
+   dl = dlm->active;
+   if (!dl)
+   goto done;
+
+   list_for_each_entry(dlb, >bodies, list) {
+   for (i = 0; i < dlb->num_patches; ++i)
+   dlb->patches[i].entry->data = dlb->patches[i].data;
+   dlb->num_patches = 0;
+   }
+
+done:
+   spin_unlock(>lock);
+}
+
 /**
  * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
  * @dlm: the display list manager
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index e0fdb145e6ed..f845607abc4c 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -54,6 +54,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
unsigned int prealloc);
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct 

[PATCH v5 17/19] drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure

[Laurent Pinchart]

The mapping between DRM and V4L2 fourcc's is stored in two separate
tables in rcar_du_vsp.c. In order to make it reusable to implement
writeback support, move it to the rcar_du_format_info structure.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 25 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.h |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 44 ---
 3 files changed, 32 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index b0c80dffd8b8..999440c7b258 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -32,60 +32,70 @@
 static const struct rcar_du_format_info rcar_du_format_infos[] = {
{
.fourcc = DRM_FORMAT_RGB565,
+   .v4l2 = V4L2_PIX_FMT_RGB565,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_ARGB1555,
+   .v4l2 = V4L2_PIX_FMT_ARGB555,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_XRGB1555,
+   .v4l2 = V4L2_PIX_FMT_XRGB555,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_XRGB,
+   .v4l2 = V4L2_PIX_FMT_XBGR32,
.bpp = 32,
.planes = 1,
.pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_RGB888,
}, {
.fourcc = DRM_FORMAT_ARGB,
+   .v4l2 = V4L2_PIX_FMT_ABGR32,
.bpp = 32,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_ARGB,
}, {
.fourcc = DRM_FORMAT_UYVY,
+   .v4l2 = V4L2_PIX_FMT_UYVY,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_YUYV,
+   .v4l2 = V4L2_PIX_FMT_YUYV,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV12,
+   .v4l2 = V4L2_PIX_FMT_NV12M,
.bpp = 12,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV21,
+   .v4l2 = V4L2_PIX_FMT_NV21M,
.bpp = 12,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV16,
+   .v4l2 = V4L2_PIX_FMT_NV16M,
.bpp = 16,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
@@ -97,62 +107,77 @@ static const struct rcar_du_format_info 
rcar_du_format_infos[] = {
 */
{
.fourcc = DRM_FORMAT_RGB332,
+   .v4l2 = V4L2_PIX_FMT_RGB332,
.bpp = 8,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_ARGB,
+   .v4l2 = V4L2_PIX_FMT_ARGB444,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_XRGB,
+   .v4l2 = V4L2_PIX_FMT_XRGB444,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGR888,
+   .v4l2 = V4L2_PIX_FMT_RGB24,
.bpp = 24,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_RGB888,
+   .v4l2 = V4L2_PIX_FMT_BGR24,
.bpp = 24,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGRA,
+   .v4l2 = V4L2_PIX_FMT_ARGB32,
.bpp = 32,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGRX,
+   .v4l2 = V4L2_PIX_FMT_XRGB32,
.bpp = 32,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_YVYU,
+   .v4l2 = V4L2_PIX_FMT_YVYU,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_NV61,
+   .v4l2 = V4L2_PIX_FMT_NV61M,
.bpp = 16,
.planes = 2,
}, {
.fourcc = DRM_FORMAT_YUV420,
+   .v4l2 = V4L2_PIX_FMT_YUV420M,
.bpp = 12,
.planes = 3,
}, 

[PATCH v5 15/19] drm/msm: Remove prototypes for non-existing functions

[Laurent Pinchart]

The msm_atomic_state_clear() and msm_atomic_state_free() functions are
declared but never defined. Remove their prototypes.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/msm/msm_drv.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 4e0c6c2f9a86..8f0287e75efb 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -240,8 +240,6 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
  struct drm_plane_state *new_state);
 void msm_atomic_commit_tail(struct drm_atomic_state *state);
 struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device *dev);
-void msm_atomic_state_clear(struct drm_atomic_state *state);
-void msm_atomic_state_free(struct drm_atomic_state *state);
 
 int msm_gem_init_vma(struct msm_gem_address_space *aspace,
struct msm_gem_vma *vma, int npages);
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 19/19] drm: rcar-du: Add writeback support for R-Car Gen3

[Laurent Pinchart]

Implement writeback support for R-Car Gen3 by exposing writeback
connectors. Behind the scene the calls are forwarded to the VSP
backend.

Using writeback connectors will allow implemented writeback support for
R-Car Gen2 with a consistent API if desired.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig |   4 +
 drivers/gpu/drm/rcar-du/Makefile|   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |   7 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  12 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |   5 +
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 203 
 drivers/gpu/drm/rcar-du/rcar_du_writeback.h |  39 
 7 files changed, 271 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.h

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 7c36e2777a15..1529849e217e 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -36,3 +36,7 @@ config DRM_RCAR_VSP
depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m)
help
  Enable support to expose the R-Car VSP Compositor as KMS planes.
+
+config DRM_RCAR_WRITEBACK
+   bool
+   default y if ARM64
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 2a3b8d7972b5..6c2ed9c46467 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,7 +4,7 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_encoder.o \
 rcar_du_group.o \
 rcar_du_kms.o \
-rcar_du_plane.o
+rcar_du_plane.o \
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
   rcar_du_of_lvds_r8a7790.dtb.o \
@@ -13,6 +13,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)   += rcar_du_of.o \
   rcar_du_of_lvds_r8a7795.dtb.o \
   rcar_du_of_lvds_r8a7796.dtb.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
+rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
 obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index c478953be092..92f7d5f3ff80 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -15,6 +15,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 
@@ -39,6 +40,7 @@ struct rcar_du_vsp;
  * @group: CRTC group this CRTC belongs to
  * @vsp: VSP feeding video to this CRTC
  * @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
+ * @writeback: the writeback connector
  */
 struct rcar_du_crtc {
struct drm_crtc crtc;
@@ -65,9 +67,12 @@ struct rcar_du_crtc {
 
const char *const *sources;
unsigned int sources_count;
+
+   struct drm_writeback_connector writeback;
 };
 
-#define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc, crtc)
+#define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc, 
crtc)
+#define wb_to_rcar_crtc(c) container_of(c, struct rcar_du_crtc, writeback)
 
 /**
  * struct rcar_du_crtc_state - Driver-specific CRTC state
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 999440c7b258..c729f048626e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -24,6 +24,7 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_regs.h"
 #include "rcar_du_vsp.h"
+#include "rcar_du_writeback.h"
 
 /* 
-
  * Format helpers
@@ -662,6 +663,17 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
encoder->possible_clones = (1 << num_encoders) - 1;
}
 
+   /* Create the writeback connectors. */
+   if (rcdu->info->gen >= 3) {
+   for (i = 0; i < rcdu->num_crtcs; ++i) {
+   struct rcar_du_crtc *rcrtc = >crtcs[i];
+
+   ret = rcar_du_writeback_init(rcdu, rcrtc);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
/*
 * Initialize the default DPAD0 source to the index of the first DU
 * channel that can be connected to DPAD0. The exact value doesn't
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 0806a69c4679..99ae03a1713a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -25,6 +25,7 @@
 #include "rcar_du_drv.h"
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
+#include "rcar_du_writeback.h"
 
 static void rcar_du_vsp_complete(void *private, unsigned int status, u32 

[PATCH v5 05/19] media: vsp1: Refactor vsp1_video_complete_buffer() for later reuse

[Laurent Pinchart]

The vsp1_video_complete_buffer() function completes the current buffer
and returns a pointer to the next buffer. Split the code that completes
the buffer to a separate function for later reuse, and rename
vsp1_video_complete_buffer() to vsp1_video_complete_next_buffer().

Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_video.c | 36 ++--
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 328d686189be..2f3d6153fabd 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -300,8 +300,23 @@ static int vsp1_video_pipeline_setup_partitions(struct 
vsp1_pipeline *pipe)
  * Pipeline Management
  */
 
+static void vsp1_video_complete_buffer(struct vsp1_video *video,
+  struct vsp1_vb2_buffer *buffer)
+{
+   struct vsp1_pipeline *pipe = video->rwpf->entity.pipe;
+   unsigned int i;
+
+   buffer->buf.sequence = pipe->sequence;
+   buffer->buf.vb2_buf.timestamp = ktime_get_ns();
+   for (i = 0; i < buffer->buf.vb2_buf.num_planes; ++i)
+   vb2_set_plane_payload(>buf.vb2_buf, i,
+ vb2_plane_size(>buf.vb2_buf, i));
+   vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
+}
+
 /*
- * vsp1_video_complete_buffer - Complete the current buffer
+ * vsp1_video_complete_next_buffer - Complete the current buffer and return the
+ * next buffer
  * @video: the video node
  *
  * This function completes the current buffer by filling its sequence number,
@@ -310,13 +325,11 @@ static int vsp1_video_pipeline_setup_partitions(struct 
vsp1_pipeline *pipe)
  * Return the next queued buffer or NULL if the queue is empty.
  */
 static struct vsp1_vb2_buffer *
-vsp1_video_complete_buffer(struct vsp1_video *video)
+vsp1_video_complete_next_buffer(struct vsp1_video *video)
 {
-   struct vsp1_pipeline *pipe = video->rwpf->entity.pipe;
-   struct vsp1_vb2_buffer *next = NULL;
+   struct vsp1_vb2_buffer *next;
struct vsp1_vb2_buffer *done;
unsigned long flags;
-   unsigned int i;
 
spin_lock_irqsave(>irqlock, flags);
 
@@ -327,21 +340,14 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
 
done = list_first_entry(>irqqueue,
struct vsp1_vb2_buffer, queue);
-
list_del(>queue);
 
-   if (!list_empty(>irqqueue))
-   next = list_first_entry(>irqqueue,
+   next = list_first_entry_or_null(>irqqueue,
struct vsp1_vb2_buffer, queue);
 
spin_unlock_irqrestore(>irqlock, flags);
 
-   done->buf.sequence = pipe->sequence;
-   done->buf.vb2_buf.timestamp = ktime_get_ns();
-   for (i = 0; i < done->buf.vb2_buf.num_planes; ++i)
-   vb2_set_plane_payload(>buf.vb2_buf, i,
- vb2_plane_size(>buf.vb2_buf, i));
-   vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
+   vsp1_video_complete_buffer(video, done);
 
return next;
 }
@@ -352,7 +358,7 @@ static void vsp1_video_frame_end(struct vsp1_pipeline *pipe,
struct vsp1_video *video = rwpf->video;
struct vsp1_vb2_buffer *buf;
 
-   buf = vsp1_video_complete_buffer(video);
+   buf = vsp1_video_complete_next_buffer(video);
if (buf == NULL)
return;
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 01/19] Revert "[media] v4l: vsp1: Supply frames to the DU continuously"

[Laurent Pinchart]

From: Kieran Bingham 

This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to
the DU continuously")

The DU output mode does not rely on frames being supplied on the WPF as
its pipeline is supplied from DRM. For the upcoming WPF writeback
functionality, we will choose to enable writeback mode if there is an
output buffer, or disable it (leaving the existing display pipeline
unharmed) otherwise.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_video.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 7ceaf3222145..328d686189be 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -307,11 +307,6 @@ static int vsp1_video_pipeline_setup_partitions(struct 
vsp1_pipeline *pipe)
  * This function completes the current buffer by filling its sequence number,
  * time stamp and payload size, and hands it back to the videobuf core.
  *
- * When operating in DU output mode (deep pipeline to the DU through the LIF),
- * the VSP1 needs to constantly supply frames to the display. In that case, if
- * no other buffer is queued, reuse the one that has just been processed 
instead
- * of handing it back to the videobuf core.
- *
  * Return the next queued buffer or NULL if the queue is empty.
  */
 static struct vsp1_vb2_buffer *
@@ -333,12 +328,6 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
done = list_first_entry(>irqqueue,
struct vsp1_vb2_buffer, queue);
 
-   /* In DU output mode reuse the buffer if the list is singular. */
-   if (pipe->lif && list_is_singular(>irqqueue)) {
-   spin_unlock_irqrestore(>irqlock, flags);
-   return done;
-   }
-
list_del(>queue);
 
if (!list_empty(>irqqueue))
-- 
Regards,

Laurent Pinchart

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

[Bug 109712] S2idle is not working on AMD Gigabyte platform

[bugzilla-daemon]

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

--- Comment #1 from shahul  ---
Comment on attachment 143427
  --> https://bugs.freedesktop.org/attachment.cgi?id=143427
suspend/resume error log in s2idle

>
>[  852.851628] smpboot: CPU 1 is now offline
>[  852.876714] smpboot: CPU 2 is now offline
>[  852.901690] smpboot: CPU 3 is now offline
>[  852.921911] smpboot: CPU 4 is now offline
>[  852.941588] smpboot: CPU 5 is now offline
>[  852.954720] smpboot: CPU 6 is now offline
>[  852.969625] smpboot: CPU 7 is now offline
>[  852.974523] PM: suspend entry (s2idle)
>[  852.974525] PM: Syncing filesystems ... done.
>[  852.987057] PM: Preparing system for sleep (s2idle)
>[  852.987335] Freezing user space processes ... (elapsed 0.002 seconds) done.
>[  852.990264] OOM killer disabled.
>[  852.990265] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) 
>done.
>[  852.990968] PM: Suspending system (s2idle)
>[  852.990969] PM:  platform_suspend_begin 1
>[  852.990970] PM:  platform_suspend_begin PM_SUSPEND_TO_IDLE
>[  852.990971] ACPI: acpi_s2idle_begin 
>[  852.990972] PM:  suspend_devices_and_enter
>[  852.990972] Suspending console(s) (use no_console_suspend to debug)
>[  852.992193] rtc_cmos 00:01: suspend, ctrl 02
>[  852.992892] [drm:amdgpu_pmops_suspend [amdgpu]] *ERROR*  in if 
>amdgpu_pmops_suspend
>[  852.995310] amdgpu: [powerplay] smu firmware version too old, can not set 
>dpm level
>[  853.011977] amdgpu: [powerplay] smu firmware version too old, can not set 
>dpm level
>[  853.060914] amdgpu: [powerplay] smu firmware version too old, can not set 
>dpm level
>[  853.101456] [drm:amdgpu_device_suspend [amdgpu]] *ERROR* before  
>amdgpu_device_suspend  curr=0, req=3 
>[  853.113257] amdgpu :04:00.0:  curr=3, req=3 
>[  853.113261] amdgpu :04:00.0:  dev->bus->self
>[  853.113355] [drm:amdgpu_device_suspend [amdgpu]] *ERROR* before  
>amdgpu_device_suspend  curr=3, req=3 
>[  853.122540] PM: suspend of devices complete after 131.420 msecs
>[  853.122543] PM:  1 suspend_devices_and_enter
>[  853.122546] PM: suspend devices took 0.131 seconds
>[  853.122547] PM:  2 suspend_devices_and_enter
>[  853.123153] PM: late suspend of devices complete after 0.604 msecs
>[  853.123155] ACPI: aacpi_s2idle_prepare  out 
>[  853.123156] PM: suspend-to-idle
>[  853.123299] ACPI: EC: interrupt blocked
>[  853.136027] power-0276 __acpi_power_off  : Power resource [P0ST] 
>turned off
>[  853.136032] device_pm-0236 device_set_power  : Device [SATA] 
>transitioned to D3hot
>[  853.136061] power-0189 power_get_state   : Resource [P0ST] is off
>[  853.136065] power-0220 power_get_list_state  : Resource list is off
>[  853.136087] power-0189 power_get_state   : Resource [P3ST] is off
>[  853.136090] power-0220 power_get_list_state  : Resource list is off
>[  853.136093] device_pm-0125 device_get_power  : Device [SATA] power 
>state is D3cold
>[  853.147966] PM: noirq suspend of devices complete after 24.762 msecs
>[  857.458149] PM: Timekeeping suspended for 4.809 seconds
>[  857.458248] ACPI: acpi_s2idle_wake  out 
>[  857.458485] ACPI: EC: interrupt unblocked 
>[  857.470478] power-0235 __acpi_power_on   : Power resource [P0ST] 
>turned on
>[  857.470503] device_pm-0236 device_set_power  : Device [SATA] 
>transitioned to D0
>[  857.470516] ahci :05:00.0:  Refused to change power state, currently in 
>D3
>[  857.470517] ahci :05:00.0:  curr=3, req=0 
>[  857.470518] ahci :05:00.0:  dev->bus->self
>[  857.470534] power-0189 power_get_state   : Resource [P0ST] is on
>[  857.470536] power-0220 power_get_list_state  : Resource list is on
>[  857.470538] device_pm-0125 device_get_power  : Device [SATA] power 
>state is D0
>[  857.494570] PM: noirq resume of devices complete after 36.315 msecs
>[  857.494797] ACPI: acpi_s2idle_sync out 
>[  857.495136] PM: resume from suspend-to-idle
>[  857.495136] ACPI: acpi_s2idle_restore 
>[  857.495451] PM: early resume of devices complete after 0.312 msecs
>[  857.495451] PM:  3 suspend_devices_and_enter
>[  857.496002] [drm:amdgpu_pmops_resume [amdgpu]] *ERROR*  in if 
>amdgpu_pmops_resume
>[  857.496045] [drm:amdgpu_device_resume [amdgpu]] *ERROR* before  
>amdgpu_device_resume  curr=0, req=0 
>[  857.496091] [drm:amdgpu_device_resume [amdgpu]] *ERROR* after  
>amdgpu_device_resume  curr=0, req=0 
>[  857.496838] [drm] PCIE GART of 1024M enabled (table at 0x00F40090).
>[  857.496865] [drm] PSP is resuming...
>[  857.501901] rtc_cmos 00:01: resume, ctrl 22
>
>[  857.611273] amdgpu: [powerplay] dpm has been enabled
>[  857.611278] amdgpu: [powerplay] smu firmware version too old, can not set 
>dpm level
>[  857.636777] [drm] SADs count is: 0, don't need to read it
>[  857.713206] nvme nvme0: Shutdown timeout set to 8 seconds
>[  857.764036] amdgpu: [powerplay] smu firmware version too old, can not set 
>dpm level
>[  857.814556] ata1: SATA link down (SStatus 0 SControl 300)
>

[radeon-alex:amd-18.50 1/1] drivers/gpu/drm/amd/amdgpu/amdgpu.h:854:1: sparse: error: expected ; at end of declaration

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-18.50
head:   e4440937836a9d6a260bb43e87989b8cdd3c2f2c
commit: e4440937836a9d6a260bb43e87989b8cdd3c2f2c [1/1] drm/amdgpu: don't clamp 
debugfs register access to the BAR size
reproduce:
# apt-get install sparse
git checkout e4440937836a9d6a260bb43e87989b8cdd3c2f2c
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

All error/warnings (new ones prefixed by >>):

>> include/kcl/kcl_drm_global.h:46:30: sparse: warning: no newline at end of 
>> file
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h:854:1: sparse: error: expected ; at end 
>> of declaration
   In file included from 
drivers/gpu/drm/amd/amdgpu/../backport/include/kcl/kcl_amdgpu.h:5,
from drivers/gpu/drm/amd/amdgpu/../backport/backport.h:12,
from :
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:854:1: warning: no semicolon at end of 
struct or union
};
^
--
>> include/kcl/kcl_drm_global.h:46:30: sparse: warning: no newline at end of 
>> file
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h:854:1: sparse: error: expected ; at end 
>> of declaration
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:60:10: sparse: warning: 
symbol 'generic_reg_get' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:68:10: sparse: warning: 
symbol 'generic_reg_get2' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:78:10: sparse: warning: 
symbol 'generic_reg_get3' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:90:10: sparse: warning: 
symbol 'generic_reg_get4' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:104:10: sparse: 
warning: symbol 'generic_reg_get5' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:120:10: sparse: 
warning: symbol 'generic_reg_get6' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:138:10: sparse: 
warning: symbol 'generic_reg_get7' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:158:10: sparse: 
warning: symbol 'generic_reg_get8' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254:6: sparse: warning: 
symbol 'generic_write_indirect_reg' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:262:10: sparse: 
warning: symbol 'generic_read_indirect_reg' was not declared. Should it be 
static?
   drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:275:10: sparse: 
warning: symbol 'generic_indirect_reg_update_ex' was not declared. Should it be 
static?
   In file included from 
drivers/gpu/drm/amd/amdgpu/../backport/include/kcl/kcl_amdgpu.h:5,
from drivers/gpu/drm/amd/amdgpu/../backport/backport.h:12,
from :
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:854:1: warning: no semicolon at end of 
struct or union
};
^
--
>> include/kcl/kcl_drm_global.h:46:30: sparse: warning: no newline at end of 
>> file
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h:854:1: sparse: error: expected ; at end 
>> of declaration
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:33:9: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:34:9: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:35:9: sparse: warning: cast to 
restricted __le16
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:36:9: sparse: warning: cast to 
restricted __le16
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:37:9: sparse: warning: cast to 
restricted __le16
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:38:9: sparse: warning: cast to 
restricted __le16
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:39:9: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:40:9: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:41:9: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:43:9: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:48:34: sparse: warning: cast to 
restricted __le16
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:49:34: sparse: warning: cast to 
restricted __le16
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:58:17: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:60:17: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:69:34: sparse: warning: cast to 
restricted __le16
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:70:34: sparse: warning: cast to 
restricted __le16
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:79:17: sparse: warning: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:87:34: sparse: warning: 

[PATCH v2 1/2] drm: move i915_kick_out_vgacon to drm_fb_helper

[Gerd Hoffmann]

It'll be useful for other drivers too, so move it to drm_fb_helper.c
(and rename it of course).  Also add docs.

Signed-off-by: Gerd Hoffmann 
---
 include/drm/drm_fb_helper.h |  2 ++
 drivers/gpu/drm/drm_fb_helper.c | 39 +++
 drivers/gpu/drm/i915/i915_drv.c | 35 +--
 3 files changed, 42 insertions(+), 34 deletions(-)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index bb9acea613..a401ba47ad 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -649,4 +649,6 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct 
pci_dev *pdev,
 #endif
 }
 
+int drm_fb_helper_kick_out_vgacon(void);
+
 #endif
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0e9349ff2d..a2d7e5bc51 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3353,3 +3354,41 @@ int __init drm_fb_helper_modinit(void)
return 0;
 }
 EXPORT_SYMBOL(drm_fb_helper_modinit);
+
+/**
+ * drm_fb_helper_kick_out_vgacon - deactivate vgacon driver.
+ *
+ * Deactivate vgacon driver so it stops accessing vga io ports.
+ * Should be called after
+ * drm_fb_helper_remove_conflicting_pci_framebuffers().
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_fb_helper_kick_out_vgacon(void)
+{
+#if !defined(CONFIG_VGA_CONSOLE)
+return 0;
+#elif !defined(CONFIG_DUMMY_CONSOLE)
+return -ENODEV;
+#else
+int ret = 0;
+
+DRM_INFO("Replacing VGA console driver\n");
+
+console_lock();
+if (con_is_bound(_con))
+ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 
1);
+if (ret == 0) {
+ret = do_unregister_con_driver(_con);
+
+/* Ignore "already unregistered". */
+if (ret == -ENODEV)
+ret = 0;
+}
+console_unlock();
+
+return ret;
+#endif
+}
+EXPORT_SYMBOL(drm_fb_helper_kick_out_vgacon);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6630212f2f..3edd4d7d55 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -757,39 +757,6 @@ static int i915_kick_out_firmware_fb(struct 
drm_i915_private *dev_priv)
return ret;
 }
 
-#if !defined(CONFIG_VGA_CONSOLE)
-static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
-{
-   return 0;
-}
-#elif !defined(CONFIG_DUMMY_CONSOLE)
-static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
-{
-   return -ENODEV;
-}
-#else
-static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
-{
-   int ret = 0;
-
-   DRM_INFO("Replacing VGA console driver\n");
-
-   console_lock();
-   if (con_is_bound(_con))
-   ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 
1);
-   if (ret == 0) {
-   ret = do_unregister_con_driver(_con);
-
-   /* Ignore "already unregistered". */
-   if (ret == -ENODEV)
-   ret = 0;
-   }
-   console_unlock();
-
-   return ret;
-}
-#endif
-
 static void intel_init_dpio(struct drm_i915_private *dev_priv)
 {
/*
@@ -1420,7 +1387,7 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
goto err_ggtt;
}
 
-   ret = i915_kick_out_vgacon(dev_priv);
+   ret = drm_fb_helper_kick_out_vgacon();
if (ret) {
DRM_ERROR("failed to remove conflicting VGA console\n");
goto err_ggtt;
-- 
2.9.3

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

[PATCH v2 2/2] drm/qxl: kick out vgacon

[Gerd Hoffmann]

Problem:  qxl switches from native mode back into vga compatibility mode
when it notices someone is accessing vga registers.  And vgacon does
exactly that before fbcon takes over.  So make sure we kick out vgacon
early enough that it wouldn't disturb us.

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

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index bb81e310eb..08446561aa 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -95,6 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
goto modeset_cleanup;
 
drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
+   drm_fb_helper_kick_out_vgacon();
drm_fbdev_generic_setup(>ddev, 32);
return 0;
 
-- 
2.9.3

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

[PATCH v2 0/2] drm/qxl: kick out vgacon

[Gerd Hoffmann]

v2: move the i915 code to drm_fb_helper and use that instead of
reinventing the wheel.

Gerd Hoffmann (2):
  drm: move i915_kick_out_vgacon to drm_fb_helper
  drm/qxl: kick out vgacon

 include/drm/drm_fb_helper.h |  2 ++
 drivers/gpu/drm/drm_fb_helper.c | 39 +++
 drivers/gpu/drm/i915/i915_drv.c | 35 +--
 drivers/gpu/drm/qxl/qxl_drv.c   |  1 +
 4 files changed, 43 insertions(+), 34 deletions(-)

-- 
2.9.3

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

RE: [PATCH v14 32/33] misc/mei/hdcp: Component framework for I915 Interface

[Winkler, Tomas]

> 
> Mei hdcp driver is designed as component slave for the I915 component
> master.
> 
> v2: Rebased.
> v3:
>   Notifier chain is adopted for cldev state update [Tomas]
> v4:
>   Made static dummy functions as inline in mei_hdcp.h
>   API for polling client device status
>   IS_ENABLED used in header, for config status for mei_hdcp.
> v5:
>   Replacing the notifier with component framework. [Daniel]
> v6:
>   Rebased on the I915 comp master redesign.
> v7:
>   mei_hdcp_component_registered is made static [Uma]
>   Need for global static variable mei_cldev is removed.
> v8:
>   master comp is added to be matched with i915 subcomponent [daniel]
> v9:
>   only comp_master is set and retrieved as driver_data [Daniel]
>   Reviewed-by Daniel.
> v10:
>   small corrections at probe [Tomas]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/misc/mei/hdcp/mei_hdcp.c | 82
> +++-
>  1 file changed, 80 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 2afc7d31dacc..ad55b41550d6 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include  @@ -711,8 +712,7 @@
> mei_hdcp_close_session(struct device *dev, struct hdcp_port_data *data)
>   return 0;
>  }
> 
> -static __attribute__((unused))
> -struct i915_hdcp_component_ops mei_hdcp_ops = {
> +static struct i915_hdcp_component_ops mei_hdcp_ops = {

Should be 'const' too.

>   .owner = THIS_MODULE,
>   .initiate_hdcp2_session = mei_hdcp_initiate_session,
>   .verify_receiver_cert_prepare_km =
> @@ -729,20 +729,98 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .close_hdcp_session = mei_hdcp_close_session,  };
> 
> +static int mei_component_master_bind(struct device *dev) {
> + struct mei_cl_device *cldev = to_mei_cl_device(dev);
> + struct i915_hdcp_comp_master *comp_master =
> +
>   mei_cldev_get_drvdata(cldev);
> + int ret;
> +
> + dev_info(dev, "%s\n", __func__);


Need change this to dev_dbg() it will pollute log 

> + comp_master->ops = _hdcp_ops;
> + comp_master->mei_dev = dev;
> + ret = component_bind_all(dev, comp_master);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static void mei_component_master_unbind(struct device *dev) {
> + struct mei_cl_device *cldev = to_mei_cl_device(dev);
> + struct i915_hdcp_comp_master *comp_master =
> +
>   mei_cldev_get_drvdata(cldev);
> +
> + dev_info(dev, "%s\n", __func__);
> + component_unbind_all(dev, comp_master); }
> +
> +static const struct component_master_ops mei_component_master_ops = {
> + .bind = mei_component_master_bind,
> + .unbind = mei_component_master_unbind, };
> +
> +static int mei_hdcp_component_match(struct device *dev, int subcomponent,
> + void *data)
> +{
> + return !strcmp(dev->driver->name, "i915") &&
> +subcomponent == I915_COMPONENT_HDCP; }
> +
>  static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id)  {
> + struct i915_hdcp_comp_master *comp_master;
> + struct component_match *master_match;
>   int ret;
> 
>   ret = mei_cldev_enable(cldev);
>   if (ret < 0)
>   dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);

If this is not a fatal condition than should not print in dev_err() 

> 
> + comp_master = kzalloc(sizeof(*comp_master), GFP_KERNEL);
> + if (!comp_master) {
> + ret = -ENOMEM;
> + goto err_exit;
> + }
> +
> + master_match = NULL;
> + component_match_add_typed(>dev, _match,
> +   mei_hdcp_component_match,
> comp_master);
> + if (IS_ERR_OR_NULL(master_match)) {
> + ret = -ENOMEM;
> + goto err_exit;
> + }
> +
> + mei_cldev_set_drvdata(cldev, comp_master);
> + ret = component_master_add_with_match(>dev,
> +   _component_master_ops,
> +   master_match);
> + if (ret < 0) {
> + dev_err(>dev, "Master comp add failed %d\n", ret);
> + goto err_exit;
> + }
> +
> + return 0;
> +
> +err_exit:
> + mei_cldev_set_drvdata(cldev, NULL);
> + kfree(comp_master);
> + mei_cldev_disable(cldev);
> +
>   return ret;
>  }
> 
>  static int mei_hdcp_remove(struct mei_cl_device *cldev)  {
> + struct i915_hdcp_comp_master *comp_master =
> +
>   mei_cldev_get_drvdata(cldev);
> +
> + component_master_del(>dev, _component_master_ops);
> + kfree(comp_master);
> + mei_cldev_set_drvdata(cldev, NULL);
> +
>   return mei_cldev_disable(cldev);
>  }
> 
> --
> 2.7.4

___
dri-devel mailing 

Re: [PATCH v4 0/7] VSP1: Display writeback support

[Laurent Pinchart]

Hi Brian,

On Thu, Feb 21, 2019 at 12:19:13PM +, Brian Starkey wrote:
> On Thu, Feb 21, 2019 at 12:02:57PM +0200, Laurent Pinchart wrote:
> > On Thu, Feb 21, 2019 at 09:50:19AM +, Brian Starkey wrote:
> >> On Thu, Feb 21, 2019 at 10:23:17AM +0200, Laurent Pinchart wrote:
> >>> On Mon, Feb 18, 2019 at 12:22:58PM +, Brian Starkey wrote:
>  On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series implements display writeback support for the R-Car
> > Gen3 platforms in the VSP1 driver.
> > 
> > DRM/KMS provides a writeback API through a special type of writeback
> > connectors. This series takes a different approach by exposing writeback
> > as a V4L2 device. While there is nothing fundamentally wrong with
> > writeback connectors, display for R-Car Gen3 platforms relies on the
> > VSP1 driver behind the scene, which already implements V4L2 support.
> > Enabling writeback through V4L2 is thus significantly easier in this
> > case.
>  
>  How does this look to an application? (I'm entirely ignorant about
>  R-Car). They are interacting with the DRM device, and then need to
>  open and configure a v4l2 device to get the writeback? Can the process
>  which isn't controlling the DRM device independently capture the
>  screen output?
>  
>  I didn't see any major complication to implementing this as a
>  writeback connector. If you want/need to use the vb2_queue, couldn't
>  you just do that entirely from within the kernel?
>  
>  Honestly (predictably?), to me it seems like a bad idea to introduce a
>  second, non-compatible interface for display writeback. Any
>  application interested in display writeback (e.g. compositors) will
>  need to implement both in order to support all HW. drm_hwcomposer
>  already supports writeback via DRM writeback connectors.
>  
>  While I can see the advantages of having writeback exposed via v4l2
>  for streaming use-cases, I think it would be better to have it done in
>  such a way that it works for all writeback connectors, rather than
>  being VSP1-specific. That would allow any application to choose
>  whichever method is most appropriate for their use-case, without
>  limiting themselves to a subset of hardware.
> >>> 
> >>> So I gave writeback connectors a go, and it wasn't very pretty.
> >> 
> >> Sorry you didn't have a good time :-(
> > 
> > No worries. That was to be expected with such young code :-)
> > 
> >>> There writeback support in the DRM core leaks jobs,
> >> 
> >> Is this the cleanup on check fail, or something else?
> > 
> > Yes, that's the problem. I have patches for it that I will post soon.
> > 
> >> One possible pitfall is that you must set the job in the connector
> >> state to NULL after you call drm_writeback_queue_job(). The API there
> >> could easily be changed to pass in the connector_state and clear it in
> >> drm_writeback_queue_job() instead of relying on drivers to do it.
> > 
> > I also have a patch for that :-)
> > 
> >>> and is missing support for
> >>> the equivalent of .prepare_fb()/.cleanup_fb(), which requires per-job
> >>> driver-specific data. I'm working on these issues and will submit
> >>> patches.
> >> 
> >> Hm, yes that didn't occur to me; we don't have a prepare_fb callback.
> >> 
> >>> In the meantime, I need to test my implementation, so I need a command
> >>> line application that will let me exercise the API. I assume you've
> >>> tested your code, haven't you ? :-) Could you tell me how I can test
> >>> writeback ?
> >> 
> >> Indeed, there's igts on the list which I wrote and tested:
> >> 
> >> https://patchwork.kernel.org/patch/10764975/
> > 
> > Will you get these merged ? Pushing everybody to use the writeback
> > connector API without any test is mainline isn't nice, it almost makes
> > me want to go back to V4L2.
> 
> I wasn't trying to be pushy - I only shared my opinion that I didn't
> think it was a good idea to introduce a second display writeback API,
> when we already have one. You're entirely entitled to ignore my
> opinion.

I agree we should aim for a single API. My preference would have been
for V4L2 universally, but now that we have writeback connectors
upstream, the choice has been made, so we should stick to it.

> The tests have been available since the very early versions of the
> writeback series. I don't know what's blocking them from merging, I
> haven't been tracking it very closely.
> 
> If you'd be happy to provide your review and test on them, that may
> help the process along?

Now that I've sent an entirely untested patch series out, this is next
on my list :-)

> > igt test cases are nice to have, but what I need now is a tool to
> > execise the API manually, similar to modetest, with command line
> > parameters to configure the device, and the ability to capture frames to
> > disk using 

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Daniel Vetter]

On Tue, Feb 19, 2019 at 02:33:04PM -0800, Dylan Baker wrote:
> Quoting Emil Velikov (2019-02-19 08:51:18)
> > On Tue, 19 Feb 2019 at 15:36, Dylan Baker  wrote:
> > >
> > > Quoting Daniel Vetter (2019-02-19 07:20:12)
> > > > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom 
> > > >  wrote:
> > > > >
> > > > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > > > > > Signed-off-by: Eric Engestrom 
> > > > > > > > > > ---
> > > > > > > > > >  RELEASING | 27 ---
> > > > > > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > > > > > --- a/RELEASING
> > > > > > > > > > +++ b/RELEASING
> > > > > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving 
> > > > > > > > > > the feature in question.
> > > > > > > > > >
> > > > > > > > > >  Follow these steps to release a new version of libdrm:
> > > > > > > > > >
> > > > > > > > > > -  1) Bump the version number in configure.ac and 
> > > > > > > > > > meson.build. We seem
> > > > > > > > > > - to have settled for 2.4.x as the versioning scheme 
> > > > > > > > > > for libdrm, so
> > > > > > > > > > - just bump the  micro version.
> > > > > > > > > > -
> > > > > > > > > > -  2) Run autoconf and then re-run ./configure so the build 
> > > > > > > > > > system
> > > > > > > > > > - picks up the new version number.
> > > > > > > > > > -
> > > > > > > > > > -  3) Verify that the code passes "make distcheck".  
> > > > > > > > > > Running "make
> > > > > > > > > > - distcheck" should result in no warnings or errors and 
> > > > > > > > > > end with a
> > > > > > > > > > - message of the form:
> > > > > > > > > > -
> > > > > > > > > > -   =
> > > > > > > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > > > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > > > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > > > > > > -   =
> > > > > > > > > > -
> > > > > > > > > > - Make sure that the version number reported by 
> > > > > > > > > > distcheck and in
> > > > > > > > > > - the tarball names matches the number you bumped to in 
> > > > > > > > > > configure.ac.
> > > > > > > > > > +  1) Bump the version number in meson.build. We seem to 
> > > > > > > > > > have settled for
> > > > > > > > > > + 2.4.x as the versioning scheme for libdrm, so just 
> > > > > > > > > > bump the micro
> > > > > > > > > > + version.
> > > > > > > > > > +
> > > > > > > > > > +  2) Run `ninja -C builddir/ dist` to generate the 
> > > > > > > > > > tarballs.
> > > > > > > > > > + Make sure that the version number of the tarball name 
> > > > > > > > > > in
> > > > > > > > > > + builddir/meson-dist/ matches the number you bumped 
> > > > > > > > > > to. Move that
> > > > > > > > > > + tarball to the libdrm repo root for the release 
> > > > > > > > > > script to pick up.
> > > > > > > > > >
> > > > > > > > > >4) Push the updated master branch with the bumped 
> > > > > > > > > > version number:
> > > > > > > >
> > > > > > > > Just noticed I forgot to decrement item 4 & 5 :]
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Cheers,
> > > > > > > > > >   Eric
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Acked-by: Dylan Baker 
> > > > > > > > >
> > > > > > > > > But you should probably get someone other than just me to 
> > > > > > > > > look at this.
> > > > > > > >
> > > > > > > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > > > > > > maintainer :]
> > > > > > > >
> > > > > > > > If nobody object, I'll push this in a few weeks (there's really 
> > > > > > > > no rush,
> > > > > > > > but I want to make that move at some point, we have no reason 
> > > > > > > > to stay
> > > > > > > > dependant on autotools now that we have better tools).
> > > > > > >
> > > > > > > Must admit I'm not the biggest fan. I can see this being cool for 
> > > > > > > the
> > > > > > > maintainer, if autotools was was present on their system.
> > > > > > > The unfortunate reality is - it's there for the foreseeable 
> > > > > > > future.
> > > > > > > If anything it makes it more annoying for those using 
> > > > > > > autotools/make -
> > > > > > > regardless if they like doing so or not.
> > > > > > >
> > > > > > > So that's a nack from me :-\
> > > > > >
> > > > > > Not really following what's the downside is of using meson to cut 
> > > > > > the
> > > > > 

Re: [PATCH] drm/writeback: Delete drm_writeback_cleanup_job

[Laurent Pinchart]

Hi Brian,

On Thu, Feb 21, 2019 at 09:34:10AM +, Brian Starkey wrote:
> On Thu, Feb 21, 2019 at 10:19:35AM +0200, Laurent Pinchart wrote:
> > Hi Daniel,
> > 
> > Thank you for the patch.
> > 
> > On Thu, Feb 21, 2019 at 12:24:01AM +0100, Daniel Vetter wrote:
> >> No implementation, no callers.
> > 
> > The issue here isn't that the function is declared, but that it's not
> > defined. Jobs are leaked when atomic commit fails (or when using test
> > commits). I'm working on a fix, please don't apply this patch in the
> > meantime.
> 
> Yeah, looking at the series somehow the call to cleanup the writeback
> job on failure looks like it got lost between v9 and v10. I saw a
> patch internally, but looks like James didn't send it to the list yet.
> 
> @James, could you send out your patch which fixes the cleanup on
> failure?

I've just posted

[PATCH v5 12/19] drm: writeback: Cleanup job ownership handling when queuing job
[PATCH v5 13/19] drm: writeback: Fix leak of writeback job

that should address this issue. The series also includes the RFC-like

[PATCH v5 14/19] drm: writeback: Add job prepare and cleanup operations

that addresses a separate issue with writeback support.

> >> Cc: Brian Starkey 
> >> Cc: Liviu Dudau 
> >> Cc: Eric Anholt 
> >> Signed-off-by: Daniel Vetter 
> >> ---
> >>  include/drm/drm_writeback.h | 2 --
> >>  1 file changed, 2 deletions(-)
> >> 
> >> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> >> index 23df9d463003..f34895f7fcb1 100644
> >> --- a/include/drm/drm_writeback.h
> >> +++ b/include/drm/drm_writeback.h
> >> @@ -125,8 +125,6 @@ int drm_writeback_connector_init(struct drm_device 
> >> *dev,
> >>  void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
> >> struct drm_writeback_job *job);
> >>  
> >> -void drm_writeback_cleanup_job(struct drm_writeback_job *job);
> >> -
> >>  void
> >>  drm_writeback_signal_completion(struct drm_writeback_connector 
> >> *wb_connector,
> >>int status);

-- 
Regards,

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