All of lore.kernel.org
 help / color / mirror / Atom feed
From: Inki Dae <inki.dae@samsung.com>
To: Thierry Reding <thierry.reding@gmail.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: Mon, 11 Aug 2014 16:35:46 +0900	[thread overview]
Message-ID: <53E87252.60700@samsung.com> (raw)
In-Reply-To: <20140811072414.GA30762@ulmo>

On 2014년 08월 11일 16:24, Thierry Reding wrote:
> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
>> On 2014년 08월 08일 18:55, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
>>>> On 2014년 08월 08일 16:03, Thierry Reding wrote:
>>>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>>>>>> On 2014년 08월 07일 22:55, Thierry Reding wrote:
>>>>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>>>>>>>> On 2014년 08월 07일 22:17, Thierry Reding wrote:
>>>>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>>>>>>>>>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
>>>>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>>>>>>>>>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>>>> the meaning?
>>>>>>>>>>>
>>>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>>>> host controller should be disabled.
>>>>>>>>>>>
>>>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hm.. I see. I meant,
>>>>>>>>>>
>>>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>>>        disable HS clock <- required.
>>>>>>>>>>
>>>>>>>>>> transmit command data <- in LPM.
>>>>>>>>>
>>>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>>>> use.
>>>>>>>>>
>>>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>>>> need to be considered separately.
>>>>>>>>
>>>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>>>
>>>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>>>> non-continuous clock mode.
>>>>>>>
>>>>>>> No, that's not what I'm saying.
>>>>>>>
>>>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>>>
>>>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>>>>
>>>>>> That would may why we are mentioning same comments repeatedly.
>>>>>>
>>>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>>>> sure that yet it's correct way.
>>>>>
>>>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>>>> running?
>>>>
>>>> Actually, we are doing so. If the clock is still running then dsi driver
>>>> will wait for stop state of the clock and data lanes. Know that this is
>>>> valid only when initial time - just one time since power up.
>>>>
>>>> 	/* Check clock and data lane state are stop state */
>>>> 	timeout = 100;
>>>> 	do {
>>>> 		if (timeout-- == 0) {
>>>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>>>> 			return -EFAULT;
>>>> 		}
>>>>
>>>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>>>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>>>> 			continue;
>>>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>>>
>>>>>
>>>>>> In Tegra, What to do for it?
>>>>>
>>>>> There are two bits in two separate registers for this:
>>>>>
>>>>> 	DSI_HOST_CONTROL:
>>>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>>>> 	                               packets
>>>>> 	    - 0 = LOW: low speed
>>>>> 	    - 1 = HIGH: high speed
>>>>>
>>>>> 	DSI_CONTROL:
>>>>> 	  bit 20: 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
>>>>>
>>>>> So if the peripheral supports non-continuous mode of operation we set
>>>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>>>> remains on all the time.
>>>>>
>>>>> When a packet is to be transmitted in high speed mode, we set the
>>>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>>>> cleared.
>>>>
>>>> That is exactly what I want. In your case, if you want to transmit
>>>> command data in Low Power Mode in case of supporting non-continuous
>>>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>>>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>>>
>>>> So I guess,
>>>>
>>>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>>>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>>>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
>>>> }
>>>>
>>>> transmit command data <- in LPM.
>>>>
>>>> However, what if the peripheral doesn't support non-continuous but want
>>>> to transmit command data in LPM? Is that  impossible?
>>>
>>> The above is actually more like this:
>>>
>>> 	if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
>>> 		clear DSI_HS_CLK_CTRL;
>>> 	else
>>> 		set DSI_HS_CLK_CTRL;
>>>
>>> 	if (msg->flags & MIPI_DSI_MSG_USE_LPM)
>>> 		clear DSI_HIGH_SPEED_TRANS;
>>> 	else
>>> 		set DSI_HIGH_SPEED_TRANS;
>>>
>>> So for peripherals that don't support non-continuous clock mode, this
>>> will result in the following for low-power transmissions:
>>>
>>> 	clear DSI_HS_CLK_CTRL; /* HS clock always on */
>>> 	clear DSI_HIGH_SPEED_TRANS;
>>
>> Right, then how host driver should check it if peripheral doesn't
>> support non-continuous clock mode? Or how the peripheral should notify
>> it to host driver? It would need a new flag instead of
>> MIPI_DSI_MODE_NON_CONTINUOUS.
> 
> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
> set to signal that they support non-continuous mode. If devices don't
> have that set, then the controller should always provide the HS clock.
> 
> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
> does *not* support non-continuous mode.
> 

Again, assume that there is a peripheral that doesn't support
non-continuous clock mode but host driver want to transmit data in low
power. For this, you already mentioned like below,

"So for peripherals that don't support non-continuous clock mode, this
will result in the following for low-power transmissions:

 	clear DSI_HS_CLK_CTRL; /* HS clock always on */
 	clear DSI_HIGH_SPEED_TRANS;
"

In this case, how should host driver check it to clear above two flags?
As you know, this is required to clear two flags same as non-continuous
clock mode. Don't you think that we need a new flag to identify them -
non-continuous clock mode or just for low-power transmission?

Thanks,
Inki Dae

> Thierry
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2014-08-11  7:35 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
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 [this message]
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=53E87252.60700@samsung.com \
    --to=inki.dae@samsung.com \
    --cc=a.hajda@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    --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.