From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Peter Rosin <peda@axentia.se>
Cc: Mark Rutland <mark.rutland@arm.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
devicetree@vger.kernel.org, David Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Rob Herring <robh+dt@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Daniel Vetter <daniel.vetter@intel.com>,
Jacopo Mondi <jacopo+renesas@jmondi.org>,
Russell King <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 4/7] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
Date: Sat, 21 Apr 2018 18:19:21 +0200 [thread overview]
Message-ID: <20180421181921.75c41917@bbrezillon> (raw)
In-Reply-To: <20180419162751.25223-5-peda@axentia.se>
On Thu, 19 Apr 2018 18:27:48 +0200
Peter Rosin <peda@axentia.se> wrote:
> This beats the heuristic that the connector is involved in what format
> should be output for cases where this fails.
>
> E.g. if there is a bridge that changes format between the encoder and the
> connector, or if some of the RGB pins between the lcd controller and the
> encoder are not routed on the PCB.
>
> This is critical for the devices that have the "conflicting output
> formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
> RGB bits move around depending on the selected output mode. For
> devices that do not have the "conflicting output formats" issue
> (SAMA5D2, SAMA5D4), this is completely irrelevant.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 71 +++++++++++++++++-------
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 40 ++++++++++++-
> 3 files changed, 92 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index d73281095fac..b4e7f5b6f497 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -226,6 +226,56 @@ static void atmel_hlcdc_crtc_atomic_enable(struct drm_crtc *c,
> #define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
> #define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
>
> +static int atmel_hlcdc_connector_output_mode(struct drm_connector_state *state)
> +{
> + struct drm_connector *connector = state->connector;
> + struct atmel_hlcdc_dc *dc = connector->dev->dev_private;
> + struct drm_encoder *encoder;
> + struct drm_display_info *info = &connector->display_info;
> + unsigned int supported_fmts = 0;
> + int j;
> +
> + encoder = state->best_encoder;
> + if (!encoder)
> + encoder = connector->encoder;
> +
> + switch (dc->bus_fmt[encoder->index]) {
> + case 0:
> + break;
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + return ATMEL_HLCDC_RGB444_OUTPUT;
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + return ATMEL_HLCDC_RGB565_OUTPUT;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + return ATMEL_HLCDC_RGB666_OUTPUT;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + return ATMEL_HLCDC_RGB888_OUTPUT;
> + default:
> + return -EINVAL;
> + }
> +
> + for (j = 0; j < info->num_bus_formats; j++) {
> + switch (info->bus_formats[j]) {
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
> + break;
> + default:
> + break;
> + }
> + }
> +
> + return supported_fmts;
> +}
> +
> static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
> {
> unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
> @@ -238,31 +288,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
> crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
>
> for_each_new_connector_in_state(state->state, connector, cstate, i) {
> - struct drm_display_info *info = &connector->display_info;
> unsigned int supported_fmts = 0;
> - int j;
>
> if (!cstate->crtc)
> continue;
>
> - for (j = 0; j < info->num_bus_formats; j++) {
> - switch (info->bus_formats[j]) {
> - case MEDIA_BUS_FMT_RGB444_1X12:
> - supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB565_1X16:
> - supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB666_1X18:
> - supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB888_1X24:
> - supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
> - break;
> - default:
> - break;
> - }
> - }
> + supported_fmts = atmel_hlcdc_connector_output_mode(cstate);
>
> if (crtc->dc->desc->conflicting_output_formats)
> output_fmts &= supported_fmts;
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> index ab32d5b268d2..be2d180dd169 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> @@ -365,6 +365,7 @@ struct atmel_hlcdc_plane_properties {
> * @hlcdc: pointer to the atmel_hlcdc structure provided by the MFD device
> * @fbdev: framebuffer device attached to the Display Controller
> * @crtc: CRTC provided by the display controller
> + * @bus_fmt: Array of bus format overrides, per connector.
> * @planes: instantiated planes
> * @layers: active HLCDC layers
> * @wq: display controller workqueue
> @@ -376,6 +377,7 @@ struct atmel_hlcdc_dc {
> struct dma_pool *dscrpool;
> struct atmel_hlcdc *hlcdc;
> struct drm_crtc *crtc;
> + int *bus_fmt;
Looks like this bus_fmt information should be attached to the
atmel_hlcdc_rgb_output object, since the property is placed in the
endpoint representing the DPI encoder output.
You could then parse the format in atmel_hlcdc_attach_endpoint() and
provide a helper to retrieve the hardcoded bus-format attached to an
encoder:
int atmel_hlcdc_encoder_get_bus_fmt(struct drm_encoder *encoder);
and if it returns zero you can fallback to bus formats
defined in drm_display_info, as you do in this patch.
> struct atmel_hlcdc_layer *layers[ATMEL_HLCDC_MAX_LAYERS];
> struct workqueue_struct *wq;
> struct {
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 8db51fb131db..8787e2890c93 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -77,10 +77,48 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
>
> int atmel_hlcdc_create_outputs(struct drm_device *dev)
> {
> + struct atmel_hlcdc_dc *dc = dev->dev_private;
> + struct device_node *ep;
> + int count = of_graph_get_endpoint_count(dev->dev->of_node);
> int endpoint, ret = 0;
>
> - for (endpoint = 0; !ret; endpoint++)
> + /*
> + * Assume that each endpoint will create a single encoder
> + * so that the encoder index can be used as index into
> + * this bus_fmt array.
> + */
> + dc->bus_fmt = devm_kzalloc(dev->dev, count * sizeof(*dc->bus_fmt),
> + GFP_KERNEL);
> + if (!dc->bus_fmt)
> + return -ENOMEM;
> +
> + for (endpoint = 0; !ret; endpoint++) {
> + ep = of_graph_get_endpoint_by_regs(dev->dev->of_node, 0,
> + endpoint);
> + if (!ep) {
> + ret = -ENODEV;
> + break;
> + }
> +
> + dc->bus_fmt[endpoint] = drm_of_media_bus_fmt(ep);
> +
> + switch (dc->bus_fmt[endpoint]) {
> + case 0:
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + break;
> + default:
> + ret = dc->bus_fmt[endpoint];
> + if (ret > 0)
> + ret = -EINVAL;
> + }
> + if (ret < 0)
> + break;
> +
> ret = atmel_hlcdc_attach_endpoint(dev, endpoint);
> + }
>
> /* At least one device was successfully attached.*/
> if (ret == -ENODEV && endpoint)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-04-21 16:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 16:27 [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc Peter Rosin
2018-04-19 16:27 ` [PATCH v3 1/7] dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185 Peter Rosin
2018-04-19 16:27 ` [PATCH v3 2/7] dt-bindings: display: atmel: optional video-interface of endpoints Peter Rosin
2018-04-19 16:27 ` [PATCH v3 3/7] drm: of: introduce drm_of_media_bus_fmt Peter Rosin
2018-04-19 16:27 ` [PATCH v3 4/7] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes Peter Rosin
2018-04-21 16:19 ` Boris Brezillon [this message]
2018-04-21 22:13 ` Peter Rosin
2018-04-19 16:27 ` [PATCH v3 5/7] drm/i2c: tda998x: find the drm_device via the drm_connector Peter Rosin
2018-04-20 9:41 ` Laurent Pinchart
2018-04-19 16:27 ` [PATCH v3 6/7] drm/i2c: tda998x: split encoder and component functions from the work Peter Rosin
2018-04-20 9:51 ` Laurent Pinchart
2018-04-19 16:27 ` [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge Peter Rosin
2018-04-20 10:06 ` Laurent Pinchart
2018-04-20 10:24 ` Russell King - ARM Linux
2018-04-20 13:28 ` Peter Rosin
2018-04-20 10:41 ` kbuild test robot
2018-04-20 10:49 ` Peter Rosin
2018-04-20 10:53 ` Russell King - ARM Linux
2018-04-20 13:09 ` Peter Rosin
2018-04-20 12:00 ` Russell King - ARM Linux
2018-04-20 8:52 ` [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc jacopo mondi
2018-04-20 10:18 ` Laurent Pinchart
2018-04-20 11:05 ` Peter Rosin
2018-04-20 11:38 ` jacopo mondi
2018-04-20 12:55 ` Peter Rosin
2018-04-21 8:38 ` Laurent Pinchart
2018-04-21 15:05 ` Peter Rosin
2018-04-20 11:22 ` jacopo mondi
2018-04-21 8:20 ` Laurent Pinchart
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=20180421181921.75c41917@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=airlied@linux.ie \
--cc=alexandre.belloni@bootlin.com \
--cc=boris.brezillon@free-electrons.com \
--cc=daniel.vetter@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacopo+renesas@jmondi.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=nicolas.ferre@microchip.com \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).