All of lore.kernel.org
 help / color / mirror / Atom feed
From: Archit Taneja <archit@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
Date: Mon, 11 Mar 2013 05:47:02 +0000	[thread overview]
Message-ID: <513D6D06.7030902@ti.com> (raw)
In-Reply-To: <1362743515-10152-11-git-send-email-tomi.valkeinen@ti.com>

Hi,

On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
> The DISPC channel used for each output is currently passed in panel
> platform data from the board files.
>
> To simplify this, and to make the panel drivers less dependent on OMAP,
> this patch changes omapdss to resolve the channel independently. The
> channel is resolved based on the OMAP version and, in case of DSI, the
> DSI module id.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   drivers/video/omap2/dss/dpi.c  |   37 ++++++++++++++++++++++++++-----
>   drivers/video/omap2/dss/dsi.c  |   48 ++++++++++++++++++++++++++++++++++++++++
>   drivers/video/omap2/dss/rfbi.c |    2 ++
>   drivers/video/omap2/dss/sdi.c  |    2 ++
>   4 files changed, 84 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index e282456..3261644 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
>   	return 0;
>   }
>
> +/*
> + * Return a hardcoded channel for the DPI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dpi_get_channel(void)
> +{
> +	switch (omapdss_get_version()) {
> +	case OMAPDSS_VER_OMAP24xx:
> +	case OMAPDSS_VER_OMAP34xx_ES1:
> +	case OMAPDSS_VER_OMAP34xx_ES3:
> +	case OMAPDSS_VER_OMAP3630:
> +	case OMAPDSS_VER_AM35xx:
> +		return OMAP_DSS_CHANNEL_LCD;
> +
> +	case OMAPDSS_VER_OMAP4430_ES1:
> +	case OMAPDSS_VER_OMAP4430_ES2:
> +	case OMAPDSS_VER_OMAP4:
> +		return OMAP_DSS_CHANNEL_LCD2;
> +
> +	case OMAPDSS_VER_OMAP5:
> +		return OMAP_DSS_CHANNEL_LCD2;
> +
> +	default:
> +		DSSWARN("unsupported DSS version\n");
> +		return OMAP_DSS_CHANNEL_LCD;
> +	}
> +}
> +
>   static int __init dpi_init_display(struct omap_dss_device *dssdev)
>   {
>   	struct platform_device *dsidev;
>
>   	DSSDBG("init_display\n");
>
> +	dssdev->channel = dpi_get_channel();

In patch 14 of the series, we remove these dssdev->channel assignments. 
I don't see the point of adding them in this patch in the first place. 
The dssdev->channel assignments will not be modified in this series, so 
we don't need to worry about a kernel crash or something after this patch.

I feel this patch should only add the dpi_get_channel and 
dsi_get_channel funcs.

> +
>   	if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
>   					dpi.vdds_dsi_reg = NULL) {
>   		struct regulator *vdds_dsi;
> @@ -416,11 +448,6 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
>   		dpi.vdds_dsi_reg = vdds_dsi;
>   	}
>
> -	/*
> -	 * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
> -	 * source for DPI is SoC integration detail, not something that should
> -	 * be configured in the dssdev
> -	 */
>   	dsidev = dpi_get_dsidev(dssdev->channel);
>
>   	if (dsidev && dpi_verify_dsi_pll(dsidev)) {
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 1a6ad6f..c39ca86 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct omap_dss_device *dssdev,
>   }
>   EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
>
> +/*
> + * Return a hardcoded channel for the DSI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dsi_get_channel(int module_id)
> +{
> +	switch (omapdss_get_version()) {
> +	case OMAPDSS_VER_OMAP24xx:

We should remove the above case so that we hit the default case and get 
a warning about omap2 not having DSI.

> +	case OMAPDSS_VER_OMAP34xx_ES1:
> +	case OMAPDSS_VER_OMAP34xx_ES3:
> +	case OMAPDSS_VER_OMAP3630:
> +	case OMAPDSS_VER_AM35xx:

<snip>

Archit


WARNING: multiple messages have this Message-ID (diff)
From: Archit Taneja <archit@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
Date: Mon, 11 Mar 2013 11:05:02 +0530	[thread overview]
Message-ID: <513D6D06.7030902@ti.com> (raw)
In-Reply-To: <1362743515-10152-11-git-send-email-tomi.valkeinen@ti.com>

Hi,

On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
> The DISPC channel used for each output is currently passed in panel
> platform data from the board files.
>
> To simplify this, and to make the panel drivers less dependent on OMAP,
> this patch changes omapdss to resolve the channel independently. The
> channel is resolved based on the OMAP version and, in case of DSI, the
> DSI module id.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   drivers/video/omap2/dss/dpi.c  |   37 ++++++++++++++++++++++++++-----
>   drivers/video/omap2/dss/dsi.c  |   48 ++++++++++++++++++++++++++++++++++++++++
>   drivers/video/omap2/dss/rfbi.c |    2 ++
>   drivers/video/omap2/dss/sdi.c  |    2 ++
>   4 files changed, 84 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index e282456..3261644 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
>   	return 0;
>   }
>
> +/*
> + * Return a hardcoded channel for the DPI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dpi_get_channel(void)
> +{
> +	switch (omapdss_get_version()) {
> +	case OMAPDSS_VER_OMAP24xx:
> +	case OMAPDSS_VER_OMAP34xx_ES1:
> +	case OMAPDSS_VER_OMAP34xx_ES3:
> +	case OMAPDSS_VER_OMAP3630:
> +	case OMAPDSS_VER_AM35xx:
> +		return OMAP_DSS_CHANNEL_LCD;
> +
> +	case OMAPDSS_VER_OMAP4430_ES1:
> +	case OMAPDSS_VER_OMAP4430_ES2:
> +	case OMAPDSS_VER_OMAP4:
> +		return OMAP_DSS_CHANNEL_LCD2;
> +
> +	case OMAPDSS_VER_OMAP5:
> +		return OMAP_DSS_CHANNEL_LCD2;
> +
> +	default:
> +		DSSWARN("unsupported DSS version\n");
> +		return OMAP_DSS_CHANNEL_LCD;
> +	}
> +}
> +
>   static int __init dpi_init_display(struct omap_dss_device *dssdev)
>   {
>   	struct platform_device *dsidev;
>
>   	DSSDBG("init_display\n");
>
> +	dssdev->channel = dpi_get_channel();

In patch 14 of the series, we remove these dssdev->channel assignments. 
I don't see the point of adding them in this patch in the first place. 
The dssdev->channel assignments will not be modified in this series, so 
we don't need to worry about a kernel crash or something after this patch.

I feel this patch should only add the dpi_get_channel and 
dsi_get_channel funcs.

> +
>   	if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
>   					dpi.vdds_dsi_reg == NULL) {
>   		struct regulator *vdds_dsi;
> @@ -416,11 +448,6 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
>   		dpi.vdds_dsi_reg = vdds_dsi;
>   	}
>
> -	/*
> -	 * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
> -	 * source for DPI is SoC integration detail, not something that should
> -	 * be configured in the dssdev
> -	 */
>   	dsidev = dpi_get_dsidev(dssdev->channel);
>
>   	if (dsidev && dpi_verify_dsi_pll(dsidev)) {
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 1a6ad6f..c39ca86 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct omap_dss_device *dssdev,
>   }
>   EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
>
> +/*
> + * Return a hardcoded channel for the DSI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dsi_get_channel(int module_id)
> +{
> +	switch (omapdss_get_version()) {
> +	case OMAPDSS_VER_OMAP24xx:

We should remove the above case so that we hit the default case and get 
a warning about omap2 not having DSI.

> +	case OMAPDSS_VER_OMAP34xx_ES1:
> +	case OMAPDSS_VER_OMAP34xx_ES3:
> +	case OMAPDSS_VER_OMAP3630:
> +	case OMAPDSS_VER_AM35xx:

<snip>

Archit


  reply	other threads:[~2013-03-11  5:47 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-08 11:51 [PATCH 00/20] OMAPDSS: misc improvements Tomi Valkeinen
2013-03-08 11:51 ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 01/20] OMAPDSS: DSI: remove DSI & DISPC clk divisors from dssdev Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 02/20] OMAPDSS: HDMI: remove HDMI " Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 03/20] OMAPDSS: DPI: remove omap_dss_device uses Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 04/20] OMAPDSS: DSI: " Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 05/20] OMAPDSS: Taal: remove multi-panel support Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 06/20] OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 07/20] OMAPDSS: add missing export for omap_dss_get_output() Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 08/20] OMAPDSS: HDMI: init output earlier Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 09/20] OMAPDSS: add output->name Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 10/20] OMAPDSS: Resolve channels for outputs Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-11  5:35   ` Archit Taneja [this message]
2013-03-11  5:47     ` Archit Taneja
2013-03-11 11:02     ` Tomi Valkeinen
2013-03-11 11:02       ` Tomi Valkeinen
2013-03-11 12:05     ` Tomi Valkeinen
2013-03-11 12:05       ` Tomi Valkeinen
2013-03-11 12:19       ` Archit Taneja
2013-03-11 12:31         ` Archit Taneja
2013-03-11  5:53   ` Archit Taneja
2013-03-11  5:54     ` Archit Taneja
2013-03-11 11:54     ` Tomi Valkeinen
2013-03-11 11:54       ` Tomi Valkeinen
2013-03-11 12:01     ` Tomi Valkeinen
2013-03-11 12:01       ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 11/20] OMAPDSS: add output->recommended_channel Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 12/20] OMAPDSS: DPI: use output->recommended_channel Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 13/20] OMAPFB: " Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 14/20] OMAPDSS: remove dssdev->channel assignments Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-11  6:24   ` Archit Taneja
2013-03-11  6:36     ` Archit Taneja
2013-03-08 11:51 ` [PATCH 15/20] OMAP: dss-common.c: remove uses of dss channel (LATER) Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 16/20] OMAPDSS: omapdss.h: remove channel field from omap_dss_device (LATER) Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 17/20] OMAPDSS: add pdata->default_display_name Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 18/20] OMAPDSS: DSI: delay dispc initialization Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-11  6:05   ` Archit Taneja
2013-03-11  6:17     ` Archit Taneja
2013-03-08 11:51 ` [PATCH 19/20] OMAPDSS: DSI: fix DSI channel source initialization Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-11  6:10   ` Archit Taneja
2013-03-11  6:22     ` Archit Taneja
2013-03-11  7:02     ` Tomi Valkeinen
2013-03-11  7:02       ` Tomi Valkeinen
2013-03-11  8:15       ` Archit Taneja
2013-03-11  8:27         ` Archit Taneja
2013-03-11  8:25         ` Tomi Valkeinen
2013-03-11  8:25           ` Tomi Valkeinen
2013-03-08 11:51 ` [PATCH 20/20] OMAPDSS: Taal: remove rotate & mirror support Tomi Valkeinen
2013-03-08 11:51   ` Tomi Valkeinen
2013-03-11  6:21   ` Archit Taneja
2013-03-11  6:33     ` Archit Taneja
2013-03-11  6:51     ` Tomi Valkeinen
2013-03-11  6:51       ` 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=513D6D06.7030902@ti.com \
    --to=archit@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tomi.valkeinen@ti.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.