diff mbox

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

Message ID 20140805111223.GA27340@ulmo (mailing list archive)
State New, archived
Headers show

Commit Message

Thierry Reding Aug. 5, 2014, 11:12 a.m. UTC
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

Comments

Inki Dae Aug. 6, 2014, 7:11 a.m. UTC | #1
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
>
Thierry Reding Aug. 6, 2014, 7:43 a.m. UTC | #2
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
Inki Dae Aug. 6, 2014, 5:09 p.m. UTC | #3
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
>
Thierry Reding Aug. 7, 2014, 6:58 a.m. UTC | #4
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
Inki Dae Aug. 7, 2014, 7:51 a.m. UTC | #5
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
>
Thierry Reding Aug. 7, 2014, 9:09 a.m. UTC | #6
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
Inki Dae Aug. 7, 2014, 10:49 a.m. UTC | #7
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
>
Thierry Reding Aug. 7, 2014, 11:09 a.m. UTC | #8
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
Inki Dae Aug. 7, 2014, 1:05 p.m. UTC | #9
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
>
Thierry Reding Aug. 7, 2014, 1:17 p.m. UTC | #10
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
Inki Dae Aug. 7, 2014, 1:39 p.m. UTC | #11
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
>
Thierry Reding Aug. 7, 2014, 1:55 p.m. UTC | #12
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
Inki Dae Aug. 8, 2014, 1:45 a.m. UTC | #13
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
>
Thierry Reding Aug. 8, 2014, 7:03 a.m. UTC | #14
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
Inki Dae Aug. 8, 2014, 7:37 a.m. UTC | #15
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
>
Andrzej Hajda Aug. 8, 2014, 9:02 a.m. UTC | #16
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
>>
>
Andrzej Hajda Aug. 8, 2014, 9:40 a.m. UTC | #17
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
>
Thierry Reding Aug. 8, 2014, 9:55 a.m. UTC | #18
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
Inki Dae Aug. 11, 2014, 5:19 a.m. UTC | #19
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
>
Inki Dae Aug. 11, 2014, 7:09 a.m. UTC | #20
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
>
Thierry Reding Aug. 11, 2014, 7:24 a.m. UTC | #21
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
Inki Dae Aug. 11, 2014, 7:35 a.m. UTC | #22
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
>
Andrzej Hajda Aug. 11, 2014, 7:44 a.m. UTC | #23
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
>>
>
Thierry Reding Aug. 11, 2014, 7:50 a.m. UTC | #24
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
Inki Dae Aug. 11, 2014, 8:01 a.m. UTC | #25
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
>
Andrzej Hajda Aug. 11, 2014, 8:05 a.m. UTC | #26
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
>>>
Inki Dae Aug. 11, 2014, 8:15 a.m. UTC | #27
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
>
Thierry Reding Aug. 11, 2014, 9:11 a.m. UTC | #28
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
Inki Dae Aug. 12, 2014, 2:51 a.m. UTC | #29
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
>
YoungJun Cho Aug. 12, 2014, 11:54 a.m. UTC | #30
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
>
Inki Dae Aug. 12, 2014, 1:08 p.m. UTC | #31
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
>
diff mbox

Patch

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