| Message ID | 20140805111223.GA27340@ulmo (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Thanks for comments. On 2014? 08? 05? 20:12, Thierry Reding wrote: > On Mon, Jul 28, 2014 at 06:09:58PM +0200, Andrzej Hajda wrote: >> On 07/28/2014 04:00 AM, Inki Dae wrote: >>> This patch adds below two flags for LPM transfer, and it attaches LPM flags >>> to a msg in accordance with master's mode_flags set by LCD Panel driver. >>> >>> MIPI_DSI_MODE_CMD_LPM >>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>> command data to Panel device in Low Power Mode. >> >> What do you mean by command data? It could be: >> - all transfer in command mode of operations, >> - transfer initialized by the driver by writing to DSIM registers. >> >>> >>> MIPI_DSI_MODE_VIDEO_LPM >>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>> image data to Panel device in Low Power Mode. >> >> What is the meaning of this flag in case of command mode of operation? >> >> Maybe it would be better to create flags based on source of data/FIFOs: >> - commands send by SFR registers, >> - commands generated from data sent from Display Controller. > > I have no idea what SFR is. But it sounds like you're talking about two > ways to generate command packets here. We have something similar on > Tegra, where it's called "host-driven command mode" and "DC-driven > command mode". > > In host-driven command mode the driver needs to explicitly program some > of the DSI controller registers to send command packets. This is > essentially a FIFO register and a control register to trigger > transmission and poll for completion. > > DC-driven command mode is typically used to update contents of a remote > framebuffer (what MIPI calls "Type 1 Display Architecture"). This is > done by programming a different set of registers that cause the DSI > controller to take data output by the display controller and wrap it > into DCS commands (e.g. write_memory_start and write_memory_continue). > Exynos also supports above two command mode but we have never used DC-driven command mode. > I think that low power mode is more often used for command transmission > (in host-driven mode). I'm not sure how much sense it really makes to > transmit video data in low power mode. It also seems like low power mode > is what all peripherals need to support (if they can do command mode). > Hence I'd like to propose the attached patch that makes all command > messages use low power mode. To use low power mode, I think SoC drivers should add more codes: checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does exactly that, http://www.spinics.net/lists/linux-samsung-soc/msg34866.html And what I and Andrzej don't make sure is non-continuous clock mode. Do you know how non-continuous clock mode is related to HS clock? > > The .transfer() function was really designed with initialization > commands in mind, so it doesn't deal with mixing video data and commands > anyway and for initialization low-power mode should be fast enough. The > downside is that it may not be optimal for some peripherals, but it > gives us a good solution for the general case since it should support > all devices. > > If we absolutely must have faster initialization, or if we come across a > device that can only initialize in high speed mode, then I think we > should introduce a new flag to allow DSI host controllers to optimize in > those cases. Originally, mipi-dsi framework enforces implicitly using HS mode for video and command data as default so I added LPM relevant flags - for video and also command data - for host driver can consider Low Power Mode. However, your patch makes it use Low Power Mode for command data as default. So your patch would mean that default transfer mode for command data is Low Power Mode, but HS mode for video data. Do you intend to control transfer mode - HS or LPM - only for command data? If so, we would need only one flag, i.e., MIPI_DSI_MODE_HS. Thanks, Inki Dae > > Note that this is based on some of my local patches, so it won't apply > as-is. But if anybody wants to give this a go it should be easy to apply > manually as well. > > Thierry > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 > -- 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
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
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 > -- 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
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
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 > -- 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
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
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 > -- 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
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
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 > -- 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
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
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 > -- 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
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
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 > -- 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
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 >> > -- 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
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 > -- 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
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
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 > -- 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
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 > -- 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
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
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 > -- 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
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 >> > -- 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
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
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 > -- 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
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 >>> -- 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
On 2014? 08? 11? 16:50, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: >> On 2014? 08? 11? 16:24, Thierry Reding wrote: >>> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: >>>> On 2014? 08? 08? 18:55, Thierry Reding wrote: > [...] >>>>> The above is actually more like this: >>>>> >>>>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) >>>>> clear DSI_HS_CLK_CTRL; >>>>> else >>>>> set DSI_HS_CLK_CTRL; >>>>> >>>>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) >>>>> clear DSI_HIGH_SPEED_TRANS; >>>>> else >>>>> set DSI_HIGH_SPEED_TRANS; >>>>> >>>>> So for peripherals that don't support non-continuous clock mode, this >>>>> will result in the following for low-power transmissions: >>>>> >>>>> clear DSI_HS_CLK_CTRL; /* HS clock always on */ >>>>> clear DSI_HIGH_SPEED_TRANS; >>>> >>>> Right, then how host driver should check it if peripheral doesn't >>>> support non-continuous clock mode? Or how the peripheral should notify >>>> it to host driver? It would need a new flag instead of >>>> MIPI_DSI_MODE_NON_CONTINUOUS. >>> >>> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to >>> set to signal that they support non-continuous mode. If devices don't >>> have that set, then the controller should always provide the HS clock. >>> >>> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral >>> does *not* support non-continuous mode. >>> >> >> Again, assume that there is a peripheral that doesn't support >> non-continuous clock mode but host driver want to transmit data in low >> power. For this, you already mentioned like below, >> >> "So for peripherals that don't support non-continuous clock mode, this >> will result in the following for low-power transmissions: >> >> clear DSI_HS_CLK_CTRL; /* HS clock always on */ >> clear DSI_HIGH_SPEED_TRANS; >> " >> >> In this case, how should host driver check it to clear above two flags? >> As you know, this is required to clear two flags same as non-continuous >> clock mode. Don't you think that we need a new flag to identify them - >> non-continuous clock mode or just for low-power transmission? > > See what I wrote a little further up: > >>>>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) >>>>> clear DSI_HS_CLK_CTRL; >>>>> else >>>>> set DSI_HS_CLK_CTRL; >>>>> >>>>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) >>>>> clear DSI_HIGH_SPEED_TRANS; >>>>> else >>>>> set DSI_HIGH_SPEED_TRANS; >>>>> > > MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- > continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because > that tells the controller to turn off the HS clock between high-speed > transmissions. > > MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power > mode. > > With the above two flags we can cover four cases: > > 1) non-continuous mode with messages transmitted in low-power mode > 2) non-continuous mode with messages transmitted in high-speed mode > 3) continuous mode with messages transmitted in low-power mode In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag..... Ah, right. You mean that continuous mode is set by default implicitly? Thanks, Inki Dae > 4) continuous mode with messages transmitted in high-speed mode > > What other cases do you think we need to support? > > Thierry > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 > -- 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
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 > -- 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
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 > -- 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
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