[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

Thierry Reding thierry.reding at gmail.com
Mon Aug 11 02:11:53 PDT 2014


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/6a21266b/attachment.sig>


More information about the dri-devel mailing list