Re: [PATCH v2] ARM: EXYNOS: Refactor the pm code to use DT based lookup
Hi Kukjin,
On Fri, Jul 25, 2014 at 5:34 PM, Vikas Sajjan wrote:
> Refactoring the pm.c to avoid using "soc_is_exynos" checks,
> instead use the DT based lookup.
>
> While at it, consolidate the common code across SoCs
> and create a static helper functions.
>
> Signed-off-by: Vikas Sajjan
> ---
> changes since v1:
> - Address Kukjin Kim comments to respin this patch separately from
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/272574.html
> - removed panic, returned if no PMU node found and added check in
> exynos_wkup_irq.
>
Do you have any more comments.
> Rebased on Kukjin Kim's tree, for-next branch
>
> https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next
> ---
> arch/arm/mach-exynos/pm.c | 234
> ---
> arch/arm/mach-exynos/regs-pmu.h |1 +
> 2 files changed, 192 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> index c4c6d98..1c875e5 100644
> --- a/arch/arm/mach-exynos/pm.c
> +++ b/arch/arm/mach-exynos/pm.c
> @@ -36,6 +36,8 @@
> #include "regs-pmu.h"
> #include "regs-sys.h"
>
> +#define REG_TABLE_END (-1U)
> +
> /**
> * struct exynos_wkup_irq - Exynos GIC to PMU IRQ mapping
> * @hwirq: Hardware IRQ signal of the GIC
> @@ -59,6 +61,19 @@ static struct sleep_save exynos_core_save[] = {
> SAVE_ITEM(S5P_SROM_BC3),
> };
>
> +struct exynos_pm_data {
> + const struct exynos_wkup_irq *wkup_irq;
> + unsigned int wake_disable_mask;
> + unsigned int *release_ret_regs;
> +
> + void (*pm_prepare)(void);
> + void (*pm_resume)(void);
> + int (*pm_suspend)(void);
> + int (*cpu_suspend)(unsigned long);
> +};
> +
> +struct exynos_pm_data *pm_data;
> +
> /*
> * GIC wake-up support
> */
> @@ -77,14 +92,24 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[]
> = {
> { /* sentinel */ },
> };
>
> +unsigned int exynos_release_ret_regs[] = {
> + S5P_PAD_RET_MAUDIO_OPTION,
> + S5P_PAD_RET_GPIO_OPTION,
> + S5P_PAD_RET_UART_OPTION,
> + S5P_PAD_RET_MMCA_OPTION,
> + S5P_PAD_RET_MMCB_OPTION,
> + S5P_PAD_RET_EBIA_OPTION,
> + S5P_PAD_RET_EBIB_OPTION,
> + REG_TABLE_END,
> +};
> +
> static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
> {
> const struct exynos_wkup_irq *wkup_irq;
>
> - if (soc_is_exynos5250())
> - wkup_irq = exynos5250_wkup_irq;
> - else
> - wkup_irq = exynos4_wkup_irq;
> + if (!pm_data->wkup_irq)
> + return -ENOENT;
> + wkup_irq = pm_data->wkup_irq;
>
> while (wkup_irq->mask) {
> if (wkup_irq->hwirq == data->hwirq) {
> @@ -241,13 +266,13 @@ static void exynos_cpu_restore_register(void)
>
> static int exynos_cpu_suspend(unsigned long arg)
> {
> -#ifdef CONFIG_CACHE_L2X0
> - outer_flush_all();
> -#endif
> -
> - if (soc_is_exynos5250())
> - flush_cache_all();
> + if (pm_data->cpu_suspend)
> + return pm_data->cpu_suspend(arg);
> + return -1;
> +}
>
> +static int exynos_cpu_do_idle(void)
> +{
> /* issue the standby signal into the pm unit. */
> cpu_do_idle();
>
> @@ -257,32 +282,73 @@ static int exynos_cpu_suspend(unsigned long arg)
>
> static void exynos_pm_prepare(void)
> {
> - unsigned int tmp;
> + if (pm_data->pm_prepare)
> + pm_data->pm_prepare();
> +}
>
> +static int exynos4_cpu_suspend(unsigned long arg)
> +{
> +#ifdef CONFIG_CACHE_L2X0
> + outer_flush_all();
> +#endif
> + return exynos_cpu_do_idle();
> +}
> +
> +static int exynos5250_cpu_suspend(unsigned long arg)
> +{
> +#ifdef CONFIG_CACHE_L2X0
> + outer_flush_all();
> +#endif
> + flush_cache_all();
> + return exynos_cpu_do_idle();
> +}
> +
> +static void exynos_pm_set_wakeup_mask(void)
> +{
> /* Set wake-up mask registers */
> pmu_raw_writel(exynos_get_eint_wake_mask(), S5P_EINT_WAKEUP_MASK);
> pmu_raw_writel(exynos_irqwake_intmask & ~(1 << 31), S5P_WAKEUP_MASK);
> +}
>
> - s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
> -
> - if (soc_is_exynos5250()) {
> - s3c_pm_do_save(exynos5_sys_save,
> ARRAY_SIZE(exynos5_sys_save));
> - /* Disable USE_RETENTION of JPEG_MEM_OPTION */
> - tmp = pmu_raw_readl(EXYNOS5_JPEG_MEM_OPTION);
> - tmp &= ~EXYNOS5_OPTION_USE_RETENTION;
> - pmu_raw_writel(tmp, EXYNOS5_JPEG_MEM_OPTION);
> - }
> -
> +static void exynos_pm_enter_sleep_mode(void)
> +{
> /* Set value of power down register for sleep mode */
> -
> exynos_sys_powerdown_conf(SYS_SLEEP);
> pmu_raw_writel(S5P_CHECK_SLEEP, S5P_INFORM1);
>
> /* ensure at least INFORM0 has the resume address */
> -
> pmu_raw_writel(virt_to_phys(exynos_cpu_re
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Tomasz, On Fri, Aug 1, 2014 at 1:00 AM, Tomasz Figa wrote: > On 31.07.2014 21:25, Thomas Abraham wrote: >> On Fri, Aug 1, 2014 at 12:24 AM, Tomasz Figa wrote: >>> >>> >>> On 31.07.2014 20:40, Tomasz Figa wrote: Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: > On 07/30/14 17:07, Thomas Abraham wrote: >> The new CPU clock type allows the use of generic CPUfreq drivers. So for >> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, >> which did not have CPUfreq driver support, enable the use of generic >> CPUfreq driver. >> >> Suggested-by: Tomasz Figa >> Cc: Kukjin Kim > > Looks good to me, > > Acked-by: Kukjin Kim > > BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree. [1] ARM: dts: add CPU nodes for Exynos4 SoCs - https://lkml.org/lkml/2014/7/21/315 [2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt - http://www.spinics.net/lists/arm-kernel/msg351134.html >>> >>> Aha, I'm not quite sure we really want to hurry with this series for >>> 3.17. I'd prefer it to be picked up early after 3.17-rc1 shows up to sit >>> in linux-next for a while an be thoroughly tested on a number of boards. >> >> The v9 revision of this series has completed about 2 days of testing >> now on 4210/5250/5420 boards. I will let it run for few more days. For >> v8 and previous versions, the tests had completed 3 or more days. So I >> really don't think there is anything fundamentally wrong with this >> series. It would be nice to have this series merged and we start >> migrating other Exynos based boards to use generic cpufreq drivers. > > We have 22 Exynos-based boards currently supported in mainline. Is the > testing running on all of them? This is the purpose of linux-next and This series replaces existing cpufreq driver for Exynos4210 and Exynos5250 which impact 7 Exynos boards - Exynos4210 (smdk, origen, trats, universal), Exynos5250 (smdk, arndale, snow). Out of these, it is trats and universal that have not been tested. Which other 15 Exynos boards did you feel this series needs to be tested on? Sanity testing for Exynos4x12 cpufreq support was done on Exynos4412 Origen board. > for series that completely replace one driver with another I'd consider > this as the only reasonable choice, if not keeping the old driver for a > release. > > Of course we have never good testing traditions on Samsung SoC (see > OMAP and Tegra baseline tests), but does it mean that we shouldn't start > doing the right thing? Aren't Tegra/OMAP baseline tests for upstream kernel versions only, not for linux-next? Thanks, Thomas. > > Best regards, > Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Javier, On Sat, Aug 2, 2014 at 9:19 AM, Javier Martinez Canillas wrote: > Hello Thomas, > > On 07/30/2014 10:07 AM, Thomas Abraham wrote: >> For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU >> regulator supply properties for migrating from Exynos specific cpufreq driver >> to using generic cpufreq drivers. >> >> Cc: Kukjin Kim >> Cc: Doug Anderson >> Cc: Javier Martinez Canillas >> Cc: Andreas Faerber >> Cc: Sachin Kamat >> Signed-off-by: Thomas Abraham >> --- >> arch/arm/boot/dts/exynos4210-origen.dts |4 +++ >> arch/arm/boot/dts/exynos4210-trats.dts |4 +++ >> arch/arm/boot/dts/exynos4210-universal_c210.dts |4 +++ >> arch/arm/boot/dts/exynos4210.dtsi | 14 - >> arch/arm/boot/dts/exynos5250-arndale.dts|4 +++ >> arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++ >> arch/arm/boot/dts/exynos5250-snow.dts |4 +++ >> arch/arm/boot/dts/exynos5250.dtsi | 25 ++- >> arch/arm/boot/dts/exynos5420.dtsi | 38 >> +++ >> 9 files changed, 99 insertions(+), 2 deletions(-) >> > > Tested the series on a Exynos5420 based Peach Pit Chromebook by doing the > following for CPU0-3: > > 1) Verified that the big.LITTLE CPUFreq (arm-big-little) driver was reported > as > used in /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver. > > 2) Set all available governors (conservative, ondemand, userspace, powersave > and > performance). > > 3) Confirmed that cpuinfo_cur_freq and scaling_cur_freq values were fixed or > changing according to the selected governor policy. > > 4) Verified that the statistics in > /sys/devices/system/cpu/cpu*/cpufreq/stats/* > were filled. > > Everything is working correctly so please feel free to add for the whole > series: > > Tested-by: Javier Martinez Canillas Thank you for using this series and the details of what has worked. This is very helpful. Regards, Thomas. > > Best regards, > Javier > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drm/exynos: g2d: make ioctls more robust
On 2014년 08월 03일 18:52, Tobias Jakobi wrote: > Inki Dae wrote: >> It seems that you have no build test because above line incurs build >> error. Anyway I fixed it up. > That's why I have sent v2 of the patch. > Oops, sorry. I didn't check v2. Thanks, Inki Dae > With best wishes, > Tobias > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drm/exynos: g2d: make ioctls more robust
Inki Dae wrote: > It seems that you have no build test because above line incurs build > error. Anyway I fixed it up. That's why I have sent v2 of the patch. With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/15] drm/exynos: dsi: Add support for panel prepare and unprepare routines
2014-08-01 18:05 GMT+09:00 Thierry Reding : > On Thu, Jul 31, 2014 at 11:12:06PM +0530, Ajay Kumar wrote: >> Modify exynos_dsi driver to support the new panel calls: >> prepare and unprepare. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 12 ++-- >> 1 file changed, 10 insertions(+), 2 deletions(-) > > And this one as well. Acked-by: Inki Dae Thanks, Inki Dae > > Thierry > > ___ > dri-devel mailing list > dri-de...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drm/exynos: g2d: make ioctls more robust
2014-07-23 23:57 GMT+09:00 Tobias Jakobi :
> Both exynos_g2d_set_cmdlist_ioctl and exynos_g2d_exec_ioctl don't check
> if the G2D was succesfully probe. If that is not the case, then g2d_priv
> is just NULL and extracting 'dev' from it in the next step is going to
> produce a kernel oops.
>
> Add proper checks and return ENODEV if the G2D is not available.
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 5fa1bb6..8c62423 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1056,7 +1056,7 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
> *drm_dev, void *data,
> {
> struct drm_exynos_file_private *file_priv = file->driver_priv;
> struct exynos_drm_g2d_private *g2d_priv = file_priv->g2d_priv;
> - struct device *dev = g2d_priv->dev;
> + struct device *dev;
> struct g2d_data *g2d;
> struct drm_exynos_g2d_set_cmdlist *req = data;
> struct drm_exynos_g2d_cmd *cmd;
> @@ -1067,6 +1067,10 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
> *drm_dev, void *data,
> int size;
> int ret;
>
> + if (!g2d_priv)
> + return -ENODEV;
> +
> + dev = g2d_priv->dev;
> if (!dev)
> return -ENODEV;
>
> @@ -1223,13 +1227,17 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev,
> void *data,
> {
> struct drm_exynos_file_private *file_priv = file->driver_priv;
> struct exynos_drm_g2d_private *g2d_priv = file_priv->g2d_priv;
> - struct device *dev = g2d_priv->dev;
> + struct device *dev;
> struct g2d_data *g2d;
> struct drm_exynos_g2d_exec *req = data;
> struct g2d_runqueue_node *runqueue_node;
> struct list_head *run_cmdlist;
> struct list_head *event_list;
>
> + if (!g2d_priv)
> + return -ENODEV;
> +
> + dev = g2d_priv->dev
It seems that you have no build test because above line incurs build
error. Anyway I fixed it up.
Thanks,
Inki Dae
> if (!dev)
> return -ENODEV;
>
> --
> 1.8.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
2014-08-03 16:03 GMT+09:00 Inki Dae : > 2014-07-29 19:23 GMT+09:00 Andrzej Hajda : >> On 07/29/2014 02:57 AM, YoungJun Cho wrote: >>> Hi Andrzej, >>> >>> On 07/29/2014 01:09 AM, Andrzej Hajda wrote: On 07/28/2014 04:00 AM, Inki Dae wrote: > This patch adds below two flags for LPM transfer, and it attaches LPM > flags > to a msg in accordance with master's mode_flags set by LCD Panel driver. > > MIPI_DSI_MODE_CMD_LPM > - If this flag is set by Panel driver, MIPI-DSI controller will tranfer > command data to Panel device in Low Power Mode. What do you mean by command data? It could be: - all transfer in command mode of operations, - transfer initialized by the driver by writing to DSIM registers. >>> The 2nd one. >>> > MIPI_DSI_MODE_VIDEO_LPM > - If this flag is set by Panel driver, MIPI-DSI controller will tranfer > image data to Panel device in Low Power Mode. What is the meaning of this flag in case of command mode of operation? >>> I'm also not sure that there is a case to transfer image data in Low >>> Power Mode, but this flag is not related with 'command mode' only. >>> Inki may consider generic condition. >>> Maybe it would be better to create flags based on source of data/FIFOs: - commands send by SFR registers, - commands generated from data sent from Display Controller. > And above two flags can be combined together to transfer command and video > data to Panel device. > > MIPI DSI spec says, > "the host processor controls the desired mode of clock operation. >Host protocol and applications control Clock Lane operating mode >(High Speed or Low Power mode). System designers are responsible >for understanding the clock requirements for peripherals attached >to DSI and controlling clock behavior in accordance with those >requirements." > > Some LCD Panel devices, nt35502a, would need LPM transfer support > because they should receive some initial commands with LPM by default > hardware setting. Is this requirement for initial commands, or for all commands. Btw what is the mode of operation of nt35502a? What flags do you need for it? >>> The nt35502a panel is video(RGB) mode panel and it requires low power >>> mode for initial commands, which means to initialize nt35502a panel, the >>> initial commands are transferred by LP mode(Not HS mode). >>> And after initialization, its other features like gamma control or etc >>> could be controlled in HS mode. >> >> It sounds similar to my tc358764 bridge driver [1]. The difference is that >> it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM. >> >> As I understand nt35502a requires also different driving of >> TxRequestHSClk signal >> and this seems to me unrelated to LPM. As LPM is not related at all with >> HS clock, AFAIK. >> > > + Tomi Valkeinen > > At private talks before, I think we reached the following consensus, > > 1. D-PHY could disable HS clock of MIPI-DSI controller in case that > D-PHY detectsTransition to Stop state (LP=11) and TxRequestHSClk bit > of MIPI-DSI controller is set, which means that Panel driver set > MIPI_DSI_CLOCK_NON_CONTINUOUS flag. > > 2. Lower Power Mode means that the state of HS clock is low, Positive > and Negative lane are all low, LP-11 state. > > However, it seems some misunderstanding each other. > > I guess that non-contiguous clock mode - TxRequestHSCllk bit is set or > maybe unset - would mean that HS clock is high while MIPI-DSI > controller transmits data to Panel until D-PHY detects LP-11 state. Or with non-contiguous clock mode, data may be transmistted to Panel in LPM (HS clock is low and LP-11) after D-PHY detects LP-11 state. To make sure this, I will try to test that Panel - requiring LPM transfer for initial commands as default hw setting - works well with non-contiguous clock mode. In this cae, it seems that we need to consider HW that supports non-continuous clock mode. Thanks, Inki Dae > Therefore, I think LPM is different from non-contiguous clock mode, > and I think with LPM flag, host driver - for MIPI-DSI device - should > disable HS clock to transmit data to Panel. So I think HS clock is > related to LPM. > > Anyway, we all are not sure how D-PHY handles HS clock of MIPI-DSI > controller. So we would need more comments from HW guy or > specitialists of MIPI-DSI to make sure. I think Tomi Valkeinen would > be one of the specitialists. > > Hi Tomi, > Could you give us some comments about this? Is HS clock unrelated to > Low Power Mode at all? And do you know D-PHY handle HS clock of > MIPI-DSI controller with non-contigous clock mode? > > Thanks, > Inki Dae > >> Regards >> Andrzej >> >> [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 >> >> >>> >>> Thank you. >>> Best regards YJ >>> > Changelog v2: just add more descriptions. > > Signed-off-b
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
2014-07-29 19:23 GMT+09:00 Andrzej Hajda : > On 07/29/2014 02:57 AM, YoungJun Cho wrote: >> Hi Andrzej, >> >> On 07/29/2014 01:09 AM, Andrzej Hajda wrote: >>> On 07/28/2014 04:00 AM, Inki Dae wrote: This patch adds below two flags for LPM transfer, and it attaches LPM flags to a msg in accordance with master's mode_flags set by LCD Panel driver. MIPI_DSI_MODE_CMD_LPM - If this flag is set by Panel driver, MIPI-DSI controller will tranfer command data to Panel device in Low Power Mode. >>> What do you mean by command data? It could be: >>> - all transfer in command mode of operations, >>> - transfer initialized by the driver by writing to DSIM registers. >> The 2nd one. >> MIPI_DSI_MODE_VIDEO_LPM - If this flag is set by Panel driver, MIPI-DSI controller will tranfer image data to Panel device in Low Power Mode. >>> What is the meaning of this flag in case of command mode of operation? >> I'm also not sure that there is a case to transfer image data in Low >> Power Mode, but this flag is not related with 'command mode' only. >> Inki may consider generic condition. >> >>> Maybe it would be better to create flags based on source of data/FIFOs: >>> - commands send by SFR registers, >>> - commands generated from data sent from Display Controller. >>> >>> And above two flags can be combined together to transfer command and video data to Panel device. MIPI DSI spec says, "the host processor controls the desired mode of clock operation. Host protocol and applications control Clock Lane operating mode (High Speed or Low Power mode). System designers are responsible for understanding the clock requirements for peripherals attached to DSI and controlling clock behavior in accordance with those requirements." Some LCD Panel devices, nt35502a, would need LPM transfer support because they should receive some initial commands with LPM by default hardware setting. >>> >>> Is this requirement for initial commands, or for all commands. >>> Btw what is the mode of operation of nt35502a? What flags do you need >>> for it? >>> >> The nt35502a panel is video(RGB) mode panel and it requires low power >> mode for initial commands, which means to initialize nt35502a panel, the >> initial commands are transferred by LP mode(Not HS mode). >> And after initialization, its other features like gamma control or etc >> could be controlled in HS mode. > > It sounds similar to my tc358764 bridge driver [1]. The difference is that > it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM. > > As I understand nt35502a requires also different driving of > TxRequestHSClk signal > and this seems to me unrelated to LPM. As LPM is not related at all with > HS clock, AFAIK. > + Tomi Valkeinen At private talks before, I think we reached the following consensus, 1. D-PHY could disable HS clock of MIPI-DSI controller in case that D-PHY detectsTransition to Stop state (LP=11) and TxRequestHSClk bit of MIPI-DSI controller is set, which means that Panel driver set MIPI_DSI_CLOCK_NON_CONTINUOUS flag. 2. Lower Power Mode means that the state of HS clock is low, Positive and Negative lane are all low, LP-11 state. However, it seems some misunderstanding each other. I guess that non-contiguous clock mode - TxRequestHSCllk bit is set or maybe unset - would mean that HS clock is high while MIPI-DSI controller transmits data to Panel until D-PHY detects LP-11 state. Therefore, I think LPM is different from non-contiguous clock mode, and I think with LPM flag, host driver - for MIPI-DSI device - should disable HS clock to transmit data to Panel. So I think HS clock is related to LPM. Anyway, we all are not sure how D-PHY handles HS clock of MIPI-DSI controller. So we would need more comments from HW guy or specitialists of MIPI-DSI to make sure. I think Tomi Valkeinen would be one of the specitialists. Hi Tomi, Could you give us some comments about this? Is HS clock unrelated to Low Power Mode at all? And do you know D-PHY handle HS clock of MIPI-DSI controller with non-contigous clock mode? Thanks, Inki Dae > Regards > Andrzej > > [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 > > >> >> Thank you. >> Best regards YJ >> >>> Changelog v2: just add more descriptions. Signed-off-by: Inki Dae Acked-by: Kyungmin Park --- drivers/gpu/drm/drm_mipi_dsi.c |3 +++ include/drm/drm_mipi_dsi.h |4 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index e633df2..6b2bbda 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, unsigned int channel, break; } + if (dsi->mode_flags & MIPI_DSI_MODE_CM
