linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <archit@ti.com>
Cc: linux-omap@vger.kernel.org
Subject: Re: [RFC v2 3/5] OMAPDSS: DPI: support multiple DPI instances
Date: Tue, 27 May 2014 12:04:21 +0300	[thread overview]
Message-ID: <53845515.6030305@ti.com> (raw)
In-Reply-To: <1401096492-1405-3-git-send-email-archit@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

On 26/05/14 12:28, Archit Taneja wrote:
> SoCs containing DSS until now had only one DPI instance. DRA7x has 3 DPI
> instances.
> 
> In order to support multiple instances, we allocate a driver data
> struct(dpi_data) for each instance. This is somewhat similar to how DSI driver
> was changed to support multiple instances.
> 
> One difference is that there aren't platform devices for each DPI instance
> when DT is used. In the DT case, we store the dpi_data pointer in the DPI port's
> (of the type struct device_node) data pointer. In the non DT case, we still
> have dummy platform devices, and the device's private data pointer is used to
> store the DPI instance's dpi_data.
> 
> dpi_init_output/dpi_uninit_output are untouched and only used for non DT case,
> dpi_init_output_port/dpi_uninit_output_port are used in the DT case, where DSS
> configures the ports using dpi_init_port/dpi_uninit_port.

This is a bit too big patch, I think it should be split.

The first patch could add the name to the struct dpi_data, but still
keep it static, and also change the functions to pass the dpi_data
pointer around, as you do in this patch.

The functions where you do

struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);

could just do

struct dpi_data *dpi = &dpi;

This way the in the first patch you can do most of the bulk changes,
without actually changing the behavior in any way.

In the next patch, you could then add the actual support for allocating
the dpi_data instances.

Those two patches should be moved to the beginning of the series, as
they are just preparatory patches, and they don't actually change
anything with DPI.

Third DPI patch would then add support for the actual multiple DPI
instances.

> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
>  drivers/video/fbdev/omap2/dss/dpi.c | 263 +++++++++++++++++++++++++-----------
>  1 file changed, 181 insertions(+), 82 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/dss/dpi.c b/drivers/video/fbdev/omap2/dss/dpi.c
> index 8593567..43966a7 100644
> --- a/drivers/video/fbdev/omap2/dss/dpi.c
> +++ b/drivers/video/fbdev/omap2/dss/dpi.c
> @@ -37,7 +37,7 @@
>  #include "dss.h"
>  #include "dss_features.h"
>  
> -static struct {
> +struct dpi_data {
>  	struct platform_device *pdev;
>  
>  	struct regulator *vdds_dsi_reg;
> @@ -52,7 +52,27 @@ static struct {
>  	struct omap_dss_device output;
>  
>  	bool port_initialized;
> -} dpi;
> +};
> +
> +static struct dpi_data *dpi_get_data_from_dssdev(struct omap_dss_device *dssdev)
> +{
> +	struct device_node *parent = dssdev->dev->of_node;
> +
> +	/* non DT */
> +	if (!parent) {
> +		struct omap_dss_device *out = dssdev->src;
> +
> +		return dev_get_drvdata(out->dev);
> +	}

Why do you need the above? Just plain container_of() below should work
for both DT and non-DT.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-05-27  9:04 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-08  9:15 [RFC 1/6] omapdss: remove check for simpler port/endpoint binding Archit Taneja
2014-05-08  9:15 ` [RFC 2/6] omapdss: add init port functions for different omap revs Archit Taneja
2014-05-20  8:04   ` Tomi Valkeinen
2014-05-20  9:31     ` Archit Taneja
2014-05-08  9:15 ` [RFC 3/6] omapdss: DT: Get source endpoint by matching reg-id Archit Taneja
2014-05-08  9:15 ` [RFC 4/6] omapdss: DPI: support multiple DPI instances Archit Taneja
2014-05-08  9:15 ` [RFC 5/6] omapdss: DPI: make dpi_get_channel take DPI reg-id Archit Taneja
2014-05-08  9:15 ` [RFC 6/6] omapdss: DSS: add reg-id param to dpi_select_source Archit Taneja
2014-05-09  9:59 ` [RFC 1/6] omapdss: remove check for simpler port/endpoint binding Tomi Valkeinen
2014-05-26  9:28 ` [RFC v2 1/5] OMAPDSS: DSS: init dss ports cleanly Archit Taneja
2014-05-26  9:28   ` [RFC v2 2/5] OMAPDSS: DT: Get source endpoint by matching reg-id Archit Taneja
2014-05-27  8:34     ` Tomi Valkeinen
2014-05-27  9:49       ` Archit Taneja
2014-05-27 10:24         ` Tomi Valkeinen
2014-05-27 10:51           ` Archit Taneja
2014-05-26  9:28   ` [RFC v2 3/5] OMAPDSS: DPI: support multiple DPI instances Archit Taneja
2014-05-27  9:04     ` Tomi Valkeinen [this message]
2014-05-27  9:27       ` Archit Taneja
2014-05-26  9:28   ` [RFC v2 4/5] OMAPDSS: DPI: make dpi_get_channel take DPI reg-id Archit Taneja
2014-05-26  9:28   ` [RFC v2 5/5] OMAPDSS: DSS: add reg-id param to dpi_select_source Archit Taneja
2014-05-27  8:24   ` [RFC v2 1/5] OMAPDSS: DSS: init dss ports cleanly Tomi Valkeinen
2014-05-27 11:42     ` Archit Taneja
2014-06-04  6:40   ` [PATCH v3 0/7] OMAPDSS: Support multiple DPI instances Archit Taneja
2014-06-04  6:40     ` [PATCH v3 1/7] OMAPDSS: DPI: Use DPI driver data Archit Taneja
2014-06-04  6:40     ` [PATCH v3 2/7] OMAPDSS: DPI: Allocate " Archit Taneja
2014-06-04  6:40     ` [PATCH v3 3/7] OMAPDSS: DPI: Store dpi_data pointer in the DT port's data Archit Taneja
2014-06-04  6:41     ` [PATCH v3 4/7] OMAPDSS: DSS: init dss ports cleanly Archit Taneja
2014-06-26 12:16       ` Tomi Valkeinen
2014-06-04  6:41     ` [PATCH v3 5/7] OMAPDSS: DT: Get source endpoint by matching reg-id Archit Taneja
2014-06-04  6:41     ` [PATCH v3 6/7] OMAPDSS: DPI: Add support for multiple instances Archit Taneja
2014-06-26 12:15       ` Tomi Valkeinen
2014-06-04  6:41     ` [PATCH v3 7/7] omapdss: DSS: add reg-id param to dpi_select_source Archit Taneja
2014-06-26 12:28     ` [PATCH v3 0/7] OMAPDSS: Support multiple DPI instances Tomi Valkeinen

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=53845515.6030305@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=archit@ti.com \
    --cc=linux-omap@vger.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).