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 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.