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@xxxxxxxxx>: >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>>>> 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@xxxxxxxxxxxxxxxxxxxxx >>>> 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@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html