[PATCH v2 0/2] drm/mipi-dsi: support lpm (low power mode) transfer

[PATCH v2 0/2] drm/mipi-dsi: support lpm (low power mode) transfer

[Inki Dae]

This patch series adds lpm tranfer support for video and command data.

for this, this patch adds two flags, and makes mipi dsi host to send
commands to lcd panel device with lpm if mode_flags of lcd panel driver
includes lpm flag.

and also it applies this feature to exynos mipi dsi driver.

Changelog v2:
- Add more describtions.
- Enable High Speed clock only in case of stand by request.

Inki Dae (2):
  drm/mipi-dsi: add (LPM) Low Power Mode transfer support
  drm/exynos: dsi: add LPM (Low Power Mode) transfer support

 drivers/gpu/drm/drm_mipi_dsi.c          |    3 +++
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 ++++++++++++++++++++--
 include/drm/drm_mipi_dsi.h              |    4 ++++
 3 files changed, 27 insertions(+), 2 deletions(-)

-- 
1.7.9.5

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

[Inki Dae]

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 <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 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_LPM		BIT(11)
 
 enum mipi_dsi_pixel_format {
 	MIPI_DSI_FMT_RGB888,
-- 
1.7.9.5

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

[Andrzej Hajda]

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 <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  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_LPM		BIT(11)
>  
>  enum mipi_dsi_pixel_format {
>  	MIPI_DSI_FMT_RGB888,
> 

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

[YoungJun Cho]

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 <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   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_LPM		BIT(11)
>>
>>   enum mipi_dsi_pixel_format {
>>   	MIPI_DSI_FMT_RGB888,
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

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

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

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 <inki.dae@samsung.com>
>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>> ---
>>>   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_LPM		BIT(11)
>>>
>>>   enum mipi_dsi_pixel_format {
>>>   	MIPI_DSI_FMT_RGB888,
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

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

[Inki Dae]

2014-07-29 19:23 GMT+09:00 Andrzej Hajda <a.hajda@samsung.com>:
> 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 <inki.dae@samsung.com>
>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>> ---
>>>>   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_LPM            BIT(11)
>>>>
>>>>   enum mipi_dsi_pixel_format {
>>>>     MIPI_DSI_FMT_RGB888,
>>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Inki Dae]

2014-08-03 16:03 GMT+09:00 Inki Dae <inki.dae@samsung.com>:
> 2014-07-29 19:23 GMT+09:00 Andrzej Hajda <a.hajda@samsung.com>:
>> 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-by: Inki Dae <inki.dae@samsung.com>
>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>> ---
>>>>>   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_LPM            BIT(11)
>>>>>
>>>>>   enum mipi_dsi_pixel_format {
>>>>>     MIPI_DSI_FMT_RGB888,
>>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Andrzej Hajda]

On 08/03/2014 09:16 AM, Inki Dae wrote:
> 2014-08-03 16:03 GMT+09:00 Inki Dae <inki.dae@samsung.com>:
>> 2014-07-29 19:23 GMT+09:00 Andrzej Hajda <a.hajda@samsung.com>:
>>> 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 with HS clock. It uses so-caled
Spaced-One-Hot coding which roughly means the clock is embedded in data
signal. In case of drm_mipi_dsi if we want to transfer
data using LPM (or more precisely escape mode) we can use
MIPI_DSI_MSG_USE_LPM flag.

3. There is question if and how TxRequestHSClk bit in Exynos-DSI is
connected with "continuous clock behavior", it should be tested or consulted
with Exynos HW guys but it is just a problem of this specific chipset
and should be quite easy to solve.

4. I guess it could be good to have more control what and when shall be
transmitted in LP or HS mode. But for this we first need to separate
LPM issues from HS clock issues.

[1]: MIPI DSI specs, especially "Clock Management" chapter.
 
Regards
Andrzej

>
> 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-by: Inki Dae <inki.dae@samsung.com>
>>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>>> ---
>>>>>>   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_LPM            BIT(11)
>>>>>>
>>>>>>   enum mipi_dsi_pixel_format {
>>>>>>     MIPI_DSI_FMT_RGB888,
>>>>>>
>>>>> _______________________________________________
>>>>> dri-devel mailing list
>>>>> dri-devel@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Inki Dae]

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 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 <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>  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_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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

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

[Thierry Reding]

[-- Attachment #1.1.1: Type: text/plain, Size: 3025 bytes --]

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

[-- Attachment #1.1.2: 0001-drm-dsi-Always-use-low-power-mode-for-DCS-commands.patch --]
[-- Type: text/x-diff, Size: 1979 bytes --]

From f93dd508afc19262fd95c01520d5d6d7937be4e8 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
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 <treding@nvidia.com>
---
 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


[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

[Inki Dae]

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
> 

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5316 bytes --]

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. Given the
above discussion I think it may still be worthwhile to invert the
meaning of the flag and rename it MIPI_DSI_MSG_USE_HS, so that all
messages are indeed sent in low power mode by default.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Inki Dae]

2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> 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 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. Given the
> above discussion I think it may still be worthwhile to invert the
> meaning of the flag and rename it MIPI_DSI_MSG_USE_HS, so that all
> messages are indeed sent in low power mode by default.

Yes, it may be reasonable. But I'm not sure that there is no any issue
in case of transmitting always video data in HS mode.

Thanks,
Inki Dae

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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 7332 bytes --]

On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> > 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 supports non-continuous mode of operation. That is, it has own
circuitry to generate a clock that can be used for clocked operations
between high-speed transmissions (when the HS clock isn't available).

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

I suspect it's usually the host controller. But does it matter? From a
software perspective we usually only access the host controller, so the
D-PHY is usually completely hidden (except maybe for some registers in
the host controller to configure it).

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

Like I said, low power mode and non-continuous clock are not directly
related. Peripherals may require the HS clock to be always on and still
use low power mode for transmissions.

> >> 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. Given the
> > above discussion I think it may still be worthwhile to invert the
> > meaning of the flag and rename it MIPI_DSI_MSG_USE_HS, so that all
> > messages are indeed sent in low power mode by default.
> 
> Yes, it may be reasonable. But I'm not sure that there is no any issue
> in case of transmitting always video data in HS mode.

Like I said, with low power mode you can't meet the bandwidth
requirements of any reasonable resolution and framerate, so I would
assume that video data can always be transmitted in HS mode. So even if
some device required video data transmission to use low power mode, then
that should be considered the oddball peripheral and it could be handled
by an extra flag.

By default we should still assume high-speed mode for video data packet
transmissions. We can address those quirks when we actually encounter
peripherals that don't work under those assumptions.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Inki Dae]

On 2014년 08월 07일 15:58, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
>>> 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? 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?

If so, shouldn't the host driver disable HS clock, in case of LP mode,
before the host driver transmits command data? 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.

Thanks,
Inki Dae

> 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 supports non-continuous mode of operation. That is, it has own
> circuitry to generate a clock that can be used for clocked operations
> between high-speed transmissions (when the HS clock isn't available).
> 
>> 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?
> 
> I suspect it's usually the host controller. But does it matter? From a
> software perspective we usually only access the host controller, so the
> D-PHY is usually completely hidden (except maybe for some registers in
> the host controller to configure it).
> 
>> 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?
> 
> Like I said, low power mode and non-continuous clock are not directly
> related. Peripherals may require the HS clock to be always on and still
> use low power mode for transmissions.
> 
>>>> 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. Given the
>>> above discussion I think it may still be worthwhile to invert the
>>> meaning of the flag and rename it MIPI_DSI_MSG_USE_HS, so that all
>>> messages are indeed sent in low power mode by default.
>>
>> Yes, it may be reasonable. But I'm not sure that there is no any issue
>> in case of transmitting always video data in HS mode.
> 
> Like I said, with low power mode you can't meet the bandwidth
> requirements of any reasonable resolution and framerate, so I would
> assume that video data can always be transmitted in HS mode. So even if
> some device required video data transmission to use low power mode, then
> that should be considered the oddball peripheral and it could be handled
> by an extra flag.
> 
> By default we should still assume high-speed mode for video data packet
> transmissions. We can address those quirks when we actually encounter
> peripherals that don't work under those assumptions.
> 
> Thierry
> 

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

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

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 4796 bytes --]

On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> On 2014년 08월 07일 15:58, Thierry Reding wrote:
> > On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> >> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
[...]
> >>> As far as I can tell non-continuous mode simply means that the host can
> >>> turn off the HS clock after a high-speed transmission. I think Andrzej
> >>> mentioned this already in another subthread, but this is an optional
> >>> mode that peripherals can support if they have extra circuitry that
> >>> provides an internal clock. Peripherals that don't have such circuitry
> >>> may rely on the HS clock to perform in between transmissions and
> >>> therefore require the HS clock to be always on (continuous mode). That's
> >>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> >>> peripheral supports non-continuous mode and therefore the host can turn
> >>> the HS clock off after high-speed transmissions.
> >>
> >> What I don't make sure is this sentence. With
> >> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
> >> One is,
> >> 1. host controller will generates signals if a bit of a register
> >> related to non-contiguous clock mode is set or unset.
> >> 2. And then video data is transmitted to panel in HS mode.
> >> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
> >> are high).
> >> 4. And then D-PHY disables HS clock of host controller.
> >> 5. At this time, operation mode of host controller becomes LPM.
> >>
> >> Other is,
> >> 1. host controller will generates signals if a bit of a register
> >> related to non-contiguous clock mode is set or unset.
> >> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
> >> are high).
> >> 3. And then video data is transmitted to panel in LPM.
> >> 4. At this time, operation mode of host controller becomes LPM.
> >>
> >> It seems that you says latter case.
> >
> > No. High speed clock and low power mode are orthogonal. Non-continuous
> > mode simply means that the clock lane enters LP-11 between HS
> > transmissions (see 5.6 "Clock Management" of the DSI specification).
> >
> 
> It seems that clock lane enters LP-11 regardless of HS clock enabled if
> non-continous mode is used. Right?

No, I think as long as HS clock is enabled the clock lane won't enter
LP-11. Non-continuous mode means that the controller can disable the HS
clock between HS transmissions. So in non-continuous mode the clock lane
can enter LP-11 because the controller disables the HS clock.

In continuous mode, then the clock will never be disabled, hence the
clock lane will never enter LP-11.

> And also it seems that non-continous mode is different from LPM at all
> because with non-continuous mode, command data is transmitted to panel
> in HS mode, but with LPM, command data is transmitted to panel in LP
> mode. Also right?

No. I think you can send command data to the peripheral in low power
mode in both continuous and non-continuous clock modes.

> If so, shouldn't the host driver disable HS clock, in case of LP mode,
> before the host driver transmits command data?

No. If the peripheral doesn't support non-continuous mode, then the HS
clock must never be turned off. On the other hand, if the peripheral
supports non-continuous mode, then the DSI host should automatically
disable the HS clock between high-speed transmissions. That means if a
packet is transmitted in low power mode the DSI host will not be
transmitting in high-speed mode and therefore disable the HS clock.

Obviously if the controller can't do that automatically then it might be
necessary to explicitly do that in the driver. But I doubt that any DSI
controller wouldn't be able to do that automatically. On Tegra we have a
control bit that enables non-continuous mode:

	DSI_HS_CLK_CTRL: control for the HS clock lane
	  - 0 = CONTINUOUS: HS clock is on all the time
	  - 1 = TX_ONLY: HS clock is only active during HS transmissions

> And  it seems that only one of these two flags, MSG_LPM and NON-CONTINUOUS,
> should be set by panel driver because with NON-CONTINUOUS clock mode, host
> controller generate clock and data lane signals regardless of controlling
> HS clock.

No. Non-continuous mode is something that's specific to the peripheral
and is always valid, whereas the MSG_LPM flag is only used to mark a
packet to be transmitted in low power mode (as opposed to high speed
mode). For peripherals that don't support non-continuous mode the
NON_CONTINUOUS flag needs to be set. But the driver for the peripheral
can still initiate low power mode packet transmissions by setting the
MSG_LPM flag.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

[Inki Dae]

On 2014년 08월 07일 18:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> [...]
>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>> mentioned this already in another subthread, but this is an optional
>>>>> mode that peripherals can support if they have extra circuitry that
>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>> may rely on the HS clock to perform in between transmissions and
>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>> the HS clock off after high-speed transmissions.
>>>>
>>>> What I don't make sure is this sentence. With
>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>> One is,
>>>> 1. host controller will generates signals if a bit of a register
>>>> related to non-contiguous clock mode is set or unset.
>>>> 2. And then video data is transmitted to panel in HS mode.
>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>> are high).
>>>> 4. And then D-PHY disables HS clock of host controller.
>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>
>>>> Other is,
>>>> 1. host controller will generates signals if a bit of a register
>>>> related to non-contiguous clock mode is set or unset.
>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>> are high).
>>>> 3. And then video data is transmitted to panel in LPM.
>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>
>>>> It seems that you says latter case.
>>>
>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>> mode simply means that the clock lane enters LP-11 between HS
>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>
>>
>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>> non-continous mode is used. Right?
> 
> No, I think as long as HS clock is enabled the clock lane won't enter
> LP-11. Non-continuous mode means that the controller can disable the HS
> clock between HS transmissions. So in non-continuous mode the clock lane
> can enter LP-11 because the controller disables the HS clock.

It makes me a little bit confusing. You said "if HS clock is enabled,
the the clock lane won't enter LP-11" But you said again "the clock lane
can enter LP-11 because the controller disables the HS clock" What is
the meaning?

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

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

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 4974 bytes --]

On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> On 2014년 08월 07일 18:09, Thierry Reding wrote:
> > On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> >> On 2014년 08월 07일 15:58, Thierry Reding wrote:
> >>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> >>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> > [...]
> >>>>> As far as I can tell non-continuous mode simply means that the host can
> >>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
> >>>>> mentioned this already in another subthread, but this is an optional
> >>>>> mode that peripherals can support if they have extra circuitry that
> >>>>> provides an internal clock. Peripherals that don't have such circuitry
> >>>>> may rely on the HS clock to perform in between transmissions and
> >>>>> therefore require the HS clock to be always on (continuous mode). That's
> >>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> >>>>> peripheral supports non-continuous mode and therefore the host can turn
> >>>>> the HS clock off after high-speed transmissions.
> >>>>
> >>>> What I don't make sure is this sentence. With
> >>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
> >>>> One is,
> >>>> 1. host controller will generates signals if a bit of a register
> >>>> related to non-contiguous clock mode is set or unset.
> >>>> 2. And then video data is transmitted to panel in HS mode.
> >>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>> are high).
> >>>> 4. And then D-PHY disables HS clock of host controller.
> >>>> 5. At this time, operation mode of host controller becomes LPM.
> >>>>
> >>>> Other is,
> >>>> 1. host controller will generates signals if a bit of a register
> >>>> related to non-contiguous clock mode is set or unset.
> >>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>> are high).
> >>>> 3. And then video data is transmitted to panel in LPM.
> >>>> 4. At this time, operation mode of host controller becomes LPM.
> >>>>
> >>>> It seems that you says latter case.
> >>>
> >>> No. High speed clock and low power mode are orthogonal. Non-continuous
> >>> mode simply means that the clock lane enters LP-11 between HS
> >>> transmissions (see 5.6 "Clock Management" of the DSI specification).
> >>>
> >>
> >> It seems that clock lane enters LP-11 regardless of HS clock enabled if
> >> non-continous mode is used. Right?
> > 
> > No, I think as long as HS clock is enabled the clock lane won't enter
> > LP-11. Non-continuous mode means that the controller can disable the HS
> > clock between HS transmissions. So in non-continuous mode the clock lane
> > can enter LP-11 because the controller disables the HS clock.
> 
> It makes me a little bit confusing. You said "if HS clock is enabled,
> the the clock lane won't enter LP-11" But you said again "the clock lane
> can enter LP-11 because the controller disables the HS clock" What is
> the meaning?

It means that if the HS clock is enabled, then the clock lane is not in
LP-11. When the HS clock stops, then the clock lane enters LP-11.

> > In continuous mode, then the clock will never be disabled, hence the
> > clock lane will never enter LP-11.
> > 
> >> And also it seems that non-continous mode is different from LPM at all
> >> because with non-continuous mode, command data is transmitted to panel
> >> in HS mode, but with LPM, command data is transmitted to panel in LP
> >> mode. Also right?
> > 
> > No. I think you can send command data to the peripheral in low power
> > mode in both continuous and non-continuous clock modes.
> > 
> >> If so, shouldn't the host driver disable HS clock, in case of LP mode,
> >> before the host driver transmits command data?
> > 
> > No. If the peripheral doesn't support non-continuous mode, then the HS
> > clock must never be turned off. On the other hand, if the peripheral
> > supports non-continuous mode, then the DSI host should automatically
> > disable the HS clock between high-speed transmissions. That means if a
> > packet is transmitted in low power mode the DSI host will not be
> > transmitting in high-speed mode and therefore disable the HS clock.
> 
> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> host controller should be disabled.

No. I don't think any transmissions can happen when all lanes are in
LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
should be transmitted in low power mode (see LP Transmission in 2.1
"Definitions" of the MIPI DSI specification).

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

[Inki Dae]

On 2014년 08월 07일 20:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
>>> [...]
>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>
>>>>>> What I don't make sure is this sentence. With
>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>> One is,
>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>> are high).
>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>
>>>>>> Other is,
>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>> are high).
>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>
>>>>>> It seems that you says latter case.
>>>>>
>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>
>>>>
>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>> non-continous mode is used. Right?
>>>
>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>> can enter LP-11 because the controller disables the HS clock.
>>
>> It makes me a little bit confusing. You said "if HS clock is enabled,
>> the the clock lane won't enter LP-11" But you said again "the clock lane
>> can enter LP-11 because the controller disables the HS clock" What is
>> the meaning?
> 
> It means that if the HS clock is enabled, then the clock lane is not in
> LP-11. When the HS clock stops, then the clock lane enters LP-11.
> 
>>> In continuous mode, then the clock will never be disabled, hence the
>>> clock lane will never enter LP-11.
>>>
>>>> And also it seems that non-continous mode is different from LPM at all
>>>> because with non-continuous mode, command data is transmitted to panel
>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>> mode. Also right?
>>>
>>> No. I think you can send command data to the peripheral in low power
>>> mode in both continuous and non-continuous clock modes.
>>>
>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>> before the host driver transmits command data?
>>>
>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>> clock must never be turned off. On the other hand, if the peripheral
>>> supports non-continuous mode, then the DSI host should automatically
>>> disable the HS clock between high-speed transmissions. That means if a
>>> packet is transmitted in low power mode the DSI host will not be
>>> transmitting in high-speed mode and therefore disable the HS clock.
>>
>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>> host controller should be disabled.
> 
> No. I don't think any transmissions can happen when all lanes are in
> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> should be transmitted in low power mode (see LP Transmission in 2.1
> "Definitions" of the MIPI DSI specification).
> 

Hm.. I see. I meant,

if (flags & MIPI_DSI_MSG_USE_LPM)
       disable HS clock <- required.

transmit command data <- in LPM.

Thanks,
Inki Dae

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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5609 bytes --]

On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
> On 2014년 08월 07일 20:09, Thierry Reding wrote:
> > On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> >> On 2014년 08월 07일 18:09, Thierry Reding wrote:
> >>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> >>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
> >>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> >>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> >>> [...]
> >>>>>>> As far as I can tell non-continuous mode simply means that the host can
> >>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
> >>>>>>> mentioned this already in another subthread, but this is an optional
> >>>>>>> mode that peripherals can support if they have extra circuitry that
> >>>>>>> provides an internal clock. Peripherals that don't have such circuitry
> >>>>>>> may rely on the HS clock to perform in between transmissions and
> >>>>>>> therefore require the HS clock to be always on (continuous mode). That's
> >>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> >>>>>>> peripheral supports non-continuous mode and therefore the host can turn
> >>>>>>> the HS clock off after high-speed transmissions.
> >>>>>>
> >>>>>> What I don't make sure is this sentence. With
> >>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
> >>>>>> One is,
> >>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>> 2. And then video data is transmitted to panel in HS mode.
> >>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>> are high).
> >>>>>> 4. And then D-PHY disables HS clock of host controller.
> >>>>>> 5. At this time, operation mode of host controller becomes LPM.
> >>>>>>
> >>>>>> Other is,
> >>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>> are high).
> >>>>>> 3. And then video data is transmitted to panel in LPM.
> >>>>>> 4. At this time, operation mode of host controller becomes LPM.
> >>>>>>
> >>>>>> It seems that you says latter case.
> >>>>>
> >>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
> >>>>> mode simply means that the clock lane enters LP-11 between HS
> >>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
> >>>>>
> >>>>
> >>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
> >>>> non-continous mode is used. Right?
> >>>
> >>> No, I think as long as HS clock is enabled the clock lane won't enter
> >>> LP-11. Non-continuous mode means that the controller can disable the HS
> >>> clock between HS transmissions. So in non-continuous mode the clock lane
> >>> can enter LP-11 because the controller disables the HS clock.
> >>
> >> It makes me a little bit confusing. You said "if HS clock is enabled,
> >> the the clock lane won't enter LP-11" But you said again "the clock lane
> >> can enter LP-11 because the controller disables the HS clock" What is
> >> the meaning?
> >
> > It means that if the HS clock is enabled, then the clock lane is not in
> > LP-11. When the HS clock stops, then the clock lane enters LP-11.
> >
> >>> In continuous mode, then the clock will never be disabled, hence the
> >>> clock lane will never enter LP-11.
> >>>
> >>>> And also it seems that non-continous mode is different from LPM at all
> >>>> because with non-continuous mode, command data is transmitted to panel
> >>>> in HS mode, but with LPM, command data is transmitted to panel in LP
> >>>> mode. Also right?
> >>>
> >>> No. I think you can send command data to the peripheral in low power
> >>> mode in both continuous and non-continuous clock modes.
> >>>
> >>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
> >>>> before the host driver transmits command data?
> >>>
> >>> No. If the peripheral doesn't support non-continuous mode, then the HS
> >>> clock must never be turned off. On the other hand, if the peripheral
> >>> supports non-continuous mode, then the DSI host should automatically
> >>> disable the HS clock between high-speed transmissions. That means if a
> >>> packet is transmitted in low power mode the DSI host will not be
> >>> transmitting in high-speed mode and therefore disable the HS clock.
> >>
> >> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
> >> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> >> host controller should be disabled.
> >
> > No. I don't think any transmissions can happen when all lanes are in
> > LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> > should be transmitted in low power mode (see LP Transmission in 2.1
> > "Definitions" of the MIPI DSI specification).
> >
> 
> Hm.. I see. I meant,
> 
> if (flags & MIPI_DSI_MSG_USE_LPM)
>        disable HS clock <- required.
> 
> transmit command data <- in LPM.

No. Disabling the HS clock is not required for LPM mode. In fact if the
peripheral specifies that it doesn't support non-continuous mode then
the HS clock must *never* be disabled as long as the peripheral is in
use.

MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
need to be considered separately.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Inki Dae]

On 2014년 08월 07일 22:17, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
>>>>> [...]
>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>
>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>> One is,
>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>> are high).
>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>
>>>>>>>> Other is,
>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>> are high).
>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>
>>>>>>>> It seems that you says latter case.
>>>>>>>
>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>
>>>>>>
>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>> non-continous mode is used. Right?
>>>>>
>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>
>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>> the meaning?
>>>
>>> It means that if the HS clock is enabled, then the clock lane is not in
>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>
>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>> clock lane will never enter LP-11.
>>>>>
>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>> mode. Also right?
>>>>>
>>>>> No. I think you can send command data to the peripheral in low power
>>>>> mode in both continuous and non-continuous clock modes.
>>>>>
>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>> before the host driver transmits command data?
>>>>>
>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>
>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>> host controller should be disabled.
>>>
>>> No. I don't think any transmissions can happen when all lanes are in
>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>> "Definitions" of the MIPI DSI specification).
>>>
>>
>> Hm.. I see. I meant,
>>
>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>        disable HS clock <- required.
>>
>> transmit command data <- in LPM.
> 
> No. Disabling the HS clock is not required for LPM mode. In fact if the
> peripheral specifies that it doesn't support non-continuous mode then
> the HS clock must *never* be disabled as long as the peripheral is in
> use.
> 
> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> need to be considered separately.

I mentioned already LPM and NON_CONTINUOUS are unrelated.

It seems that you say the only way to transfer command data in LPM is
non-continuous clock mode. However, you said and also the spec says,
"Non-continuous mode simply means that the clock lane enters LP-11
between HS transmissions". Doesn't *between HS transmissions" mean the
command data is transmitted in HS, *not in LPM*, and clock lane enters
LP-11 between them?

We have one lcd panel, nt35502a, which needs LPM transfer support
because it should receive some initial commands with LPM by default
hardware setting, and we faced with that the panel didn't work without
disabling HS clock before transmitting command data. How can you explain
that?

Thanks,
Inki Dae

> 
> Thierry
> 

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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 7501 bytes --]

On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
> On 2014년 08월 07일 22:17, Thierry Reding wrote:
> > On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
> >> On 2014년 08월 07일 20:09, Thierry Reding wrote:
> >>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> >>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
> >>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> >>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
> >>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> >>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> >>>>> [...]
> >>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
> >>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
> >>>>>>>>> mentioned this already in another subthread, but this is an optional
> >>>>>>>>> mode that peripherals can support if they have extra circuitry that
> >>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
> >>>>>>>>> may rely on the HS clock to perform in between transmissions and
> >>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
> >>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> >>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
> >>>>>>>>> the HS clock off after high-speed transmissions.
> >>>>>>>>
> >>>>>>>> What I don't make sure is this sentence. With
> >>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
> >>>>>>>> One is,
> >>>>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>>>> 2. And then video data is transmitted to panel in HS mode.
> >>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>>>> are high).
> >>>>>>>> 4. And then D-PHY disables HS clock of host controller.
> >>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
> >>>>>>>>
> >>>>>>>> Other is,
> >>>>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>>>> are high).
> >>>>>>>> 3. And then video data is transmitted to panel in LPM.
> >>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
> >>>>>>>>
> >>>>>>>> It seems that you says latter case.
> >>>>>>>
> >>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
> >>>>>>> mode simply means that the clock lane enters LP-11 between HS
> >>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
> >>>>>>>
> >>>>>>
> >>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
> >>>>>> non-continous mode is used. Right?
> >>>>>
> >>>>> No, I think as long as HS clock is enabled the clock lane won't enter
> >>>>> LP-11. Non-continuous mode means that the controller can disable the HS
> >>>>> clock between HS transmissions. So in non-continuous mode the clock lane
> >>>>> can enter LP-11 because the controller disables the HS clock.
> >>>>
> >>>> It makes me a little bit confusing. You said "if HS clock is enabled,
> >>>> the the clock lane won't enter LP-11" But you said again "the clock lane
> >>>> can enter LP-11 because the controller disables the HS clock" What is
> >>>> the meaning?
> >>>
> >>> It means that if the HS clock is enabled, then the clock lane is not in
> >>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
> >>>
> >>>>> In continuous mode, then the clock will never be disabled, hence the
> >>>>> clock lane will never enter LP-11.
> >>>>>
> >>>>>> And also it seems that non-continous mode is different from LPM at all
> >>>>>> because with non-continuous mode, command data is transmitted to panel
> >>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
> >>>>>> mode. Also right?
> >>>>>
> >>>>> No. I think you can send command data to the peripheral in low power
> >>>>> mode in both continuous and non-continuous clock modes.
> >>>>>
> >>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
> >>>>>> before the host driver transmits command data?
> >>>>>
> >>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
> >>>>> clock must never be turned off. On the other hand, if the peripheral
> >>>>> supports non-continuous mode, then the DSI host should automatically
> >>>>> disable the HS clock between high-speed transmissions. That means if a
> >>>>> packet is transmitted in low power mode the DSI host will not be
> >>>>> transmitting in high-speed mode and therefore disable the HS clock.
> >>>>
> >>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
> >>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> >>>> host controller should be disabled.
> >>>
> >>> No. I don't think any transmissions can happen when all lanes are in
> >>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> >>> should be transmitted in low power mode (see LP Transmission in 2.1
> >>> "Definitions" of the MIPI DSI specification).
> >>>
> >>
> >> Hm.. I see. I meant,
> >>
> >> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>        disable HS clock <- required.
> >>
> >> transmit command data <- in LPM.
> > 
> > No. Disabling the HS clock is not required for LPM mode. In fact if the
> > peripheral specifies that it doesn't support non-continuous mode then
> > the HS clock must *never* be disabled as long as the peripheral is in
> > use.
> > 
> > MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> > need to be considered separately.
> 
> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> 
> It seems that you say the only way to transfer command data in LPM is
> non-continuous clock mode.

No, that's not what I'm saying.

> However, you said and also the spec says, "Non-continuous mode simply
> means that the clock lane enters LP-11 between HS transmissions".
> Doesn't *between HS transmissions" mean the command data is transmitted
> in HS, *not in LPM*, and clock lane enters LP-11 between them?

Not necessarily. You can transmit command packets in high-speed mode,
but you don't have to. If you transmit packets in low power mode, then
the HS clock isn't involved in the transmission and the clock lane may
enter LP-11 during the whole transmission (if non-continuous mode is
enabled).

> We have one lcd panel, nt35502a, which needs LPM transfer support
> because it should receive some initial commands with LPM by default
> hardware setting, and we faced with that the panel didn't work without
> disabling HS clock before transmitting command data. How can you explain
> that?

The specification clearly says that (5.6.1 "Clock Requirements"):

	All DSI transmitters and receivers shall support continuous
	clock behavior on the Clock Lane, and optionally may support
	non-continuous clock behavior.

So if you need to "disable HS clock" for command data to be successfully
transmitted, either the panel doesn't comply to the specification, or
whatever you do to "disable HS clock" doesn't do what you think it does.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Inki Dae]

On 2014년 08월 07일 22:55, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>> On 2014년 08월 07일 22:17, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>>>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>>>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>>>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
>>>>>>> [...]
>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>
>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>> One is,
>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>> are high).
>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>
>>>>>>>>>> Other is,
>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>> are high).
>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>
>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>
>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>
>>>>>>>>
>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>> non-continous mode is used. Right?
>>>>>>>
>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>
>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>> the meaning?
>>>>>
>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>
>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>> clock lane will never enter LP-11.
>>>>>>>
>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>> mode. Also right?
>>>>>>>
>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>
>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>> before the host driver transmits command data?
>>>>>>>
>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>
>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>> host controller should be disabled.
>>>>>
>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>> "Definitions" of the MIPI DSI specification).
>>>>>
>>>>
>>>> Hm.. I see. I meant,
>>>>
>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>        disable HS clock <- required.
>>>>
>>>> transmit command data <- in LPM.
>>>
>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>> peripheral specifies that it doesn't support non-continuous mode then
>>> the HS clock must *never* be disabled as long as the peripheral is in
>>> use.
>>>
>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>> need to be considered separately.
>>
>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>
>> It seems that you say the only way to transfer command data in LPM is
>> non-continuous clock mode.
> 
> No, that's not what I'm saying.
> 
>> However, you said and also the spec says, "Non-continuous mode simply
>> means that the clock lane enters LP-11 between HS transmissions".
>> Doesn't *between HS transmissions" mean the command data is transmitted
>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> 
> Not necessarily. You can transmit command packets in high-speed mode,
> but you don't have to. If you transmit packets in low power mode, then

That would may why we are mentioning same comments repeatedly.

In my case, host driver waits for the lane stop state (LP-11), and then
disables HS clock to transmit command data in LPM. Of course, I'm not
sure that yet it's correct way.

In Tegra, What to do for it?

Thanks,
Inki Dae

> the HS clock isn't involved in the transmission and the clock lane may
> enter LP-11 during the whole transmission (if non-continuous mode is
> enabled).
> 
>> We have one lcd panel, nt35502a, which needs LPM transfer support
>> because it should receive some initial commands with LPM by default
>> hardware setting, and we faced with that the panel didn't work without
>> disabling HS clock before transmitting command data. How can you explain
>> that?
> 
> The specification clearly says that (5.6.1 "Clock Requirements"):
> 
> 	All DSI transmitters and receivers shall support continuous
> 	clock behavior on the Clock Lane, and optionally may support
> 	non-continuous clock behavior.
> 
> So if you need to "disable HS clock" for command data to be successfully
> transmitted, either the panel doesn't comply to the specification, or
> whatever you do to "disable HS clock" doesn't do what you think it does.
> 
> Thierry
> 

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

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

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 8131 bytes --]

On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
> On 2014년 08월 07일 22:55, Thierry Reding wrote:
> > On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
> >> On 2014년 08월 07일 22:17, Thierry Reding wrote:
> >>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
> >>>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
> >>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> >>>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
> >>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> >>>>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
> >>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> >>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> >>>>>>> [...]
> >>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
> >>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
> >>>>>>>>>>> mentioned this already in another subthread, but this is an optional
> >>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
> >>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
> >>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
> >>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
> >>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> >>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
> >>>>>>>>>>> the HS clock off after high-speed transmissions.
> >>>>>>>>>>
> >>>>>>>>>> What I don't make sure is this sentence. With
> >>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
> >>>>>>>>>> One is,
> >>>>>>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
> >>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>>>>>> are high).
> >>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
> >>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
> >>>>>>>>>>
> >>>>>>>>>> Other is,
> >>>>>>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>>>>>> are high).
> >>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
> >>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
> >>>>>>>>>>
> >>>>>>>>>> It seems that you says latter case.
> >>>>>>>>>
> >>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
> >>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
> >>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
> >>>>>>>> non-continous mode is used. Right?
> >>>>>>>
> >>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
> >>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
> >>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
> >>>>>>> can enter LP-11 because the controller disables the HS clock.
> >>>>>>
> >>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
> >>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
> >>>>>> can enter LP-11 because the controller disables the HS clock" What is
> >>>>>> the meaning?
> >>>>>
> >>>>> It means that if the HS clock is enabled, then the clock lane is not in
> >>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
> >>>>>
> >>>>>>> In continuous mode, then the clock will never be disabled, hence the
> >>>>>>> clock lane will never enter LP-11.
> >>>>>>>
> >>>>>>>> And also it seems that non-continous mode is different from LPM at all
> >>>>>>>> because with non-continuous mode, command data is transmitted to panel
> >>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
> >>>>>>>> mode. Also right?
> >>>>>>>
> >>>>>>> No. I think you can send command data to the peripheral in low power
> >>>>>>> mode in both continuous and non-continuous clock modes.
> >>>>>>>
> >>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
> >>>>>>>> before the host driver transmits command data?
> >>>>>>>
> >>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
> >>>>>>> clock must never be turned off. On the other hand, if the peripheral
> >>>>>>> supports non-continuous mode, then the DSI host should automatically
> >>>>>>> disable the HS clock between high-speed transmissions. That means if a
> >>>>>>> packet is transmitted in low power mode the DSI host will not be
> >>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
> >>>>>>
> >>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
> >>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> >>>>>> host controller should be disabled.
> >>>>>
> >>>>> No. I don't think any transmissions can happen when all lanes are in
> >>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> >>>>> should be transmitted in low power mode (see LP Transmission in 2.1
> >>>>> "Definitions" of the MIPI DSI specification).
> >>>>>
> >>>>
> >>>> Hm.. I see. I meant,
> >>>>
> >>>> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>>>        disable HS clock <- required.
> >>>>
> >>>> transmit command data <- in LPM.
> >>>
> >>> No. Disabling the HS clock is not required for LPM mode. In fact if the
> >>> peripheral specifies that it doesn't support non-continuous mode then
> >>> the HS clock must *never* be disabled as long as the peripheral is in
> >>> use.
> >>>
> >>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> >>> need to be considered separately.
> >>
> >> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> >>
> >> It seems that you say the only way to transfer command data in LPM is
> >> non-continuous clock mode.
> >
> > No, that's not what I'm saying.
> >
> >> However, you said and also the spec says, "Non-continuous mode simply
> >> means that the clock lane enters LP-11 between HS transmissions".
> >> Doesn't *between HS transmissions" mean the command data is transmitted
> >> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> >
> > Not necessarily. You can transmit command packets in high-speed mode,
> > but you don't have to. If you transmit packets in low power mode, then
> 
> That would may why we are mentioning same comments repeatedly.
> 
> In my case, host driver waits for the lane stop state (LP-11), and then
> disables HS clock to transmit command data in LPM. Of course, I'm not
> sure that yet it's correct way.

That's confusing. How can the lane go to LP-11 when the clock is still
running?

> In Tegra, What to do for it?

There are two bits in two separate registers for this:

	DSI_HOST_CONTROL:
	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
	                               packets
	    - 0 = LOW: low speed
	    - 1 = HIGH: high speed

	DSI_CONTROL:
	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
	    - 0 = CONTINUOUS: HS clock is on all the time
	    - 1 = TX_ONLY: HS clock is only active during HS
	                   transmissions

So if the peripheral supports non-continuous mode of operation we set
the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
remains on all the time.

When a packet is to be transmitted in high speed mode, we set the
DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
cleared.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

[Inki Dae]

On 2014년 08월 08일 16:03, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>> On 2014년 08월 07일 22:55, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>>>> On 2014년 08월 07일 22:17, Thierry Reding wrote:
>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>>>>>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>>>>>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>>>>>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
>>>>>>>>> [...]
>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>
>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>> One is,
>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>> are high).
>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>
>>>>>>>>>>>> Other is,
>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>> are high).
>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>
>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>
>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>
>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>
>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>> the meaning?
>>>>>>>
>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>
>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>
>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>> mode. Also right?
>>>>>>>>>
>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>
>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>
>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>
>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>> host controller should be disabled.
>>>>>>>
>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>
>>>>>>
>>>>>> Hm.. I see. I meant,
>>>>>>
>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>        disable HS clock <- required.
>>>>>>
>>>>>> transmit command data <- in LPM.
>>>>>
>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>> use.
>>>>>
>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>> need to be considered separately.
>>>>
>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>
>>>> It seems that you say the only way to transfer command data in LPM is
>>>> non-continuous clock mode.
>>>
>>> No, that's not what I'm saying.
>>>
>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>
>>> Not necessarily. You can transmit command packets in high-speed mode,
>>> but you don't have to. If you transmit packets in low power mode, then
>>
>> That would may why we are mentioning same comments repeatedly.
>>
>> In my case, host driver waits for the lane stop state (LP-11), and then
>> disables HS clock to transmit command data in LPM. Of course, I'm not
>> sure that yet it's correct way.
> 
> That's confusing. How can the lane go to LP-11 when the clock is still
> running?

Actually, we are doing so. If the clock is still running then dsi driver
will wait for stop state of the clock and data lanes. Know that this is
valid only when initial time - just one time since power up.

	/* Check clock and data lane state are stop state */
	timeout = 100;
	do {
		if (timeout-- == 0) {
			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
			return -EFAULT;
		}

		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
		    != DSIM_STOP_STATE_DAT(lanes_mask))
			continue;
	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));

> 
>> In Tegra, What to do for it?
> 
> There are two bits in two separate registers for this:
> 
> 	DSI_HOST_CONTROL:
> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
> 	                               packets
> 	    - 0 = LOW: low speed
> 	    - 1 = HIGH: high speed
> 
> 	DSI_CONTROL:
> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
> 	    - 0 = CONTINUOUS: HS clock is on all the time
> 	    - 1 = TX_ONLY: HS clock is only active during HS
> 	                   transmissions
> 
> So if the peripheral supports non-continuous mode of operation we set
> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
> remains on all the time.
>
> When a packet is to be transmitted in high speed mode, we set the
> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
> cleared.

That is exactly what I want. In your case, if you want to transmit
command data in Low Power Mode in case of supporting non-continuous
clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
would clear DSI_HIGH_SPEED_TRANS (LOW).

So I guess,

if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
        disable DSI_HIGH_SPEED_TRANS;   <- LOW
        enable DSI_HS_CLK_CTRL; <- TX_ONLY
}

transmit command data <- in LPM.

However, what if the peripheral doesn't support non-continuous but want
to transmit command data in LPM? Is that  impossible?

Thanks,
Inki Dae

> 
> Thierry
> 

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

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

[Andrzej Hajda]

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 <thierry.reding@gmail.com>:
>>>>>>>>>> [...]
>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>> One is,
>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>> are high).
>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>> are high).
>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>
>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>> the meaning?
>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>
>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>
>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>> mode. Also right?
>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>
>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>> host controller should be disabled.
>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>
>>>>>>> Hm.. I see. I meant,
>>>>>>>
>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>        disable HS clock <- required.
>>>>>>>
>>>>>>> transmit command data <- in LPM.
>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>> use.
>>>>>>
>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>> need to be considered separately.
>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>
>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>> non-continuous clock mode.
>>>> No, that's not what I'm saying.
>>>>
>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>> but you don't have to. If you transmit packets in low power mode, then
>>> That would may why we are mentioning same comments repeatedly.
>>>
>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>> sure that yet it's correct way.
>> That's confusing. How can the lane go to LP-11 when the clock is still
>> running?
> Actually, we are doing so. If the clock is still running then dsi driver
> will wait for stop state of the clock and data lanes. Know that this is
> valid only when initial time - just one time since power up.
>
> 	/* Check clock and data lane state are stop state */
> 	timeout = 100;
> 	do {
> 		if (timeout-- == 0) {
> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
> 			return -EFAULT;
> 		}
>
> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
> 			continue;
> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));

This is only in initialization phase of DSI. 'If' inside the loop is
quite clear
- it checks for LP11 on all requested data lanes. 'while' check is
little bit suspicious.
It seems to be only for non-continuous clock behavior, on the other side
it is according to guidelines
in specs.

Inki, have you tried to take an assumption your panel requires
continuous clock behavior and exynos
dsi driver currently supports only non-continuous clock behavior, so it
needs some fixes to make it work.
Exynos specs are very unclear on the subject so it is hard to guess how
the registers should be configured
to have continuous/non-continuous clock behavior.

Regards
Andrzej

>
>>> In Tegra, What to do for it?
>> There are two bits in two separate registers for this:
>>
>> 	DSI_HOST_CONTROL:
>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>> 	                               packets
>> 	    - 0 = LOW: low speed
>> 	    - 1 = HIGH: high speed
>>
>> 	DSI_CONTROL:
>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>> 	                   transmissions
>>
>> So if the peripheral supports non-continuous mode of operation we set
>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>> remains on all the time.
>>
>> When a packet is to be transmitted in high speed mode, we set the
>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>> cleared.
> That is exactly what I want. In your case, if you want to transmit
> command data in Low Power Mode in case of supporting non-continuous
> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
> would clear DSI_HIGH_SPEED_TRANS (LOW).
>
> So I guess,
>
> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
> }
>
> transmit command data <- in LPM.
>
> However, what if the peripheral doesn't support non-continuous but want
> to transmit command data in LPM? Is that  impossible?
>
> Thanks,
> Inki Dae
>
>> Thierry
>>
>

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

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

[Andrzej Hajda]

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 <thierry.reding@gmail.com>:
>>>>>>>>>>> [...]
>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>>
>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>> the meaning?
>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>
>>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>
>>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>
>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>> host controller should be disabled.
>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>
>>>>>>>> Hm.. I see. I meant,
>>>>>>>>
>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>        disable HS clock <- required.
>>>>>>>>
>>>>>>>> transmit command data <- in LPM.
>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>> use.
>>>>>>>
>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>> need to be considered separately.
>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>
>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>> non-continuous clock mode.
>>>>> No, that's not what I'm saying.
>>>>>
>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>> That would may why we are mentioning same comments repeatedly.
>>>>
>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>> sure that yet it's correct way.
>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>> running?
>> Actually, we are doing so. If the clock is still running then dsi driver
>> will wait for stop state of the clock and data lanes. Know that this is
>> valid only when initial time - just one time since power up.
>>
>> 	/* Check clock and data lane state are stop state */
>> 	timeout = 100;
>> 	do {
>> 		if (timeout-- == 0) {
>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>> 			return -EFAULT;
>> 		}
>>
>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>> 			continue;
>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
> 
> This is only in initialization phase of DSI. 'If' inside the loop is
> quite clear
> - it checks for LP11 on all requested data lanes. 'while' check is
> little bit suspicious.
> It seems to be only for non-continuous clock behavior, on the other side
> it is according to guidelines
> in specs.

After reviewing it again 'while' check looks OK :), sorry for noise.
Loop exits w/o timeout either HS_CLK is ready (continuous clock
behavior) either HS_CLK is stopped (non-continuous clock behavior).

Regards
Andrzej

> 
> Inki, have you tried to take an assumption your panel requires
> continuous clock behavior and exynos
> dsi driver currently supports only non-continuous clock behavior, so it
> needs some fixes to make it work.
> Exynos specs are very unclear on the subject so it is hard to guess how
> the registers should be configured
> to have continuous/non-continuous clock behavior.
> 
> Regards
> Andrzej
> 
>>
>>>> In Tegra, What to do for it?
>>> There are two bits in two separate registers for this:
>>>
>>> 	DSI_HOST_CONTROL:
>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>> 	                               packets
>>> 	    - 0 = LOW: low speed
>>> 	    - 1 = HIGH: high speed
>>>
>>> 	DSI_CONTROL:
>>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>>> 	                   transmissions
>>>
>>> So if the peripheral supports non-continuous mode of operation we set
>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>> remains on all the time.
>>>
>>> When a packet is to be transmitted in high speed mode, we set the
>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>> cleared.
>> That is exactly what I want. In your case, if you want to transmit
>> command data in Low Power Mode in case of supporting non-continuous
>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>
>> So I guess,
>>
>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
>> }
>>
>> transmit command data <- in LPM.
>>
>> However, what if the peripheral doesn't support non-continuous but want
>> to transmit command data in LPM? Is that  impossible?
>>
>> Thanks,
>> Inki Dae
>>
>>> Thierry
>>>
>>
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

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

[Inki Dae]

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 <thierry.reding@gmail.com>:
>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>>> the meaning?
>>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>>
>>>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>>
>>>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>>
>>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>>> host controller should be disabled.
>>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>>
>>>>>>>>> Hm.. I see. I meant,
>>>>>>>>>
>>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>>        disable HS clock <- required.
>>>>>>>>>
>>>>>>>>> transmit command data <- in LPM.
>>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>>> use.
>>>>>>>>
>>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>>> need to be considered separately.
>>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>>
>>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>>> non-continuous clock mode.
>>>>>> No, that's not what I'm saying.
>>>>>>
>>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>>> That would may why we are mentioning same comments repeatedly.
>>>>>
>>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>>> sure that yet it's correct way.
>>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>>> running?
>>> Actually, we are doing so. If the clock is still running then dsi driver
>>> will wait for stop state of the clock and data lanes. Know that this is
>>> valid only when initial time - just one time since power up.
>>>
>>> 	/* Check clock and data lane state are stop state */
>>> 	timeout = 100;
>>> 	do {
>>> 		if (timeout-- == 0) {
>>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>>> 			return -EFAULT;
>>> 		}
>>>
>>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>>> 			continue;
>>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>
>> This is only in initialization phase of DSI. 'If' inside the loop is
>> quite clear
>> - it checks for LP11 on all requested data lanes. 'while' check is
>> little bit suspicious.
>> It seems to be only for non-continuous clock behavior, on the other side
>> it is according to guidelines
>> in specs.
> 
> After reviewing it again 'while' check looks OK :), sorry for noise.
> Loop exits w/o timeout either HS_CLK is ready (continuous clock
> behavior) either HS_CLK is stopped (non-continuous clock behavior).
> 
> Regards
> Andrzej
> 
>>
>> Inki, have you tried to take an assumption your panel requires
>> continuous clock behavior and exynos
>> dsi driver currently supports only non-continuous clock behavior, so it
>> needs some fixes to make it work.

I'm not sure yet. All I can say is that the panel works well only with
clearing DSIM_TX_REQUEST_HSCLK and DSIM_CMD_LPDT_LP.
And more thing, we need to check that disabling these two flags means
non-continuous clock mode or just low power transfer.
I think these two flags all should be also disabled in case peripheral
doesn't support non-continuous clock but want to transmit data in low power.
In this case, what should we call this mode?

>> Exynos specs are very unclear on the subject so it is hard to guess how
>> the registers should be configured

For this, Youngjun are trying to contact HW guys.

Thanks,
Inki Dae

>> to have continuous/non-continuous clock behavior.
>>
>> Regards
>> Andrzej
>>
>>>
>>>>> In Tegra, What to do for it?
>>>> There are two bits in two separate registers for this:
>>>>
>>>> 	DSI_HOST_CONTROL:
>>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>>> 	                               packets
>>>> 	    - 0 = LOW: low speed
>>>> 	    - 1 = HIGH: high speed
>>>>
>>>> 	DSI_CONTROL:
>>>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>>>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>>>> 	                   transmissions
>>>>
>>>> So if the peripheral supports non-continuous mode of operation we set
>>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>>> remains on all the time.
>>>>
>>>> When a packet is to be transmitted in high speed mode, we set the
>>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>>> cleared.
>>> That is exactly what I want. In your case, if you want to transmit
>>> command data in Low Power Mode in case of supporting non-continuous
>>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>>
>>> So I guess,
>>>
>>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
>>> }
>>>
>>> transmit command data <- in LPM.
>>>
>>> However, what if the peripheral doesn't support non-continuous but want
>>> to transmit command data in LPM? Is that  impossible?
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>> Thierry
>>>>
>>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@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 majordomo@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

[Andrzej Hajda]

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 <thierry.reding@gmail.com>:
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>>>> the meaning?
>>>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>>>
>>>>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>>>> host controller should be disabled.
>>>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>>>
>>>>>>>>>> Hm.. I see. I meant,
>>>>>>>>>>
>>>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>>>        disable HS clock <- required.
>>>>>>>>>>
>>>>>>>>>> transmit command data <- in LPM.
>>>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>>>> use.
>>>>>>>>>
>>>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>>>> need to be considered separately.
>>>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>>>
>>>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>>>> non-continuous clock mode.
>>>>>>> No, that's not what I'm saying.
>>>>>>>
>>>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>>>> That would may why we are mentioning same comments repeatedly.
>>>>>>
>>>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>>>> sure that yet it's correct way.
>>>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>>>> running?
>>>> Actually, we are doing so. If the clock is still running then dsi driver
>>>> will wait for stop state of the clock and data lanes. Know that this is
>>>> valid only when initial time - just one time since power up.
>>>>
>>>> 	/* Check clock and data lane state are stop state */
>>>> 	timeout = 100;
>>>> 	do {
>>>> 		if (timeout-- == 0) {
>>>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>>>> 			return -EFAULT;
>>>> 		}
>>>>
>>>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>>>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>>>> 			continue;
>>>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>> This is only in initialization phase of DSI. 'If' inside the loop is
>>> quite clear
>>> - it checks for LP11 on all requested data lanes. 'while' check is
>>> little bit suspicious.
>>> It seems to be only for non-continuous clock behavior, on the other side
>>> it is according to guidelines
>>> in specs.
>> After reviewing it again 'while' check looks OK :), sorry for noise.
>> Loop exits w/o timeout either HS_CLK is ready (continuous clock
>> behavior) either HS_CLK is stopped (non-continuous clock behavior).
>>
>> Regards
>> Andrzej
>>
>>> Inki, have you tried to take an assumption your panel requires
>>> continuous clock behavior and exynos
>>> dsi driver currently supports only non-continuous clock behavior, so it
>>> needs some fixes to make it work.
> I'm not sure yet. All I can say is that the panel works well only with
> clearing DSIM_TX_REQUEST_HSCLK and DSIM_CMD_LPDT_LP.

I have performed simple test: I have enabled/disabled DSIM_TX_REQUEST_HSCLK
and tested DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK bits at the end
of the initialization. The result:
a) DSIM_TX_REQUEST_HSCLK == 0 => DSIM_TX_READY_HS_CLK set
b) DSIM_TX_REQUEST_HSCLK == 1 => DSIM_STOP_STATE_CLK set

It clearly indicates that DSIM_TX_REQUEST_HSCLK is equivalent of
non-continuous clock behavior.
So your panel requires continuous clock behavior(DSIM_TX_REQUEST_HSCLK
== 0).

Regarding DSIM_CMD_LPDT_LP you wrote it should be cleared in case of
your panel. It means
you need HS mode transfer.

Regards
Andrzej

> And more thing, we need to check that disabling these two flags means
> non-continuous clock mode or just low power transfer.
> I think these two flags all should be also disabled in case peripheral
> doesn't support non-continuous clock but want to transmit data in low power.
> In this case, what should we call this mode?
>
>>> Exynos specs are very unclear on the subject so it is hard to guess how
>>> the registers should be configured
> For this, Youngjun are trying to contact HW guys.
>
> Thanks,
> Inki Dae
>
>>> to have continuous/non-continuous clock behavior.
>>>
>>> Regards
>>> Andrzej
>>>
>>>>>> In Tegra, What to do for it?
>>>>> There are two bits in two separate registers for this:
>>>>>
>>>>> 	DSI_HOST_CONTROL:
>>>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>>>> 	                               packets
>>>>> 	    - 0 = LOW: low speed
>>>>> 	    - 1 = HIGH: high speed
>>>>>
>>>>> 	DSI_CONTROL:
>>>>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>>>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>>>>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>>>>> 	                   transmissions
>>>>>
>>>>> So if the peripheral supports non-continuous mode of operation we set
>>>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>>>> remains on all the time.
>>>>>
>>>>> When a packet is to be transmitted in high speed mode, we set the
>>>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>>>> cleared.
>>>> That is exactly what I want. In your case, if you want to transmit
>>>> command data in Low Power Mode in case of supporting non-continuous
>>>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>>>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>>>
>>>> So I guess,
>>>>
>>>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>>>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>>>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
>>>> }
>>>>
>>>> transmit command data <- in LPM.
>>>>
>>>> However, what if the peripheral doesn't support non-continuous but want
>>>> to transmit command data in LPM? Is that  impossible?
>>>>
>>>> Thanks,
>>>> Inki Dae
>>>>
>>>>> Thierry
>>>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

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

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

[Inki Dae]

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 <thierry.reding@gmail.com>:
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>>>>> the meaning?
>>>>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>>>>
>>>>>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>>>>> host controller should be disabled.
>>>>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>>>>
>>>>>>>>>>> Hm.. I see. I meant,
>>>>>>>>>>>
>>>>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>>>>        disable HS clock <- required.
>>>>>>>>>>>
>>>>>>>>>>> transmit command data <- in LPM.
>>>>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>>>>> use.
>>>>>>>>>>
>>>>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>>>>> need to be considered separately.
>>>>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>>>>
>>>>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>>>>> non-continuous clock mode.
>>>>>>>> No, that's not what I'm saying.
>>>>>>>>
>>>>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>>>>> That would may why we are mentioning same comments repeatedly.
>>>>>>>
>>>>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>>>>> sure that yet it's correct way.
>>>>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>>>>> running?
>>>>> Actually, we are doing so. If the clock is still running then dsi driver
>>>>> will wait for stop state of the clock and data lanes. Know that this is
>>>>> valid only when initial time - just one time since power up.
>>>>>
>>>>> 	/* Check clock and data lane state are stop state */
>>>>> 	timeout = 100;
>>>>> 	do {
>>>>> 		if (timeout-- == 0) {
>>>>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>>>>> 			return -EFAULT;
>>>>> 		}
>>>>>
>>>>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>>>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>>>>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>>>>> 			continue;
>>>>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>>> This is only in initialization phase of DSI. 'If' inside the loop is
>>>> quite clear
>>>> - it checks for LP11 on all requested data lanes. 'while' check is
>>>> little bit suspicious.
>>>> It seems to be only for non-continuous clock behavior, on the other side
>>>> it is according to guidelines
>>>> in specs.
>>> After reviewing it again 'while' check looks OK :), sorry for noise.
>>> Loop exits w/o timeout either HS_CLK is ready (continuous clock
>>> behavior) either HS_CLK is stopped (non-continuous clock behavior).
>>>
>>> Regards
>>> Andrzej
>>>
>>>> Inki, have you tried to take an assumption your panel requires
>>>> continuous clock behavior and exynos
>>>> dsi driver currently supports only non-continuous clock behavior, so it
>>>> needs some fixes to make it work.
>> I'm not sure yet. All I can say is that the panel works well only with
>> clearing DSIM_TX_REQUEST_HSCLK and DSIM_CMD_LPDT_LP.
> 
> I have performed simple test: I have enabled/disabled DSIM_TX_REQUEST_HSCLK
> and tested DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK bits at the end
> of the initialization. The result:
> a) DSIM_TX_REQUEST_HSCLK == 0 => DSIM_TX_READY_HS_CLK set
> b) DSIM_TX_REQUEST_HSCLK == 1 => DSIM_STOP_STATE_CLK set
> 
> It clearly indicates that DSIM_TX_REQUEST_HSCLK is equivalent of
> non-continuous clock behavior.
> So your panel requires continuous clock behavior(DSIM_TX_REQUEST_HSCLK
> == 0).
> 
> Regarding DSIM_CMD_LPDT_LP you wrote it should be cleared in case of
> your panel. It means
> you need HS mode transfer.

As a result,  it doesn't work. there would be our missing something.
I'll let me know how to test it by private email.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
>> And more thing, we need to check that disabling these two flags means
>> non-continuous clock mode or just low power transfer.
>> I think these two flags all should be also disabled in case peripheral
>> doesn't support non-continuous clock but want to transmit data in low power.
>> In this case, what should we call this mode?
>>
>>>> Exynos specs are very unclear on the subject so it is hard to guess how
>>>> the registers should be configured
>> For this, Youngjun are trying to contact HW guys.
>>
>> Thanks,
>> Inki Dae
>>
>>>> to have continuous/non-continuous clock behavior.
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>>>>> In Tegra, What to do for it?
>>>>>> There are two bits in two separate registers for this:
>>>>>>
>>>>>> 	DSI_HOST_CONTROL:
>>>>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>>>>> 	                               packets
>>>>>> 	    - 0 = LOW: low speed
>>>>>> 	    - 1 = HIGH: high speed
>>>>>>
>>>>>> 	DSI_CONTROL:
>>>>>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>>>>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>>>>>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>>>>>> 	                   transmissions
>>>>>>
>>>>>> So if the peripheral supports non-continuous mode of operation we set
>>>>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>>>>> remains on all the time.
>>>>>>
>>>>>> When a packet is to be transmitted in high speed mode, we set the
>>>>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>>>>> cleared.
>>>>> That is exactly what I want. In your case, if you want to transmit
>>>>> command data in Low Power Mode in case of supporting non-continuous
>>>>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>>>>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>>>>
>>>>> So I guess,
>>>>>
>>>>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>>>>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>>>>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
>>>>> }
>>>>>
>>>>> transmit command data <- in LPM.
>>>>>
>>>>> However, what if the peripheral doesn't support non-continuous but want
>>>>> to transmit command data in LPM? Is that  impossible?
>>>>>
>>>>> Thanks,
>>>>> Inki Dae
>>>>>
>>>>>> Thierry
>>>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel@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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

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

[Andrzej Hajda]

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 <thierry.reding@gmail.com>:
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>>>>> the meaning?
>>>>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>>>>
>>>>>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>>>>> host controller should be disabled.
>>>>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>>>>
>>>>>>>>>>> Hm.. I see. I meant,
>>>>>>>>>>>
>>>>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>>>>        disable HS clock <- required.
>>>>>>>>>>>
>>>>>>>>>>> transmit command data <- in LPM.
>>>>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>>>>> use.
>>>>>>>>>>
>>>>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>>>>> need to be considered separately.
>>>>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>>>>
>>>>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>>>>> non-continuous clock mode.
>>>>>>>> No, that's not what I'm saying.
>>>>>>>>
>>>>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>>>>> That would may why we are mentioning same comments repeatedly.
>>>>>>>
>>>>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>>>>> sure that yet it's correct way.
>>>>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>>>>> running?
>>>>> Actually, we are doing so. If the clock is still running then dsi driver
>>>>> will wait for stop state of the clock and data lanes. Know that this is
>>>>> valid only when initial time - just one time since power up.
>>>>>
>>>>> 	/* Check clock and data lane state are stop state */
>>>>> 	timeout = 100;
>>>>> 	do {
>>>>> 		if (timeout-- == 0) {
>>>>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>>>>> 			return -EFAULT;
>>>>> 		}
>>>>>
>>>>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>>>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>>>>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>>>>> 			continue;
>>>>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>>> This is only in initialization phase of DSI. 'If' inside the loop is
>>>> quite clear
>>>> - it checks for LP11 on all requested data lanes. 'while' check is
>>>> little bit suspicious.
>>>> It seems to be only for non-continuous clock behavior, on the other side
>>>> it is according to guidelines
>>>> in specs.
>>> After reviewing it again 'while' check looks OK :), sorry for noise.
>>> Loop exits w/o timeout either HS_CLK is ready (continuous clock
>>> behavior) either HS_CLK is stopped (non-continuous clock behavior).
>>>
>>> Regards
>>> Andrzej
>>>
>>>> Inki, have you tried to take an assumption your panel requires
>>>> continuous clock behavior and exynos
>>>> dsi driver currently supports only non-continuous clock behavior, so it
>>>> needs some fixes to make it work.
>> I'm not sure yet. All I can say is that the panel works well only with
>> clearing DSIM_TX_REQUEST_HSCLK and DSIM_CMD_LPDT_LP.
> I have performed simple test: I have enabled/disabled DSIM_TX_REQUEST_HSCLK
> and tested DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK bits at the end
> of the initialization. The result:
> a) DSIM_TX_REQUEST_HSCLK == 0 => DSIM_TX_READY_HS_CLK set
> b) DSIM_TX_REQUEST_HSCLK == 1 => DSIM_STOP_STATE_CLK set
>
> It clearly indicates that DSIM_TX_REQUEST_HSCLK is equivalent of
> non-continuous clock behavior.
> So your panel requires continuous clock behavior(DSIM_TX_REQUEST_HSCLK
> == 0).
Ups, did stupid mistake, it is opposite:

a) DSIM_TX_REQUEST_HSCLK == 1 => DSIM_TX_READY_HS_CLK set
b) DSIM_TX_REQUEST_HSCLK == 0 => DSIM_STOP_STATE_CLK set

So DSIM_TX_REQUEST_HSCLK is equivalent of continuous clock behavior.

So it means your panel requires non-continuous clock behavior and this
seems quite strange.

Regards
Andrzej

>
> Regarding DSIM_CMD_LPDT_LP you wrote it should be cleared in case of
> your panel. It means
> you need HS mode transfer.
>
> Regards
> Andrzej
>
>> And more thing, we need to check that disabling these two flags means
>> non-continuous clock mode or just low power transfer.
>> I think these two flags all should be also disabled in case peripheral
>> doesn't support non-continuous clock but want to transmit data in low power.
>> In this case, what should we call this mode?
>>
>>>> Exynos specs are very unclear on the subject so it is hard to guess how
>>>> the registers should be configured
>> For this, Youngjun are trying to contact HW guys.
>>
>> Thanks,
>> Inki Dae
>>
>>>> to have continuous/non-continuous clock behavior.
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>>>>> In Tegra, What to do for it?
>>>>>> There are two bits in two separate registers for this:
>>>>>>
>>>>>> 	DSI_HOST_CONTROL:
>>>>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>>>>> 	                               packets
>>>>>> 	    - 0 = LOW: low speed
>>>>>> 	    - 1 = HIGH: high speed
>>>>>>
>>>>>> 	DSI_CONTROL:
>>>>>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>>>>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>>>>>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>>>>>> 	                   transmissions
>>>>>>
>>>>>> So if the peripheral supports non-continuous mode of operation we set
>>>>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>>>>> remains on all the time.
>>>>>>
>>>>>> When a packet is to be transmitted in high speed mode, we set the
>>>>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>>>>> cleared.
>>>>> That is exactly what I want. In your case, if you want to transmit
>>>>> command data in Low Power Mode in case of supporting non-continuous
>>>>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>>>>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>>>>
>>>>> So I guess,
>>>>>
>>>>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>>>>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>>>>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
>>>>> }
>>>>>
>>>>> transmit command data <- in LPM.
>>>>>
>>>>> However, what if the peripheral doesn't support non-continuous but want
>>>>> to transmit command data in LPM? Is that  impossible?
>>>>>
>>>>> Thanks,
>>>>> Inki Dae
>>>>>
>>>>>> Thierry
>>>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel@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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>

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

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

[YoungJun Cho]

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 <thierry.reding@gmail.com>:
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>>>> the meaning?
>>>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>>>
>>>>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>>>> host controller should be disabled.
>>>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>>>
>>>>>>>>>> Hm.. I see. I meant,
>>>>>>>>>>
>>>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>>>         disable HS clock <- required.
>>>>>>>>>>
>>>>>>>>>> transmit command data <- in LPM.
>>>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>>>> use.
>>>>>>>>>
>>>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>>>> need to be considered separately.
>>>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>>>
>>>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>>>> non-continuous clock mode.
>>>>>>> No, that's not what I'm saying.
>>>>>>>
>>>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>>>> That would may why we are mentioning same comments repeatedly.
>>>>>>
>>>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>>>> sure that yet it's correct way.
>>>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>>>> running?
>>>> Actually, we are doing so. If the clock is still running then dsi driver
>>>> will wait for stop state of the clock and data lanes. Know that this is
>>>> valid only when initial time - just one time since power up.
>>>>
>>>> 	/* Check clock and data lane state are stop state */
>>>> 	timeout = 100;
>>>> 	do {
>>>> 		if (timeout-- == 0) {
>>>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>>>> 			return -EFAULT;
>>>> 		}
>>>>
>>>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>>>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>>>> 			continue;
>>>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>>
>>> This is only in initialization phase of DSI. 'If' inside the loop is
>>> quite clear
>>> - it checks for LP11 on all requested data lanes. 'while' check is
>>> little bit suspicious.
>>> It seems to be only for non-continuous clock behavior, on the other side
>>> it is according to guidelines
>>> in specs.
>>
>> After reviewing it again 'while' check looks OK :), sorry for noise.
>> Loop exits w/o timeout either HS_CLK is ready (continuous clock
>> behavior) either HS_CLK is stopped (non-continuous clock behavior).
>>
>> Regards
>> Andrzej
>>
>>>
>>> Inki, have you tried to take an assumption your panel requires
>>> continuous clock behavior and exynos
>>> dsi driver currently supports only non-continuous clock behavior, so it
>>> needs some fixes to make it work.
>
> I'm not sure yet. All I can say is that the panel works well only with
> clearing DSIM_TX_REQUEST_HSCLK and DSIM_CMD_LPDT_LP.
> And more thing, we need to check that disabling these two flags means
> non-continuous clock mode or just low power transfer.
> I think these two flags all should be also disabled in case peripheral
> doesn't support non-continuous clock but want to transmit data in low power.
> In this case, what should we call this mode?
>
>>> Exynos specs are very unclear on the subject so it is hard to guess how
>>> the registers should be configured
>
> For this, Youngjun are trying to contact HW guys.
>

I asked H/W guy exynos dsi configuration.

1. For HS mode operation
	=> Sets DSIM_TX_REQUEST_HSCLK
	=> Waits till DSIM_TX_READY_HS_CLK is set

2. For LP mode operation(especially transferring command)
	=> Sets DSIM_CMD_LPDT_LP
	* Note: Don't use DSIM_TX_LPDT_LP for stability

3. For non-continuous clock control
	=> Enable: Unsets the 30th bit(Clklane_Stop/Start) in
		DSIM_CONFIG (default)
	=> Disable: Sets the 30th bit(Clklane_Stop/Start) in
		DSIM_CONFIG

So we need implementation to control non-continuous clock operation.

Thank you.
Best regards YJ

> Thanks,
> Inki Dae
>
>>> to have continuous/non-continuous clock behavior.
>>>
>>> Regards
>>> Andrzej
>>>
>>>>
>>>>>> In Tegra, What to do for it?
>>>>> There are two bits in two separate registers for this:
>>>>>
>>>>> 	DSI_HOST_CONTROL:
>>>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>>>> 	                               packets
>>>>> 	    - 0 = LOW: low speed
>>>>> 	    - 1 = HIGH: high speed
>>>>>
>>>>> 	DSI_CONTROL:
>>>>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>>>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>>>>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>>>>> 	                   transmissions
>>>>>
>>>>> So if the peripheral supports non-continuous mode of operation we set
>>>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>>>> remains on all the time.
>>>>>
>>>>> When a packet is to be transmitted in high speed mode, we set the
>>>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>>>> cleared.
>>>> That is exactly what I want. In your case, if you want to transmit
>>>> command data in Low Power Mode in case of supporting non-continuous
>>>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>>>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>>>
>>>> So I guess,
>>>>
>>>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>>>          disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>>>          enable DSI_HS_CLK_CTRL; <- TX_ONLY
>>>> }
>>>>
>>>> transmit command data <- in LPM.
>>>>
>>>> However, what if the peripheral doesn't support non-continuous but want
>>>> to transmit command data in LPM? Is that  impossible?
>>>>
>>>> Thanks,
>>>> Inki Dae
>>>>
>>>>> Thierry
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

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

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

[Inki Dae]

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
>>>>>>>>>>>>>>>>> <thierry.reding@gmail.com>:
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means
>>>>>>>>>>>>>>>>>> that the host can
>>>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission.
>>>>>>>>>>>>>>>>>> I think Andrzej
>>>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this
>>>>>>>>>>>>>>>>>> is an optional
>>>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra
>>>>>>>>>>>>>>>>>> circuitry that
>>>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't
>>>>>>>>>>>>>>>>>> have such circuitry
>>>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between
>>>>>>>>>>>>>>>>>> transmissions and
>>>>>>>>>>>>>>>>>> therefore require the HS clock to be always on
>>>>>>>>>>>>>>>>>> (continuous mode). That's
>>>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it
>>>>>>>>>>>>>>>>>> advertises that the
>>>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore
>>>>>>>>>>>>>>>>>> the host can turn
>>>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible
>>>>>>>>>>>>>>>>> operations.
>>>>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a
>>>>>>>>>>>>>>>>> register
>>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and
>>>>>>>>>>>>>>>>> negative lane all
>>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>>>>> 5. At this time, operation mode of host controller
>>>>>>>>>>>>>>>>> becomes LPM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a
>>>>>>>>>>>>>>>>> register
>>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and
>>>>>>>>>>>>>>>>> negative lane all
>>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>>>>> 4. At this time, operation mode of host controller
>>>>>>>>>>>>>>>>> becomes LPM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal.
>>>>>>>>>>>>>>>> Non-continuous
>>>>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11
>>>>>>>>>>>>>>>> between HS
>>>>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI
>>>>>>>>>>>>>>>> specification).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS
>>>>>>>>>>>>>>> clock enabled if
>>>>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane
>>>>>>>>>>>>>> won't enter
>>>>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can
>>>>>>>>>>>>>> disable the HS
>>>>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode
>>>>>>>>>>>>>> the clock lane
>>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock
>>>>>>>>>>>>> is enabled,
>>>>>>>>>>>>> the the clock lane won't enter LP-11" But you said again
>>>>>>>>>>>>> "the clock lane
>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS
>>>>>>>>>>>>> clock" What is
>>>>>>>>>>>>> the meaning?
>>>>>>>>>>>> It means that if the HS clock is enabled, then the clock
>>>>>>>>>>>> lane is not in
>>>>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters
>>>>>>>>>>>> LP-11.
>>>>>>>>>>>>
>>>>>>>>>>>>>> In continuous mode, then the clock will never be disabled,
>>>>>>>>>>>>>> hence the
>>>>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And also it seems that non-continous mode is different
>>>>>>>>>>>>>>> from LPM at all
>>>>>>>>>>>>>>> because with non-continuous mode, command data is
>>>>>>>>>>>>>>> transmitted to panel
>>>>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to
>>>>>>>>>>>>>>> panel in LP
>>>>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>>>>> No. I think you can send command data to the peripheral in
>>>>>>>>>>>>>> low power
>>>>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in
>>>>>>>>>>>>>>> case of LP mode,
>>>>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode,
>>>>>>>>>>>>>> then the HS
>>>>>>>>>>>>>> clock must never be turned off. On the other hand, if the
>>>>>>>>>>>>>> peripheral
>>>>>>>>>>>>>> supports non-continuous mode, then the DSI host should
>>>>>>>>>>>>>> automatically
>>>>>>>>>>>>>> disable the HS clock between high-speed transmissions.
>>>>>>>>>>>>>> That means if a
>>>>>>>>>>>>>> packet is transmitted in low power mode the DSI host will
>>>>>>>>>>>>>> not be
>>>>>>>>>>>>>> transmitting in high-speed mode and therefore disable the
>>>>>>>>>>>>>> HS clock.
>>>>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock
>>>>>>>>>>>>> disabled. So
>>>>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS
>>>>>>>>>>>>> clock of the
>>>>>>>>>>>>> host controller should be disabled.
>>>>>>>>>>>> No. I don't think any transmissions can happen when all
>>>>>>>>>>>> lanes are in
>>>>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify
>>>>>>>>>>>> that a packet
>>>>>>>>>>>> should be transmitted in low power mode (see LP Transmission
>>>>>>>>>>>> in 2.1
>>>>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>>>>
>>>>>>>>>>> Hm.. I see. I meant,
>>>>>>>>>>>
>>>>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>>>>         disable HS clock <- required.
>>>>>>>>>>>
>>>>>>>>>>> transmit command data <- in LPM.
>>>>>>>>>> No. Disabling the HS clock is not required for LPM mode. In
>>>>>>>>>> fact if the
>>>>>>>>>> peripheral specifies that it doesn't support non-continuous
>>>>>>>>>> mode then
>>>>>>>>>> the HS clock must *never* be disabled as long as the
>>>>>>>>>> peripheral is in
>>>>>>>>>> use.
>>>>>>>>>>
>>>>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are
>>>>>>>>>> unrelated and
>>>>>>>>>> need to be considered separately.
>>>>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>>>>
>>>>>>>>> It seems that you say the only way to transfer command data in
>>>>>>>>> LPM is
>>>>>>>>> non-continuous clock mode.
>>>>>>>> No, that's not what I'm saying.
>>>>>>>>
>>>>>>>>> However, you said and also the spec says, "Non-continuous mode
>>>>>>>>> simply
>>>>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>>>>> Doesn't *between HS transmissions" mean the command data is
>>>>>>>>> transmitted
>>>>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>>>> Not necessarily. You can transmit command packets in high-speed
>>>>>>>> mode,
>>>>>>>> but you don't have to. If you transmit packets in low power
>>>>>>>> mode, then
>>>>>>> That would may why we are mentioning same comments repeatedly.
>>>>>>>
>>>>>>> In my case, host driver waits for the lane stop state (LP-11),
>>>>>>> and then
>>>>>>> disables HS clock to transmit command data in LPM. Of course, I'm
>>>>>>> not
>>>>>>> sure that yet it's correct way.
>>>>>> That's confusing. How can the lane go to LP-11 when the clock is
>>>>>> still
>>>>>> running?
>>>>> Actually, we are doing so. If the clock is still running then dsi
>>>>> driver
>>>>> will wait for stop state of the clock and data lanes. Know that
>>>>> this is
>>>>> valid only when initial time - just one time since power up.
>>>>>
>>>>>     /* Check clock and data lane state are stop state */
>>>>>     timeout = 100;
>>>>>     do {
>>>>>         if (timeout-- == 0) {
>>>>>             dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>>>>>             return -EFAULT;
>>>>>         }
>>>>>
>>>>>         reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>>>>         if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>>>>>             != DSIM_STOP_STATE_DAT(lanes_mask))
>>>>>             continue;
>>>>>     } while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>>>
>>>> This is only in initialization phase of DSI. 'If' inside the loop is
>>>> quite clear
>>>> - it checks for LP11 on all requested data lanes. 'while' check is
>>>> little bit suspicious.
>>>> It seems to be only for non-continuous clock behavior, on the other
>>>> side
>>>> it is according to guidelines
>>>> in specs.
>>>
>>> After reviewing it again 'while' check looks OK :), sorry for noise.
>>> Loop exits w/o timeout either HS_CLK is ready (continuous clock
>>> behavior) either HS_CLK is stopped (non-continuous clock behavior).
>>>
>>> Regards
>>> Andrzej
>>>
>>>>
>>>> Inki, have you tried to take an assumption your panel requires
>>>> continuous clock behavior and exynos
>>>> dsi driver currently supports only non-continuous clock behavior, so it
>>>> needs some fixes to make it work.
>>
>> I'm not sure yet. All I can say is that the panel works well only with
>> clearing DSIM_TX_REQUEST_HSCLK and DSIM_CMD_LPDT_LP.
>> And more thing, we need to check that disabling these two flags means
>> non-continuous clock mode or just low power transfer.
>> I think these two flags all should be also disabled in case peripheral
>> doesn't support non-continuous clock but want to transmit data in low
>> power.
>> In this case, what should we call this mode?
>>
>>>> Exynos specs are very unclear on the subject so it is hard to guess how
>>>> the registers should be configured
>>
>> For this, Youngjun are trying to contact HW guys.
>>
> 
> I asked H/W guy exynos dsi configuration.
> 
> 1. For HS mode operation
>     => Sets DSIM_TX_REQUEST_HSCLK
>     => Waits till DSIM_TX_READY_HS_CLK is set
> 
> 2. For LP mode operation(especially transferring command)
>     => Sets DSIM_CMD_LPDT_LP
>     * Note: Don't use DSIM_TX_LPDT_LP for stability
> 
> 3. For non-continuous clock control
>     => Enable: Unsets the 30th bit(Clklane_Stop/Start) in
>         DSIM_CONFIG (default)
>     => Disable: Sets the 30th bit(Clklane_Stop/Start) in
>         DSIM_CONFIG
> 
> So we need implementation to control non-continuous clock operation.
> 

Thanks for confirmation. :)

I had posted a new patch series for low power transmission and
non-continuous clock support but as above, we should control
Clklane_Stop/Start bit to use non-continuous clock mode. I will fix and
re-send them soon.

Thanks,
Inki Dae

> Thank you.
> Best regards YJ
> 
>> Thanks,
>> Inki Dae
>>
>>>> to have continuous/non-continuous clock behavior.
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>>>
>>>>>>> In Tegra, What to do for it?
>>>>>> There are two bits in two separate registers for this:
>>>>>>
>>>>>>     DSI_HOST_CONTROL:
>>>>>>       bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>>>>>                                    packets
>>>>>>         - 0 = LOW: low speed
>>>>>>         - 1 = HIGH: high speed
>>>>>>
>>>>>>     DSI_CONTROL:
>>>>>>       bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>>>>>         - 0 = CONTINUOUS: HS clock is on all the time
>>>>>>         - 1 = TX_ONLY: HS clock is only active during HS
>>>>>>                        transmissions
>>>>>>
>>>>>> So if the peripheral supports non-continuous mode of operation we set
>>>>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>>>>> remains on all the time.
>>>>>>
>>>>>> When a packet is to be transmitted in high speed mode, we set the
>>>>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that
>>>>>> bit is
>>>>>> cleared.
>>>>> That is exactly what I want. In your case, if you want to transmit
>>>>> command data in Low Power Mode in case of supporting non-continuous
>>>>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>>>>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>>>>
>>>>> So I guess,
>>>>>
>>>>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>>>>          disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>>>>          enable DSI_HS_CLK_CTRL; <- TX_ONLY
>>>>> }
>>>>>
>>>>> transmit command data <- in LPM.
>>>>>
>>>>> However, what if the peripheral doesn't support non-continuous but
>>>>> want
>>>>> to transmit command data in LPM? Is that  impossible?
>>>>>
>>>>> Thanks,
>>>>> Inki Dae
>>>>>
>>>>>> Thierry
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel@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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@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 majordomo@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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 10370 bytes --]

On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
> On 2014년 08월 08일 16:03, Thierry Reding wrote:
> > On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
> >> On 2014년 08월 07일 22:55, Thierry Reding wrote:
> >>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
> >>>> On 2014년 08월 07일 22:17, Thierry Reding wrote:
> >>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
> >>>>>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
> >>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> >>>>>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
> >>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> >>>>>>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
> >>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> >>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> >>>>>>>>> [...]
> >>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
> >>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
> >>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
> >>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
> >>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
> >>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
> >>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
> >>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> >>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
> >>>>>>>>>>>>> the HS clock off after high-speed transmissions.
> >>>>>>>>>>>>
> >>>>>>>>>>>> What I don't make sure is this sentence. With
> >>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
> >>>>>>>>>>>> One is,
> >>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
> >>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>>>>>>>> are high).
> >>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
> >>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Other is,
> >>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>>>>>>>> are high).
> >>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
> >>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It seems that you says latter case.
> >>>>>>>>>>>
> >>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
> >>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
> >>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
> >>>>>>>>>> non-continous mode is used. Right?
> >>>>>>>>>
> >>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
> >>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
> >>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
> >>>>>>>>> can enter LP-11 because the controller disables the HS clock.
> >>>>>>>>
> >>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
> >>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
> >>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
> >>>>>>>> the meaning?
> >>>>>>>
> >>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
> >>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
> >>>>>>>
> >>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
> >>>>>>>>> clock lane will never enter LP-11.
> >>>>>>>>>
> >>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
> >>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
> >>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
> >>>>>>>>>> mode. Also right?
> >>>>>>>>>
> >>>>>>>>> No. I think you can send command data to the peripheral in low power
> >>>>>>>>> mode in both continuous and non-continuous clock modes.
> >>>>>>>>>
> >>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
> >>>>>>>>>> before the host driver transmits command data?
> >>>>>>>>>
> >>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
> >>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
> >>>>>>>>> supports non-continuous mode, then the DSI host should automatically
> >>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
> >>>>>>>>> packet is transmitted in low power mode the DSI host will not be
> >>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
> >>>>>>>>
> >>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
> >>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> >>>>>>>> host controller should be disabled.
> >>>>>>>
> >>>>>>> No. I don't think any transmissions can happen when all lanes are in
> >>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> >>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
> >>>>>>> "Definitions" of the MIPI DSI specification).
> >>>>>>>
> >>>>>>
> >>>>>> Hm.. I see. I meant,
> >>>>>>
> >>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>>>>>        disable HS clock <- required.
> >>>>>>
> >>>>>> transmit command data <- in LPM.
> >>>>>
> >>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
> >>>>> peripheral specifies that it doesn't support non-continuous mode then
> >>>>> the HS clock must *never* be disabled as long as the peripheral is in
> >>>>> use.
> >>>>>
> >>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> >>>>> need to be considered separately.
> >>>>
> >>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> >>>>
> >>>> It seems that you say the only way to transfer command data in LPM is
> >>>> non-continuous clock mode.
> >>>
> >>> No, that's not what I'm saying.
> >>>
> >>>> However, you said and also the spec says, "Non-continuous mode simply
> >>>> means that the clock lane enters LP-11 between HS transmissions".
> >>>> Doesn't *between HS transmissions" mean the command data is transmitted
> >>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> >>>
> >>> Not necessarily. You can transmit command packets in high-speed mode,
> >>> but you don't have to. If you transmit packets in low power mode, then
> >>
> >> That would may why we are mentioning same comments repeatedly.
> >>
> >> In my case, host driver waits for the lane stop state (LP-11), and then
> >> disables HS clock to transmit command data in LPM. Of course, I'm not
> >> sure that yet it's correct way.
> > 
> > That's confusing. How can the lane go to LP-11 when the clock is still
> > running?
> 
> Actually, we are doing so. If the clock is still running then dsi driver
> will wait for stop state of the clock and data lanes. Know that this is
> valid only when initial time - just one time since power up.
> 
> 	/* Check clock and data lane state are stop state */
> 	timeout = 100;
> 	do {
> 		if (timeout-- == 0) {
> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
> 			return -EFAULT;
> 		}
> 
> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
> 			continue;
> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
> 
> > 
> >> In Tegra, What to do for it?
> > 
> > There are two bits in two separate registers for this:
> > 
> > 	DSI_HOST_CONTROL:
> > 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
> > 	                               packets
> > 	    - 0 = LOW: low speed
> > 	    - 1 = HIGH: high speed
> > 
> > 	DSI_CONTROL:
> > 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
> > 	    - 0 = CONTINUOUS: HS clock is on all the time
> > 	    - 1 = TX_ONLY: HS clock is only active during HS
> > 	                   transmissions
> > 
> > So if the peripheral supports non-continuous mode of operation we set
> > the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
> > remains on all the time.
> >
> > When a packet is to be transmitted in high speed mode, we set the
> > DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
> > cleared.
> 
> That is exactly what I want. In your case, if you want to transmit
> command data in Low Power Mode in case of supporting non-continuous
> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
> would clear DSI_HIGH_SPEED_TRANS (LOW).
> 
> So I guess,
> 
> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
> }
> 
> transmit command data <- in LPM.
> 
> However, what if the peripheral doesn't support non-continuous but want
> to transmit command data in LPM? Is that  impossible?

The above is actually more like this:

	if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
		clear DSI_HS_CLK_CTRL;
	else
		set DSI_HS_CLK_CTRL;

	if (msg->flags & MIPI_DSI_MSG_USE_LPM)
		clear DSI_HIGH_SPEED_TRANS;
	else
		set DSI_HIGH_SPEED_TRANS;

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

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

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Inki Dae]

On 2014년 08월 08일 18:55, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
>> On 2014년 08월 08일 16:03, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>>>> On 2014년 08월 07일 22:55, Thierry Reding wrote:
>>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>>>>>> On 2014년 08월 07일 22:17, Thierry Reding wrote:
>>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>>>>>>>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
>>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>>>>>>>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
>>>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>>>>>>>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>>>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
>>>>>>>>>>> [...]
>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>>
>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>>
>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>> the meaning?
>>>>>>>>>
>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>
>>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>
>>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>>
>>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>
>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>>
>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>>>
>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>> host controller should be disabled.
>>>>>>>>>
>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hm.. I see. I meant,
>>>>>>>>
>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>        disable HS clock <- required.
>>>>>>>>
>>>>>>>> transmit command data <- in LPM.
>>>>>>>
>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>> use.
>>>>>>>
>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>> need to be considered separately.
>>>>>>
>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>
>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>> non-continuous clock mode.
>>>>>
>>>>> No, that's not what I'm saying.
>>>>>
>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>
>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>>
>>>> That would may why we are mentioning same comments repeatedly.
>>>>
>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>> sure that yet it's correct way.
>>>
>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>> running?
>>
>> Actually, we are doing so. If the clock is still running then dsi driver
>> will wait for stop state of the clock and data lanes. Know that this is
>> valid only when initial time - just one time since power up.
>>
>> 	/* Check clock and data lane state are stop state */
>> 	timeout = 100;
>> 	do {
>> 		if (timeout-- == 0) {
>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>> 			return -EFAULT;
>> 		}
>>
>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>> 			continue;
>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>
>>>
>>>> In Tegra, What to do for it?
>>>
>>> There are two bits in two separate registers for this:
>>>
>>> 	DSI_HOST_CONTROL:
>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>> 	                               packets
>>> 	    - 0 = LOW: low speed
>>> 	    - 1 = HIGH: high speed
>>>
>>> 	DSI_CONTROL:
>>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>>> 	                   transmissions
>>>
>>> So if the peripheral supports non-continuous mode of operation we set
>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>> remains on all the time.
>>>
>>> When a packet is to be transmitted in high speed mode, we set the
>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>> cleared.
>>
>> That is exactly what I want. In your case, if you want to transmit
>> command data in Low Power Mode in case of supporting non-continuous
>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>
>> So I guess,
>>
>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
>> }
>>
>> transmit command data <- in LPM.
>>
>> However, what if the peripheral doesn't support non-continuous but want
>> to transmit command data in LPM? Is that  impossible?
> 
> The above is actually more like this:
> 
> 	if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
> 		clear DSI_HS_CLK_CTRL;
> 	else
> 		set DSI_HS_CLK_CTRL;
> 
> 	if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> 		clear DSI_HIGH_SPEED_TRANS;
> 	else
> 		set DSI_HIGH_SPEED_TRANS;
> 
> So for peripherals that don't support non-continuous clock mode, this
> will result in the following for low-power transmissions:
> 
> 	clear DSI_HS_CLK_CTRL; /* HS clock always on */
> 	clear DSI_HIGH_SPEED_TRANS;

Right, then how host driver should check it if peripheral doesn't
support non-continuous clock mode? Or how the peripheral should notify
it to host driver? It would need a new flag instead of
MIPI_DSI_MODE_NON_CONTINUOUS.

Thanks,
Inki Dae

> 
> Thierry
> 

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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 11542 bytes --]

On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
> On 2014년 08월 08일 18:55, Thierry Reding wrote:
> > On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
> >> On 2014년 08월 08일 16:03, Thierry Reding wrote:
> >>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
> >>>> On 2014년 08월 07일 22:55, Thierry Reding wrote:
> >>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
> >>>>>> On 2014년 08월 07일 22:17, Thierry Reding wrote:
> >>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
> >>>>>>>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
> >>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> >>>>>>>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
> >>>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> >>>>>>>>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
> >>>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> >>>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
> >>>>>>>>>>> [...]
> >>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
> >>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
> >>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
> >>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
> >>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
> >>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
> >>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
> >>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> >>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
> >>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> What I don't make sure is this sentence. With
> >>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
> >>>>>>>>>>>>>> One is,
> >>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
> >>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>>>>>>>>>> are high).
> >>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
> >>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Other is,
> >>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
> >>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
> >>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
> >>>>>>>>>>>>>> are high).
> >>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
> >>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It seems that you says latter case.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
> >>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
> >>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
> >>>>>>>>>>>> non-continous mode is used. Right?
> >>>>>>>>>>>
> >>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
> >>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
> >>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
> >>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
> >>>>>>>>>>
> >>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
> >>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
> >>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
> >>>>>>>>>> the meaning?
> >>>>>>>>>
> >>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
> >>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
> >>>>>>>>>
> >>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
> >>>>>>>>>>> clock lane will never enter LP-11.
> >>>>>>>>>>>
> >>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
> >>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
> >>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
> >>>>>>>>>>>> mode. Also right?
> >>>>>>>>>>>
> >>>>>>>>>>> No. I think you can send command data to the peripheral in low power
> >>>>>>>>>>> mode in both continuous and non-continuous clock modes.
> >>>>>>>>>>>
> >>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
> >>>>>>>>>>>> before the host driver transmits command data?
> >>>>>>>>>>>
> >>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
> >>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
> >>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
> >>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
> >>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
> >>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
> >>>>>>>>>>
> >>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
> >>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> >>>>>>>>>> host controller should be disabled.
> >>>>>>>>>
> >>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
> >>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> >>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
> >>>>>>>>> "Definitions" of the MIPI DSI specification).
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Hm.. I see. I meant,
> >>>>>>>>
> >>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>>>>>>>        disable HS clock <- required.
> >>>>>>>>
> >>>>>>>> transmit command data <- in LPM.
> >>>>>>>
> >>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
> >>>>>>> peripheral specifies that it doesn't support non-continuous mode then
> >>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
> >>>>>>> use.
> >>>>>>>
> >>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> >>>>>>> need to be considered separately.
> >>>>>>
> >>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> >>>>>>
> >>>>>> It seems that you say the only way to transfer command data in LPM is
> >>>>>> non-continuous clock mode.
> >>>>>
> >>>>> No, that's not what I'm saying.
> >>>>>
> >>>>>> However, you said and also the spec says, "Non-continuous mode simply
> >>>>>> means that the clock lane enters LP-11 between HS transmissions".
> >>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
> >>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> >>>>>
> >>>>> Not necessarily. You can transmit command packets in high-speed mode,
> >>>>> but you don't have to. If you transmit packets in low power mode, then
> >>>>
> >>>> That would may why we are mentioning same comments repeatedly.
> >>>>
> >>>> In my case, host driver waits for the lane stop state (LP-11), and then
> >>>> disables HS clock to transmit command data in LPM. Of course, I'm not
> >>>> sure that yet it's correct way.
> >>>
> >>> That's confusing. How can the lane go to LP-11 when the clock is still
> >>> running?
> >>
> >> Actually, we are doing so. If the clock is still running then dsi driver
> >> will wait for stop state of the clock and data lanes. Know that this is
> >> valid only when initial time - just one time since power up.
> >>
> >> 	/* Check clock and data lane state are stop state */
> >> 	timeout = 100;
> >> 	do {
> >> 		if (timeout-- == 0) {
> >> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
> >> 			return -EFAULT;
> >> 		}
> >>
> >> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
> >> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
> >> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
> >> 			continue;
> >> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
> >>
> >>>
> >>>> In Tegra, What to do for it?
> >>>
> >>> There are two bits in two separate registers for this:
> >>>
> >>> 	DSI_HOST_CONTROL:
> >>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
> >>> 	                               packets
> >>> 	    - 0 = LOW: low speed
> >>> 	    - 1 = HIGH: high speed
> >>>
> >>> 	DSI_CONTROL:
> >>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
> >>> 	    - 0 = CONTINUOUS: HS clock is on all the time
> >>> 	    - 1 = TX_ONLY: HS clock is only active during HS
> >>> 	                   transmissions
> >>>
> >>> So if the peripheral supports non-continuous mode of operation we set
> >>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
> >>> remains on all the time.
> >>>
> >>> When a packet is to be transmitted in high speed mode, we set the
> >>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
> >>> cleared.
> >>
> >> That is exactly what I want. In your case, if you want to transmit
> >> command data in Low Power Mode in case of supporting non-continuous
> >> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
> >> would clear DSI_HIGH_SPEED_TRANS (LOW).
> >>
> >> So I guess,
> >>
> >> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
> >>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
> >>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
> >> }
> >>
> >> transmit command data <- in LPM.
> >>
> >> However, what if the peripheral doesn't support non-continuous but want
> >> to transmit command data in LPM? Is that  impossible?
> > 
> > The above is actually more like this:
> > 
> > 	if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
> > 		clear DSI_HS_CLK_CTRL;
> > 	else
> > 		set DSI_HS_CLK_CTRL;
> > 
> > 	if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> > 		clear DSI_HIGH_SPEED_TRANS;
> > 	else
> > 		set DSI_HIGH_SPEED_TRANS;
> > 
> > So for peripherals that don't support non-continuous clock mode, this
> > will result in the following for low-power transmissions:
> > 
> > 	clear DSI_HS_CLK_CTRL; /* HS clock always on */
> > 	clear DSI_HIGH_SPEED_TRANS;
> 
> Right, then how host driver should check it if peripheral doesn't
> support non-continuous clock mode? Or how the peripheral should notify
> it to host driver? It would need a new flag instead of
> MIPI_DSI_MODE_NON_CONTINUOUS.

MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
set to signal that they support non-continuous mode. If devices don't
have that set, then the controller should always provide the HS clock.

So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
does *not* support non-continuous mode.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Inki Dae]

On 2014년 08월 11일 16:24, Thierry Reding wrote:
> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
>> On 2014년 08월 08일 18:55, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
>>>> On 2014년 08월 08일 16:03, Thierry Reding wrote:
>>>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>>>>>> On 2014년 08월 07일 22:55, Thierry Reding wrote:
>>>>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>>>>>>>> On 2014년 08월 07일 22:17, Thierry Reding wrote:
>>>>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>>>>>>>>>> On 2014년 08월 07일 20:09, Thierry Reding wrote:
>>>>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>>>>>>>>>>>> On 2014년 08월 07일 18:09, Thierry Reding wrote:
>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>>>>>>>>>>>>> On 2014년 08월 07일 15:58, Thierry Reding wrote:
>>>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>>>>>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding <thierry.reding@gmail.com>:
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host can
>>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej
>>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an optional
>>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry that
>>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry
>>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and
>>>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). That's
>>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
>>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can turn
>>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What I don't make sure is this sentence. With
>>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>>>>>>>>>>>>>>>> One is,
>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode.
>>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
>>>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Other is,
>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register
>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset.
>>>>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all
>>>>>>>>>>>>>>>> are high).
>>>>>>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM.
>>>>>>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It seems that you says latter case.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous
>>>>>>>>>>>>>>> mode simply means that the clock lane enters LP-11 between HS
>>>>>>>>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if
>>>>>>>>>>>>>> non-continous mode is used. Right?
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>>>>>>>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>>>>>>>>>>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock.
>>>>>>>>>>>>
>>>>>>>>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
>>>>>>>>>>>> the the clock lane won't enter LP-11" But you said again "the clock lane
>>>>>>>>>>>> can enter LP-11 because the controller disables the HS clock" What is
>>>>>>>>>>>> the meaning?
>>>>>>>>>>>
>>>>>>>>>>> It means that if the HS clock is enabled, then the clock lane is not in
>>>>>>>>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>>>>>>>>>
>>>>>>>>>>>>> In continuous mode, then the clock will never be disabled, hence the
>>>>>>>>>>>>> clock lane will never enter LP-11.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> And also it seems that non-continous mode is different from LPM at all
>>>>>>>>>>>>>> because with non-continuous mode, command data is transmitted to panel
>>>>>>>>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>>>>>>>>>>>>> mode. Also right?
>>>>>>>>>>>>>
>>>>>>>>>>>>> No. I think you can send command data to the peripheral in low power
>>>>>>>>>>>>> mode in both continuous and non-continuous clock modes.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP mode,
>>>>>>>>>>>>>> before the host driver transmits command data?
>>>>>>>>>>>>>
>>>>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>>>>>>>>>>>> clock must never be turned off. On the other hand, if the peripheral
>>>>>>>>>>>>> supports non-continuous mode, then the DSI host should automatically
>>>>>>>>>>>>> disable the HS clock between high-speed transmissions. That means if a
>>>>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
>>>>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
>>>>>>>>>>>>
>>>>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
>>>>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
>>>>>>>>>>>> host controller should be disabled.
>>>>>>>>>>>
>>>>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
>>>>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
>>>>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
>>>>>>>>>>> "Definitions" of the MIPI DSI specification).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hm.. I see. I meant,
>>>>>>>>>>
>>>>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
>>>>>>>>>>        disable HS clock <- required.
>>>>>>>>>>
>>>>>>>>>> transmit command data <- in LPM.
>>>>>>>>>
>>>>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
>>>>>>>>> peripheral specifies that it doesn't support non-continuous mode then
>>>>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
>>>>>>>>> use.
>>>>>>>>>
>>>>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
>>>>>>>>> need to be considered separately.
>>>>>>>>
>>>>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>>>>>>>>
>>>>>>>> It seems that you say the only way to transfer command data in LPM is
>>>>>>>> non-continuous clock mode.
>>>>>>>
>>>>>>> No, that's not what I'm saying.
>>>>>>>
>>>>>>>> However, you said and also the spec says, "Non-continuous mode simply
>>>>>>>> means that the clock lane enters LP-11 between HS transmissions".
>>>>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
>>>>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
>>>>>>>
>>>>>>> Not necessarily. You can transmit command packets in high-speed mode,
>>>>>>> but you don't have to. If you transmit packets in low power mode, then
>>>>>>
>>>>>> That would may why we are mentioning same comments repeatedly.
>>>>>>
>>>>>> In my case, host driver waits for the lane stop state (LP-11), and then
>>>>>> disables HS clock to transmit command data in LPM. Of course, I'm not
>>>>>> sure that yet it's correct way.
>>>>>
>>>>> That's confusing. How can the lane go to LP-11 when the clock is still
>>>>> running?
>>>>
>>>> Actually, we are doing so. If the clock is still running then dsi driver
>>>> will wait for stop state of the clock and data lanes. Know that this is
>>>> valid only when initial time - just one time since power up.
>>>>
>>>> 	/* Check clock and data lane state are stop state */
>>>> 	timeout = 100;
>>>> 	do {
>>>> 		if (timeout-- == 0) {
>>>> 			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>>>> 			return -EFAULT;
>>>> 		}
>>>>
>>>> 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>>> 		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>>>> 		    != DSIM_STOP_STATE_DAT(lanes_mask))
>>>> 			continue;
>>>> 	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
>>>>
>>>>>
>>>>>> In Tegra, What to do for it?
>>>>>
>>>>> There are two bits in two separate registers for this:
>>>>>
>>>>> 	DSI_HOST_CONTROL:
>>>>> 	  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
>>>>> 	                               packets
>>>>> 	    - 0 = LOW: low speed
>>>>> 	    - 1 = HIGH: high speed
>>>>>
>>>>> 	DSI_CONTROL:
>>>>> 	  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
>>>>> 	    - 0 = CONTINUOUS: HS clock is on all the time
>>>>> 	    - 1 = TX_ONLY: HS clock is only active during HS
>>>>> 	                   transmissions
>>>>>
>>>>> So if the peripheral supports non-continuous mode of operation we set
>>>>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
>>>>> remains on all the time.
>>>>>
>>>>> When a packet is to be transmitted in high speed mode, we set the
>>>>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
>>>>> cleared.
>>>>
>>>> That is exactly what I want. In your case, if you want to transmit
>>>> command data in Low Power Mode in case of supporting non-continuous
>>>> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
>>>> would clear DSI_HIGH_SPEED_TRANS (LOW).
>>>>
>>>> So I guess,
>>>>
>>>> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
>>>>         disable DSI_HIGH_SPEED_TRANS;   <- LOW
>>>>         enable DSI_HS_CLK_CTRL; <- TX_ONLY
>>>> }
>>>>
>>>> transmit command data <- in LPM.
>>>>
>>>> However, what if the peripheral doesn't support non-continuous but want
>>>> to transmit command data in LPM? Is that  impossible?
>>>
>>> The above is actually more like this:
>>>
>>> 	if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
>>> 		clear DSI_HS_CLK_CTRL;
>>> 	else
>>> 		set DSI_HS_CLK_CTRL;
>>>
>>> 	if (msg->flags & MIPI_DSI_MSG_USE_LPM)
>>> 		clear DSI_HIGH_SPEED_TRANS;
>>> 	else
>>> 		set DSI_HIGH_SPEED_TRANS;
>>>
>>> So for peripherals that don't support non-continuous clock mode, this
>>> will result in the following for low-power transmissions:
>>>
>>> 	clear DSI_HS_CLK_CTRL; /* HS clock always on */
>>> 	clear DSI_HIGH_SPEED_TRANS;
>>
>> Right, then how host driver should check it if peripheral doesn't
>> support non-continuous clock mode? Or how the peripheral should notify
>> it to host driver? It would need a new flag instead of
>> MIPI_DSI_MODE_NON_CONTINUOUS.
> 
> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
> set to signal that they support non-continuous mode. If devices don't
> have that set, then the controller should always provide the HS clock.
> 
> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
> does *not* support non-continuous mode.
> 

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

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

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

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

Thanks,
Inki Dae

> Thierry
> 

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

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

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 3178 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

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

[Inki Dae]

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
> 

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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3783 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Inki Dae]

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 transmission of each SoC <- by default

Thanks,
Inki Dae

> Thierry
> 

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

[Inki Dae]

This patch adds LPM transfer support for video or command data.

With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.

Changelog v2: Enable High Speed clock only in case of stand by request.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..1bed105 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
 			| DSIM_ESC_PRESCALER(esc_div)
 			| DSIM_LANE_ESC_CLK_EN_CLK
 			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
-			| DSIM_BYTE_CLK_SRC(0)
-			| DSIM_TX_REQUEST_HSCLK;
+			| DSIM_BYTE_CLK_SRC(0);
+
+	if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
+		reg |= DSIM_TX_REQUEST_HSCLK;
+
 	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
 
 	return 0;
@@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
 	writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
 }
 
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+					bool enable)
+{
+	u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
+
+	reg &= ~DSIM_TX_REQUEST_HSCLK;
+	if (enable)
+		reg |= DSIM_TX_REQUEST_HSCLK;
+
+	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
+}
+
 static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
 {
 	u32 reg;
@@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
 {
 	u32 reg;
 
+	if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
+		exynos_dsi_enable_hs_clock(dsi, true);
+
 	reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
 	if (enable)
 		reg |= DSIM_MAIN_STAND_BY;
-- 
1.7.9.5

Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Andrzej Hajda]

On 07/28/2014 04:00 AM, Inki Dae wrote:
> This patch adds LPM transfer support for video or command data.
>
> With this patch, Exynos MIPI DSI controller can transfer command or
> video data with HS or LP mode in accordance with mode_flags set
> by LCD Panel driver.
>
> Changelog v2: Enable High Speed clock only in case of stand by request.
>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 5e78d45..1bed105 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
>  			| DSIM_ESC_PRESCALER(esc_div)
>  			| DSIM_LANE_ESC_CLK_EN_CLK
>  			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
> -			| DSIM_BYTE_CLK_SRC(0)
> -			| DSIM_TX_REQUEST_HSCLK;
> +			| DSIM_BYTE_CLK_SRC(0);
> +
> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
> +		reg |= DSIM_TX_REQUEST_HSCLK;
> +
>  	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>  
>  	return 0;
> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
>  	writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>  }
>  
> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
> +					bool enable)
> +{
> +	u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
> +
> +	reg &= ~DSIM_TX_REQUEST_HSCLK;
> +	if (enable)
> +		reg |= DSIM_TX_REQUEST_HSCLK;
> +
> +	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
> +}
> +

I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
it works with and without the bit set.
So I start to suspect this bit is not just for simply enable/disable HS
clock as function name suggests, do you know what is its
exact meaning? The specs are quite succinct on it.
On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
in DSIM_ESCMODE register
which seems to be related to flags you have introduced:
- DSIM_CMD_LPDT_LP - transmit commands in LP mode,
- DSIM_TX_LPDT_LP - transmit data in LP mode.
The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
you use the latter?

Regards
Andrzej

>  static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>  {
>  	u32 reg;
> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
>  {
>  	u32 reg;
>  
> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
> +		exynos_dsi_enable_hs_clock(dsi, true);
> +
>  	reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>  	if (enable)
>  		reg |= DSIM_MAIN_STAND_BY;

Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Inki Dae]

On 2014년 07월 29일 00:50, Andrzej Hajda wrote:
> On 07/28/2014 04:00 AM, Inki Dae wrote:
>> This patch adds LPM transfer support for video or command data.
>>
>> With this patch, Exynos MIPI DSI controller can transfer command or
>> video data with HS or LP mode in accordance with mode_flags set
>> by LCD Panel driver.
>>
>> Changelog v2: Enable High Speed clock only in case of stand by request.
>>
>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 ++++++++++++++++++++--
>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 5e78d45..1bed105 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
>>  			| DSIM_ESC_PRESCALER(esc_div)
>>  			| DSIM_LANE_ESC_CLK_EN_CLK
>>  			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>> -			| DSIM_BYTE_CLK_SRC(0)
>> -			| DSIM_TX_REQUEST_HSCLK;
>> +			| DSIM_BYTE_CLK_SRC(0);
>> +
>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>> +
>>  	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>  
>>  	return 0;
>> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
>>  	writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>>  }
>>  
>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>> +					bool enable)
>> +{
>> +	u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>> +
>> +	reg &= ~DSIM_TX_REQUEST_HSCLK;
>> +	if (enable)
>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>> +
>> +	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>> +}
>> +
> 
> I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
> it works with and without the bit set.

If you can test thmorstat board, you will face with that its panel is
not worked.

> So I start to suspect this bit is not just for simply enable/disable HS
> clock as function name suggests, do you know what is its
> exact meaning? The specs are quite succinct on it.

HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.

> On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
> in DSIM_ESCMODE register
> which seems to be related to flags you have introduced:
> - DSIM_CMD_LPDT_LP - transmit commands in LP mode,
> - DSIM_TX_LPDT_LP - transmit data in LP mode.

As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
that host can transmit command and also image data to Panel in Low Power
Mode. So these flags are specific to MIPI-DSI controller of Exynos.

> The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not

This flag is set only when command msg transmission is requested by
Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
transmit command and also image.

Thanks,
Inki Dae

> you use the latter?
> 
> Regards
> Andrzej
> 
>>  static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>>  {
>>  	u32 reg;
>> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
>>  {
>>  	u32 reg;
>>  
>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
>> +		exynos_dsi_enable_hs_clock(dsi, true);
>> +
>>  	reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>>  	if (enable)
>>  		reg |= DSIM_MAIN_STAND_BY;
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Andrzej Hajda]

On 07/29/2014 05:42 AM, Inki Dae wrote:
> On 2014년 07월 29일 00:50, Andrzej Hajda wrote:
>> On 07/28/2014 04:00 AM, Inki Dae wrote:
>>> This patch adds LPM transfer support for video or command data.
>>>
>>> With this patch, Exynos MIPI DSI controller can transfer command or
>>> video data with HS or LP mode in accordance with mode_flags set
>>> by LCD Panel driver.
>>>
>>> Changelog v2: Enable High Speed clock only in case of stand by request.
>>>
>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 ++++++++++++++++++++--
>>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index 5e78d45..1bed105 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
>>>  			| DSIM_ESC_PRESCALER(esc_div)
>>>  			| DSIM_LANE_ESC_CLK_EN_CLK
>>>  			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>>> -			| DSIM_BYTE_CLK_SRC(0)
>>> -			| DSIM_TX_REQUEST_HSCLK;
>>> +			| DSIM_BYTE_CLK_SRC(0);
>>> +
>>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>>> +
>>>  	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>  
>>>  	return 0;
>>> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
>>>  	writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>>>  }
>>>  
>>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>>> +					bool enable)
>>> +{
>>> +	u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>>> +
>>> +	reg &= ~DSIM_TX_REQUEST_HSCLK;
>>> +	if (enable)
>>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>>> +
>>> +	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>> +}
>>> +
>> I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
>> it works with and without the bit set.
> If you can test thmorstat board, you will face with that its panel is
> not worked.

So it means this panel requires proper driving of this bit, but it does
not prove it is
LPM related.

>> So I start to suspect this bit is not just for simply enable/disable HS
>> clock as function name suggests, do you know what is its
>> exact meaning? The specs are quite succinct on it.
> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.

This sounds very strange. DSI specs and D-PHY specs says clearly
that LPM transmissions are unrelated to HS clock [1][2]. Even timing
diagrams
in Exynos specs shows no dependency of LPM transmissions on HS clock.
And the
description of TxRequestHsClk bit says "HS clock request for HS transfer
at clock lane (Turn
on HS clock)".

Maybe different flag should be used to describe your panel requirements
regarding this bit.

It would be good to see the real initialization sequence in form of
pseudo-code or better in the driver.


[1]: MIPI DSI: "Note that in Low Power signaling mode, LP clock is
functionally embedded in the data signals. When LP
data transmission ends, the clock effectively stops and subsequent LP
clocks are not available to the
peripheral. The peripheral shall not require additional bits, bytes, or
packets from the host processor in
order to complete processing or pipeline movement of received data in LP
mode transmissions. There are a
variety of ways to meet this requirement. For example, the peripheral
may generate its own clock or it may
require the host processor to keep the HS serial clock running."

[2]: MIPI D-PHY: "The data is self-clocked by the applied bit encoding
and does not rely on the Clock Lane".

Regards
Andrzej

>
>> On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
>> in DSIM_ESCMODE register
>> which seems to be related to flags you have introduced:
>> - DSIM_CMD_LPDT_LP - transmit commands in LP mode,
>> - DSIM_TX_LPDT_LP - transmit data in LP mode.
> As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
> that host can transmit command and also image data to Panel in Low Power
> Mode. So these flags are specific to MIPI-DSI controller of Exynos.
>
>> The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
> This flag is set only when command msg transmission is requested by
> Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
> and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
> transmit command and also image.
>
> Thanks,
> Inki Dae
>
>> you use the latter?
>>
>> Regards
>> Andrzej
>>
>>>  static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>>>  {
>>>  	u32 reg;
>>> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
>>>  {
>>>  	u32 reg;
>>>  
>>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
>>> +		exynos_dsi_enable_hs_clock(dsi, true);
>>> +
>>>  	reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>>>  	if (enable)
>>>  		reg |= DSIM_MAIN_STAND_BY;
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Inki Dae]

On 2014년 07월 29일 20:39, Andrzej Hajda wrote:
> On 07/29/2014 05:42 AM, Inki Dae wrote:
>> On 2014년 07월 29일 00:50, Andrzej Hajda wrote:
>>> On 07/28/2014 04:00 AM, Inki Dae wrote:
>>>> This patch adds LPM transfer support for video or command data.
>>>>
>>>> With this patch, Exynos MIPI DSI controller can transfer command or
>>>> video data with HS or LP mode in accordance with mode_flags set
>>>> by LCD Panel driver.
>>>>
>>>> Changelog v2: Enable High Speed clock only in case of stand by request.
>>>>
>>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>> ---
>>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 ++++++++++++++++++++--
>>>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> index 5e78d45..1bed105 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
>>>>  			| DSIM_ESC_PRESCALER(esc_div)
>>>>  			| DSIM_LANE_ESC_CLK_EN_CLK
>>>>  			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>>>> -			| DSIM_BYTE_CLK_SRC(0)
>>>> -			| DSIM_TX_REQUEST_HSCLK;
>>>> +			| DSIM_BYTE_CLK_SRC(0);
>>>> +
>>>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>>>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>>>> +
>>>>  	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>  
>>>>  	return 0;
>>>> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
>>>>  	writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>>>>  }
>>>>  
>>>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>>>> +					bool enable)
>>>> +{
>>>> +	u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>>>> +
>>>> +	reg &= ~DSIM_TX_REQUEST_HSCLK;
>>>> +	if (enable)
>>>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>>>> +
>>>> +	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>> +}
>>>> +
>>> I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
>>> it works with and without the bit set.
>> If you can test thmorstat board, you will face with that its panel is
>> not worked.
> 
> So it means this panel requires proper driving of this bit, but it does
> not prove it is
> LPM related.
> 
>>> So I start to suspect this bit is not just for simply enable/disable HS
>>> clock as function name suggests, do you know what is its
>>> exact meaning? The specs are quite succinct on it.
>> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
> 
> This sounds very strange. DSI specs and D-PHY specs says clearly
> that LPM transmissions are unrelated to HS clock [1][2]. Even timing
> diagrams
> in Exynos specs shows no dependency of LPM transmissions on HS clock.
> And the
> description of TxRequestHsClk bit says "HS clock request for HS transfer
> at clock lane (Turn
> on HS clock)".

There are three System power states of D-PHY, Low-Power mode, High-Speed
mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
Lane. Therefore, to use HS mode, HS clock should be enabled. On the
other hand, LP mode needs only 10MHz (max).

So do you really think LP mode will be worked well with HS clock
enabled? The purpose of LP mode is to reduce power consumption while
transmitting data. Can you reduce the power consumption in LP mode with
HS clock enabled?

Thanks,
Inki Dae

> 
> Maybe different flag should be used to describe your panel requirements
> regarding this bit.
> 
> It would be good to see the real initialization sequence in form of
> pseudo-code or better in the driver.
> 
> 
> [1]: MIPI DSI: "Note that in Low Power signaling mode, LP clock is
> functionally embedded in the data signals. When LP
> data transmission ends, the clock effectively stops and subsequent LP
> clocks are not available to the
> peripheral. The peripheral shall not require additional bits, bytes, or
> packets from the host processor in
> order to complete processing or pipeline movement of received data in LP
> mode transmissions. There are a
> variety of ways to meet this requirement. For example, the peripheral
> may generate its own clock or it may
> require the host processor to keep the HS serial clock running."
> 
> [2]: MIPI D-PHY: "The data is self-clocked by the applied bit encoding
> and does not rely on the Clock Lane".
> 
> Regards
> Andrzej
> 
>>
>>> On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
>>> in DSIM_ESCMODE register
>>> which seems to be related to flags you have introduced:
>>> - DSIM_CMD_LPDT_LP - transmit commands in LP mode,
>>> - DSIM_TX_LPDT_LP - transmit data in LP mode.
>> As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
>> that host can transmit command and also image data to Panel in Low Power
>> Mode. So these flags are specific to MIPI-DSI controller of Exynos.
>>
>>> The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
>> This flag is set only when command msg transmission is requested by
>> Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
>> and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
>> transmit command and also image.
>>
>> Thanks,
>> Inki Dae
>>
>>> you use the latter?
>>>
>>> Regards
>>> Andrzej
>>>
>>>>  static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>>>>  {
>>>>  	u32 reg;
>>>> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
>>>>  {
>>>>  	u32 reg;
>>>>  
>>>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
>>>> +		exynos_dsi_enable_hs_clock(dsi, true);
>>>> +
>>>>  	reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>>>>  	if (enable)
>>>>  		reg |= DSIM_MAIN_STAND_BY;
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Andrzej Hajda]

On 07/29/2014 02:08 PM, Inki Dae wrote:
> On 2014년 07월 29일 20:39, Andrzej Hajda wrote:
>> On 07/29/2014 05:42 AM, Inki Dae wrote:
>>> On 2014년 07월 29일 00:50, Andrzej Hajda wrote:
>>>> On 07/28/2014 04:00 AM, Inki Dae wrote:
>>>>> This patch adds LPM transfer support for video or command data.
>>>>>
>>>>> With this patch, Exynos MIPI DSI controller can transfer command or
>>>>> video data with HS or LP mode in accordance with mode_flags set
>>>>> by LCD Panel driver.
>>>>>
>>>>> Changelog v2: Enable High Speed clock only in case of stand by request.
>>>>>
>>>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>> ---
>>>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 ++++++++++++++++++++--
>>>>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> index 5e78d45..1bed105 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
>>>>>  			| DSIM_ESC_PRESCALER(esc_div)
>>>>>  			| DSIM_LANE_ESC_CLK_EN_CLK
>>>>>  			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>>>>> -			| DSIM_BYTE_CLK_SRC(0)
>>>>> -			| DSIM_TX_REQUEST_HSCLK;
>>>>> +			| DSIM_BYTE_CLK_SRC(0);
>>>>> +
>>>>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>>>>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>>>>> +
>>>>>  	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>>  
>>>>>  	return 0;
>>>>> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
>>>>>  	writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>>>>>  }
>>>>>  
>>>>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>>>>> +					bool enable)
>>>>> +{
>>>>> +	u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>> +
>>>>> +	reg &= ~DSIM_TX_REQUEST_HSCLK;
>>>>> +	if (enable)
>>>>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>>>>> +
>>>>> +	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>> +}
>>>>> +
>>>> I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
>>>> it works with and without the bit set.
>>> If you can test thmorstat board, you will face with that its panel is
>>> not worked.
>> So it means this panel requires proper driving of this bit, but it does
>> not prove it is
>> LPM related.
>>
>>>> So I start to suspect this bit is not just for simply enable/disable HS
>>>> clock as function name suggests, do you know what is its
>>>> exact meaning? The specs are quite succinct on it.
>>> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
>> This sounds very strange. DSI specs and D-PHY specs says clearly
>> that LPM transmissions are unrelated to HS clock [1][2]. Even timing
>> diagrams
>> in Exynos specs shows no dependency of LPM transmissions on HS clock.
>> And the
>> description of TxRequestHsClk bit says "HS clock request for HS transfer
>> at clock lane (Turn
>> on HS clock)".
> There are three System power states of D-PHY, Low-Power mode, High-Speed
> mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
> Lane. Therefore, to use HS mode, HS clock should be enabled. On the
> other hand, LP mode needs only 10MHz (max).
>
> So do you really think LP mode will be worked well with HS clock
> enabled? The purpose of LP mode is to reduce power consumption while
> transmitting data. Can you reduce the power consumption in LP mode with
> HS clock enabled?

As MIPI specs says "All DSI transmitters and receivers shall support
continuous clock
behavior on the Clock Lane, and optionally may support non-continuous
clock behavior"
and "For continuous clock behavior, the Clock Lane remains in high-speed
mode generating
active clock signals between HS data packet transmissions".
This means that HS clock should be on even in LP mode, unless panel
supports non-continuous clock
behavior. For signaling non-continuous clock capability there is
MIPI_DSI_CLOCK_NON_CONTINUOUS flag already.

Regards
Andrzej

>
> Thanks,
> Inki Dae
>
>> Maybe different flag should be used to describe your panel requirements
>> regarding this bit.
>>
>> It would be good to see the real initialization sequence in form of
>> pseudo-code or better in the driver.
>>
>>
>> [1]: MIPI DSI: "Note that in Low Power signaling mode, LP clock is
>> functionally embedded in the data signals. When LP
>> data transmission ends, the clock effectively stops and subsequent LP
>> clocks are not available to the
>> peripheral. The peripheral shall not require additional bits, bytes, or
>> packets from the host processor in
>> order to complete processing or pipeline movement of received data in LP
>> mode transmissions. There are a
>> variety of ways to meet this requirement. For example, the peripheral
>> may generate its own clock or it may
>> require the host processor to keep the HS serial clock running."
>>
>> [2]: MIPI D-PHY: "The data is self-clocked by the applied bit encoding
>> and does not rely on the Clock Lane".
>>
>> Regards
>> Andrzej
>>
>>>> On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
>>>> in DSIM_ESCMODE register
>>>> which seems to be related to flags you have introduced:
>>>> - DSIM_CMD_LPDT_LP - transmit commands in LP mode,
>>>> - DSIM_TX_LPDT_LP - transmit data in LP mode.
>>> As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
>>> that host can transmit command and also image data to Panel in Low Power
>>> Mode. So these flags are specific to MIPI-DSI controller of Exynos.
>>>
>>>> The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
>>> This flag is set only when command msg transmission is requested by
>>> Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
>>> and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
>>> transmit command and also image.
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>> you use the latter?
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>>>  static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>>>>>  {
>>>>>  	u32 reg;
>>>>> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
>>>>>  {
>>>>>  	u32 reg;
>>>>>  
>>>>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
>>>>> +		exynos_dsi_enable_hs_clock(dsi, true);
>>>>> +
>>>>>  	reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>>>>>  	if (enable)
>>>>>  		reg |= DSIM_MAIN_STAND_BY;
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

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

Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Inki Dae]

On 2014년 07월 29일 22:16, Andrzej Hajda wrote:
> On 07/29/2014 02:08 PM, Inki Dae wrote:
>> On 2014년 07월 29일 20:39, Andrzej Hajda wrote:
>>> On 07/29/2014 05:42 AM, Inki Dae wrote:
>>>> On 2014년 07월 29일 00:50, Andrzej Hajda wrote:
>>>>> On 07/28/2014 04:00 AM, Inki Dae wrote:
>>>>>> This patch adds LPM transfer support for video or command data.
>>>>>>
>>>>>> With this patch, Exynos MIPI DSI controller can transfer command or
>>>>>> video data with HS or LP mode in accordance with mode_flags set
>>>>>> by LCD Panel driver.
>>>>>>
>>>>>> Changelog v2: Enable High Speed clock only in case of stand by request.
>>>>>>
>>>>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>>> ---
>>>>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 ++++++++++++++++++++--
>>>>>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>> index 5e78d45..1bed105 100644
>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
>>>>>>  			| DSIM_ESC_PRESCALER(esc_div)
>>>>>>  			| DSIM_LANE_ESC_CLK_EN_CLK
>>>>>>  			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>>>>>> -			| DSIM_BYTE_CLK_SRC(0)
>>>>>> -			| DSIM_TX_REQUEST_HSCLK;
>>>>>> +			| DSIM_BYTE_CLK_SRC(0);
>>>>>> +
>>>>>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>>>>>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>>>>>> +
>>>>>>  	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>>>  
>>>>>>  	return 0;
>>>>>> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
>>>>>>  	writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>>>>>>  }
>>>>>>  
>>>>>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>>>>>> +					bool enable)
>>>>>> +{
>>>>>> +	u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>>> +
>>>>>> +	reg &= ~DSIM_TX_REQUEST_HSCLK;
>>>>>> +	if (enable)
>>>>>> +		reg |= DSIM_TX_REQUEST_HSCLK;
>>>>>> +
>>>>>> +	writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>>> +}
>>>>>> +
>>>>> I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
>>>>> it works with and without the bit set.
>>>> If you can test thmorstat board, you will face with that its panel is
>>>> not worked.
>>> So it means this panel requires proper driving of this bit, but it does
>>> not prove it is
>>> LPM related.
>>>
>>>>> So I start to suspect this bit is not just for simply enable/disable HS
>>>>> clock as function name suggests, do you know what is its
>>>>> exact meaning? The specs are quite succinct on it.
>>>> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
>>> This sounds very strange. DSI specs and D-PHY specs says clearly
>>> that LPM transmissions are unrelated to HS clock [1][2]. Even timing
>>> diagrams
>>> in Exynos specs shows no dependency of LPM transmissions on HS clock.
>>> And the
>>> description of TxRequestHsClk bit says "HS clock request for HS transfer
>>> at clock lane (Turn
>>> on HS clock)".
>> There are three System power states of D-PHY, Low-Power mode, High-Speed
>> mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
>> Lane. Therefore, to use HS mode, HS clock should be enabled. On the
>> other hand, LP mode needs only 10MHz (max).
>>
>> So do you really think LP mode will be worked well with HS clock
>> enabled? The purpose of LP mode is to reduce power consumption while
>> transmitting data. Can you reduce the power consumption in LP mode with
>> HS clock enabled?
> 
> As MIPI specs says "All DSI transmitters and receivers shall support
> continuous clock
> behavior on the Clock Lane, and optionally may support non-continuous
> clock behavior"
> and "For continuous clock behavior, the Clock Lane remains in high-speed
> mode generating
> active clock signals between HS data packet transmissions".
> This means that HS clock should be on even in LP mode, unless panel
> supports non-continuous clock

We know what the spec says. As I mentioned already before and in other
threads, the important thing is how we should handle HS clock in
mipi-dsi framework and host driver.

To make sure that,
1. In case of supporting non-continuous clock mode, who should control
HS clock of host controller properly every time D-PHY detected LP-11? by
D-PHY hw regardless of host driver? So  in this case, doesn't the host
driver need to check MSG_LPM flag and to control HS clock before host
controller transmits command data in LPM?
One more thing, in this case, is the operation mode HS mode or LP mode
while transmitting command data - there would be LP-11 signal between
command packets and operation mode would be entered to LP mode only when
D-PHY detected LP-11? Therefore, If HS mode,
MIPI_DSI_CLOCK_NON_CONTINUOUS would have different operation from
MSG_LPM because command data will be transmitted to panel in HS mode,
not in LP mode.

2. In case of not supporting non-continuous clock mode but requesting
MSG_LPM, should the host driver check the flag and control HS clock
properly before host controller transmits command data in LPM?

Thanks,
Inki Dae

> behavior. For signaling non-continuous clock capability there is
> MIPI_DSI_CLOCK_NON_CONTINUOUS flag already.
> 
> Regards
> Andrzej
> 
>>
>> Thanks,
>> Inki Dae
>>
>>> Maybe different flag should be used to describe your panel requirements
>>> regarding this bit.
>>>
>>> It would be good to see the real initialization sequence in form of
>>> pseudo-code or better in the driver.
>>>
>>>
>>> [1]: MIPI DSI: "Note that in Low Power signaling mode, LP clock is
>>> functionally embedded in the data signals. When LP
>>> data transmission ends, the clock effectively stops and subsequent LP
>>> clocks are not available to the
>>> peripheral. The peripheral shall not require additional bits, bytes, or
>>> packets from the host processor in
>>> order to complete processing or pipeline movement of received data in LP
>>> mode transmissions. There are a
>>> variety of ways to meet this requirement. For example, the peripheral
>>> may generate its own clock or it may
>>> require the host processor to keep the HS serial clock running."
>>>
>>> [2]: MIPI D-PHY: "The data is self-clocked by the applied bit encoding
>>> and does not rely on the Clock Lane".
>>>
>>> Regards
>>> Andrzej
>>>
>>>>> On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
>>>>> in DSIM_ESCMODE register
>>>>> which seems to be related to flags you have introduced:
>>>>> - DSIM_CMD_LPDT_LP - transmit commands in LP mode,
>>>>> - DSIM_TX_LPDT_LP - transmit data in LP mode.
>>>> As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
>>>> that host can transmit command and also image data to Panel in Low Power
>>>> Mode. So these flags are specific to MIPI-DSI controller of Exynos.
>>>>
>>>>> The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
>>>> This flag is set only when command msg transmission is requested by
>>>> Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
>>>> and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
>>>> transmit command and also image.
>>>>
>>>> Thanks,
>>>> Inki Dae
>>>>
>>>>> you use the latter?
>>>>>
>>>>> Regards
>>>>> Andrzej
>>>>>
>>>>>>  static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>>>>>>  {
>>>>>>  	u32 reg;
>>>>>> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
>>>>>>  {
>>>>>>  	u32 reg;
>>>>>>  
>>>>>> +	if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
>>>>>> +		exynos_dsi_enable_hs_clock(dsi, true);
>>>>>> +
>>>>>>  	reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>>>>>>  	if (enable)
>>>>>>  		reg |= DSIM_MAIN_STAND_BY;
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 
>