Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 12일 20:54, YoungJun Cho wrote: > Hi Inki, Andrzej > > On 08/11/2014 04:09 PM, Inki Dae wrote: >> On 2014년 08월 08일 18:40, Andrzej Hajda wrote: >>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: On 08/08/2014 09:37 AM, 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 > : >> [...] >> 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 >>
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
Hi Inki, Andrzej On 08/11/2014 04:09 PM, Inki Dae wrote: On 2014년 08월 08일 18:40, Andrzej Hajda wrote: On 08/08/2014 11:02 AM, Andrzej Hajda wrote: On 08/08/2014 09:37 AM, 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 : [...] 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
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 11일 18:11, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote: >> On 2014년 08월 11일 16:50, Thierry Reding wrote: >>> On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: 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: >>> [...] >>> 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? >>> >>> See what I wrote a little further up: >>> >>> 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; >>> >>> >>> MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- >>> continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because >>> that tells the controller to turn off the HS clock between high-speed >>> transmissions. >>> >>> MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power >>> mode. >>> >>> With the above two flags we can cover four cases: >>> >>> 1) non-continuous mode with messages transmitted in low-power mode >>> 2) non-continuous mode with messages transmitted in high-speed mode >>> 3) continuous mode with messages transmitted in low-power mode >> >> In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear >> DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but >> dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right. >> You mean that continuous mode is set by default implicitly? > > Yes, if the MIPI_DSI_MODE_NON_CONTINUOUS flag is not specified, then it > means the peripheral supports only continuous mode. > On more thing, in case of non-continuous clock mode, host controller can transmit data in low power or high speed. With MIPI_DSI_MODE_NON_CONTINUOUS flag, host controller can clear DSI_HS_CLK_CTRL or set it by default. However, we have no any flag to select low power or high speed transmission. Of course, as your patch of other thread, we can set MIPI_DSI_MSG_USE_LPM by default but I'm not sure that the change incurs what problem to all other panel devices. So I think it's better to add a new flag which decides host controller should transmit data in high speed or low power. i.e., MIPI_DSI_MODE_LPM at mipi dsi framework, if ((flags & MIPI_DSI_MODE_LPM) == 0) msg->flags |= MIPI_DSI_MSG_USE_LPM; at each host driver, if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) clear high speed clock of each SoC else set high speed clock of each SoC <- by default if ((msg->flags = MIPI_DSI_MSG_USE_LPM) == 0) clear high speed transmission of each SoC else set high speed t
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote: > On 2014년 08월 11일 16:50, Thierry Reding wrote: > > On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: > >> 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: > > [...] > > 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? > > > > See what I wrote a little further up: > > > > 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; > > > > > > MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- > > continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because > > that tells the controller to turn off the HS clock between high-speed > > transmissions. > > > > MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power > > mode. > > > > With the above two flags we can cover four cases: > > > > 1) non-continuous mode with messages transmitted in low-power mode > > 2) non-continuous mode with messages transmitted in high-speed mode > > 3) continuous mode with messages transmitted in low-power mode > > In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear > DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but > dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right. > You mean that continuous mode is set by default implicitly? Yes, if the MIPI_DSI_MODE_NON_CONTINUOUS flag is not specified, then it means the peripheral supports only continuous mode. Thierry pgpDS3SM5RpCn.pgp Description: PGP signature
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 11일 16:50, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: >> 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: > [...] > 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? > > See what I wrote a little further up: > > 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; > > > MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- > continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because > that tells the controller to turn off the HS clock between high-speed > transmissions. > > MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power > mode. > > With the above two flags we can cover four cases: > > 1) non-continuous mode with messages transmitted in low-power mode > 2) non-continuous mode with messages transmitted in high-speed mode > 3) continuous mode with messages transmitted in low-power mode In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right. You mean that continuous mode is set by default implicitly? Thanks, Inki Dae > 4) continuous mode with messages transmitted in high-speed mode > > What other cases do you think we need to support? > > Thierry > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 08/11/2014 09:44 AM, Andrzej Hajda wrote: > On 08/11/2014 09:09 AM, Inki Dae wrote: >> On 2014년 08월 08일 18:40, Andrzej Hajda wrote: >>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: On 08/08/2014 09:37 AM, 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 > : >> [...] >> 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 wil
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 11일 16:44, Andrzej Hajda wrote: > On 08/11/2014 09:09 AM, Inki Dae wrote: >> On 2014년 08월 08일 18:40, Andrzej Hajda wrote: >>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: On 08/08/2014 09:37 AM, 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 > : >> [...] >> 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 wil
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: > 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: [...] > >>> 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? See what I wrote a little further up: > >>> 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; > >>> MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because that tells the controller to turn off the HS clock between high-speed transmissions. MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power mode. With the above two flags we can cover four cases: 1) non-continuous mode with messages transmitted in low-power mode 2) non-continuous mode with messages transmitted in high-speed mode 3) continuous mode with messages transmitted in low-power mode 4) continuous mode with messages transmitted in high-speed mode What other cases do you think we need to support? Thierry pgp7G1pImdMYn.pgp Description: PGP signature
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 08/11/2014 09:09 AM, Inki Dae wrote: > On 2014년 08월 08일 18:40, Andrzej Hajda wrote: >> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: >>> On 08/08/2014 09:37 AM, 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 : > [...] > 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-continuo
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : > [...] > 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. > >> An
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 > >> : > >>> [...] > >>> 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 differ
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 08월 08일 18:40, Andrzej Hajda wrote: > On 08/08/2014 11:02 AM, Andrzej Hajda wrote: >> On 08/08/2014 09:37 AM, 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 >>> : [...] 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
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 >> : >>> [...] >>> 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
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 > : > > [...] > > 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
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 08/08/2014 11:02 AM, Andrzej Hajda wrote: > On 08/08/2014 09:37 AM, 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 >> : >>> [...] >>> 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
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 08/08/2014 09:37 AM, 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 > : >> [...] >> 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 does
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : > [...] > 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 turne
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 > >> : > >>> [...] > >>> 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 > >>>
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : >>> [...] >>> 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
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : > > [...] > > 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 shoul
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : > [...] > 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
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : > >>> [...] > >>> 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 specifi
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : >>> [...] >>> 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. Thanks, Inki Dae > For low power transmissions, only data lane 0 is used (with a clock > embedded in the signal), therefore th
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : > > [...] > > 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). For low power transmissions, only data lane 0 is used (with a clock embedded in the signal), therefore the clock lane (driven by the HS clock) can be in LP-11. Thierry pgpH58pafye95.pgp Description: PGP signature
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : > [...] > 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? > > 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. Your comment, "if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefor disable the HS clock" would mean same as my question. > > 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 MIPI-DSI of Exynos SoC also has similar bit but the spec doesn't describe it enough. Thanks for information. I will try to get more information about above comments from HW guys if I can contact them. Thanks, Inki Dae > >> And it seems that only one of these two flags, MSG_LPM and
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : [...] > >>> 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 pgpOCE3c6B34y.pgp Description: PGP signature
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
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 : >>> On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: On 2014년 08월 05일 20:12, Thierry Reding wrote: >>> [...] > I think that low power mode is more often used for command transmission > (in host-driven mode). I'm not sure how much sense it really makes to > transmit video data in low power mode. It also seems like low power mode > is what all peripherals need to support (if they can do command mode). > Hence I'd like to propose the attached patch that makes all command > messages use low power mode. To use low power mode, I think SoC drivers should add more codes: checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does exactly that, http://www.spinics.net/lists/linux-samsung-soc/msg34866.html >>> >>> I agree in general that DSI host drivers need to check the flags to make >>> a decision about which mode to enable. But your patch also introduces >>> additional flags that I don't think are necessary (at least for any of >>> the use-cases discussed so far). >>> >>> As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM >>> flags that you introduce would advertise that the device only supports >>> low power mode for command or video modes respectively. However, I doubt >> >> Not so. My intention is to add LPM support for video and command data >> transfers because mipi-dsi framework enforces implicitly using HS mode >> for by default. > > No, it doesn't enforce anything at this point. Everyone is free to use > whatever they see fit. Drivers that require low power mode for command > transmission can set the MIPI_DSI_MSG_USE_LPM flag in messages. For > video there's no way to specify what a given peripheral uses, so DSI > host controller drivers are free to do whatever they want. > > So for command data we already have a means, and for video data I don't > think it makes sense to use low power mode. Therefore I don't think > these new flags are necessary. > >>> that there really are devices that only support low power video mode. It >>> wouldn't make much sense because you'd get a maximum of 10 MHz for the >>> clock, which is about 1.6 frames per second at 1920x1080 resolution (not >>> counting blanking). And even with lower resolutions such as 1024x768 it >>> would be somewhere around 4 frames per second. And I think it's >>> reasonable to assume that we'll see that kind of resolution become very >>> rare in the future. >>> >>> So my point is that devices which support video mode will always support >>> high speed mode for video transmission too. Similarly, if a device >>> supports command mode, then it will likely support it in low-power mode, >>> and optionally in high speed mode too. >>> And what I and Andrzej don't make sure is non-continuous clock mode. Do you know how non-continuous clock mode is related to HS clock? >>> >>> 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
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: > 2014-08-06 16:43 GMT+09:00 Thierry Reding : > > On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: > >> On 2014년 08월 05일 20:12, Thierry Reding wrote: > > [...] > >> > I think that low power mode is more often used for command transmission > >> > (in host-driven mode). I'm not sure how much sense it really makes to > >> > transmit video data in low power mode. It also seems like low power mode > >> > is what all peripherals need to support (if they can do command mode). > >> > Hence I'd like to propose the attached patch that makes all command > >> > messages use low power mode. > >> > >> To use low power mode, I think SoC drivers should add more codes: > >> checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does > >> exactly that, > >> http://www.spinics.net/lists/linux-samsung-soc/msg34866.html > > > > I agree in general that DSI host drivers need to check the flags to make > > a decision about which mode to enable. But your patch also introduces > > additional flags that I don't think are necessary (at least for any of > > the use-cases discussed so far). > > > > As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM > > flags that you introduce would advertise that the device only supports > > low power mode for command or video modes respectively. However, I doubt > > Not so. My intention is to add LPM support for video and command data > transfers because mipi-dsi framework enforces implicitly using HS mode > for by default. No, it doesn't enforce anything at this point. Everyone is free to use whatever they see fit. Drivers that require low power mode for command transmission can set the MIPI_DSI_MSG_USE_LPM flag in messages. For video there's no way to specify what a given peripheral uses, so DSI host controller drivers are free to do whatever they want. So for command data we already have a means, and for video data I don't think it makes sense to use low power mode. Therefore I don't think these new flags are necessary. > > that there really are devices that only support low power video mode. It > > wouldn't make much sense because you'd get a maximum of 10 MHz for the > > clock, which is about 1.6 frames per second at 1920x1080 resolution (not > > counting blanking). And even with lower resolutions such as 1024x768 it > > would be somewhere around 4 frames per second. And I think it's > > reasonable to assume that we'll see that kind of resolution become very > > rare in the future. > > > > So my point is that devices which support video mode will always support > > high speed mode for video transmission too. Similarly, if a device > > supports command mode, then it will likely support it in low-power mode, > > and optionally in high speed mode too. > > > >> And what I and Andrzej don't make sure is non-continuous clock mode. Do > >> you know how non-continuous clock mode is related to HS clock? > > > > 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). For low power mode the clock is embedded in the signal on the data lane and therefore independent of the high speed clock. A peripheral device will set the MIPI_DSI_CLOCK_NON_CONTINUOUS flag if it sup
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
2014-08-06 16:43 GMT+09:00 Thierry Reding : > On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: >> On 2014년 08월 05일 20:12, Thierry Reding wrote: > [...] >> > I think that low power mode is more often used for command transmission >> > (in host-driven mode). I'm not sure how much sense it really makes to >> > transmit video data in low power mode. It also seems like low power mode >> > is what all peripherals need to support (if they can do command mode). >> > Hence I'd like to propose the attached patch that makes all command >> > messages use low power mode. >> >> To use low power mode, I think SoC drivers should add more codes: >> checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does >> exactly that, >> http://www.spinics.net/lists/linux-samsung-soc/msg34866.html > > I agree in general that DSI host drivers need to check the flags to make > a decision about which mode to enable. But your patch also introduces > additional flags that I don't think are necessary (at least for any of > the use-cases discussed so far). > > As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM > flags that you introduce would advertise that the device only supports > low power mode for command or video modes respectively. However, I doubt Not so. My intention is to add LPM support for video and command data transfers because mipi-dsi framework enforces implicitly using HS mode for by default. > that there really are devices that only support low power video mode. It > wouldn't make much sense because you'd get a maximum of 10 MHz for the > clock, which is about 1.6 frames per second at 1920x1080 resolution (not > counting blanking). And even with lower resolutions such as 1024x768 it > would be somewhere around 4 frames per second. And I think it's > reasonable to assume that we'll see that kind of resolution become very > rare in the future. > > So my point is that devices which support video mode will always support > high speed mode for video transmission too. Similarly, if a device > supports command mode, then it will likely support it in low-power mode, > and optionally in high speed mode too. > >> And what I and Andrzej don't make sure is non-continuous clock mode. Do >> you know how non-continuous clock mode is related to HS clock? > > 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. I really know that with non-contiguous clock mode, HS clock of host controller can be disabled. My question is who controls HS clock in this case. D-PHY or host controller? In other words, with LPM and MIPI_DSI_CLOCK_NON_CONTIUOUS flags, should the host driver check these two flags to disable HS clock? or In this case, does the D-PHY disable HS clock regardless of host driver? I think we should make sure that to handle LP and HS modes correctly. > > If a device doesn't specify that flag then the host needs to keep the HS > clock running all the time. > >> > The .transfer() function was really designed with initialization >> > commands in mind, so it doesn't deal with mixing video data and commands >> > anyway and for initialization low-power mode should be fast enough. The >> > downside is that it may not be optimal for some peripherals, but it >> > gives us a good solution for the general case since it should support >> > all devices. >> > >> > If we absolutely must have faster initialization, or if we come across a >> > device that can only initialize in high speed mode, then I think we >> > should int
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: > On 2014년 08월 05일 20:12, Thierry Reding wrote: [...] > > I think that low power mode is more often used for command transmission > > (in host-driven mode). I'm not sure how much sense it really makes to > > transmit video data in low power mode. It also seems like low power mode > > is what all peripherals need to support (if they can do command mode). > > Hence I'd like to propose the attached patch that makes all command > > messages use low power mode. > > To use low power mode, I think SoC drivers should add more codes: > checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does > exactly that, > http://www.spinics.net/lists/linux-samsung-soc/msg34866.html I agree in general that DSI host drivers need to check the flags to make a decision about which mode to enable. But your patch also introduces additional flags that I don't think are necessary (at least for any of the use-cases discussed so far). As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM flags that you introduce would advertise that the device only supports low power mode for command or video modes respectively. However, I doubt that there really are devices that only support low power video mode. It wouldn't make much sense because you'd get a maximum of 10 MHz for the clock, which is about 1.6 frames per second at 1920x1080 resolution (not counting blanking). And even with lower resolutions such as 1024x768 it would be somewhere around 4 frames per second. And I think it's reasonable to assume that we'll see that kind of resolution become very rare in the future. So my point is that devices which support video mode will always support high speed mode for video transmission too. Similarly, if a device supports command mode, then it will likely support it in low-power mode, and optionally in high speed mode too. > And what I and Andrzej don't make sure is non-continuous clock mode. Do > you know how non-continuous clock mode is related to HS clock? 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. If a device doesn't specify that flag then the host needs to keep the HS clock running all the time. > > The .transfer() function was really designed with initialization > > commands in mind, so it doesn't deal with mixing video data and commands > > anyway and for initialization low-power mode should be fast enough. The > > downside is that it may not be optimal for some peripherals, but it > > gives us a good solution for the general case since it should support > > all devices. > > > > If we absolutely must have faster initialization, or if we come across a > > device that can only initialize in high speed mode, then I think we > > should introduce a new flag to allow DSI host controllers to optimize in > > those cases. > > Originally, mipi-dsi framework enforces implicitly using HS mode for > video and command data as default so I added LPM relevant flags - for > video and also command data Yes, it transmits in HS mode by default. Quite frankly, I'm not sure if that's really the right default. Given that .transfer() is meant for sending synchronous commands, low-power mode would probably be a better default. > - for host driver can consider Low Power Mode. However, your patch makes > it use Low Power Mode for command data as default. Not as default. It just means that all messages that are sent using the standard functions use low-power mode. Drivers could still override the default by constructing the messages themselves. > So your patch would mean that default transfer mode for command data is > Low Power Mode, but HS mode for video data. Exactly. For the reasons specified above, I'd expect peripherals to always support command transmissions in low-power mode, whereas I'd equally expect them to support video transmission in high-speed mode. Therefore I think the default should be to send commands in low-power mode and video data in high speed mode (by default), because those are the normal cases. If we ever encounter a device that requires something different we can always introduce an additional flag/quirk at that point. > Do you intend to control transfer mode - HS or LPM - only for command > data? If so, we would need only one flag, i.e., MIPI_DSI_MODE_HS. We already have that flag, it's called MIPI_DSI_MSG_USE_LPM.
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
Thanks for comments. On 2014년 08월 05일 20:12, Thierry Reding wrote: > On Mon, Jul 28, 2014 at 06:09:58PM +0200, Andrzej Hajda wrote: >> On 07/28/2014 04:00 AM, Inki Dae wrote: >>> This patch adds below two flags for LPM transfer, and it attaches LPM flags >>> to a msg in accordance with master's mode_flags set by LCD Panel driver. >>> >>> MIPI_DSI_MODE_CMD_LPM >>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>> command data to Panel device in Low Power Mode. >> >> What do you mean by command data? It could be: >> - all transfer in command mode of operations, >> - transfer initialized by the driver by writing to DSIM registers. >> >>> >>> MIPI_DSI_MODE_VIDEO_LPM >>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>> image data to Panel device in Low Power Mode. >> >> What is the meaning of this flag in case of command mode of operation? >> >> Maybe it would be better to create flags based on source of data/FIFOs: >> - commands send by SFR registers, >> - commands generated from data sent from Display Controller. > > I have no idea what SFR is. But it sounds like you're talking about two > ways to generate command packets here. We have something similar on > Tegra, where it's called "host-driven command mode" and "DC-driven > command mode". > > In host-driven command mode the driver needs to explicitly program some > of the DSI controller registers to send command packets. This is > essentially a FIFO register and a control register to trigger > transmission and poll for completion. > > DC-driven command mode is typically used to update contents of a remote > framebuffer (what MIPI calls "Type 1 Display Architecture"). This is > done by programming a different set of registers that cause the DSI > controller to take data output by the display controller and wrap it > into DCS commands (e.g. write_memory_start and write_memory_continue). > Exynos also supports above two command mode but we have never used DC-driven command mode. > I think that low power mode is more often used for command transmission > (in host-driven mode). I'm not sure how much sense it really makes to > transmit video data in low power mode. It also seems like low power mode > is what all peripherals need to support (if they can do command mode). > Hence I'd like to propose the attached patch that makes all command > messages use low power mode. To use low power mode, I think SoC drivers should add more codes: checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does exactly that, http://www.spinics.net/lists/linux-samsung-soc/msg34866.html And what I and Andrzej don't make sure is non-continuous clock mode. Do you know how non-continuous clock mode is related to HS clock? > > The .transfer() function was really designed with initialization > commands in mind, so it doesn't deal with mixing video data and commands > anyway and for initialization low-power mode should be fast enough. The > downside is that it may not be optimal for some peripherals, but it > gives us a good solution for the general case since it should support > all devices. > > If we absolutely must have faster initialization, or if we come across a > device that can only initialize in high speed mode, then I think we > should introduce a new flag to allow DSI host controllers to optimize in > those cases. Originally, mipi-dsi framework enforces implicitly using HS mode for video and command data as default so I added LPM relevant flags - for video and also command data - for host driver can consider Low Power Mode. However, your patch makes it use Low Power Mode for command data as default. So your patch would mean that default transfer mode for command data is Low Power Mode, but HS mode for video data. Do you intend to control transfer mode - HS or LPM - only for command data? If so, we would need only one flag, i.e., MIPI_DSI_MODE_HS. Thanks, Inki Dae > > Note that this is based on some of my local patches, so it won't apply > as-is. But if anybody wants to give this a go it should be easy to apply > manually as well. > > Thierry > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On Mon, Jul 28, 2014 at 06:09:58PM +0200, Andrzej Hajda wrote:
> On 07/28/2014 04:00 AM, Inki Dae wrote:
> > This patch adds below two flags for LPM transfer, and it attaches LPM flags
> > to a msg in accordance with master's mode_flags set by LCD Panel driver.
> >
> > MIPI_DSI_MODE_CMD_LPM
> > - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
> > command data to Panel device in Low Power Mode.
>
> What do you mean by command data? It could be:
> - all transfer in command mode of operations,
> - transfer initialized by the driver by writing to DSIM registers.
>
> >
> > MIPI_DSI_MODE_VIDEO_LPM
> > - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
> > image data to Panel device in Low Power Mode.
>
> What is the meaning of this flag in case of command mode of operation?
>
> Maybe it would be better to create flags based on source of data/FIFOs:
> - commands send by SFR registers,
> - commands generated from data sent from Display Controller.
I have no idea what SFR is. But it sounds like you're talking about two
ways to generate command packets here. We have something similar on
Tegra, where it's called "host-driven command mode" and "DC-driven
command mode".
In host-driven command mode the driver needs to explicitly program some
of the DSI controller registers to send command packets. This is
essentially a FIFO register and a control register to trigger
transmission and poll for completion.
DC-driven command mode is typically used to update contents of a remote
framebuffer (what MIPI calls "Type 1 Display Architecture"). This is
done by programming a different set of registers that cause the DSI
controller to take data output by the display controller and wrap it
into DCS commands (e.g. write_memory_start and write_memory_continue).
I think that low power mode is more often used for command transmission
(in host-driven mode). I'm not sure how much sense it really makes to
transmit video data in low power mode. It also seems like low power mode
is what all peripherals need to support (if they can do command mode).
Hence I'd like to propose the attached patch that makes all command
messages use low power mode.
The .transfer() function was really designed with initialization
commands in mind, so it doesn't deal with mixing video data and commands
anyway and for initialization low-power mode should be fast enough. The
downside is that it may not be optimal for some peripherals, but it
gives us a good solution for the general case since it should support
all devices.
If we absolutely must have faster initialization, or if we come across a
device that can only initialize in high speed mode, then I think we
should introduce a new flag to allow DSI host controllers to optimize in
those cases.
Note that this is based on some of my local patches, so it won't apply
as-is. But if anybody wants to give this a go it should be easy to apply
manually as well.
Thierry
From f93dd508afc19262fd95c01520d5d6d7937be4e8 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Tue, 5 Aug 2014 11:30:14 +0200
Subject: [PATCH] drm/dsi: Always use low-power mode for DCS commands
Many peripherals require DCS commands to be sent in low power mode and
will fail to correctly process them in high speed mode. Section 5.2 of
the MIPI DSI specification also mandates that on bidirectional lanes,
data shall be transmitted in low power mode only. At worst this change
will make transmission of DCS commands slower than optimal on some DSI
peripherals, but it should enable DCS commands to be successfully
transmitted to any DSI peripheral.
If transmission in low power mode turns out to be too slow at some point
in the future, one possible solution would be to explicitly mark devices
that support high speed transmission of DCS commands.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_mipi_dsi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index b0a304ab6827..57588b9ff7c6 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -370,6 +370,7 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device *dsi,
{
struct mipi_dsi_msg msg = {
.channel = dsi->channel,
+ .flags = MIPI_DSI_MSG_USE_LPM,
.tx_buf = data,
.tx_len = len
};
@@ -457,6 +458,7 @@ ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, u8 cmd,
}
memset(&msg, 0, sizeof(msg));
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
msg.channel = dsi->channel;
msg.tx_len = size;
msg.tx_buf = tx;
@@ -501,6 +503,7 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 cmd, void *data,
struct mipi_dsi_msg msg = {
.channel = dsi->channel,
.type = MIPI_DSI_DCS_READ,
+ .flags = MIPI_DSI_MSG_USE_LPM,
.tx_buf = &cmd,
.tx_len = 1,
.rx_buf = data,
--
2.0.4
pgpx9L2xcAA18.pgp
Description: PGP signature
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 08/03/2014 09:16 AM, Inki Dae wrote: > 2014-08-03 16:03 GMT+09:00 Inki Dae : >> 2014-07-29 19:23 GMT+09:00 Andrzej Hajda : >>> On 07/29/2014 02:57 AM, YoungJun Cho wrote: Hi Andrzej, On 07/29/2014 01:09 AM, Andrzej Hajda wrote: > On 07/28/2014 04:00 AM, Inki Dae wrote: >> This patch adds below two flags for LPM transfer, and it attaches LPM >> flags >> to a msg in accordance with master's mode_flags set by LCD Panel driver. >> >> MIPI_DSI_MODE_CMD_LPM >> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >> command data to Panel device in Low Power Mode. > What do you mean by command data? It could be: > - all transfer in command mode of operations, > - transfer initialized by the driver by writing to DSIM registers. The 2nd one. >> MIPI_DSI_MODE_VIDEO_LPM >> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >> image data to Panel device in Low Power Mode. > What is the meaning of this flag in case of command mode of operation? I'm also not sure that there is a case to transfer image data in Low Power Mode, but this flag is not related with 'command mode' only. Inki may consider generic condition. > Maybe it would be better to create flags based on source of data/FIFOs: > - commands send by SFR registers, > - commands generated from data sent from Display Controller. > > >> And above two flags can be combined together to transfer command and >> video >> data to Panel device. >> >> MIPI DSI spec says, >> "the host processor controls the desired mode of clock operation. >>Host protocol and applications control Clock Lane operating mode >>(High Speed or Low Power mode). System designers are responsible >>for understanding the clock requirements for peripherals attached >>to DSI and controlling clock behavior in accordance with those >>requirements." >> >> Some LCD Panel devices, nt35502a, would need LPM transfer support >> because they should receive some initial commands with LPM by default >> hardware setting. > Is this requirement for initial commands, or for all commands. > Btw what is the mode of operation of nt35502a? What flags do you need > for it? > The nt35502a panel is video(RGB) mode panel and it requires low power mode for initial commands, which means to initialize nt35502a panel, the initial commands are transferred by LP mode(Not HS mode). And after initialization, its other features like gamma control or etc could be controlled in HS mode. >>> It sounds similar to my tc358764 bridge driver [1]. The difference is that >>> it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM. >>> >>> As I understand nt35502a requires also different driving of >>> TxRequestHSClk signal >>> and this seems to me unrelated to LPM. As LPM is not related at all with >>> HS clock, AFAIK. >>> >> + Tomi Valkeinen >> >> At private talks before, I think we reached the following consensus, >> >> 1. D-PHY could disable HS clock of MIPI-DSI controller in case that >> D-PHY detectsTransition to Stop state (LP=11) and TxRequestHSClk bit >> of MIPI-DSI controller is set, which means that Panel driver set >> MIPI_DSI_CLOCK_NON_CONTINUOUS flag. >> >> 2. Lower Power Mode means that the state of HS clock is low, Positive >> and Negative lane are all low, LP-11 state. >> >> However, it seems some misunderstanding each other. >> >> I guess that non-contiguous clock mode - TxRequestHSCllk bit is set or >> maybe unset - would mean that HS clock is high while MIPI-DSI >> controller transmits data to Panel until D-PHY detects LP-11 state. > Or with non-contiguous clock mode, data may be transmistted to Panel > in LPM (HS clock is low and LP-11) after D-PHY detects LP-11 state. To > make sure this, I will try to test that Panel - requiring LPM transfer > for initial commands as default hw setting - works well with > non-contiguous clock mode. In this cae, it seems that we need to > consider HW that supports non-continuous clock mode. I think the situation is quite simple: 1. HS clock is provided via clock line and according to DSI specs it can be used for two things: a) HS transfers, b) Application clock - "to support active circuitry at the peripheral" [1]. Some peripherals does not need it so in such case DSI-Master can disable the HS clock between HS transfer - it is called "non-continuous clock behavior". All DSI-Masters shall support "continuous clock behavior" and can optionally support "non-continuous clock behavior". "non-continuous clock behavior" can be enabled in case peripheral have such capability. In case of drm_mipi_dsi bus the capability is signaled by recently introduced MIPI_DSI_CLOCK_NON_CONTINUOUS flag. 2. Low-Power Transmissions does not use/depend on clock line, so it has nothing to do
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
2014-08-03 16:03 GMT+09:00 Inki Dae : > 2014-07-29 19:23 GMT+09:00 Andrzej Hajda : >> On 07/29/2014 02:57 AM, YoungJun Cho wrote: >>> Hi Andrzej, >>> >>> On 07/29/2014 01:09 AM, Andrzej Hajda wrote: On 07/28/2014 04:00 AM, Inki Dae wrote: > This patch adds below two flags for LPM transfer, and it attaches LPM > flags > to a msg in accordance with master's mode_flags set by LCD Panel driver. > > MIPI_DSI_MODE_CMD_LPM > - If this flag is set by Panel driver, MIPI-DSI controller will tranfer > command data to Panel device in Low Power Mode. What do you mean by command data? It could be: - all transfer in command mode of operations, - transfer initialized by the driver by writing to DSIM registers. >>> The 2nd one. >>> > MIPI_DSI_MODE_VIDEO_LPM > - If this flag is set by Panel driver, MIPI-DSI controller will tranfer > image data to Panel device in Low Power Mode. What is the meaning of this flag in case of command mode of operation? >>> I'm also not sure that there is a case to transfer image data in Low >>> Power Mode, but this flag is not related with 'command mode' only. >>> Inki may consider generic condition. >>> Maybe it would be better to create flags based on source of data/FIFOs: - commands send by SFR registers, - commands generated from data sent from Display Controller. > And above two flags can be combined together to transfer command and video > data to Panel device. > > MIPI DSI spec says, > "the host processor controls the desired mode of clock operation. >Host protocol and applications control Clock Lane operating mode >(High Speed or Low Power mode). System designers are responsible >for understanding the clock requirements for peripherals attached >to DSI and controlling clock behavior in accordance with those >requirements." > > Some LCD Panel devices, nt35502a, would need LPM transfer support > because they should receive some initial commands with LPM by default > hardware setting. Is this requirement for initial commands, or for all commands. Btw what is the mode of operation of nt35502a? What flags do you need for it? >>> The nt35502a panel is video(RGB) mode panel and it requires low power >>> mode for initial commands, which means to initialize nt35502a panel, the >>> initial commands are transferred by LP mode(Not HS mode). >>> And after initialization, its other features like gamma control or etc >>> could be controlled in HS mode. >> >> It sounds similar to my tc358764 bridge driver [1]. The difference is that >> it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM. >> >> As I understand nt35502a requires also different driving of >> TxRequestHSClk signal >> and this seems to me unrelated to LPM. As LPM is not related at all with >> HS clock, AFAIK. >> > > + Tomi Valkeinen > > At private talks before, I think we reached the following consensus, > > 1. D-PHY could disable HS clock of MIPI-DSI controller in case that > D-PHY detectsTransition to Stop state (LP=11) and TxRequestHSClk bit > of MIPI-DSI controller is set, which means that Panel driver set > MIPI_DSI_CLOCK_NON_CONTINUOUS flag. > > 2. Lower Power Mode means that the state of HS clock is low, Positive > and Negative lane are all low, LP-11 state. > > However, it seems some misunderstanding each other. > > I guess that non-contiguous clock mode - TxRequestHSCllk bit is set or > maybe unset - would mean that HS clock is high while MIPI-DSI > controller transmits data to Panel until D-PHY detects LP-11 state. Or with non-contiguous clock mode, data may be transmistted to Panel in LPM (HS clock is low and LP-11) after D-PHY detects LP-11 state. To make sure this, I will try to test that Panel - requiring LPM transfer for initial commands as default hw setting - works well with non-contiguous clock mode. In this cae, it seems that we need to consider HW that supports non-continuous clock mode. Thanks, Inki Dae > Therefore, I think LPM is different from non-contiguous clock mode, > and I think with LPM flag, host driver - for MIPI-DSI device - should > disable HS clock to transmit data to Panel. So I think HS clock is > related to LPM. > > Anyway, we all are not sure how D-PHY handles HS clock of MIPI-DSI > controller. So we would need more comments from HW guy or > specitialists of MIPI-DSI to make sure. I think Tomi Valkeinen would > be one of the specitialists. > > Hi Tomi, > Could you give us some comments about this? Is HS clock unrelated to > Low Power Mode at all? And do you know D-PHY handle HS clock of > MIPI-DSI controller with non-contigous clock mode? > > Thanks, > Inki Dae > >> Regards >> Andrzej >> >> [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 >> >> >>> >>> Thank you. >>> Best regards YJ >>> > Changelog v2: just add more descriptions. > > Signed-off-b
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
2014-07-29 19:23 GMT+09:00 Andrzej Hajda : > On 07/29/2014 02:57 AM, YoungJun Cho wrote: >> Hi Andrzej, >> >> On 07/29/2014 01:09 AM, Andrzej Hajda wrote: >>> On 07/28/2014 04:00 AM, Inki Dae wrote: This patch adds below two flags for LPM transfer, and it attaches LPM flags to a msg in accordance with master's mode_flags set by LCD Panel driver. MIPI_DSI_MODE_CMD_LPM - If this flag is set by Panel driver, MIPI-DSI controller will tranfer command data to Panel device in Low Power Mode. >>> What do you mean by command data? It could be: >>> - all transfer in command mode of operations, >>> - transfer initialized by the driver by writing to DSIM registers. >> The 2nd one. >> MIPI_DSI_MODE_VIDEO_LPM - If this flag is set by Panel driver, MIPI-DSI controller will tranfer image data to Panel device in Low Power Mode. >>> What is the meaning of this flag in case of command mode of operation? >> I'm also not sure that there is a case to transfer image data in Low >> Power Mode, but this flag is not related with 'command mode' only. >> Inki may consider generic condition. >> >>> Maybe it would be better to create flags based on source of data/FIFOs: >>> - commands send by SFR registers, >>> - commands generated from data sent from Display Controller. >>> >>> And above two flags can be combined together to transfer command and video data to Panel device. MIPI DSI spec says, "the host processor controls the desired mode of clock operation. Host protocol and applications control Clock Lane operating mode (High Speed or Low Power mode). System designers are responsible for understanding the clock requirements for peripherals attached to DSI and controlling clock behavior in accordance with those requirements." Some LCD Panel devices, nt35502a, would need LPM transfer support because they should receive some initial commands with LPM by default hardware setting. >>> >>> Is this requirement for initial commands, or for all commands. >>> Btw what is the mode of operation of nt35502a? What flags do you need >>> for it? >>> >> The nt35502a panel is video(RGB) mode panel and it requires low power >> mode for initial commands, which means to initialize nt35502a panel, the >> initial commands are transferred by LP mode(Not HS mode). >> And after initialization, its other features like gamma control or etc >> could be controlled in HS mode. > > It sounds similar to my tc358764 bridge driver [1]. The difference is that > it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM. > > As I understand nt35502a requires also different driving of > TxRequestHSClk signal > and this seems to me unrelated to LPM. As LPM is not related at all with > HS clock, AFAIK. > + Tomi Valkeinen At private talks before, I think we reached the following consensus, 1. D-PHY could disable HS clock of MIPI-DSI controller in case that D-PHY detectsTransition to Stop state (LP=11) and TxRequestHSClk bit of MIPI-DSI controller is set, which means that Panel driver set MIPI_DSI_CLOCK_NON_CONTINUOUS flag. 2. Lower Power Mode means that the state of HS clock is low, Positive and Negative lane are all low, LP-11 state. However, it seems some misunderstanding each other. I guess that non-contiguous clock mode - TxRequestHSCllk bit is set or maybe unset - would mean that HS clock is high while MIPI-DSI controller transmits data to Panel until D-PHY detects LP-11 state. Therefore, I think LPM is different from non-contiguous clock mode, and I think with LPM flag, host driver - for MIPI-DSI device - should disable HS clock to transmit data to Panel. So I think HS clock is related to LPM. Anyway, we all are not sure how D-PHY handles HS clock of MIPI-DSI controller. So we would need more comments from HW guy or specitialists of MIPI-DSI to make sure. I think Tomi Valkeinen would be one of the specitialists. Hi Tomi, Could you give us some comments about this? Is HS clock unrelated to Low Power Mode at all? And do you know D-PHY handle HS clock of MIPI-DSI controller with non-contigous clock mode? Thanks, Inki Dae > Regards > Andrzej > > [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 > > >> >> Thank you. >> Best regards YJ >> >>> Changelog v2: just add more descriptions. Signed-off-by: Inki Dae Acked-by: Kyungmin Park --- drivers/gpu/drm/drm_mipi_dsi.c |3 +++ include/drm/drm_mipi_dsi.h |4 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index e633df2..6b2bbda 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, unsigned int channel, break; } + if (dsi->mode_flags & MIPI_DSI_MODE_CM
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 07/29/2014 02:57 AM, YoungJun Cho wrote:
> Hi Andrzej,
>
> On 07/29/2014 01:09 AM, Andrzej Hajda wrote:
>> On 07/28/2014 04:00 AM, Inki Dae wrote:
>>> This patch adds below two flags for LPM transfer, and it attaches LPM flags
>>> to a msg in accordance with master's mode_flags set by LCD Panel driver.
>>>
>>> MIPI_DSI_MODE_CMD_LPM
>>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
>>> command data to Panel device in Low Power Mode.
>> What do you mean by command data? It could be:
>> - all transfer in command mode of operations,
>> - transfer initialized by the driver by writing to DSIM registers.
> The 2nd one.
>
>>> MIPI_DSI_MODE_VIDEO_LPM
>>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
>>> image data to Panel device in Low Power Mode.
>> What is the meaning of this flag in case of command mode of operation?
> I'm also not sure that there is a case to transfer image data in Low
> Power Mode, but this flag is not related with 'command mode' only.
> Inki may consider generic condition.
>
>> Maybe it would be better to create flags based on source of data/FIFOs:
>> - commands send by SFR registers,
>> - commands generated from data sent from Display Controller.
>>
>>
>>> And above two flags can be combined together to transfer command and video
>>> data to Panel device.
>>>
>>> MIPI DSI spec says,
>>> "the host processor controls the desired mode of clock operation.
>>>Host protocol and applications control Clock Lane operating mode
>>>(High Speed or Low Power mode). System designers are responsible
>>>for understanding the clock requirements for peripherals attached
>>>to DSI and controlling clock behavior in accordance with those
>>>requirements."
>>>
>>> Some LCD Panel devices, nt35502a, would need LPM transfer support
>>> because they should receive some initial commands with LPM by default
>>> hardware setting.
>>
>> Is this requirement for initial commands, or for all commands.
>> Btw what is the mode of operation of nt35502a? What flags do you need
>> for it?
>>
> The nt35502a panel is video(RGB) mode panel and it requires low power
> mode for initial commands, which means to initialize nt35502a panel, the
> initial commands are transferred by LP mode(Not HS mode).
> And after initialization, its other features like gamma control or etc
> could be controlled in HS mode.
It sounds similar to my tc358764 bridge driver [1]. The difference is that
it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM.
As I understand nt35502a requires also different driving of
TxRequestHSClk signal
and this seems to me unrelated to LPM. As LPM is not related at all with
HS clock, AFAIK.
Regards
Andrzej
[1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559
>
> Thank you.
> Best regards YJ
>
>>
>>> Changelog v2: just add more descriptions.
>>>
>>> Signed-off-by: Inki Dae
>>> Acked-by: Kyungmin Park
>>> ---
>>> drivers/gpu/drm/drm_mipi_dsi.c |3 +++
>>> include/drm/drm_mipi_dsi.h |4
>>> 2 files changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
>>> index e633df2..6b2bbda 100644
>>> --- a/drivers/gpu/drm/drm_mipi_dsi.c
>>> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
>>> @@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
>>> unsigned int channel,
>>> break;
>>> }
>>>
>>> + if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
>>> + msg.flags = MIPI_DSI_MSG_USE_LPM;
>>> +
>>> return ops->transfer(dsi->host, &msg);
>>> }
>> Shouldn't this be also the same for dcs read?
>>
>> Anyway I think check in the DSIM should be used instead, as panel driver
>> can issue other dsi transfers without MIPI_DSI_MSG_USE_LPM flag set.
>>
>> Regards
>> Andrzej
>>
>>
>>> EXPORT_SYMBOL(mipi_dsi_dcs_write);
>>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>>> index 944f33f..1c41e49 100644
>>> --- a/include/drm/drm_mipi_dsi.h
>>> +++ b/include/drm/drm_mipi_dsi.h
>>> @@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host
>>> *host);
>>> #define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
>>> /* disable EoT packets in HS mode */
>>> #define MIPI_DSI_MODE_EOT_PACKET BIT(9)
>>> +/* command low power mode */
>>> +#define MIPI_DSI_MODE_CMD_LPM BIT(10)
>>> +/* video low power mode */
>>> +#define MIPI_DSI_MODE_VIDEO_LPMBIT(11)
>>>
>>> enum mipi_dsi_pixel_format {
>>> MIPI_DSI_FMT_RGB888,
>>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014년 07월 29일 01:09, Andrzej Hajda wrote: > On 07/28/2014 04:00 AM, Inki Dae wrote: >> This patch adds below two flags for LPM transfer, and it attaches LPM flags >> to a msg in accordance with master's mode_flags set by LCD Panel driver. >> >> MIPI_DSI_MODE_CMD_LPM >> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >> command data to Panel device in Low Power Mode. > > What do you mean by command data? It could be: > - all transfer in command mode of operations, > - transfer initialized by the driver by writing to DSIM registers. > >> >> MIPI_DSI_MODE_VIDEO_LPM >> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >> image data to Panel device in Low Power Mode. > > What is the meaning of this flag in case of command mode of operation? > > Maybe it would be better to create flags based on source of data/FIFOs: > - commands send by SFR registers, > - commands generated from data sent from Display Controller. > I wrote the descriptions in host controller point of view: with MIPI_DSI_MODE_CMD_LPM, host controller will set the operation mode to command mode operation and transfer command data to Panel (MIPI DSI client), and with MIPI_DSI_MODE_VIDEO_LPM, host controller will set the operation mode to video mode and transfer video data (pixel stream) to Panel. However, it seems that these descriptions aren't enough. So make sure the meanings. MIPI-DSI has two operation modes, Command and Video mode. And MIPI-DSI spec says, "Command Mode refers to operation in which transactions primarily take the form of sending commands and data to a peripheral, such as a display module, that incorporates a display controller. The display controller may include local registers and a frame buffer. Systems using Command Mode write to, and read from, the registers and frame buffer memory. The host processor indirectly controls activity at the peripheral by sending commands, parameters and data to the display controller. The host processor can also read display module status information or the contents of the frame memory. Command Mode operation requires a bidirectional interface.". And also the spec says for Video mode, "Video mode Mode refers to operation in which transfers from the host processor to the peripheral take the form of a real-time pixel stream. In normal operation, the display module relies on the host processor to provide image data at sufficient bandwidth to avoid flicker or other visible artifacts in the displayed image. Video information should only be transmitted using High Speed Mode. Some Video Mode architectures may include a simple timing controller and partial frame buffer, used to maintain a partial-screen or lower-resolution image in standby or low-power mode. This permits the interface to be shut down to reduce power consumption. To reduce complexity and cost, systems that only operate in Video Mode may use a unidirectional data path." Thus, with Command mode, host can send command and image data to Panel device, and with Video mode, host can send image data to Panel device in High Speed Mode (HS clock enabled) Therefore, I think MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM flags have generic meaning, In default, host transmits Command and image data to Panel in High Speed Mode. MIP_DSI_MODE_CMD_LPM: Host transmits command and image data to Panel in Low Power mode, and also the host can read data from SRF and internal frame buffer of Panel device. With this flag, host needs to set transmission mode to Low Power Mode (and HS clock disabled) MIPI_DSI_MODE_VIDEO_LPM: Host transmits image data to Panel in Low Power mode. With this flags, host needs to set transmission mode to Low Power Mode. I think above two flags are common to all SoC. In case of Exynos MIPI-DSI, 'CmdLpdt bit = 1' specifies that host transmits commands to Panel in Low Power Mode so this would be corresponded to MIPI_DSI_MODE_CMD_LPM. However, 'TxLpdt = 1' specifies that host transmits all data that include commands and imageto Panel in Low Power Mode (and HS clock disabled). So this bit would be corresponded to MIPI_DSI_MODE_VIDEO_LPM. Feel free to give me your opinions if you have other opinions or there is my missing point. Thanks, Inki Dae > >> >> And above two flags can be combined together to transfer command and video >> data to Panel device. >> >> MIPI DSI spec says, >> "the host processor controls the desired mode of clock operation. >> Host protocol and applications control Clock Lane operating mode >> (High Speed or Low Power mode). System designers are responsible >> for understanding the clock requirements for peripherals attached >> to DSI and controlling clock behavior in accordance with those >> requirements." >> >> Some LCD Panel devices, nt35502a, would need LPM transfer support >> because they should receive some initial commands with LPM by default >> hardware setting. > > > Is this requirement for initial comman
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
Hi Andrzej,
On 07/29/2014 01:09 AM, Andrzej Hajda wrote:
On 07/28/2014 04:00 AM, Inki Dae wrote:
This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's mode_flags set by LCD Panel driver.
MIPI_DSI_MODE_CMD_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
command data to Panel device in Low Power Mode.
What do you mean by command data? It could be:
- all transfer in command mode of operations,
- transfer initialized by the driver by writing to DSIM registers.
The 2nd one.
MIPI_DSI_MODE_VIDEO_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
image data to Panel device in Low Power Mode.
What is the meaning of this flag in case of command mode of operation?
I'm also not sure that there is a case to transfer image data in Low
Power Mode, but this flag is not related with 'command mode' only.
Inki may consider generic condition.
Maybe it would be better to create flags based on source of data/FIFOs:
- commands send by SFR registers,
- commands generated from data sent from Display Controller.
And above two flags can be combined together to transfer command and video
data to Panel device.
MIPI DSI spec says,
"the host processor controls the desired mode of clock operation.
Host protocol and applications control Clock Lane operating mode
(High Speed or Low Power mode). System designers are responsible
for understanding the clock requirements for peripherals attached
to DSI and controlling clock behavior in accordance with those
requirements."
Some LCD Panel devices, nt35502a, would need LPM transfer support
because they should receive some initial commands with LPM by default
hardware setting.
Is this requirement for initial commands, or for all commands.
Btw what is the mode of operation of nt35502a? What flags do you need
for it?
The nt35502a panel is video(RGB) mode panel and it requires low power
mode for initial commands, which means to initialize nt35502a panel, the
initial commands are transferred by LP mode(Not HS mode).
And after initialization, its other features like gamma control or etc
could be controlled in HS mode.
Thank you.
Best regards YJ
Changelog v2: just add more descriptions.
Signed-off-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/drm_mipi_dsi.c |3 +++
include/drm/drm_mipi_dsi.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index e633df2..6b2bbda 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
unsigned int channel,
break;
}
+ if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, &msg);
}
Shouldn't this be also the same for dcs read?
Anyway I think check in the DSIM should be used instead, as panel driver
can issue other dsi transfers without MIPI_DSI_MSG_USE_LPM flag set.
Regards
Andrzej
EXPORT_SYMBOL(mipi_dsi_dcs_write);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..1c41e49 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
#define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
/* disable EoT packets in HS mode */
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
+/* command low power mode */
+#define MIPI_DSI_MODE_CMD_LPM BIT(10)
+/* video low power mode */
+#define MIPI_DSI_MODE_VIDEO_LPMBIT(11)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 07/28/2014 04:00 AM, Inki Dae wrote:
> This patch adds below two flags for LPM transfer, and it attaches LPM flags
> to a msg in accordance with master's mode_flags set by LCD Panel driver.
>
> MIPI_DSI_MODE_CMD_LPM
> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
> command data to Panel device in Low Power Mode.
What do you mean by command data? It could be:
- all transfer in command mode of operations,
- transfer initialized by the driver by writing to DSIM registers.
>
> MIPI_DSI_MODE_VIDEO_LPM
> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
> image data to Panel device in Low Power Mode.
What is the meaning of this flag in case of command mode of operation?
Maybe it would be better to create flags based on source of data/FIFOs:
- commands send by SFR registers,
- commands generated from data sent from Display Controller.
>
> And above two flags can be combined together to transfer command and video
> data to Panel device.
>
> MIPI DSI spec says,
> "the host processor controls the desired mode of clock operation.
> Host protocol and applications control Clock Lane operating mode
> (High Speed or Low Power mode). System designers are responsible
> for understanding the clock requirements for peripherals attached
> to DSI and controlling clock behavior in accordance with those
> requirements."
>
> Some LCD Panel devices, nt35502a, would need LPM transfer support
> because they should receive some initial commands with LPM by default
> hardware setting.
Is this requirement for initial commands, or for all commands.
Btw what is the mode of operation of nt35502a? What flags do you need
for it?
>
> Changelog v2: just add more descriptions.
>
> Signed-off-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> drivers/gpu/drm/drm_mipi_dsi.c |3 +++
> include/drm/drm_mipi_dsi.h |4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index e633df2..6b2bbda 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
> unsigned int channel,
> break;
> }
>
> + if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
> + msg.flags = MIPI_DSI_MSG_USE_LPM;
> +
> return ops->transfer(dsi->host, &msg);
> }
Shouldn't this be also the same for dcs read?
Anyway I think check in the DSIM should be used instead, as panel driver
can issue other dsi transfers without MIPI_DSI_MSG_USE_LPM flag set.
Regards
Andrzej
> EXPORT_SYMBOL(mipi_dsi_dcs_write);
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 944f33f..1c41e49 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
> #define MIPI_DSI_MODE_VSYNC_FLUSHBIT(8)
> /* disable EoT packets in HS mode */
> #define MIPI_DSI_MODE_EOT_PACKET BIT(9)
> +/* command low power mode */
> +#define MIPI_DSI_MODE_CMD_LPMBIT(10)
> +/* video low power mode */
> +#define MIPI_DSI_MODE_VIDEO_LPM BIT(11)
>
> enum mipi_dsi_pixel_format {
> MIPI_DSI_FMT_RGB888,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's mode_flags set by LCD Panel driver.
MIPI_DSI_MODE_CMD_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
command data to Panel device in Low Power Mode.
MIPI_DSI_MODE_VIDEO_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
image data to Panel device in Low Power Mode.
And above two flags can be combined together to transfer command and video
data to Panel device.
MIPI DSI spec says,
"the host processor controls the desired mode of clock operation.
Host protocol and applications control Clock Lane operating mode
(High Speed or Low Power mode). System designers are responsible
for understanding the clock requirements for peripherals attached
to DSI and controlling clock behavior in accordance with those
requirements."
Some LCD Panel devices, nt35502a, would need LPM transfer support
because they should receive some initial commands with LPM by default
hardware setting.
Changelog v2: just add more descriptions.
Signed-off-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/drm_mipi_dsi.c |3 +++
include/drm/drm_mipi_dsi.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index e633df2..6b2bbda 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
unsigned int channel,
break;
}
+ if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, &msg);
}
EXPORT_SYMBOL(mipi_dsi_dcs_write);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..1c41e49 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
#define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
/* disable EoT packets in HS mode */
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
+/* command low power mode */
+#define MIPI_DSI_MODE_CMD_LPM BIT(10)
+/* video low power mode */
+#define MIPI_DSI_MODE_VIDEO_LPMBIT(11)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
