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>, Rob Clark <rob@ti.com>
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH v2 09/13] OMAPDSS: SDI: Create a function to set timings
Date: Tue, 14 Aug 2012 17:33:20 +0000	[thread overview]
Message-ID: <1344965600.2345.70.camel@deskari> (raw)
In-Reply-To: <502A8322.6000309@ti.com>

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

On Tue, 2012-08-14 at 22:26 +0530, Archit Taneja wrote:
> On Tuesday 14 August 2012 07:14 PM, Tomi Valkeinen wrote:

> I guess it depends on how drm/fb want to use it. I guess an output 
> should have a set_timings() kind of op if it can do it seamlessly. I 
> guess we can do that easily in DPI, for example, we could reduce the fps 
> from 60 to 30 without causing an artefacts(I think). For outputs which 

Yes, that kind of thing is easy to do by just changing the pck divider,
which is in a shadow register. I mean, "easy" in theory, at least. Our
clock calculation doesn't work like that currently, though, so it could
end up changing DSS fck.

> can't do it, we could remove the set_timings totally.

But we do need set_timings for other outputs also (like sdi). We just
can't change them just like that. Only outputs that do not need timings
are DSI command mode and rfbi.

> However, it'll be kind of inconsistent for some outputs to set timings, 
> and for others to not, and if in the future drm/fb gets exposed to ops 
> too, we may have dirty checks to see if set_timings is populated or not.
> 
> The easiest way would be to make all set_timings just update the copy of 
> the timings output has, and expect drm/fb to disable and re enable the 
> panel. We may end up doing unnecessary gpio resets and configuration of 
> the panels though.

I think changing things like timings is quite a rare operation. The only
case it'd be necessary to change timings often, with speed, and without
artifacts would be the fps drop you mentioned, for lower power use with
panels that don't mind the fps drop.

If I understood correctly, Rob said that drm already disables the output
when changing the mode, when I asked if it's ok for the apply's
set_timings to require the output to be off.

In any case this is not a big issue, I mean, it's not causing any
problems. Somebody is going to disable the output anyway when changing
the timings. Perhaps even these patches are good, because they make the
set_timings consistent across the output drivers (don't they?).

 Tomi


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

  reply	other threads:[~2012-08-14 17:33 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-01 10:43 [RFC 00/17] OMAPDSS: Change way of passing timings from panel driver to interface Archit Taneja
2012-08-01 10:43 ` [RFC 01/17] OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings Archit Taneja
2012-08-01 10:43 ` [RFC 02/17] OMAPDSS: DPI: Remove omap_dss_device arguments in dpi_set_dsi_clk/dpi_set_dispc_clk Archit Taneja
2012-08-01 10:43 ` [RFC 03/17] OMAPDSS: HDMI: Remove omap_dss_device argument from hdmi_compute_pll Archit Taneja
2012-08-01 10:43 ` [RFC 04/17] OMAPDSS: DPI: Add locking for DPI interface Archit Taneja
2012-08-01 10:43 ` [RFC 05/17] OMAPDSS: DPI: Maintain our own timings field in driver data Archit Taneja
2012-08-01 10:43 ` [RFC 06/17] OMAPDSS: DPI displays: Take care of panel timings in the driver itself Archit Taneja
2012-08-01 10:43 ` [RFC 07/17] OMAPDSS: Displays: Add locking in generic DPI panel driver Archit Taneja
2012-08-01 10:43 ` [RFC 08/17] OMAPDSS: DSI: Maintain own copy of timings in driver data Archit Taneja
2012-08-07 14:07   ` Tomi Valkeinen
2012-08-08  6:09     ` Archit Taneja
2012-08-08  6:15       ` Tomi Valkeinen
2012-08-08  6:41         ` Archit Taneja
2012-08-08  7:10           ` Tomi Valkeinen
2012-08-08  8:06             ` Archit Taneja
2012-08-01 10:43 ` [RFC 09/17] OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings Archit Taneja
2012-08-01 10:43 ` [RFC 10/17] OMAPDSS: HDMI: Add a get_timing function for HDMI interface Archit Taneja
2012-08-01 10:43 ` [RFC 11/17] OMAPDSS: HDMI: Add locking for hdmi interface get/set timing functions Archit Taneja
2012-08-01 10:43 ` [RFC 12/17] OMAPDSS: SDI: Create a separate function for timing/clock configurations Archit Taneja
2012-08-01 10:43 ` [RFC 13/17] OMAPDSS: SDI: Create a function to set timings Archit Taneja
2012-08-07 14:20   ` Tomi Valkeinen
2012-08-08  6:10     ` Archit Taneja
2012-08-01 10:43 ` [RFC 14/17] OMAPDSS: SDI: Maintain our own timings field in driver data Archit Taneja
2012-08-01 10:43 ` [RFC 15/17] OMAPDSS: VENC: Split VENC into interface and panel driver Archit Taneja
2012-08-01 10:43 ` [RFC 16/17] OMAPDSS: VENC: Maintain our own timings field in driver data Archit Taneja
2012-08-01 10:43 ` [RFC 17/17] OMAPDSS: VENC: Add a get_timing function for VENC interface Archit Taneja
2012-08-01 10:47 ` [RFC 00/17] OMAPDSS: Change way of passing timings from panel driver to interface Archit Taneja
2012-08-07 14:32 ` Tomi Valkeinen
2012-08-08  6:17   ` Archit Taneja
2012-08-08  6:25     ` Tomi Valkeinen
2012-08-08  6:59       ` Archit Taneja
2012-08-08  7:27         ` Tomi Valkeinen
2012-08-08  8:11           ` Archit Taneja
2012-08-08  8:13             ` Tomi Valkeinen
2012-08-08  8:50               ` Archit Taneja
2012-08-08  8:48                 ` Tomi Valkeinen
2012-08-08  9:36                   ` Archit Taneja
2012-08-09 11:55 ` [PATCH v2 00/13] " Archit Taneja
2012-08-09 11:56   ` [PATCH v2 01/13] OMAPDSS: DPI: Maintain our own timings field in driver data Archit Taneja
2012-08-09 11:56   ` [PATCH v2 02/13] OMAPDSS: DPI displays: Take care of panel timings in the driver itself Archit Taneja
2012-08-09 11:56   ` [PATCH v2 03/13] OMAPDSS: DSI: Maintain own copy of timings in driver data Archit Taneja
2012-08-09 11:56   ` [PATCH v2 04/13] OMAPDSS: DSI: Add function to set panel size for command mode panels Archit Taneja
2012-08-09 11:56   ` [PATCH v2 05/13] OMAPDSS: DSI: Update manager timings on a manual update Archit Taneja
2012-08-09 11:56   ` [PATCH v2 06/13] OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings Archit Taneja
2012-08-09 11:56   ` [PATCH v2 07/13] OMAPDSS: HDMI: Add a get_timing function for HDMI interface Archit Taneja
2012-08-14 13:02     ` Tomi Valkeinen
2012-08-14 13:27       ` Archit Taneja
2012-08-14 14:10         ` Tomi Valkeinen
2012-08-14 17:28           ` Archit Taneja
2012-08-09 11:56   ` [PATCH v2 08/13] OMAPDSS: HDMI: Add locking for hdmi interface get/set timing functions Archit Taneja
2012-08-09 11:56   ` [PATCH v2 09/13] OMAPDSS: SDI: Create a function to set timings Archit Taneja
2012-08-14 13:44     ` Tomi Valkeinen
2012-08-14 17:08       ` Archit Taneja
2012-08-14 17:33         ` Tomi Valkeinen [this message]
2012-08-14 19:20           ` Archit Taneja
2012-08-15  6:43             ` Tomi Valkeinen
2012-08-14 19:26         ` Rob Clark
2012-08-09 11:56   ` [PATCH v2 10/13] OMAPDSS: SDI: Maintain our own timings field in driver data Archit Taneja
2012-08-09 11:56   ` [PATCH v2 11/13] OMAPDSS: VENC: Split VENC into interface and panel driver Archit Taneja
2012-08-09 11:56   ` [PATCH v2 12/13] OMAPDSS: VENC: Maintain our own timings field in driver data Archit Taneja
2012-08-09 11:56   ` [PATCH v2 13/13] OMAPDSS: VENC: Add a get_timing function for VENC interface 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=1344965600.2345.70.camel@deskari \
    --to=tomi.valkeinen@ti.com \
    --cc=archit@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rob@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 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).