From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <a0393947@ti.com>
Cc: rob@ti.com, linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 17/17] OMAPDSS: DSI: Remove redundant fields in omap_dss_dsi_videomode_data
Date: Wed, 27 Jun 2012 12:31:14 +0000 [thread overview]
Message-ID: <1340800274.2649.64.camel@deskari> (raw)
In-Reply-To: <4FEAFA18.3070908@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
On Wed, 2012-06-27 at 17:48 +0530, Archit Taneja wrote:
> On Wednesday 27 June 2012 05:35 PM, Tomi Valkeinen wrote:
> > The sync polarities between DISPC and DSI do not matter elsewhere, they
> > do not affect the DSI output, so why do we have them in the panel data?
> > Why doesn't dsi.c just use some hardcoded values for these.
>
> Ok, are you saying that unlike DPI, where a panel may request for some
> different polarities. There is no such need for DSI panels, and we can
> set the polarities of DISPC and DSI always to active high(or any other
> combination)?
Yes. There are no sync polarities in DSI bus, there are only sync
packets. So afaik, the polarities used here matter only for DISPC and
DSI communication. And there the only thing that matters is that both
DISPC and DSI have the same configuration for the polarities, so that
the communication works.
> Well, we are doing that indirectly in a way, a DSI panel driver would
> populate a omap_video_timings struct, and would leave hsync_level,
> vsync_level and de_level empty(i.e, the default values). This would be
> passed to the DSI driver, and the timings would be applied to DISPC. The
> function above would just pick up the same default values and program to
> the DSI registers.
>
> What we could do is ignore these fields in the omap_video_timings when
> passed from the panel driver to DSI driver, and always use a fixed value
> for them, and this way we can use the same fixed values for DSI too. Do
> you think that is better?
I think that is clearer. Optimally we wouldn't even have a video timings
struct for DSI panels, the kind that contains sync polarities and such,
but a separate timings struct that contains stuff relevant for DSI. But
for now I think we should just ignore the "extra" values in video
timings.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-06-27 12:31 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 9:48 [PATCH 00/17] OMAPDSS: Misc DSS clean ups Archit Taneja
2012-06-26 9:48 ` [PATCH 01/17] OMAPDSS: Remove passive matrix LCD support (part 1) Archit Taneja
2012-06-26 9:48 ` [PATCH 02/17] OMAPDSS: Remove passive matrix lcd support (part 2) Archit Taneja
2012-06-26 9:48 ` [PATCH 02/17] OMAPDSS: Remove passive matrix LCD " Archit Taneja
2012-06-26 9:48 ` [PATCH 03/17] OMAPDSS: Remove passive matrix LCD support (part 3) Archit Taneja
2012-06-26 9:48 ` [PATCH 04/17] OMAPDSS: Remove passive matrix LCD support (part 4) Archit Taneja
2012-06-26 9:48 ` [PATCH 05/17] OMAPDSS: Add some new fields to omap_video_timings Archit Taneja
2012-06-27 11:48 ` Tomi Valkeinen
2012-06-27 12:38 ` Archit Taneja
2012-06-27 12:42 ` Tomi Valkeinen
2012-06-27 12:59 ` Archit Taneja
2012-06-27 13:02 ` Tomi Valkeinen
2012-06-26 9:48 ` [PATCH 06/17] OMAPDSS: DISPLAY: Ignore newly added omap_video_timings fields for display timings sys Archit Taneja
2012-06-26 9:48 ` [PATCH 07/17] OMAPDSS: DISPC: Configure newly added omap_video_timing fields Archit Taneja
2012-06-26 9:48 ` [PATCH 08/17] OMAPDSS: DISPC: Remove dispc_mgr_set_pol_freq() Archit Taneja
2012-06-26 9:48 ` [PATCH 09/17] OMAPFB: Map the newly added omap_video_timings fields with fb sync flags Archit Taneja
2012-06-26 9:48 ` [PATCH 10/17] OMAPDRM: Map the newly added omap_video_timings fields with drm mode flags Archit Taneja
2012-06-26 9:48 ` [PATCH 11/17] OMAPDSS: Remove omap_panel_config enum from omap_dss_device Archit Taneja
2012-06-26 9:48 ` [PATCH 12/17] OMAPDSS: Add interlace parameter to omap_video_timings Archit Taneja
2012-06-26 9:48 ` [PATCH 13/17] OMAPDSS: DISPC/APPLY: Use interlace info in manager timings for dispc_ovl_setup() Archit Taneja
2012-06-26 9:48 ` [PATCH 14/17] OMAPFB: Map interlace field in omap_video_timings with fb vmode flags Archit Taneja
2012-06-26 9:48 ` [PATCH 15/17] OMAPDRM: Map interlace field in omap_video_timings with drm mode flags Archit Taneja
2012-06-26 9:48 ` [PATCH 16/17] OMAPDSS: HDMI: Remove custom hdmi_video_timings struct Archit Taneja
2012-06-26 9:48 ` [PATCH 17/17] OMAPDSS: DSI: Remove redundant fields in omap_dss_dsi_videomode_data Archit Taneja
2012-06-27 12:05 ` Tomi Valkeinen
2012-06-27 12:30 ` Archit Taneja
2012-06-27 12:31 ` Tomi Valkeinen [this message]
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=1340800274.2649.64.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=a0393947@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).