[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
Inki Dae
inki.dae at samsung.com
Tue Aug 12 06:08:19 PDT 2014
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 at 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 at 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 at vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at 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 at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
More information about the dri-devel
mailing list