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] OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
Date: Fri, 18 May 2012 13:39:56 +0000 [thread overview]
Message-ID: <1337348396.2607.19.camel@deskari> (raw)
In-Reply-To: <1337061738-32488-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]
Hi,
On Tue, 2012-05-15 at 11:32 +0530, Archit Taneja wrote:
> DSI supports interleaving of command mode packets during the HSA, HFP, HBP and
> BLLP blanking intervals in a video mode stream. This is useful as a user may
> want to read or change the configuration of a panel without stopping the video
> stream.
>
> On OMAP DSI, we can queue HS or LP command mode packets in the TX FIFO, and
> the DSI HW takes care of interleaving this data during the one of the blanking
> intervals. The DSI HW needs to be programmed with the maximum amount of data
> that can be interleaved in a particular blanking period. A blanking period
> cannot be used to send command mode data for it's complete duration, there is
> some amount of time required for the DSI data and clock lanes to transition
> to the desired LP or HS state.
>
> Based on the state of the lanes at the beginning and end of the blanking period,
> we have different scenarios, with each scenario having a different value of time
> required to transition to HS or LP. Refer to the section 'Interleaving Mode' in
> OMAP TRM for more info on the scenarios and the equations to calculate the time
> required for HS or LP transitions.
>
> We use the scenarios which takes the maximum time for HS or LP transition, this
> gives us the minimum amount of time that can be used to interleave command mode
> data. The amount of data that can be sent during this minimum time is calculated
> for command mode packets both in LP and HS. These are written to the registers
> DSI_VM_TIMING4 to DSI_VM_TIMING6.
>
> The calculations don't take into account the time required of transmitting BTA
> when doing a DSI read, or verifying if a DSI write went through correctly. Until
> these latencies aren't considered, the behaviour of DSI is unpredictable when
> a BTA is interleaved during a blanking period. Enhancement of these calculations
> is a TODO item.
The code in dsi_config_cmd_mode_interleaving() looks a bit long and
confusing, but I don't think it's trivial to simplify it. There's just
so many variables to consider.
In the future I think we should store the DSI configurations into
memory, so that we don't need to parse the hardware registers to find
out things like DSI timings.
I'll apply this, as it's very nice to have at least minimal interleaving
support.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-05-18 13:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 6:14 [PATCH] OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods Archit Taneja
2012-05-18 13:39 ` Tomi Valkeinen [this message]
2012-05-21 8:26 ` 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=1337348396.2607.19.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 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).