From: Thierry Reding <thierry.reding@gmail.com>
To: Inki Dae <inki.dae@samsung.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>,
treding@nvidia.com, dri-devel@lists.freedesktop.org,
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
Date: Thu, 7 Aug 2014 11:09:01 +0200 [thread overview]
Message-ID: <20140807090859.GD13315@ulmo.nvidia.com> (raw)
In-Reply-To: <53E32FF6.6050402@samsung.com>
[-- Attachment #1.1: Type: text/plain, Size: 4796 bytes --]
On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> On 2014년 08월 07일 15:58, Thierry Reding wrote:
> > On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> >> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
[...]
> >>> As far as I can tell non-continuous mode simply means that the host can
> >>> turn off the HS clock after a high-speed transmission. I think Andrzej
> >>> mentioned this already in another subthread, but this is an optional
> >>> mode that peripherals can support if they have extra circuitry that
> >>> provides an internal clock. Peripherals that don't have such circuitry
> >>> may rely on the HS clock to perform in between transmissions and
> >>> therefore require the HS clock to be always on (continuous mode). That's
> >>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> >>> peripheral supports non-continuous mode and therefore the host can turn
> >>> the HS clock off after high-speed transmissions.
> >>
> >> What I don't make sure is this sentence. With
> >> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
> >> One is,
> >> 1. host controller will generates signals if a bit of a register
> >> related to non-contiguous clock mode is set or unset.
> >> 2. And then video data is transmitted to panel in HS mode.
> >> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
> >> are high).
> >> 4. And then D-PHY disables HS clock of host controller.
> >> 5. At this time, operation mode of host controller becomes LPM.
> >>
> >> Other is,
> >> 1. host controller will generates signals if a bit of a register
> >> related to non-contiguous clock mode is set or unset.
> >> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
> >> are high).
> >> 3. And then video data is transmitted to panel in LPM.
> >> 4. At this time, operation mode of host controller becomes LPM.
> >>
> >> It seems that you says latter case.
> >
> > No. High speed clock and low power mode are orthogonal. Non-continuous
> > mode simply means that the clock lane enters LP-11 between HS
> > transmissions (see 5.6 "Clock Management" of the DSI specification).
> >
>
> It seems that clock lane enters LP-11 regardless of HS clock enabled if
> non-continous mode is used. Right?
No, I think as long as HS clock is enabled the clock lane won't enter
LP-11. Non-continuous mode means that the controller can disable the HS
clock between HS transmissions. So in non-continuous mode the clock lane
can enter LP-11 because the controller disables the HS clock.
In continuous mode, then the clock will never be disabled, hence the
clock lane will never enter LP-11.
> And also it seems that non-continous mode is different from LPM at all
> because with non-continuous mode, command data is transmitted to panel
> in HS mode, but with LPM, command data is transmitted to panel in LP
> mode. Also right?
No. I think you can send command data to the peripheral in low power
mode in both continuous and non-continuous clock modes.
> If so, shouldn't the host driver disable HS clock, in case of LP mode,
> before the host driver transmits command data?
No. If the peripheral doesn't support non-continuous mode, then the HS
clock must never be turned off. On the other hand, if the peripheral
supports non-continuous mode, then the DSI host should automatically
disable the HS clock between high-speed transmissions. That means if a
packet is transmitted in low power mode the DSI host will not be
transmitting in high-speed mode and therefore disable the HS clock.
Obviously if the controller can't do that automatically then it might be
necessary to explicitly do that in the driver. But I doubt that any DSI
controller wouldn't be able to do that automatically. On Tegra we have a
control bit that enables non-continuous mode:
DSI_HS_CLK_CTRL: control for the HS clock lane
- 0 = CONTINUOUS: HS clock is on all the time
- 1 = TX_ONLY: HS clock is only active during HS transmissions
> And it seems that only one of these two flags, MSG_LPM and NON-CONTINUOUS,
> should be set by panel driver because with NON-CONTINUOUS clock mode, host
> controller generate clock and data lane signals regardless of controlling
> HS clock.
No. Non-continuous mode is something that's specific to the peripheral
and is always valid, whereas the MSG_LPM flag is only used to mark a
packet to be transmitted in low power mode (as opposed to high speed
mode). For peripherals that don't support non-continuous mode the
NON_CONTINUOUS flag needs to be set. But the driver for the peripheral
can still initiate low power mode packet transmissions by setting the
MSG_LPM flag.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-08-07 9:09 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-28 2:00 [PATCH v2 0/2] drm/mipi-dsi: support lpm (low power mode) transfer Inki Dae
2014-07-28 2:00 ` [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support Inki Dae
2014-07-28 16:09 ` Andrzej Hajda
2014-07-29 0:57 ` YoungJun Cho
2014-07-29 10:23 ` Andrzej Hajda
2014-08-03 7:03 ` Inki Dae
2014-08-03 7:16 ` Inki Dae
2014-08-05 8:12 ` Andrzej Hajda
2014-07-29 3:30 ` Inki Dae
2014-08-05 11:12 ` Thierry Reding
2014-08-06 7:11 ` Inki Dae
2014-08-06 7:43 ` Thierry Reding
2014-08-06 17:09 ` Inki Dae
2014-08-07 6:58 ` Thierry Reding
2014-08-07 7:51 ` Inki Dae
2014-08-07 9:09 ` Thierry Reding [this message]
2014-08-07 10:49 ` Inki Dae
2014-08-07 11:09 ` Thierry Reding
2014-08-07 13:05 ` Inki Dae
2014-08-07 13:17 ` Thierry Reding
2014-08-07 13:39 ` Inki Dae
2014-08-07 13:55 ` Thierry Reding
2014-08-08 1:45 ` Inki Dae
2014-08-08 7:03 ` Thierry Reding
2014-08-08 7:37 ` Inki Dae
2014-08-08 9:02 ` Andrzej Hajda
2014-08-08 9:40 ` Andrzej Hajda
2014-08-11 7:09 ` Inki Dae
2014-08-11 7:44 ` Andrzej Hajda
2014-08-11 8:01 ` Inki Dae
2014-08-11 8:05 ` Andrzej Hajda
2014-08-12 11:54 ` YoungJun Cho
2014-08-12 13:08 ` Inki Dae
2014-08-08 9:55 ` Thierry Reding
2014-08-11 5:19 ` Inki Dae
2014-08-11 7:24 ` Thierry Reding
2014-08-11 7:35 ` Inki Dae
2014-08-11 7:50 ` Thierry Reding
2014-08-11 8:15 ` Inki Dae
2014-08-11 9:11 ` Thierry Reding
2014-08-12 2:51 ` Inki Dae
2014-07-28 2:00 ` [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) " Inki Dae
2014-07-28 15:50 ` Andrzej Hajda
2014-07-29 3:42 ` Inki Dae
2014-07-29 11:39 ` Andrzej Hajda
2014-07-29 12:08 ` Inki Dae
2014-07-29 13:16 ` Andrzej Hajda
2014-08-07 7:09 ` Inki Dae
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=20140807090859.GD13315@ulmo.nvidia.com \
--to=thierry.reding@gmail.com \
--cc=a.hajda@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=treding@nvidia.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