linux-fbdev.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-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 07/12] OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drive
Date: Fri, 29 Jun 2012 10:12:25 +0000	[thread overview]
Message-ID: <1340964745.1866.26.camel@lappyti> (raw)
In-Reply-To: <1340893842-10626-9-git-send-email-archit@ti.com>

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

On Thu, 2012-06-28 at 20:00 +0530, Archit Taneja wrote:
> Replace the DISPC fuctions used to configure LCD channel related manager
> parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that
> the DISPC registers are written at the right time by using the shadow register
> programming model.
> 
> The LCD manager configurations is stored as a private data of manager in APPLY.
> It is treated as an extra info as it's the panel drivers which trigger this
> apply via interface drivers, and not a DSS2 user like omapfb or omapdrm.
> 
> Storing LCD manager related properties in APPLY also prevents the need to refer
> to the panel connected to the manager for information. This helps in making the
> DSS driver less dependent on panel.
> 
> A helper function is added to check whether the manager is LCD or TV. The direct
> DISPC register writes are removed from the interface drivers.


 
> +static void dss_apply_mgr_lcd_config(struct omap_overlay_manager *mgr,
> +		struct dss_lcd_mgr_config config)
> +{

This one should take a pointer to the config, not a copy (and const).

> +	struct mgr_priv_data *mp = get_mgr_priv(mgr);
> +
> +	mp->lcd_config = config;
> +	mp->extra_info_dirty = true;
> +}
> +
> +void dss_mgr_set_lcd_config(struct omap_overlay_manager *mgr,
> +		struct dss_lcd_mgr_config config)

And this.

> +{
> +	unsigned long flags;
> +	struct mgr_priv_data *mp = get_mgr_priv(mgr);
> +
> +	mutex_lock(&apply_lock);
> +
> +	if (mp->enabled)
> +		goto out;

Hmm. Should we print a warning or such here? Isn't it a bug in the
interface driver, if it tries to set the lcd config when the output is
enabled?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-06-29 10:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28 14:42 [PATCH 00/12] OMAPDSS: Apply LCD manager related parameters Archit Taneja
2012-06-28 14:42 ` [PATCH 01/12] MAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div() Archit Taneja
2012-06-28 14:42 ` [PATCH 01/12] OMAPDSS: " Archit Taneja
2012-06-28 14:42 ` [PATCH 02/12] OMAPDSS: Add struct to hold LCD overlay manager configuration Archit Taneja
2012-06-28 14:42 ` [PATCH 03/12] OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parameters Archit Taneja
2012-06-28 14:42 ` [PATCH 04/12] OMAPDSS: RFBI: " Archit Taneja
2012-06-28 14:42 ` [PATCH 05/12] OMAPDSS: DSI: " Archit Taneja
2012-06-28 14:42 ` [PATCH 06/12] OMAPDSS: SDI: " Archit Taneja
2012-06-28 14:42 ` [PATCH 07/12] OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drivers Archit Taneja
2012-06-29 10:12   ` Tomi Valkeinen [this message]
2012-06-29 10:40     ` [PATCH 07/12] OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drive Archit Taneja
2012-06-28 14:42 ` [PATCH 08/12] OMAPDSS: MANAGER: Check LCD related overlay manager parameters Archit Taneja
2012-06-28 14:42 ` [PATCH 09/12] OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checks Archit Taneja
2012-06-28 14:42 ` [PATCH 10/12] OMAPDSS: DISPC: Remove a redundant function Archit Taneja
2012-06-28 14:42 ` [PATCH 11/12] OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay manager Archit Taneja
2012-06-28 14:42 ` [PATCH 12/12] OMAPDSS: OVERLAY: Clean up replication checking Archit Taneja

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=1340964745.1866.26.camel@lappyti \
    --to=tomi.valkeinen@ti.com \
    --cc=archit@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --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).