All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <archit@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH 3/4] OMAP: DSS2: Handle manager change in apply
Date: Fri, 02 Sep 2011 07:25:22 +0000	[thread overview]
Message-ID: <1314948322.3374.21.camel@deskari> (raw)
In-Reply-To: <4E607CC3.2000407@ti.com>

On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
> On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
> > Currently when changing the manager of an overlay, set_manager()
> directly
> > calls dispc to set the overlay's destination.
> >
> > Change this to be more in line with other overlay configurations,
> and
> > this will also remove the need to have dispc clocks enabled when
> calling
> > set_manager().
> >
> > A new field is added to overlay struct, "manager_changed". This is
> > similar to "display_changed" field in manager struct, and is used to
> > inform apply that the manager has changed and thus write to the
> > registers is needed.
> 
> I was wondering if it would be better to create an overlay_info
> member 
> called 'channel_out' rather than having 'manager_enabled' at a higher 
> level? This way, we won't need to do some of the things below(I have 
> pointed them out): 

The overlay_info is written by the users of the DSS. So if we had
channel_out there, we'd need to remove the set/get_manager() functions.
I made those functions in the first place as I felt changing the manager
is a bit bigger operation than the normal overlay attributes. Changing
the manager does effect both the old and the new managers. While I don't
think we currently do anything related to that, I believe it would be
needed for optimizations like FIFO merge.

It could perhaps be possible to change this so that the overlay_info has
the channel_out parameter, but that would be a bit bigger change, and
would needs lots of testing. So I feel this is a safer change, and it
fixes a problem we had with DRM.

 Tomi



WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <archit@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH 3/4] OMAP: DSS2: Handle manager change in apply
Date: Fri, 02 Sep 2011 10:25:22 +0300	[thread overview]
Message-ID: <1314948322.3374.21.camel@deskari> (raw)
In-Reply-To: <4E607CC3.2000407@ti.com>

On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
> On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
> > Currently when changing the manager of an overlay, set_manager()
> directly
> > calls dispc to set the overlay's destination.
> >
> > Change this to be more in line with other overlay configurations,
> and
> > this will also remove the need to have dispc clocks enabled when
> calling
> > set_manager().
> >
> > A new field is added to overlay struct, "manager_changed". This is
> > similar to "display_changed" field in manager struct, and is used to
> > inform apply that the manager has changed and thus write to the
> > registers is needed.
> 
> I was wondering if it would be better to create an overlay_info
> member 
> called 'channel_out' rather than having 'manager_enabled' at a higher 
> level? This way, we won't need to do some of the things below(I have 
> pointed them out): 

The overlay_info is written by the users of the DSS. So if we had
channel_out there, we'd need to remove the set/get_manager() functions.
I made those functions in the first place as I felt changing the manager
is a bit bigger operation than the normal overlay attributes. Changing
the manager does effect both the old and the new managers. While I don't
think we currently do anything related to that, I believe it would be
needed for optimizations like FIFO merge.

It could perhaps be possible to change this so that the overlay_info has
the channel_out parameter, but that would be a bit bigger change, and
would needs lots of testing. So I feel this is a safer change, and it
fixes a problem we had with DRM.

 Tomi



  reply	other threads:[~2011-09-02  7:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-22  8:27 [PATCH 0/4] OMAPDSS: misc minor fixes Tomi Valkeinen
2011-08-22  8:27 ` Tomi Valkeinen
2011-08-22  8:27 ` [PATCH 1/4] OMAP: OMAPFB: make omapfb start even when a display is missing a driver Tomi Valkeinen
2011-08-22  8:27   ` Tomi Valkeinen
2011-08-27 10:28   ` [PATCH 1/4] OMAP: OMAPFB: make omapfb start even when a display Jaya Kumar
2011-08-27 10:28     ` [PATCH 1/4] OMAP: OMAPFB: make omapfb start even when a display is missing a driver Jaya Kumar
2011-08-22  8:27 ` [PATCH 2/4] OMAP: DSS2: fix clock sources on error and uninit Tomi Valkeinen
2011-08-22  8:27   ` Tomi Valkeinen
2011-08-22  8:27 ` [PATCH 3/4] OMAP: DSS2: Handle manager change in apply Tomi Valkeinen
2011-08-22  8:27   ` Tomi Valkeinen
2011-09-02  6:50   ` Archit Taneja
2011-09-02  6:51     ` Archit Taneja
2011-09-02  7:25     ` Tomi Valkeinen [this message]
2011-09-02  7:25       ` Tomi Valkeinen
2011-09-02  7:32       ` Archit Taneja
2011-09-02  7:44         ` Archit Taneja
2011-08-22  8:27 ` [PATCH 4/4] OMAP: DSS2: Remove "EXPERIMENTAL" from Kconfig Tomi Valkeinen
2011-08-22  8:27   ` 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=1314948322.3374.21.camel@deskari \
    --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 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.