From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Brian Starkey <brian.starkey@arm.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
liviu.dudau@arm.com, laurent.pinchart@ideasonboard.com,
linux-media@vger.kernel.org
Subject: Re: [PATCH 1/6] drm: Add writeback connector type
Date: Fri, 14 Apr 2017 12:08:23 +0200 [thread overview]
Message-ID: <20170414120823.2cafc748@bbrezillon> (raw)
In-Reply-To: <1480092544-1725-2-git-send-email-brian.starkey@arm.com>
On Fri, 25 Nov 2016 16:48:59 +0000
Brian Starkey <brian.starkey@arm.com> wrote:
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b5c6a8e..6bbd93f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -86,6 +86,7 @@ struct drm_conn_prop_enum_list {
> { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
> { DRM_MODE_CONNECTOR_DSI, "DSI" },
> { DRM_MODE_CONNECTOR_DPI, "DPI" },
> + { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
Is there a reason we have a Writeback connector, but keep using a
Virtual encoder to connect it to the CRTC? Wouldn't it make more sense
to also add a Writeback encoder?
> };
>
> void drm_connector_ida_init(void)
> @@ -235,7 +236,8 @@ int drm_connector_init(struct drm_device *dev,
> list_add_tail(&connector->head, &config->connector_list);
> config->num_connector++;
>
> - if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
> + if ((connector_type != DRM_MODE_CONNECTOR_VIRTUAL) &&
> + (connector_type != DRM_MODE_CONNECTOR_WRITEBACK))
Nitpick: you don't need the extra parenthesis:
if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL &&
connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
> drm_object_attach_property(&connector->base,
> config->edid_property,
> 0);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 34f9741..dc4910d6 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -214,6 +214,19 @@ struct drm_connector_state {
> struct drm_encoder *best_encoder;
>
> struct drm_atomic_state *state;
> +
> + /**
> + * @writeback_job: Writeback job for writeback connectors
> + *
> + * Holds the framebuffer for a writeback connector. As the writeback
> + * completion may be asynchronous to the normal commit cycle, the
> + * writeback job lifetime is managed separately from the normal atomic
> + * state by this object.
> + *
> + * See also: drm_writeback_queue_job() and
> + * drm_writeback_signal_completion()
> + */
> + struct drm_writeback_job *writeback_job;
Maybe I'm wrong, but is feels weird to have the writeback_job field
directly embedded in drm_connector_state, while drm_writeback_connector
inherits from drm_connector.
IMO, either you decide to directly put the drm_writeback_connector's
job_xxx fields in drm_connector and keep the drm_connector_state as is,
or you create a drm_writeback_connector_state which inherits from
drm_connector_state and embeds the writeback_job field.
Anyway, wait for Daniel's feedback before doing this change.
> };
>
> /**
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index bf9991b2..3d3d07f 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -634,6 +634,20 @@ struct drm_mode_config {
> */
> struct drm_property *suggested_y_property;
>
> + /**
> + * @writeback_fb_id_property: Property for writeback connectors, storing
> + * the ID of the output framebuffer.
> + * See also: drm_writeback_connector_init()
> + */
> + struct drm_property *writeback_fb_id_property;
> + /**
> + * @writeback_pixel_formats_property: Property for writeback connectors,
> + * storing an array of the supported pixel formats for the writeback
> + * engine (read-only).
> + * See also: drm_writeback_connector_init()
> + */
> + struct drm_property *writeback_pixel_formats_property;
> +
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
>
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> new file mode 100644
> index 0000000..6b2ac45
> --- /dev/null
> +++ b/include/drm/drm_writeback.h
> @@ -0,0 +1,78 @@
> +/*
> + * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
> + * Author: Brian Starkey <brian.starkey@arm.com>
> + *
> + * This program is free software and is provided to you under the terms of the
> + * GNU General Public License version 2 as published by the Free Software
> + * Foundation, and any use by you of this program is subject to the terms
> + * of such GNU licence.
> + */
> +
> +#ifndef __DRM_WRITEBACK_H__
> +#define __DRM_WRITEBACK_H__
> +#include <drm/drm_connector.h>
> +#include <linux/workqueue.h>
> +
> +struct drm_writeback_connector {
> + struct drm_connector base;
AFAIU, a writeback connector will always require an 'dummy' encoder to
make the DRM framework happy (AFAIK, a connector is always connected to
a CRTC through an encoder).
Wouldn't it make more sense to have a drm_encoder object embedded in
drm_writeback_connector so that people don't have to declare an extra
structure containing both the drm_writeback_connector connector and a
drm_encoder? Is there a good reason to keep them separate?
> +
> + /**
> + * @pixel_formats_blob_ptr:
> + *
> + * DRM blob property data for the pixel formats list on writeback
> + * connectors
> + * See also drm_writeback_connector_init()
> + */
> + struct drm_property_blob *pixel_formats_blob_ptr;
> +
> + /** @job_lock: Protects job_queue */
> + spinlock_t job_lock;
> + /**
> + * @job_queue:
> + *
> + * Holds a list of a connector's writeback jobs; the last item is the
> + * most recent. The first item may be either waiting for the hardware
> + * to begin writing, or currently being written.
> + *
> + * See also: drm_writeback_queue_job() and
> + * drm_writeback_signal_completion()
> + */
> + struct list_head job_queue;
> +};
next prev parent reply other threads:[~2017-04-14 10:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-25 16:48 [RFC PATCH v3 0/6] Introduce writeback connectors Brian Starkey
2016-11-25 16:48 ` Brian Starkey
2016-11-25 16:48 ` [PATCH 1/6] drm: Add writeback connector type Brian Starkey
2016-11-25 16:48 ` Brian Starkey
2017-04-14 10:08 ` Boris Brezillon [this message]
2017-04-18 17:34 ` Brian Starkey
2017-04-18 17:34 ` Brian Starkey
2017-04-18 19:57 ` Boris Brezillon
2017-04-19 9:51 ` Brian Starkey
2017-04-19 11:34 ` Boris Brezillon
2017-04-19 11:34 ` Boris Brezillon
2017-04-19 12:50 ` Brian Starkey
2017-04-19 12:50 ` Brian Starkey
2017-05-05 8:22 ` Boris Brezillon
2017-05-05 8:22 ` Boris Brezillon
2017-05-05 12:47 ` Liviu Dudau
2017-05-05 12:47 ` Liviu Dudau
2016-11-25 16:49 ` [PATCH 2/6] drm: writeback: Add out-fences for writeback connectors Brian Starkey
2016-11-25 16:49 ` Brian Starkey
2017-04-14 10:11 ` Boris Brezillon
2017-04-14 10:11 ` Boris Brezillon
2017-04-18 17:35 ` Brian Starkey
2017-04-18 17:35 ` Brian Starkey
2016-11-25 16:49 ` [PATCH 3/6] drm: mali-dp: Rename malidp_input_format Brian Starkey
2016-11-25 16:49 ` Brian Starkey
2016-11-25 16:49 ` [PATCH 4/6] drm: mali-dp: Add support for writeback on DP550/DP650 Brian Starkey
2016-11-25 16:49 ` Brian Starkey
2016-11-25 16:49 ` [PATCH 5/6] drm: mali-dp: Add RGB writeback formats for DP550/DP650 Brian Starkey
2016-11-25 16:49 ` Brian Starkey
2016-11-25 16:49 ` [PATCH 6/6] drm: mali-dp: Add writeback connector Brian Starkey
2017-04-14 9:47 ` Boris Brezillon
2017-04-14 9:47 ` Boris Brezillon
2017-04-18 17:35 ` Brian Starkey
2017-04-18 17:35 ` Brian Starkey
2017-04-14 9:35 ` [RFC PATCH v3 0/6] Introduce writeback connectors Boris Brezillon
2017-04-14 9:35 ` Boris Brezillon
2017-04-18 17:31 ` Brian Starkey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170414120823.2cafc748@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=brian.starkey@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=liviu.dudau@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.