[RFC v2 PATCH 00/14] drm/exynos: support MIPI DSI command mode display

[RFC v2 PATCH 00/14] drm/exynos: support MIPI DSI command mode display

[YoungJun Cho]

This patch series includes the followings:
- FIMD I80 interface
- DSI command mode interface for Exynos5420 SoC
- S6E3FA0 command mode type panel driver
- Some bugs modification

The patch series is based on exynos-drm-next branch.

Previous patch set,
RFC v1: http://www.spinics.net/lists/dri-devel/msg57513.html

Changelog v2:
- Moves panel delays and size DT properties to panel probe routine.
- Moves CPU timings relevant DT properties from FIMD to panel DT.

Thank you.
Best regards YJ

YoungJun Cho (14):
  drm/exynos: dsi: move the Eot packets configuration point
  drm/exynos: dsi: delay setting clocks after reset
  drm/exynos: use wait_event_timeout() for safety usage
  ARM: dts: sysreg: add exynos5 compatible to DT bindings
  ARM: dts: samsung-fimd: add I80 specific properties
  drm/exynos: support MIPI DSI command mode
  ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings
  drm/exynos: dsi: add driver data to support Exynos5420
  ARM: dts: s6e3fa0: add DT bindings
  drm/panel: add S6E3FA0 driver
  ARM: dts: exynos4: add system register node
  ARM: dts: exynos5: add system register support
  ARM: dts: exynos5420: add mipi-phy node
  ARM: dts: exynos5420: add dsi node

 .../devicetree/bindings/arm/samsung/sysreg.txt     |    1 +
 .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 +++
 .../devicetree/bindings/video/exynos_dsim.txt      |    4 +-
 .../devicetree/bindings/video/samsung-fimd.txt     |    2 +
 arch/arm/boot/dts/exynos4.dtsi                     |    1 +
 arch/arm/boot/dts/exynos5.dtsi                     |    6 +
 arch/arm/boot/dts/exynos5420.dtsi                  |   21 +
 drivers/gpu/drm/exynos/Kconfig                     |    1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c           |   16 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h           |    2 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h            |    2 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c            |  121 ++++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c           |  280 ++++++++--
 drivers/gpu/drm/panel/Kconfig                      |    7 +
 drivers/gpu/drm/panel/Makefile                     |    1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c              |  569 ++++++++++++++++++++
 include/drm/drm_mipi_dsi.h                         |    2 +
 include/drm/drm_panel.h                            |    7 +
 include/video/samsung_fimd.h                       |    3 +-
 19 files changed, 1038 insertions(+), 71 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

-- 
1.7.9.5

[RFC v2 PATCH 01/14] drm/exynos: dsi: move the Eot packets configuration point

[YoungJun Cho]

This configuration could be used in MIPI DSI command mode also.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eb73e3b..956e5f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -472,8 +472,6 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 
 		if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
 			reg |= DSIM_MFLUSH_VS;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
-			reg |= DSIM_EOT_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
 			reg |= DSIM_SYNC_INFORM;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
@@ -490,6 +488,9 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 			reg |= DSIM_HSA_MODE;
 	}
 
+	if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
+		reg |= DSIM_EOT_DISABLE;
+
 	switch (dsi->format) {
 	case MIPI_DSI_FMT_RGB888:
 		reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
-- 
1.7.9.5

[RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[YoungJun Cho]

Some phy control registers are not kept after software reset.
So this patch makes the clocks containing phy control to be set
after software reset.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..2cf1f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
 
 static int exynos_dsi_init(struct exynos_dsi *dsi)
 {
-	exynos_dsi_enable_clock(dsi);
 	exynos_dsi_reset(dsi);
 	enable_irq(dsi->irq);
 	exynos_dsi_wait_for_reset(dsi);
+	exynos_dsi_enable_clock(dsi);
 	exynos_dsi_init_link(dsi);
 
 	return 0;
-- 
1.7.9.5

Re: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[Andrzej Hajda]

Hi YoungJun,

On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> Some phy control registers are not kept after software reset.
> So this patch makes the clocks containing phy control to be set
> after software reset.
>
> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> Acked-by: Inki Dae <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 956e5f3..2cf1f0b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
>  
>  static int exynos_dsi_init(struct exynos_dsi *dsi)
>  {
> -	exynos_dsi_enable_clock(dsi);
>  	exynos_dsi_reset(dsi);
>  	enable_irq(dsi->irq);
>  	exynos_dsi_wait_for_reset(dsi);
> +	exynos_dsi_enable_clock(dsi);
>  	exynos_dsi_init_link(dsi);
>  
>  	return 0;

I have commented it in the previous version of the patchset. I repeat it
again.
This is a regression, on exynos4210-trats I have 'timeout waiting for
reset' message after dpms off, on.

I will comment your previous answer here to make the discussion easier:
> As I mentioned in description, it came from phy control registers.
> Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
> DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
> affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
>
> So this patch is required for Exynos5 SoCs.

In the moment this patch is applied exynos_dsi_set_pll do not touch phy
registers you have mentioned.
Your change would be more clear if it will be merged together with the
patch adding PHYCTRL settings.

Anyway, solution is simple - please set PHY registers after reset and
configure clocks before reset to avoid
reset timeouts, is there any reason to not do it this way?

Regards
Andrzej

Re: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[YoungJun Cho]

Hi Andrzej

Thank you for comments.

On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
> Hi YoungJun,
>
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>> Some phy control registers are not kept after software reset.
>> So this patch makes the clocks containing phy control to be set
>> after software reset.
>>
>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>> Acked-by: Inki Dae <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 956e5f3..2cf1f0b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
>>
>>   static int exynos_dsi_init(struct exynos_dsi *dsi)
>>   {
>> -	exynos_dsi_enable_clock(dsi);
>>   	exynos_dsi_reset(dsi);
>>   	enable_irq(dsi->irq);
>>   	exynos_dsi_wait_for_reset(dsi);
>> +	exynos_dsi_enable_clock(dsi);
>>   	exynos_dsi_init_link(dsi);
>>
>>   	return 0;
>
> I have commented it in the previous version of the patchset. I repeat it
> again.
> This is a regression, on exynos4210-trats I have 'timeout waiting for
> reset' message after dpms off, on.

I'm really sorry for that. I misunderstood last time.

I think the original codes were correct, because the reset timeout would
be occurred without clock activation.

I'll check and fix again.
(By the way, why am I ok?)

>
> I will comment your previous answer here to make the discussion easier:
>> As I mentioned in description, it came from phy control registers.
>> Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
>> DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
>> affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
>>
>> So this patch is required for Exynos5 SoCs.
>
> In the moment this patch is applied exynos_dsi_set_pll do not touch phy
> registers you have mentioned.
> Your change would be more clear if it will be merged together with the
> patch adding PHYCTRL settings.
>
> Anyway, solution is simple - please set PHY registers after reset and
> configure clocks before reset to avoid
> reset timeouts, is there any reason to not do it this way?

The only reason is that the PHY control is related with PLL control and
that was in exynos_dsi_enable_clock() call path.
So I just wanted to keep current sequence.

If there is no way to use previous one, I'll consider your approach.

Thank you.
Best regards YJ

>
> Regards
> Andrzej
>

Re: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[YoungJun Cho]

Hi again Andrzej,

On 04/23/2014 10:01 AM, YoungJun Cho wrote:
> Hi Andrzej
>
> Thank you for comments.
>
> On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
>> Hi YoungJun,
>>
>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>> Some phy control registers are not kept after software reset.
>>> So this patch makes the clocks containing phy control to be set
>>> after software reset.
>>>
>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>> ---
>>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c |    2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index 956e5f3..2cf1f0b 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void
>>> *dev_id)
>>>
>>>   static int exynos_dsi_init(struct exynos_dsi *dsi)
>>>   {
>>> -    exynos_dsi_enable_clock(dsi);
>>>       exynos_dsi_reset(dsi);
>>>       enable_irq(dsi->irq);
>>>       exynos_dsi_wait_for_reset(dsi);
>>> +    exynos_dsi_enable_clock(dsi);
>>>       exynos_dsi_init_link(dsi);
>>>
>>>       return 0;
>>
>> I have commented it in the previous version of the patchset. I repeat it
>> again.
>> This is a regression, on exynos4210-trats I have 'timeout waiting for
>> reset' message after dpms off, on.
>
> I'm really sorry for that. I misunderstood last time.
>
> I think the original codes were correct, because the reset timeout would
> be occurred without clock activation.

This is not true.

>
> I'll check and fix again.
> (By the way, why am I ok?)

I have not verified with exynos4210-trats board yet(I have to get it),
but reset timeout is occured in exynos_dsi_wait_for_reset()
with &dsi->completed and that is completed by exynos_dsi_irq().

And the regulators and clocks are enabled by exynos_dsi_poweron(),
NOT by exynos_dsi_enable_clock().

So I think the reset timeout is not related with this patch.

Anyway I need more investigation.

Thank you.
Best regards YJ

>
>>
>> I will comment your previous answer here to make the discussion easier:
>>> As I mentioned in description, it came from phy control registers.
>>> Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
>>> DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
>>> affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
>>>
>>> So this patch is required for Exynos5 SoCs.
>>
>> In the moment this patch is applied exynos_dsi_set_pll do not touch phy
>> registers you have mentioned.
>> Your change would be more clear if it will be merged together with the
>> patch adding PHYCTRL settings.
>>
>> Anyway, solution is simple - please set PHY registers after reset and
>> configure clocks before reset to avoid
>> reset timeouts, is there any reason to not do it this way?
>
> The only reason is that the PHY control is related with PLL control and
> that was in exynos_dsi_enable_clock() call path.
> So I just wanted to keep current sequence.
>
> If there is no way to use previous one, I'll consider your approach.
>
> Thank you.
> Best regards YJ
>
>>
>> Regards
>> Andrzej
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[Andrzej Hajda]

On 04/23/2014 05:45 AM, YoungJun Cho wrote:
> Hi again Andrzej,
> 
> On 04/23/2014 10:01 AM, YoungJun Cho wrote:
>> Hi Andrzej
>>
>> Thank you for comments.
>>
>> On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
>>> Hi YoungJun,
>>>
>>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>>> Some phy control registers are not kept after software reset.
>>>> So this patch makes the clocks containing phy control to be set
>>>> after software reset.
>>>>
>>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>> ---
>>>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c |    2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> index 956e5f3..2cf1f0b 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> @@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void
>>>> *dev_id)
>>>>
>>>>   static int exynos_dsi_init(struct exynos_dsi *dsi)
>>>>   {
>>>> -    exynos_dsi_enable_clock(dsi);
>>>>       exynos_dsi_reset(dsi);
>>>>       enable_irq(dsi->irq);
>>>>       exynos_dsi_wait_for_reset(dsi);
>>>> +    exynos_dsi_enable_clock(dsi);
>>>>       exynos_dsi_init_link(dsi);
>>>>
>>>>       return 0;
>>>
>>> I have commented it in the previous version of the patchset. I repeat it
>>> again.
>>> This is a regression, on exynos4210-trats I have 'timeout waiting for
>>> reset' message after dpms off, on.
>>
>> I'm really sorry for that. I misunderstood last time.
>>
>> I think the original codes were correct, because the reset timeout would
>> be occurred without clock activation.
> 
> This is not true.
> 
>>
>> I'll check and fix again.
>> (By the way, why am I ok?)
> 
> I have not verified with exynos4210-trats board yet(I have to get it),
> but reset timeout is occured in exynos_dsi_wait_for_reset()
> with &dsi->completed and that is completed by exynos_dsi_irq().
> 
> And the regulators and clocks are enabled by exynos_dsi_poweron(),
> NOT by exynos_dsi_enable_clock().
> 
> So I think the reset timeout is not related with this patch.


As far as I remember there were at least two issues with init sequence:
- spurious irq storm after power on and before reset,
- irq reset timeouts after reset and without enabled clock.

The current sequence is a result of tests on live hw (documentation were
not helpful in this case). I think it could be improved little bit more
by moving exynos_dsi_enable_clock just after enable_irq this will
eliminate possible timeout when RST_RELEASE irq is signaled but irq is
still disabled. The sequence should look like below:

	exynos_dsi_reset(dsi);
	enable_irq(dsi->irq);
	exynos_dsi_enable_clock(dsi);
	exynos_dsi_wait_for_reset(dsi);
	exynos_dsi_init_link(dsi);

And PHY related configuration could be put somewhere after
exynos_dsi_wait_for_reset.

I have tested this sequence on trats, it seems to be OK.

Regards
Andrzej


> 
> Anyway I need more investigation.
> 
> Thank you.
> Best regards YJ
> 
>>
>>>
>>> I will comment your previous answer here to make the discussion easier:
>>>> As I mentioned in description, it came from phy control registers.
>>>> Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
>>>> DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
>>>> affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
>>>>
>>>> So this patch is required for Exynos5 SoCs.
>>>
>>> In the moment this patch is applied exynos_dsi_set_pll do not touch phy
>>> registers you have mentioned.
>>> Your change would be more clear if it will be merged together with the
>>> patch adding PHYCTRL settings.
>>>
>>> Anyway, solution is simple - please set PHY registers after reset and
>>> configure clocks before reset to avoid
>>> reset timeouts, is there any reason to not do it this way?
>>
>> The only reason is that the PHY control is related with PLL control and
>> that was in exynos_dsi_enable_clock() call path.
>> So I just wanted to keep current sequence.
>>
>> If there is no way to use previous one, I'll consider your approach.
>>
>> Thank you.
>> Best regards YJ
>>
>>>
>>> Regards
>>> Andrzej
>>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> 

Re: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[YoungJun Cho]

Hi Andrzej,

Thank you for the comments.

On 04/23/2014 04:37 PM, Andrzej Hajda wrote:
> On 04/23/2014 05:45 AM, YoungJun Cho wrote:
>> Hi again Andrzej,
>>
>> On 04/23/2014 10:01 AM, YoungJun Cho wrote:
>>> Hi Andrzej
>>>
>>> Thank you for comments.
>>>
>>> On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
>>>> Hi YoungJun,
>>>>
>>>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>>>> Some phy control registers are not kept after software reset.
>>>>> So this patch makes the clocks containing phy control to be set
>>>>> after software reset.
>>>>>
>>>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>> ---
>>>>>    drivers/gpu/drm/exynos/exynos_drm_dsi.c |    2 +-
>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> index 956e5f3..2cf1f0b 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> @@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void
>>>>> *dev_id)
>>>>>
>>>>>    static int exynos_dsi_init(struct exynos_dsi *dsi)
>>>>>    {
>>>>> -    exynos_dsi_enable_clock(dsi);
>>>>>        exynos_dsi_reset(dsi);
>>>>>        enable_irq(dsi->irq);
>>>>>        exynos_dsi_wait_for_reset(dsi);
>>>>> +    exynos_dsi_enable_clock(dsi);
>>>>>        exynos_dsi_init_link(dsi);
>>>>>
>>>>>        return 0;
>>>>
>>>> I have commented it in the previous version of the patchset. I repeat it
>>>> again.
>>>> This is a regression, on exynos4210-trats I have 'timeout waiting for
>>>> reset' message after dpms off, on.
>>>
>>> I'm really sorry for that. I misunderstood last time.
>>>
>>> I think the original codes were correct, because the reset timeout would
>>> be occurred without clock activation.
>>
>> This is not true.
>>
>>>
>>> I'll check and fix again.
>>> (By the way, why am I ok?)
>>
>> I have not verified with exynos4210-trats board yet(I have to get it),
>> but reset timeout is occured in exynos_dsi_wait_for_reset()
>> with &dsi->completed and that is completed by exynos_dsi_irq().
>>
>> And the regulators and clocks are enabled by exynos_dsi_poweron(),
>> NOT by exynos_dsi_enable_clock().
>>
>> So I think the reset timeout is not related with this patch.
>
>
> As far as I remember there were at least two issues with init sequence:
> - spurious irq storm after power on and before reset,
> - irq reset timeouts after reset and without enabled clock.
>
> The current sequence is a result of tests on live hw (documentation were
> not helpful in this case). I think it could be improved little bit more
> by moving exynos_dsi_enable_clock just after enable_irq this will
> eliminate possible timeout when RST_RELEASE irq is signaled but irq is
> still disabled. The sequence should look like below:
>
> 	exynos_dsi_reset(dsi);
> 	enable_irq(dsi->irq);
> 	exynos_dsi_enable_clock(dsi);
> 	exynos_dsi_wait_for_reset(dsi);
> 	exynos_dsi_init_link(dsi);
>
> And PHY related configuration could be put somewhere after
> exynos_dsi_wait_for_reset.
>
> I have tested this sequence on trats, it seems to be OK.

It also works well in Exynos5420 target.

I think it would be better to remove this patch and implement new PHY
control functions with this modification.

Thank you.
Best regards YJ

>
> Regards
> Andrzej
>
>
>>
>> Anyway I need more investigation.
>>
>> Thank you.
>> Best regards YJ
>>
>>>
>>>>
>>>> I will comment your previous answer here to make the discussion easier:
>>>>> As I mentioned in description, it came from phy control registers.
>>>>> Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
>>>>> DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
>>>>> affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
>>>>>
>>>>> So this patch is required for Exynos5 SoCs.
>>>>
>>>> In the moment this patch is applied exynos_dsi_set_pll do not touch phy
>>>> registers you have mentioned.
>>>> Your change would be more clear if it will be merged together with the
>>>> patch adding PHYCTRL settings.
>>>>
>>>> Anyway, solution is simple - please set PHY registers after reset and
>>>> configure clocks before reset to avoid
>>>> reset timeouts, is there any reason to not do it this way?
>>>
>>> The only reason is that the PHY control is related with PLL control and
>>> that was in exynos_dsi_enable_clock() call path.
>>> So I just wanted to keep current sequence.
>>>
>>> If there is no way to use previous one, I'll consider your approach.
>>>
>>> Thank you.
>>> Best regards YJ
>>>
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>
>

[RFC v2 PATCH 03/14] drm/exynos: use wait_event_timeout() for safety usage

[YoungJun Cho]

There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.

Signed-off-by: YoungJun Cho <yj44.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Acked-by: Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Acked-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e930d4f..1419d11 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,9 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
 
 	if (mode > DRM_MODE_DPMS_ON) {
 		/* wait for the completion of page flip. */
-		wait_event(exynos_crtc->pending_flip_queue,
-				atomic_read(&exynos_crtc->pending_flip) == 0);
+		wait_event_timeout(exynos_crtc->pending_flip_queue,
+				!atomic_read(&exynos_crtc->pending_flip),
+				HZ/20);
 		drm_vblank_off(crtc->dev, exynos_crtc->pipe);
 	}
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 PATCH v2 04/14] ARM: dts: sysreg: add exynos5 compatible to DT bindings

[YoungJun Cho]

This patch adds relevant to exynos5 compatible for exynos5 SoCs.

Changelog v2:
- Changes title and description (commented by Sachin Kamat)

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 .../devicetree/bindings/arm/samsung/sysreg.txt     |    1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
index 0ab3251..fd71581 100644
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -3,6 +3,7 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
 Properties:
  - compatible : should contain "samsung,<chip name>-sysreg", "syscon";
    For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
+   For Exynos5 SoC series it should be "samsung,exynos5-sysreg", "syscon";
  - reg : offset and length of the register set.
 
 Example:
-- 
1.7.9.5

[RFC v2 PATCH v3 05/14] ARM: dts: samsung-fimd: add I80 specific properties

[YoungJun Cho]

In case of using CPU interface panel, the relevant registers should be set.
So this patch adds relevant dt bindings.

Changelog v2:
- Changes "samsung,sysreg-phandle" to "samsung,sysreg"
Changelog v3:
- Moves CPU timings relevant properties to panel DT
  (commented by Laurent Pinchart, Andrzej Hajda)

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 .../devicetree/bindings/video/samsung-fimd.txt     |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..6bf93e9 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -44,6 +44,8 @@ Optional Properties:
 - display-timings: timing settings for FIMD, as described in document [1].
 		Can be used in case timings cannot be provided otherwise
 		or to override timings provided by the panel.
+- samsung,sysreg: handle to syscon used to control the system registers
+- vidout-i80-ldi: boolean to support i80 interface instead of rgb one
 
 The device node can contain 'port' child nodes according to the bindings defined
 in [2]. The following are properties specific to those nodes:
-- 
1.7.9.5

[RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[YoungJun Cho]

This patch adds I80 interface for FIMD to support command mode panel.

For this, the below features are added:
- Sets display interface mode relevant registers properly according to the
  interface type from DT
- Adds drm_panel_cpu_timings structure
 . The command mode panel sets them as the private attributes in struct
   drm_display_mode and FIMD gets them by fimd_mode_set().
- Adds TE interrupt handler
  . FIMD driver should know TE signal from lcd panel to avoid tearing issue.
- Adds trigger feature
  . In case of command mode panel, FIMD should set trigger bit,
    so that image data has to be transferred to display bus or lcd panel.

Changelog v2:
- Moves CPU timings relevant properties to panel DT
  (commented by Laurent Pinchart, Andrzej Hajda)

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/gpu/drm/exynos/Kconfig           |    1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   11 ++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |    2 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |    2 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |  280 +++++++++++++++++++++++++-----
 include/drm/drm_mipi_dsi.h               |    2 +
 include/drm/drm_panel.h                  |    7 +
 include/video/samsung_fimd.h             |    3 +-
 9 files changed, 277 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 5bf5bca..f4d34f0 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -28,6 +28,7 @@ config DRM_EXYNOS_FIMD
 	bool "Exynos DRM FIMD"
 	depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
 	select FB_MODE_HELPERS
+	select MFD_SYSCON
 	help
 	  Choose this option if you want to use Exynos FIMD for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 1419d11..d902d64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -491,3 +491,14 @@ void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb)
 			manager->ops->wait_for_vblank(manager);
 	}
 }
+
+int exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
+{
+	struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
+	int ret = 0;
+
+	if (manager->ops->te_handler)
+		ret = manager->ops->te_handler(manager);
+
+	return ret;
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index c27b66c..8482df2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -32,4 +32,6 @@ void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos);
 void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos);
 void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos);
 
+int exynos_drm_crtc_te_handler(struct drm_crtc *crtc);
+
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c5cf68..7cb0baf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -186,6 +186,7 @@ struct exynos_drm_display {
  * @win_commit: apply hardware specific overlay data to registers.
  * @win_enable: enable hardware specific overlay.
  * @win_disable: disable hardware specific overlay.
+ * @te_handler: call driver specific TE handler callback.
  */
 struct exynos_drm_manager;
 struct exynos_drm_manager_ops {
@@ -207,6 +208,7 @@ struct exynos_drm_manager_ops {
 	void (*win_commit)(struct exynos_drm_manager *mgr, int zpos);
 	void (*win_enable)(struct exynos_drm_manager *mgr, int zpos);
 	void (*win_disable)(struct exynos_drm_manager *mgr, int zpos);
+	int (*te_handler)(struct exynos_drm_manager *mgr);
 };
 
 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2cf1f0b..179f2fa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -23,6 +23,7 @@
 #include <video/mipi_display.h>
 #include <video/videomode.h>
 
+#include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"
 
 /* returns true iff both arguments logically differs */
@@ -1032,10 +1033,22 @@ static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
 	return (ret < 0) ? ret : xfer.rx_done;
 }
 
+static int exynos_dsi_host_te_handler(struct mipi_dsi_host *host)
+{
+	struct exynos_dsi *dsi = host_to_dsi(host);
+	struct drm_encoder *encoder = dsi->encoder;
+
+	if (!(dsi->state & DSIM_STATE_ENABLED))
+		return -EPERM;
+
+	return exynos_drm_crtc_te_handler(encoder->crtc);
+}
+
 static const struct mipi_dsi_host_ops exynos_dsi_ops = {
 	.attach = exynos_dsi_host_attach,
 	.detach = exynos_dsi_host_detach,
 	.transfer = exynos_dsi_host_transfer,
+	.te_handler = exynos_dsi_host_te_handler,
 };
 
 static int exynos_dsi_poweron(struct exynos_dsi *dsi)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 40fd6cc..36d28e8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,11 +19,14 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/pm_runtime.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
 
 #include <video/of_display_timing.h>
 #include <video/of_videomode.h>
 #include <video/samsung_fimd.h>
 #include <drm/exynos_drm.h>
+#include <drm/drm_panel.h>
 
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fbdev.h"
@@ -59,6 +62,22 @@
 /* color key value register for hardware window 1 ~ 4. */
 #define WKEYCON1_BASE(x)		((WKEYCON1 + 0x140) + ((x - 1) * 8))
 
+/* i80 / RGB trigger control register */
+#define TRIGCON				0x1A4
+
+/* display mode change control register except exynos4 */
+#define VIDOUT_CON			0x000
+#define VIDOUT_CON_F_I80_LDI0		(0x2 << 8)
+
+/* i80 interface control for main LDI register */
+#define I80IFCONFAx(x)			(0x1B0 + (x) * 4)
+#define I80IFCONFBx(x)			(0x1B8 + (x) * 4)
+#define LCD_CS_SETUP(x)			((x) << 16)
+#define LCD_WR_SETUP(x)			((x) << 12)
+#define LCD_WR_ACT(x)			((x) << 8)
+#define LCD_WR_HOLD(x)			((x) << 4)
+#define I80IFEN_ENABLE			(1 << 0)
+
 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR	5
 
@@ -66,10 +85,14 @@
 
 struct fimd_driver_data {
 	unsigned int timing_base;
+	unsigned int lcdblk_off;
+	unsigned int lcdblk_vt_shift;
+	unsigned int lcdblk_bypass_shift;
 
 	unsigned int has_shadowcon:1;
 	unsigned int has_clksel:1;
 	unsigned int has_limited_fmt:1;
+	unsigned int has_vidoutcon:1;
 };
 
 static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -80,12 +103,19 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
 
 static struct fimd_driver_data exynos4_fimd_driver_data = {
 	.timing_base = 0x0,
+	.lcdblk_off = 0x210,
+	.lcdblk_vt_shift = 10,
+	.lcdblk_bypass_shift = 1,
 	.has_shadowcon = 1,
 };
 
 static struct fimd_driver_data exynos5_fimd_driver_data = {
 	.timing_base = 0x20000,
+	.lcdblk_off = 0x214,
+	.lcdblk_vt_shift = 24,
+	.lcdblk_bypass_shift = 15,
 	.has_shadowcon = 1,
+	.has_vidoutcon = 1,
 };
 
 struct fimd_win_data {
@@ -110,15 +140,23 @@ struct fimd_context {
 	struct clk			*bus_clk;
 	struct clk			*lcd_clk;
 	void __iomem			*regs;
+	struct regmap			*sysreg;
 	struct drm_display_mode		mode;
 	struct fimd_win_data		win_data[WINDOWS_NR];
 	unsigned int			default_win;
 	unsigned long			irq_flags;
+	u32				vidcon0;
 	u32				vidcon1;
+	u32				vidout_con;
+	u32				i80ifcon;
+	bool				i80_if;
 	bool				suspended;
 	int				pipe;
 	wait_queue_head_t		wait_vsync_queue;
 	atomic_t			wait_vsync_event;
+	atomic_t			win_updated;
+	atomic_t			triggering;
+	spinlock_t			win_updated_lock;
 
 	struct exynos_drm_panel_info panel;
 	struct fimd_driver_data *driver_data;
@@ -190,6 +228,14 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
 	unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
 	u32 clkdiv;
 
+	if (ctx->i80_if) {
+		/*
+		 * The frame done interrupt should be occurred prior to the
+		 * next TE signal.
+		 */
+		ideal_clk *= 2;
+	}
+
 	/* Find the clock divider value that gets us closest to ideal_clk */
 	clkdiv = DIV_ROUND_UP(clk_get_rate(ctx->lcd_clk), ideal_clk);
 
@@ -212,17 +258,28 @@ static void fimd_mode_set(struct exynos_drm_manager *mgr,
 	struct fimd_context *ctx = mgr->ctx;
 
 	drm_mode_copy(&ctx->mode, in_mode);
+
+	if (ctx->i80_if) {
+		struct drm_panel_cpu_timings *cpu_timings =
+						(void *)in_mode->private;
+
+		if (cpu_timings) {
+			ctx->i80ifcon = LCD_CS_SETUP(cpu_timings->cs_setup);
+			ctx->i80ifcon |= LCD_WR_SETUP(cpu_timings->wr_setup);
+			ctx->i80ifcon |= LCD_WR_ACT(cpu_timings->wr_act);
+			ctx->i80ifcon |= LCD_WR_HOLD(cpu_timings->wr_hold);
+		}
+	}
 }
 
 static void fimd_commit(struct exynos_drm_manager *mgr)
 {
 	struct fimd_context *ctx = mgr->ctx;
 	struct drm_display_mode *mode = &ctx->mode;
-	struct fimd_driver_data *driver_data;
-	u32 val, clkdiv, vidcon1;
-	int vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
+	struct fimd_driver_data *driver_data = ctx->driver_data;
+	void *timing_base = ctx->regs + driver_data->timing_base;
+	u32 val, clkdiv;
 
-	driver_data = ctx->driver_data;
 	if (ctx->suspended)
 		return;
 
@@ -230,33 +287,65 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
 	if (mode->htotal == 0 || mode->vtotal == 0)
 		return;
 
-	/* setup polarity values */
-	vidcon1 = ctx->vidcon1;
-	if (mode->flags & DRM_MODE_FLAG_NVSYNC)
-		vidcon1 |= VIDCON1_INV_VSYNC;
-	if (mode->flags & DRM_MODE_FLAG_NHSYNC)
-		vidcon1 |= VIDCON1_INV_HSYNC;
-	writel(vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);
-
-	/* setup vertical timing values. */
-	vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start;
-	vbpd = mode->crtc_vtotal - mode->crtc_vsync_end;
-	vfpd = mode->crtc_vsync_start - mode->crtc_vdisplay;
-
-	val = VIDTCON0_VBPD(vbpd - 1) |
-		VIDTCON0_VFPD(vfpd - 1) |
-		VIDTCON0_VSPW(vsync_len - 1);
-	writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);
-
-	/* setup horizontal timing values.  */
-	hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
-	hbpd = mode->crtc_htotal - mode->crtc_hsync_end;
-	hfpd = mode->crtc_hsync_start - mode->crtc_hdisplay;
-
-	val = VIDTCON1_HBPD(hbpd - 1) |
-		VIDTCON1_HFPD(hfpd - 1) |
-		VIDTCON1_HSPW(hsync_len - 1);
-	writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);
+	if (ctx->i80_if) {
+		val = ctx->i80ifcon | I80IFEN_ENABLE;
+		writel(val, timing_base + I80IFCONFAx(0));
+
+		/* disable auto frame rate */
+		writel(0, timing_base + I80IFCONFBx(0));
+
+		if (ctx->vidout_con)
+			writel(ctx->vidout_con, timing_base + VIDOUT_CON);
+
+		/* set video type selection to i80 interface */
+		if (ctx->sysreg && regmap_update_bits(ctx->sysreg,
+					driver_data->lcdblk_off,
+					0x3 << driver_data->lcdblk_vt_shift,
+					0x1 << driver_data->lcdblk_vt_shift)) {
+			DRM_ERROR("Failed to update sysreg for i80 i/f.\n");
+			return;
+		}
+	} else {
+		int vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
+		u32 vidcon1;
+
+		/* setup polarity values */
+		vidcon1 = ctx->vidcon1;
+		if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+			vidcon1 |= VIDCON1_INV_VSYNC;
+		if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+			vidcon1 |= VIDCON1_INV_HSYNC;
+		writel(vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);
+
+		/* setup vertical timing values. */
+		vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start;
+		vbpd = mode->crtc_vtotal - mode->crtc_vsync_end;
+		vfpd = mode->crtc_vsync_start - mode->crtc_vdisplay;
+
+		val = VIDTCON0_VBPD(vbpd - 1) |
+			VIDTCON0_VFPD(vfpd - 1) |
+			VIDTCON0_VSPW(vsync_len - 1);
+		writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);
+
+		/* setup horizontal timing values.  */
+		hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
+		hbpd = mode->crtc_htotal - mode->crtc_hsync_end;
+		hfpd = mode->crtc_hsync_start - mode->crtc_hdisplay;
+
+		val = VIDTCON1_HBPD(hbpd - 1) |
+			VIDTCON1_HFPD(hfpd - 1) |
+			VIDTCON1_HSPW(hsync_len - 1);
+		writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);
+	}
+
+	/* set bypass selection */
+	if (ctx->sysreg && regmap_update_bits(ctx->sysreg,
+				driver_data->lcdblk_off,
+				0x1 << driver_data->lcdblk_bypass_shift,
+				0x1 << driver_data->lcdblk_bypass_shift)) {
+		DRM_ERROR("Failed to update sysreg for bypass setting.\n");
+		return;
+	}
 
 	/* setup horizontal and vertical display size. */
 	val = VIDTCON2_LINEVAL(mode->vdisplay - 1) |
@@ -613,6 +702,14 @@ static void fimd_win_commit(struct exynos_drm_manager *mgr, int zpos)
 	}
 
 	win_data->enabled = true;
+
+	if (ctx->i80_if) {
+		unsigned long flags;
+
+		spin_lock_irqsave(&ctx->win_updated_lock, flags);
+		atomic_set(&ctx->win_updated, 1);
+		spin_unlock_irqrestore(&ctx->win_updated_lock, flags);
+	}
 }
 
 static void fimd_win_disable(struct exynos_drm_manager *mgr, int zpos)
@@ -802,6 +899,68 @@ static void fimd_dpms(struct exynos_drm_manager *mgr, int mode)
 	}
 }
 
+static void fimd_trigger(struct device *dev)
+{
+	struct exynos_drm_manager *mgr = get_fimd_manager(dev);
+	struct fimd_context *ctx = mgr->ctx;
+	struct fimd_driver_data *driver_data = ctx->driver_data;
+	void *timing_base = ctx->regs + driver_data->timing_base;
+	u32 reg;
+
+	atomic_set(&ctx->triggering, 1);
+
+	reg = readl(ctx->regs + VIDINTCON0);
+	reg |= (VIDINTCON0_INT_ENABLE | VIDINTCON0_INT_I80IFDONE |
+						VIDINTCON0_INT_SYSMAINCON);
+	writel(reg, ctx->regs + VIDINTCON0);
+
+	reg = readl(timing_base + TRIGCON);
+	reg |= 1 << 0 | 1 << 1;
+	writel(reg, timing_base + TRIGCON);
+}
+
+static int fimd_te_handler(struct exynos_drm_manager *mgr)
+{
+	struct fimd_context *ctx = mgr->ctx;
+	unsigned long flags;
+
+	/* check the crtc is detached already from encoder */
+	if (ctx->pipe < 0 || !ctx->drm_dev)
+		return -EINVAL;
+
+	 /*
+	 * Skips triggering if in triggering state, because multiple
+	 * triggering request can cause panel reset.
+	 */
+	if (atomic_read(&ctx->triggering))
+		return 0;
+
+	spin_lock_irqsave(&ctx->win_updated_lock, flags);
+
+	/*
+	 * If there is a page flip request, trigger and handle the page flip
+	 * event so that current fb can be updated into panel GRAM.
+	 */
+	if (atomic_read(&ctx->win_updated)) {
+		atomic_set(&ctx->win_updated, 0);
+
+		fimd_trigger(ctx->dev);
+	}
+
+	spin_unlock_irqrestore(&ctx->win_updated_lock, flags);
+
+	/* wake up vsync event queue */
+	if (atomic_read(&ctx->wait_vsync_event)) {
+		atomic_set(&ctx->wait_vsync_event, 0);
+		wake_up(&ctx->wait_vsync_queue);
+
+		if (!atomic_read(&ctx->triggering))
+			drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+	}
+
+	return 0;
+}
+
 static struct exynos_drm_manager_ops fimd_manager_ops = {
 	.initialize = fimd_mgr_initialize,
 	.remove = fimd_mgr_remove,
@@ -815,6 +974,7 @@ static struct exynos_drm_manager_ops fimd_manager_ops = {
 	.win_mode_set = fimd_win_mode_set,
 	.win_commit = fimd_win_commit,
 	.win_disable = fimd_win_disable,
+	.te_handler = fimd_te_handler,
 };
 
 static struct exynos_drm_manager fimd_manager = {
@@ -825,26 +985,40 @@ static struct exynos_drm_manager fimd_manager = {
 static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
 {
 	struct fimd_context *ctx = (struct fimd_context *)dev_id;
-	u32 val;
+	u32 val, clear_bit;
 
 	val = readl(ctx->regs + VIDINTCON1);
 
-	if (val & VIDINTCON1_INT_FRAME)
-		/* VSYNC interrupt */
-		writel(VIDINTCON1_INT_FRAME, ctx->regs + VIDINTCON1);
+	clear_bit = ctx->i80_if ? VIDINTCON1_INT_I80 : VIDINTCON1_INT_FRAME;
+	if (val & clear_bit)
+		writel(clear_bit, ctx->regs + VIDINTCON1);
 
 	/* check the crtc is detached already from encoder */
 	if (ctx->pipe < 0 || !ctx->drm_dev)
 		goto out;
 
-	drm_handle_vblank(ctx->drm_dev, ctx->pipe);
-	exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+	if (ctx->i80_if) {
+		/* unset i80 frame done interrupt */
+		val = readl(ctx->regs + VIDINTCON0);
+		val &= ~(VIDINTCON0_INT_I80IFDONE | VIDINTCON0_INT_SYSMAINCON);
+		writel(val, ctx->regs + VIDINTCON0);
 
-	/* set wait vsync event to zero and wake up queue. */
-	if (atomic_read(&ctx->wait_vsync_event)) {
-		atomic_set(&ctx->wait_vsync_event, 0);
-		wake_up(&ctx->wait_vsync_queue);
+		/* exit triggering mode */
+		atomic_set(&ctx->triggering, 0);
+
+		drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+		exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+	} else {
+		drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+		exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+
+		/* set wait vsync event to zero and wake up queue. */
+		if (atomic_read(&ctx->wait_vsync_event)) {
+			atomic_set(&ctx->wait_vsync_event, 0);
+			wake_up(&ctx->wait_vsync_queue);
+		}
 	}
+
 out:
 	return IRQ_HANDLED;
 }
@@ -866,12 +1040,32 @@ static int fimd_probe(struct platform_device *pdev)
 
 	ctx->dev = dev;
 	ctx->suspended = true;
+	ctx->driver_data = drm_fimd_get_driver_data(pdev);
 
 	if (of_property_read_bool(dev->of_node, "samsung,invert-vden"))
 		ctx->vidcon1 |= VIDCON1_INV_VDEN;
 	if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
 		ctx->vidcon1 |= VIDCON1_INV_VCLK;
 
+	if (of_property_read_bool(dev->of_node, "vidout-i80-ldi")) {
+		ctx->i80_if = true;
+
+		if (ctx->driver_data->has_vidoutcon)
+			ctx->vidout_con |= VIDOUT_CON_F_I80_LDI0;
+		else
+			ctx->vidcon0 |= VIDCON0_VIDOUT_I80_LDI0;
+		ctx->vidcon0 |= VIDCON0_DSI_EN;
+
+		spin_lock_init(&ctx->win_updated_lock);
+	}
+
+	ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
+							"samsung,sysreg");
+	if (IS_ERR(ctx->sysreg)) {
+		dev_warn(dev, "failed to get system register.\n");
+		ctx->sysreg = NULL;
+	}
+
 	ctx->bus_clk = devm_clk_get(dev, "fimd");
 	if (IS_ERR(ctx->bus_clk)) {
 		dev_err(dev, "failed to get bus clock\n");
@@ -890,7 +1084,8 @@ static int fimd_probe(struct platform_device *pdev)
 	if (IS_ERR(ctx->regs))
 		return PTR_ERR(ctx->regs);
 
-	res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "vsync");
+	res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
+					ctx->i80_if ? "lcd_sys" : "vsync");
 	if (!res) {
 		dev_err(dev, "irq request failed.\n");
 		return -ENXIO;
@@ -903,7 +1098,6 @@ static int fimd_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	ctx->driver_data = drm_fimd_get_driver_data(pdev);
 	init_waitqueue_head(&ctx->wait_vsync_queue);
 	atomic_set(&ctx->wait_vsync_event, 0);
 
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7209df1..244d197 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -49,6 +49,7 @@ struct mipi_dsi_msg {
  * @detach: detach DSI device from DSI host
  * @transfer: send and/or receive DSI packet, return number of received bytes,
  * 	      or error
+ * @te_handler: call CRTC TE handler callback from DSI host
  */
 struct mipi_dsi_host_ops {
 	int (*attach)(struct mipi_dsi_host *host,
@@ -57,6 +58,7 @@ struct mipi_dsi_host_ops {
 		      struct mipi_dsi_device *dsi);
 	ssize_t (*transfer)(struct mipi_dsi_host *host,
 			    struct mipi_dsi_msg *msg);
+	int (*te_handler)(struct mipi_dsi_host *host);
 };
 
 /**
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index c2ab77a..0ad64ed 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -46,6 +46,13 @@ struct drm_panel {
 	struct list_head list;
 };
 
+struct drm_panel_cpu_timings {
+	unsigned int cs_setup;
+	unsigned int wr_setup;
+	unsigned int wr_act;
+	unsigned int wr_hold;
+};
+
 static inline int drm_panel_disable(struct drm_panel *panel)
 {
 	if (panel && panel->funcs && panel->funcs->disable)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..eaad58b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -19,6 +19,7 @@
 /* VIDCON0 */
 
 #define VIDCON0					0x00
+#define VIDCON0_DSI_EN				(1 << 30)
 #define VIDCON0_INTERLACE			(1 << 29)
 #define VIDCON0_VIDOUT_MASK			(0x7 << 26)
 #define VIDCON0_VIDOUT_SHIFT			26
@@ -355,7 +356,7 @@
 #define VIDINTCON0_INT_ENABLE			(1 << 0)
 
 #define VIDINTCON1				0x134
-#define VIDINTCON1_INT_I180			(1 << 2)
+#define VIDINTCON1_INT_I80			(1 << 2)
 #define VIDINTCON1_INT_FRAME			(1 << 1)
 #define VIDINTCON1_INT_FIFO			(1 << 0)
 
-- 
1.7.9.5

Re: [RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[Laurent Pinchart]

Hi YoungJun,

Thank you for the patch.

On Monday 21 April 2014 21:28:33 YoungJun Cho wrote:
> This patch adds I80 interface for FIMD to support command mode panel.
> 
> For this, the below features are added:
> - Sets display interface mode relevant registers properly according to the
>   interface type from DT
> - Adds drm_panel_cpu_timings structure
>  . The command mode panel sets them as the private attributes in struct
>    drm_display_mode and FIMD gets them by fimd_mode_set().
> - Adds TE interrupt handler
>   . FIMD driver should know TE signal from lcd panel to avoid tearing issue.
> - Adds trigger feature
>   . In case of command mode panel, FIMD should set trigger bit,
>     so that image data has to be transferred to display bus or lcd panel.
> 
> Changelog v2:
> - Moves CPU timings relevant properties to panel DT
>   (commented by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> Acked-by: Inki Dae <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  drivers/gpu/drm/exynos/Kconfig           |    1 +
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   11 ++
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h |    2 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |    2 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 ++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |  280 ++++++++++++++++++++++-----
>  include/drm/drm_mipi_dsi.h               |    2 +
>  include/drm/drm_panel.h                  |    7 +

Could you please split the DRM core changes into two separate standalone 
patches (as they're unrelated to each other) ?

>  include/video/samsung_fimd.h             |    3 +-
>  9 files changed, 277 insertions(+), 44 deletions(-)

[snip]

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[YoungJun Cho]

Hi Laurent,

Thank you for the comment.

On 04/22/2014 07:52 AM, Laurent Pinchart wrote:
> Hi YoungJun,
>
> Thank you for the patch.
>
> On Monday 21 April 2014 21:28:33 YoungJun Cho wrote:
>> This patch adds I80 interface for FIMD to support command mode panel.
>>
>> For this, the below features are added:
>> - Sets display interface mode relevant registers properly according to the
>>    interface type from DT
>> - Adds drm_panel_cpu_timings structure
>>   . The command mode panel sets them as the private attributes in struct
>>     drm_display_mode and FIMD gets them by fimd_mode_set().
>> - Adds TE interrupt handler
>>    . FIMD driver should know TE signal from lcd panel to avoid tearing issue.
>> - Adds trigger feature
>>    . In case of command mode panel, FIMD should set trigger bit,
>>      so that image data has to be transferred to display bus or lcd panel.
>>
>> Changelog v2:
>> - Moves CPU timings relevant properties to panel DT
>>    (commented by Laurent Pinchart, Andrzej Hajda)
>>
>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>> Acked-by: Inki Dae <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   drivers/gpu/drm/exynos/Kconfig           |    1 +
>>   drivers/gpu/drm/exynos/exynos_drm_crtc.c |   11 ++
>>   drivers/gpu/drm/exynos/exynos_drm_crtc.h |    2 +
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h  |    2 +
>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 ++
>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c |  280 ++++++++++++++++++++++-----
>>   include/drm/drm_mipi_dsi.h               |    2 +
>>   include/drm/drm_panel.h                  |    7 +
>
> Could you please split the DRM core changes into two separate standalone
> patches (as they're unrelated to each other) ?

Ok, it could be split into core and driver ones.
The DRM core changes are required to link with TE irq handler callback.

I'll do it next patch set.

Thank you.
Best regards YJ

>
>>   include/video/samsung_fimd.h             |    3 +-
>>   9 files changed, 277 insertions(+), 44 deletions(-)
>
> [snip]
>

Re: [RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1035 bytes --]

On Mon, Apr 21, 2014 at 09:28:33PM +0900, YoungJun Cho wrote:
[...]
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 7209df1..244d197 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -49,6 +49,7 @@ struct mipi_dsi_msg {
>   * @detach: detach DSI device from DSI host
>   * @transfer: send and/or receive DSI packet, return number of received bytes,
>   * 	      or error
> + * @te_handler: call CRTC TE handler callback from DSI host

Perhaps you can explain some more what this means or why it would be
necessary.

> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index c2ab77a..0ad64ed 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -46,6 +46,13 @@ struct drm_panel {
>  	struct list_head list;
>  };
>  
> +struct drm_panel_cpu_timings {
> +	unsigned int cs_setup;
> +	unsigned int wr_setup;
> +	unsigned int wr_act;
> +	unsigned int wr_hold;
> +};

Similarily here. What's this?

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[YoungJun Cho]

Hi Thierry

Thank you for the comments.

On 04/22/2014 04:34 PM, Thierry Reding wrote:
> On Mon, Apr 21, 2014 at 09:28:33PM +0900, YoungJun Cho wrote:
> [...]
>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>> index 7209df1..244d197 100644
>> --- a/include/drm/drm_mipi_dsi.h
>> +++ b/include/drm/drm_mipi_dsi.h
>> @@ -49,6 +49,7 @@ struct mipi_dsi_msg {
>>    * @detach: detach DSI device from DSI host
>>    * @transfer: send and/or receive DSI packet, return number of received bytes,
>>    * 	      or error
>> + * @te_handler: call CRTC TE handler callback from DSI host
>
> Perhaps you can explain some more what this means or why it would be
> necessary.

I'll enhance the explanation.

For your information, the panel generates Tearing Effect signal
to synchronize between the MCU and Frame Memory Writing when displays
video images.
The display controller requires this signal to trigger video images,
and there is no way to receive this signal directly.
So the panel receive this signal as an IRQ and calls te_handler() chain
for the display controller to trigger video image at that time.

>
>> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
>> index c2ab77a..0ad64ed 100644
>> --- a/include/drm/drm_panel.h
>> +++ b/include/drm/drm_panel.h
>> @@ -46,6 +46,13 @@ struct drm_panel {
>>   	struct list_head list;
>>   };
>>
>> +struct drm_panel_cpu_timings {
>> +	unsigned int cs_setup;
>> +	unsigned int wr_setup;
>> +	unsigned int wr_act;
>> +	unsigned int wr_hold;
>> +};
>
> Similarily here. What's this?

I'll enhance the explanation also.
In panel DT bindings, I already explained them.

Thank you.
Best regards YJ

>
> Thierry
>

[RFC v2 PATCH v2 07/14] ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings

[YoungJun Cho]

This patch adds relevant to exynos5420 compatible for exynos5420 SoC support.

Changelog v2:
- Changes title, description and fixes typo (commented by Sachin Kamat)

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 .../devicetree/bindings/video/exynos_dsim.txt      |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 33b5730..29bf3b2 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -1,7 +1,9 @@
 Exynos MIPI DSI Master
 
 Required properties:
-  - compatible: "samsung,exynos4210-mipi-dsi"
+  - compatible: value should be one of the following
+			"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
+			"samsung,exynos5420-mipi-dsi" /* for Exynos5420 SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
1.7.9.5

[RFC v2 PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420

[YoungJun Cho]

The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.

In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  101 ++++++++++++++++++++++++-------
 1 file changed, 80 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 179f2fa..fcd577f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
 
 #include <linux/clk.h>
 #include <linux/irq.h>
+#include <linux/of_device.h>
 #include <linux/phy/phy.h>
 #include <linux/regulator/consumer.h>
 
@@ -54,9 +55,12 @@
 
 /* FIFO memory AC characteristic register */
 #define DSIM_PLLCTRL_REG	0x4c	/* PLL control register */
-#define DSIM_PLLTMR_REG		0x50	/* PLL timer register */
 #define DSIM_PHYACCHR_REG	0x54	/* D-PHY AC characteristic register */
 #define DSIM_PHYACCHR1_REG	0x58	/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG	0x5c
+#define DSIM_PHYTIMING_REG	0x64
+#define DSIM_PHYTIMING1_REG	0x68
+#define DSIM_PHYTIMING2_REG	0x6c
 
 /* DSIM_STATUS */
 #define DSIM_STOP_STATE_DAT(x)		(((x) & 0xf) << 0)
@@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
 #define DSIM_STATE_INITIALIZED		BIT(1)
 #define DSIM_STATE_CMD_LPM		BIT(2)
 
+struct exynos_dsi_driver_data {
+	unsigned int plltmr_reg;
+
+	unsigned int has_freqband:1;
+};
+
 struct exynos_dsi {
 	struct mipi_dsi_host dsi_host;
 	struct drm_connector connector;
@@ -262,11 +272,39 @@ struct exynos_dsi {
 
 	spinlock_t transfer_lock; /* protects transfer_list */
 	struct list_head transfer_list;
+
+	struct exynos_dsi_driver_data *driver_data;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
 #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
 
+static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
+	.plltmr_reg = 0x50,
+	.has_freqband = 1,
+};
+
+static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
+	.plltmr_reg = 0x58,
+};
+
+static struct of_device_id exynos_dsi_of_match[] = {
+	{ .compatible = "samsung,exynos4210-mipi-dsi",
+	  .data = &exynos4_dsi_driver_data },
+	{ .compatible = "samsung,exynos5420-mipi-dsi",
+	  .data = &exynos5_dsi_driver_data },
+	{ }
+};
+
+static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
+						struct platform_device *pdev)
+{
+	const struct of_device_id *of_id =
+			of_match_device(exynos_dsi_of_match, &pdev->dev);
+
+	return (struct exynos_dsi_driver_data *)of_id->data;
+}
+
 static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
 {
 	if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
@@ -340,14 +378,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct exynos_dsi *dsi,
 static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
 					unsigned long freq)
 {
-	static const unsigned long freq_bands[] = {
-		100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
-		270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
-		510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
-		770 * MHZ, 870 * MHZ, 950 * MHZ,
-	};
+	struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
 	unsigned long fin, fout;
-	int timeout, band;
+	int timeout;
 	u8 p, s;
 	u16 m;
 	u32 reg;
@@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
 			"failed to find PLL PMS for requested frequency\n");
 		return -EFAULT;
 	}
+	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
 
-	for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
-		if (fout < freq_bands[band])
-			break;
+	writel(500, dsi->reg_base + driver_data->plltmr_reg);
+
+	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+
+	if (driver_data->has_freqband) {
+		static const unsigned long freq_bands[] = {
+			100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
+			270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
+			510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
+			770 * MHZ, 870 * MHZ, 950 * MHZ,
+		};
+		int band;
 
-	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d), band %d\n", fout,
-		p, m, s, band);
+		for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
+			if (fout < freq_bands[band])
+				break;
 
-	writel(500, dsi->reg_base + DSIM_PLLTMR_REG);
+		dev_dbg(dsi->dev, "band %d\n", band);
+
+		reg |= DSIM_FREQ_BAND(band);
+	}
 
-	reg = DSIM_FREQ_BAND(band) | DSIM_PLL_EN
-			| DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
 	writel(reg, dsi->reg_base + DSIM_PLLCTRL_REG);
 
 	timeout = 1000;
@@ -391,6 +436,24 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
 		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
 	} while ((reg & DSIM_PLL_STABLE) == 0);
 
+	if (!driver_data->has_freqband) {
+		/* b dphy ctrl */
+		reg = 0x0af & 0x1ff;
+		writel(reg, dsi->reg_base + DSIM_PHYCTRL_REG);
+
+		/* phy timing */
+		reg = 0x06 << 8 | 0x0b;
+		writel(reg, dsi->reg_base + DSIM_PHYTIMING_REG);
+
+		/* phy timing 1 */
+		reg = 0x07 << 24 | 0x27 << 16 | 0x0d << 8 | 0x08;
+		writel(reg, dsi->reg_base + DSIM_PHYTIMING1_REG);
+
+		/* phy timing 2 */
+		reg = 0x09 << 16 | 0x0d << 8 | 0x0b;
+		writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
+	}
+
 	return fout;
 }
 
@@ -1412,6 +1475,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 	dsi->dsi_host.dev = &pdev->dev;
 
 	dsi->dev = &pdev->dev;
+	dsi->driver_data = exynos_dsi_get_driver_data(pdev);
 
 	ret = exynos_dsi_parse_dt(dsi);
 	if (ret)
@@ -1516,11 +1580,6 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(exynos_dsi_suspend, exynos_dsi_resume)
 };
 
-static struct of_device_id exynos_dsi_of_match[] = {
-	{ .compatible = "samsung,exynos4210-mipi-dsi" },
-	{ }
-};
-
 struct platform_driver dsi_driver = {
 	.probe = exynos_dsi_probe,
 	.remove = exynos_dsi_remove,
-- 
1.7.9.5

Re: [RFC v2 PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420

[Andrzej Hajda]

On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
> from the one in Exynos4 SoC.
>
> In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
> and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
> So this patch adds driver data to distinguish it.
>
> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> Acked-by: Inki Dae <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  101 ++++++++++++++++++++++++-------
>  1 file changed, 80 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 179f2fa..fcd577f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -17,6 +17,7 @@
>  
>  #include <linux/clk.h>
>  #include <linux/irq.h>
> +#include <linux/of_device.h>
>  #include <linux/phy/phy.h>
>  #include <linux/regulator/consumer.h>
>  
> @@ -54,9 +55,12 @@
>  
>  /* FIFO memory AC characteristic register */
>  #define DSIM_PLLCTRL_REG	0x4c	/* PLL control register */
> -#define DSIM_PLLTMR_REG		0x50	/* PLL timer register */
>  #define DSIM_PHYACCHR_REG	0x54	/* D-PHY AC characteristic register */
>  #define DSIM_PHYACCHR1_REG	0x58	/* D-PHY AC characteristic register1 */
> +#define DSIM_PHYCTRL_REG	0x5c
> +#define DSIM_PHYTIMING_REG	0x64
> +#define DSIM_PHYTIMING1_REG	0x68
> +#define DSIM_PHYTIMING2_REG	0x6c
>  
>  /* DSIM_STATUS */
>  #define DSIM_STOP_STATE_DAT(x)		(((x) & 0xf) << 0)
> @@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
>  #define DSIM_STATE_INITIALIZED		BIT(1)
>  #define DSIM_STATE_CMD_LPM		BIT(2)
>  
> +struct exynos_dsi_driver_data {
> +	unsigned int plltmr_reg;
> +
> +	unsigned int has_freqband:1;
> +};
> +
>  struct exynos_dsi {
>  	struct mipi_dsi_host dsi_host;
>  	struct drm_connector connector;
> @@ -262,11 +272,39 @@ struct exynos_dsi {
>  
>  	spinlock_t transfer_lock; /* protects transfer_list */
>  	struct list_head transfer_list;
> +
> +	struct exynos_dsi_driver_data *driver_data;
>  };
>  
>  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>  #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
>  
> +static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
> +	.plltmr_reg = 0x50,
> +	.has_freqband = 1,
> +};
> +
> +static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
> +	.plltmr_reg = 0x58,
> +};
> +
> +static struct of_device_id exynos_dsi_of_match[] = {
> +	{ .compatible = "samsung,exynos4210-mipi-dsi",
> +	  .data = &exynos4_dsi_driver_data },
> +	{ .compatible = "samsung,exynos5420-mipi-dsi",
> +	  .data = &exynos5_dsi_driver_data },
> +	{ }
> +};

I wonder if it wouldn't be better to use "samsung,exynos5410-mipi-dsi"
compatible and distinguish 5410 and 5420 by DSIM_VERSION register.


> +
> +static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
> +						struct platform_device *pdev)
> +{
> +	const struct of_device_id *of_id =
> +			of_match_device(exynos_dsi_of_match, &pdev->dev);
> +
> +	return (struct exynos_dsi_driver_data *)of_id->data;
> +}
> +
>  static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
>  {
>  	if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
> @@ -340,14 +378,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct exynos_dsi *dsi,
>  static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
>  					unsigned long freq)
>  {
> -	static const unsigned long freq_bands[] = {
> -		100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
> -		270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
> -		510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
> -		770 * MHZ, 870 * MHZ, 950 * MHZ,
> -	};
> +	struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
>  	unsigned long fin, fout;
> -	int timeout, band;
> +	int timeout;
>  	u8 p, s;
>  	u16 m;
>  	u32 reg;
> @@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
>  			"failed to find PLL PMS for requested frequency\n");
>  		return -EFAULT;
>  	}
> +	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
>  
> -	for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
> -		if (fout < freq_bands[band])
> -			break;
> +	writel(500, dsi->reg_base + driver_data->plltmr_reg);
> +
> +	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
> +
> +	if (driver_data->has_freqband) {
> +		static const unsigned long freq_bands[] = {
> +			100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
> +			270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
> +			510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
> +			770 * MHZ, 870 * MHZ, 950 * MHZ,
> +		};
> +		int band;
>  
> -	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d), band %d\n", fout,
> -		p, m, s, band);
> +		for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
> +			if (fout < freq_bands[band])
> +				break;
>  
> -	writel(500, dsi->reg_base + DSIM_PLLTMR_REG);
> +		dev_dbg(dsi->dev, "band %d\n", band);
> +
> +		reg |= DSIM_FREQ_BAND(band);
> +	}
>  
> -	reg = DSIM_FREQ_BAND(band) | DSIM_PLL_EN
> -			| DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
>  	writel(reg, dsi->reg_base + DSIM_PLLCTRL_REG);
>  
>  	timeout = 1000;
> @@ -391,6 +436,24 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
>  		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>  	} while ((reg & DSIM_PLL_STABLE) == 0);
>  
> +	if (!driver_data->has_freqband) {

Could you explain why lack of freqband determines necessity of setting PHY
registers, is this a kind of hardware setting dependency?

> +		/* b dphy ctrl */
> +		reg = 0x0af & 0x1ff;
> +		writel(reg, dsi->reg_base + DSIM_PHYCTRL_REG);
> +
> +		/* phy timing */
> +		reg = 0x06 << 8 | 0x0b;
> +		writel(reg, dsi->reg_base + DSIM_PHYTIMING_REG);
> +
> +		/* phy timing 1 */
> +		reg = 0x07 << 24 | 0x27 << 16 | 0x0d << 8 | 0x08;
> +		writel(reg, dsi->reg_base + DSIM_PHYTIMING1_REG);
> +
> +		/* phy timing 2 */
> +		reg = 0x09 << 16 | 0x0d << 8 | 0x0b;
> +		writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
> +	}
> +

Please use macros if possible instead of magic numbers.

As I wrote in comment for earlier patch it would be better to separate
setting PHY registers
from clock registers.

>  	return fout;
>  }
>  
> @@ -1412,6 +1475,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
>  	dsi->dsi_host.dev = &pdev->dev;
>  
>  	dsi->dev = &pdev->dev;
> +	dsi->driver_data = exynos_dsi_get_driver_data(pdev);
>  
>  	ret = exynos_dsi_parse_dt(dsi);
>  	if (ret)
> @@ -1516,11 +1580,6 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
>  	SET_SYSTEM_SLEEP_PM_OPS(exynos_dsi_suspend, exynos_dsi_resume)
>  };
>  
> -static struct of_device_id exynos_dsi_of_match[] = {
> -	{ .compatible = "samsung,exynos4210-mipi-dsi" },
> -	{ }
> -};
> -
>  struct platform_driver dsi_driver = {
>  	.probe = exynos_dsi_probe,
>  	.remove = exynos_dsi_remove,

Re: [RFC v2 PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420

[YoungJun Cho]

Hi Andrzej,

Thank you for comments.

On 04/23/2014 05:29 PM, Andrzej Hajda wrote:
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>> The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
>> from the one in Exynos4 SoC.
>>
>> In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
>> and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
>> So this patch adds driver data to distinguish it.
>>
>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>> Acked-by: Inki Dae <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c |  101 ++++++++++++++++++++++++-------
>>   1 file changed, 80 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 179f2fa..fcd577f 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -17,6 +17,7 @@
>>
>>   #include <linux/clk.h>
>>   #include <linux/irq.h>
>> +#include <linux/of_device.h>
>>   #include <linux/phy/phy.h>
>>   #include <linux/regulator/consumer.h>
>>
>> @@ -54,9 +55,12 @@
>>
>>   /* FIFO memory AC characteristic register */
>>   #define DSIM_PLLCTRL_REG	0x4c	/* PLL control register */
>> -#define DSIM_PLLTMR_REG		0x50	/* PLL timer register */
>>   #define DSIM_PHYACCHR_REG	0x54	/* D-PHY AC characteristic register */
>>   #define DSIM_PHYACCHR1_REG	0x58	/* D-PHY AC characteristic register1 */
>> +#define DSIM_PHYCTRL_REG	0x5c
>> +#define DSIM_PHYTIMING_REG	0x64
>> +#define DSIM_PHYTIMING1_REG	0x68
>> +#define DSIM_PHYTIMING2_REG	0x6c
>>
>>   /* DSIM_STATUS */
>>   #define DSIM_STOP_STATE_DAT(x)		(((x) & 0xf) << 0)
>> @@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
>>   #define DSIM_STATE_INITIALIZED		BIT(1)
>>   #define DSIM_STATE_CMD_LPM		BIT(2)
>>
>> +struct exynos_dsi_driver_data {
>> +	unsigned int plltmr_reg;
>> +
>> +	unsigned int has_freqband:1;
>> +};
>> +
>>   struct exynos_dsi {
>>   	struct mipi_dsi_host dsi_host;
>>   	struct drm_connector connector;
>> @@ -262,11 +272,39 @@ struct exynos_dsi {
>>
>>   	spinlock_t transfer_lock; /* protects transfer_list */
>>   	struct list_head transfer_list;
>> +
>> +	struct exynos_dsi_driver_data *driver_data;
>>   };
>>
>>   #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>>   #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
>>
>> +static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
>> +	.plltmr_reg = 0x50,
>> +	.has_freqband = 1,
>> +};
>> +
>> +static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
>> +	.plltmr_reg = 0x58,
>> +};
>> +
>> +static struct of_device_id exynos_dsi_of_match[] = {
>> +	{ .compatible = "samsung,exynos4210-mipi-dsi",
>> +	  .data = &exynos4_dsi_driver_data },
>> +	{ .compatible = "samsung,exynos5420-mipi-dsi",
>> +	  .data = &exynos5_dsi_driver_data },
>> +	{ }
>> +};
>
> I wonder if it wouldn't be better to use "samsung,exynos5410-mipi-dsi"
> compatible and distinguish 5410 and 5420 by DSIM_VERSION register.
>

That's because I have only Exynos5420 SoC based target,
so made DT for that and tested it only.

But it seems to be no problem to use exynos5410 compatible at least
for the dsi device :).

I'll try.

>
>> +
>> +static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
>> +						struct platform_device *pdev)
>> +{
>> +	const struct of_device_id *of_id =
>> +			of_match_device(exynos_dsi_of_match, &pdev->dev);
>> +
>> +	return (struct exynos_dsi_driver_data *)of_id->data;
>> +}
>> +
>>   static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
>>   {
>>   	if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
>> @@ -340,14 +378,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct exynos_dsi *dsi,
>>   static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
>>   					unsigned long freq)
>>   {
>> -	static const unsigned long freq_bands[] = {
>> -		100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
>> -		270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
>> -		510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
>> -		770 * MHZ, 870 * MHZ, 950 * MHZ,
>> -	};
>> +	struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
>>   	unsigned long fin, fout;
>> -	int timeout, band;
>> +	int timeout;
>>   	u8 p, s;
>>   	u16 m;
>>   	u32 reg;
>> @@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
>>   			"failed to find PLL PMS for requested frequency\n");
>>   		return -EFAULT;
>>   	}
>> +	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
>>
>> -	for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
>> -		if (fout < freq_bands[band])
>> -			break;
>> +	writel(500, dsi->reg_base + driver_data->plltmr_reg);
>> +
>> +	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
>> +
>> +	if (driver_data->has_freqband) {
>> +		static const unsigned long freq_bands[] = {
>> +			100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
>> +			270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
>> +			510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
>> +			770 * MHZ, 870 * MHZ, 950 * MHZ,
>> +		};
>> +		int band;
>>
>> -	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d), band %d\n", fout,
>> -		p, m, s, band);
>> +		for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
>> +			if (fout < freq_bands[band])
>> +				break;
>>
>> -	writel(500, dsi->reg_base + DSIM_PLLTMR_REG);
>> +		dev_dbg(dsi->dev, "band %d\n", band);
>> +
>> +		reg |= DSIM_FREQ_BAND(band);
>> +	}
>>
>> -	reg = DSIM_FREQ_BAND(band) | DSIM_PLL_EN
>> -			| DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
>>   	writel(reg, dsi->reg_base + DSIM_PLLCTRL_REG);
>>
>>   	timeout = 1000;
>> @@ -391,6 +436,24 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
>>   		reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>   	} while ((reg & DSIM_PLL_STABLE) == 0);
>>
>> +	if (!driver_data->has_freqband) {
>
> Could you explain why lack of freqband determines necessity of setting PHY
> registers, is this a kind of hardware setting dependency?

Yes, there is H/W dependency.
In Exynos4 SoCs, from 24th to 26th bits of DSIM_PLLCTRL register are
for frequency band.
But in Exynos5410 / 5420 SoCs, those bits are used for DpDnSwap relevant
things.
So PHY ctrl and timing registers are required instead for it.

>
>> +		/* b dphy ctrl */
>> +		reg = 0x0af & 0x1ff;
>> +		writel(reg, dsi->reg_base + DSIM_PHYCTRL_REG);
>> +
>> +		/* phy timing */
>> +		reg = 0x06 << 8 | 0x0b;
>> +		writel(reg, dsi->reg_base + DSIM_PHYTIMING_REG);
>> +
>> +		/* phy timing 1 */
>> +		reg = 0x07 << 24 | 0x27 << 16 | 0x0d << 8 | 0x08;
>> +		writel(reg, dsi->reg_base + DSIM_PHYTIMING1_REG);
>> +
>> +		/* phy timing 2 */
>> +		reg = 0x09 << 16 | 0x0d << 8 | 0x0b;
>> +		writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>> +	}
>> +
>
> Please use macros if possible instead of magic numbers.

Right, I'll fix.

>
> As I wrote in comment for earlier patch it would be better to separate
> setting PHY registers
> from clock registers.
>

Ok, I'll implement new function
and call it just after exynos_dsi_wait_for_reset().

Thank you.
Best regards YJ

>>   	return fout;
>>   }
>>
>> @@ -1412,6 +1475,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
>>   	dsi->dsi_host.dev = &pdev->dev;
>>
>>   	dsi->dev = &pdev->dev;
>> +	dsi->driver_data = exynos_dsi_get_driver_data(pdev);
>>
>>   	ret = exynos_dsi_parse_dt(dsi);
>>   	if (ret)
>> @@ -1516,11 +1580,6 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
>>   	SET_SYSTEM_SLEEP_PM_OPS(exynos_dsi_suspend, exynos_dsi_resume)
>>   };
>>
>> -static struct of_device_id exynos_dsi_of_match[] = {
>> -	{ .compatible = "samsung,exynos4210-mipi-dsi" },
>> -	{ }
>> -};
>> -
>>   struct platform_driver dsi_driver = {
>>   	.probe = exynos_dsi_probe,
>>   	.remove = exynos_dsi_remove,
>
>

Re: [RFC v2 PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420

[YoungJun Cho]

Hi Andrzej,

On 04/24/2014 10:23 AM, YoungJun Cho wrote:
> Hi Andrzej,
>
> Thank you for comments.
>
> On 04/23/2014 05:29 PM, Andrzej Hajda wrote:
>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>> The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
>>> from the one in Exynos4 SoC.
>>>
>>> In case of Exynos5420 SoC, there is no frequency band bit in
>>> DSIM_PLLCTRL_REG,
>>> and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
>>> So this patch adds driver data to distinguish it.
>>>
>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>> ---
>>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c |  101
>>> ++++++++++++++++++++++++-------
>>>   1 file changed, 80 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index 179f2fa..fcd577f 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -17,6 +17,7 @@
>>>
>>>   #include <linux/clk.h>
>>>   #include <linux/irq.h>
>>> +#include <linux/of_device.h>
>>>   #include <linux/phy/phy.h>
>>>   #include <linux/regulator/consumer.h>
>>>
>>> @@ -54,9 +55,12 @@
>>>
>>>   /* FIFO memory AC characteristic register */
>>>   #define DSIM_PLLCTRL_REG    0x4c    /* PLL control register */
>>> -#define DSIM_PLLTMR_REG        0x50    /* PLL timer register */
>>>   #define DSIM_PHYACCHR_REG    0x54    /* D-PHY AC characteristic
>>> register */
>>>   #define DSIM_PHYACCHR1_REG    0x58    /* D-PHY AC characteristic
>>> register1 */
>>> +#define DSIM_PHYCTRL_REG    0x5c
>>> +#define DSIM_PHYTIMING_REG    0x64
>>> +#define DSIM_PHYTIMING1_REG    0x68
>>> +#define DSIM_PHYTIMING2_REG    0x6c
>>>
>>>   /* DSIM_STATUS */
>>>   #define DSIM_STOP_STATE_DAT(x)        (((x) & 0xf) << 0)
>>> @@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
>>>   #define DSIM_STATE_INITIALIZED        BIT(1)
>>>   #define DSIM_STATE_CMD_LPM        BIT(2)
>>>
>>> +struct exynos_dsi_driver_data {
>>> +    unsigned int plltmr_reg;
>>> +
>>> +    unsigned int has_freqband:1;
>>> +};
>>> +
>>>   struct exynos_dsi {
>>>       struct mipi_dsi_host dsi_host;
>>>       struct drm_connector connector;
>>> @@ -262,11 +272,39 @@ struct exynos_dsi {
>>>
>>>       spinlock_t transfer_lock; /* protects transfer_list */
>>>       struct list_head transfer_list;
>>> +
>>> +    struct exynos_dsi_driver_data *driver_data;
>>>   };
>>>
>>>   #define host_to_dsi(host) container_of(host, struct exynos_dsi,
>>> dsi_host)
>>>   #define connector_to_dsi(c) container_of(c, struct exynos_dsi,
>>> connector)
>>>
>>> +static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
>>> +    .plltmr_reg = 0x50,
>>> +    .has_freqband = 1,
>>> +};
>>> +
>>> +static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
>>> +    .plltmr_reg = 0x58,
>>> +};
>>> +
>>> +static struct of_device_id exynos_dsi_of_match[] = {
>>> +    { .compatible = "samsung,exynos4210-mipi-dsi",
>>> +      .data = &exynos4_dsi_driver_data },
>>> +    { .compatible = "samsung,exynos5420-mipi-dsi",
>>> +      .data = &exynos5_dsi_driver_data },
>>> +    { }
>>> +};
>>
>> I wonder if it wouldn't be better to use "samsung,exynos5410-mipi-dsi"
>> compatible and distinguish 5410 and 5420 by DSIM_VERSION register.
>>
>
> That's because I have only Exynos5420 SoC based target,
> so made DT for that and tested it only.
>
> But it seems to be no problem to use exynos5410 compatible at least
> for the dsi device :).
>
> I'll try.

I posted RFC v3 without this try.

Because there is no exynos5410 relevant DTS yet,
and making exynos5410 DTS is out of scope for this RFC.

Thank you.

Best regards YJ

>
>>
>>> +
>>> +static inline struct exynos_dsi_driver_data
>>> *exynos_dsi_get_driver_data(
>>> +                        struct platform_device *pdev)
>>> +{
>>> +    const struct of_device_id *of_id =
>>> +            of_match_device(exynos_dsi_of_match, &pdev->dev);
>>> +
>>> +    return (struct exynos_dsi_driver_data *)of_id->data;
>>> +}
>>> +
>>>   static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
>>>   {
>>>       if (wait_for_completion_timeout(&dsi->completed,
>>> msecs_to_jiffies(300)))
>>> @@ -340,14 +378,9 @@ static unsigned long
>>> exynos_dsi_pll_find_pms(struct exynos_dsi *dsi,
>>>   static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
>>>                       unsigned long freq)
>>>   {
>>> -    static const unsigned long freq_bands[] = {
>>> -        100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
>>> -        270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
>>> -        510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
>>> -        770 * MHZ, 870 * MHZ, 950 * MHZ,
>>> -    };
>>> +    struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
>>>       unsigned long fin, fout;
>>> -    int timeout, band;
>>> +    int timeout;
>>>       u8 p, s;
>>>       u16 m;
>>>       u32 reg;
>>> @@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct
>>> exynos_dsi *dsi,
>>>               "failed to find PLL PMS for requested frequency\n");
>>>           return -EFAULT;
>>>       }
>>> +    dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p,
>>> m, s);
>>>
>>> -    for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
>>> -        if (fout < freq_bands[band])
>>> -            break;
>>> +    writel(500, dsi->reg_base + driver_data->plltmr_reg);
>>> +
>>> +    reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
>>> +
>>> +    if (driver_data->has_freqband) {
>>> +        static const unsigned long freq_bands[] = {
>>> +            100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
>>> +            270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
>>> +            510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
>>> +            770 * MHZ, 870 * MHZ, 950 * MHZ,
>>> +        };
>>> +        int band;
>>>
>>> -    dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d), band %d\n",
>>> fout,
>>> -        p, m, s, band);
>>> +        for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
>>> +            if (fout < freq_bands[band])
>>> +                break;
>>>
>>> -    writel(500, dsi->reg_base + DSIM_PLLTMR_REG);
>>> +        dev_dbg(dsi->dev, "band %d\n", band);
>>> +
>>> +        reg |= DSIM_FREQ_BAND(band);
>>> +    }
>>>
>>> -    reg = DSIM_FREQ_BAND(band) | DSIM_PLL_EN
>>> -            | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
>>>       writel(reg, dsi->reg_base + DSIM_PLLCTRL_REG);
>>>
>>>       timeout = 1000;
>>> @@ -391,6 +436,24 @@ static unsigned long exynos_dsi_set_pll(struct
>>> exynos_dsi *dsi,
>>>           reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>>>       } while ((reg & DSIM_PLL_STABLE) == 0);
>>>
>>> +    if (!driver_data->has_freqband) {
>>
>> Could you explain why lack of freqband determines necessity of setting
>> PHY
>> registers, is this a kind of hardware setting dependency?
>
> Yes, there is H/W dependency.
> In Exynos4 SoCs, from 24th to 26th bits of DSIM_PLLCTRL register are
> for frequency band.
> But in Exynos5410 / 5420 SoCs, those bits are used for DpDnSwap relevant
> things.
> So PHY ctrl and timing registers are required instead for it.
>
>>
>>> +        /* b dphy ctrl */
>>> +        reg = 0x0af & 0x1ff;
>>> +        writel(reg, dsi->reg_base + DSIM_PHYCTRL_REG);
>>> +
>>> +        /* phy timing */
>>> +        reg = 0x06 << 8 | 0x0b;
>>> +        writel(reg, dsi->reg_base + DSIM_PHYTIMING_REG);
>>> +
>>> +        /* phy timing 1 */
>>> +        reg = 0x07 << 24 | 0x27 << 16 | 0x0d << 8 | 0x08;
>>> +        writel(reg, dsi->reg_base + DSIM_PHYTIMING1_REG);
>>> +
>>> +        /* phy timing 2 */
>>> +        reg = 0x09 << 16 | 0x0d << 8 | 0x0b;
>>> +        writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>>> +    }
>>> +
>>
>> Please use macros if possible instead of magic numbers.
>
> Right, I'll fix.
>
>>
>> As I wrote in comment for earlier patch it would be better to separate
>> setting PHY registers
>> from clock registers.
>>
>
> Ok, I'll implement new function
> and call it just after exynos_dsi_wait_for_reset().
>
> Thank you.
> Best regards YJ
>
>>>       return fout;
>>>   }
>>>
>>> @@ -1412,6 +1475,7 @@ static int exynos_dsi_probe(struct
>>> platform_device *pdev)
>>>       dsi->dsi_host.dev = &pdev->dev;
>>>
>>>       dsi->dev = &pdev->dev;
>>> +    dsi->driver_data = exynos_dsi_get_driver_data(pdev);
>>>
>>>       ret = exynos_dsi_parse_dt(dsi);
>>>       if (ret)
>>> @@ -1516,11 +1580,6 @@ static const struct dev_pm_ops
>>> exynos_dsi_pm_ops = {
>>>       SET_SYSTEM_SLEEP_PM_OPS(exynos_dsi_suspend, exynos_dsi_resume)
>>>   };
>>>
>>> -static struct of_device_id exynos_dsi_of_match[] = {
>>> -    { .compatible = "samsung,exynos4210-mipi-dsi" },
>>> -    { }
>>> -};
>>> -
>>>   struct platform_driver dsi_driver = {
>>>       .probe = exynos_dsi_probe,
>>>       .remove = exynos_dsi_remove,
>>
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu timings.

Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
  (commeted by Laurent Pinchart, Andrzej Hajda)

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 ++++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 0000000..9eeb38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,63 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e3fa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpio: a GPIO spec for the reset pin
+  - det-gpio: a GPIO spec for the OLED detection pin
+  - te-gpio: a GPIO spec for the TE pin
+  - display-timings: timings for the connected panel as described by [1]
+  - cpu-timings: CPU interface timings for the connected panel, and it contains
+        following optional properties.
+          - cs-setup: clock cycles for the active period of address signal
+                enable until chip select is enable in CPU interface
+          - wr-setup: clock cycles for the active period of CS signal enable
+                until write signal is enable in CPU interface
+          - wr-act: clock cycles for the active period of CS enable in CPU
+                interface
+          - wr-hold: clock cycles for the active period of CS disable until
+                write signal is disable in CPU interface
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+	panel@0 {
+		compatible = "samsung,s6e3fa0";
+		reg = <0>;
+		vdd3-supply = <&vcclcd_reg>;
+		vci-supply = <&vlcd_reg>;
+		reset-gpio = <&gpy7 4 0>;
+		det-gpio = <&gpg0 6 0>;
+		te-gpio = <&gpd1 7 0>;
+
+		display-timings {
+			timing0: timing-0 {
+				clock-frequency = <0>;
+				hactive = <1080>;
+				vactive = <1920>;
+				hfront-porch = <2>;
+				hback-porch = <2>;
+				hsync-len = <1>;
+				vfront-porch = <1>;
+				vback-porch = <4>;
+				vsync-len = <1>;
+			};
+		};
+
+		cpu-timings {
+			cs-setup = <0>;
+			wr-setup = <0>;
+			wr-act = <1>;
+			wr-hold = <0>;
+		};
+	};
-- 
1.7.9.5

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu timings.
> 
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> Changelog v3:
> - Removes optional delay, size properties (commented by Laurent Pinchart)
> - Adds OLED detection, TE gpio properties
> Changelog v4:
> - Moves CPU timings relevant properties from FIMD DT
>   (commeted by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> Acked-by: Inki Dae <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 ++++++++++++++++++++
>  1 file changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> new file mode 100644
> index 0000000..9eeb38b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> @@ -0,0 +1,63 @@
> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3fa0"
> +  - reg: the virtual channel number of a DSI peripheral
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpio: a GPIO spec for the reset pin
> +  - det-gpio: a GPIO spec for the OLED detection pin
> +  - te-gpio: a GPIO spec for the TE pin

Just FYI, according to DT documentation [1] gpio spec should be in form
[name]-gpios, however there is plenty bindings with -gpio suffix, so I
am not sure if it is really enforced. On the other side it is enforced
by descriptor based gpio framework[2]. Integer-based gpio framework
used in your driver is obsolete according to [2].

[1]: Documentation/devicetree/bindings/gpio/gpio.txt
[2]: Documentation/gpio/gpio.txt

Regards
Andrzej

> +  - display-timings: timings for the connected panel as described by [1]
> +  - cpu-timings: CPU interface timings for the connected panel, and it contains
> +        following optional properties.
> +          - cs-setup: clock cycles for the active period of address signal
> +                enable until chip select is enable in CPU interface
> +          - wr-setup: clock cycles for the active period of CS signal enable
> +                until write signal is enable in CPU interface
> +          - wr-act: clock cycles for the active period of CS enable in CPU
> +                interface
> +          - wr-hold: clock cycles for the active period of CS disable until
> +                write signal is disable in CPU interface
> +
> +Optional properties:
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +	panel@0 {
> +		compatible = "samsung,s6e3fa0";
> +		reg = <0>;
> +		vdd3-supply = <&vcclcd_reg>;
> +		vci-supply = <&vlcd_reg>;
> +		reset-gpio = <&gpy7 4 0>;
> +		det-gpio = <&gpg0 6 0>;
> +		te-gpio = <&gpd1 7 0>;
> +
> +		display-timings {
> +			timing0: timing-0 {
> +				clock-frequency = <0>;
> +				hactive = <1080>;
> +				vactive = <1920>;
> +				hfront-porch = <2>;
> +				hback-porch = <2>;
> +				hsync-len = <1>;
> +				vfront-porch = <1>;
> +				vback-porch = <4>;
> +				vsync-len = <1>;
> +			};
> +		};
> +
> +		cpu-timings {
> +			cs-setup = <0>;
> +			wr-setup = <0>;
> +			wr-act = <1>;
> +			wr-hold = <0>;
> +		};
> +	};
> 

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

Hi Andrzej

Thank you for comment.

On 04/22/2014 11:02 PM, Andrzej Hajda wrote:
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>> This patch adds DT bindings for s6e3fa0 panel.
>> The bindings describes panel resources, display timings and cpu timings.
>>
>> Changelog v2:
>> - Adds unit address (commented by Sachin Kamat)
>> Changelog v3:
>> - Removes optional delay, size properties (commented by Laurent Pinchart)
>> - Adds OLED detection, TE gpio properties
>> Changelog v4:
>> - Moves CPU timings relevant properties from FIMD DT
>>    (commeted by Laurent Pinchart, Andrzej Hajda)
>>
>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>> Acked-by: Inki Dae <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 ++++++++++++++++++++
>>   1 file changed, 63 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>
>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>> new file mode 100644
>> index 0000000..9eeb38b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>> @@ -0,0 +1,63 @@
>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
>> +
>> +Required properties:
>> +  - compatible: "samsung,s6e3fa0"
>> +  - reg: the virtual channel number of a DSI peripheral
>> +  - vdd3-supply: core voltage supply
>> +  - vci-supply: voltage supply for analog circuits
>> +  - reset-gpio: a GPIO spec for the reset pin
>> +  - det-gpio: a GPIO spec for the OLED detection pin
>> +  - te-gpio: a GPIO spec for the TE pin
>
> Just FYI, according to DT documentation [1] gpio spec should be in form
> [name]-gpios, however there is plenty bindings with -gpio suffix, so I
> am not sure if it is really enforced. On the other side it is enforced
> by descriptor based gpio framework[2]. Integer-based gpio framework
> used in your driver is obsolete according to [2].

Yes, you're right. That is my mistake.
They should be attached 's'.
At first I used integer-based gpio framework and replaced to descriptor
based one, but did not updated DT bindings.

I'll update again.

Thank you.
Best regards YJ

>
> [1]: Documentation/devicetree/bindings/gpio/gpio.txt
> [2]: Documentation/gpio/gpio.txt
>
> Regards
> Andrzej
>
>> +  - display-timings: timings for the connected panel as described by [1]
>> +  - cpu-timings: CPU interface timings for the connected panel, and it contains
>> +        following optional properties.
>> +          - cs-setup: clock cycles for the active period of address signal
>> +                enable until chip select is enable in CPU interface
>> +          - wr-setup: clock cycles for the active period of CS signal enable
>> +                until write signal is enable in CPU interface
>> +          - wr-act: clock cycles for the active period of CS enable in CPU
>> +                interface
>> +          - wr-hold: clock cycles for the active period of CS disable until
>> +                write signal is disable in CPU interface
>> +
>> +Optional properties:
>> +
>> +The device node can contain one 'port' child node with one child
>> +'endpoint' node, according to the bindings defined in [2]. This
>> +node should describe panel's video bus.
>> +
>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +
>> +	panel@0 {
>> +		compatible = "samsung,s6e3fa0";
>> +		reg = <0>;
>> +		vdd3-supply = <&vcclcd_reg>;
>> +		vci-supply = <&vlcd_reg>;
>> +		reset-gpio = <&gpy7 4 0>;
>> +		det-gpio = <&gpg0 6 0>;
>> +		te-gpio = <&gpd1 7 0>;
>> +
>> +		display-timings {
>> +			timing0: timing-0 {
>> +				clock-frequency = <0>;
>> +				hactive = <1080>;
>> +				vactive = <1920>;
>> +				hfront-porch = <2>;
>> +				hback-porch = <2>;
>> +				hsync-len = <1>;
>> +				vfront-porch = <1>;
>> +				vback-porch = <4>;
>> +				vsync-len = <1>;
>> +			};
>> +		};
>> +
>> +		cpu-timings {
>> +			cs-setup = <0>;
>> +			wr-setup = <0>;
>> +			wr-act = <1>;
>> +			wr-hold = <0>;
>> +		};
>> +	};
>>
>
>

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2852 bytes --]

On Wed, Apr 23, 2014 at 10:26:20AM +0900, YoungJun Cho wrote:
> Hi Andrzej
> 
> Thank you for comment.
> 
> On 04/22/2014 11:02 PM, Andrzej Hajda wrote:
> >On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> >>This patch adds DT bindings for s6e3fa0 panel.
> >>The bindings describes panel resources, display timings and cpu timings.
> >>
> >>Changelog v2:
> >>- Adds unit address (commented by Sachin Kamat)
> >>Changelog v3:
> >>- Removes optional delay, size properties (commented by Laurent Pinchart)
> >>- Adds OLED detection, TE gpio properties
> >>Changelog v4:
> >>- Moves CPU timings relevant properties from FIMD DT
> >>   (commeted by Laurent Pinchart, Andrzej Hajda)
> >>
> >>Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> >>Acked-by: Inki Dae <inki.dae@samsung.com>
> >>Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> >>---
> >>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 ++++++++++++++++++++
> >>  1 file changed, 63 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>
> >>diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>new file mode 100644
> >>index 0000000..9eeb38b
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>@@ -0,0 +1,63 @@
> >>+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> >>+
> >>+Required properties:
> >>+  - compatible: "samsung,s6e3fa0"
> >>+  - reg: the virtual channel number of a DSI peripheral
> >>+  - vdd3-supply: core voltage supply
> >>+  - vci-supply: voltage supply for analog circuits
> >>+  - reset-gpio: a GPIO spec for the reset pin
> >>+  - det-gpio: a GPIO spec for the OLED detection pin
> >>+  - te-gpio: a GPIO spec for the TE pin
> >
> >Just FYI, according to DT documentation [1] gpio spec should be in form
> >[name]-gpios, however there is plenty bindings with -gpio suffix, so I
> >am not sure if it is really enforced. On the other side it is enforced
> >by descriptor based gpio framework[2]. Integer-based gpio framework
> >used in your driver is obsolete according to [2].
> 
> Yes, you're right. That is my mistake.
> They should be attached 's'.
> At first I used integer-based gpio framework and replaced to descriptor
> based one, but did not updated DT bindings.

I've been working on a patch to support both *-gpios and *-gpio variants
with the GPIO descriptor framework. *-gpios makes sense if there can
indeed be several, but for something like hotplug detection I don't
think there's a reason to require the plural.

Furthermore some bindings already use the singular *-gpio anyway, so if
we ever want to convert drivers using those bindings to the GPIO
descriptor API we have to support that form too.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu timings.
> 
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> Changelog v3:
> - Removes optional delay, size properties (commented by Laurent Pinchart)
> - Adds OLED detection, TE gpio properties
> Changelog v4:
> - Moves CPU timings relevant properties from FIMD DT
>   (commeted by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> Acked-by: Inki Dae <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 ++++++++++++++++++++
>  1 file changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> new file mode 100644
> index 0000000..9eeb38b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> @@ -0,0 +1,63 @@
> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3fa0"
> +  - reg: the virtual channel number of a DSI peripheral
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpio: a GPIO spec for the reset pin
> +  - det-gpio: a GPIO spec for the OLED detection pin
> +  - te-gpio: a GPIO spec for the TE pin
> +  - display-timings: timings for the connected panel as described by [1]

Which properties of display-timings are relevant for CPU mode?
I guess width and height. Anything more?

> +  - cpu-timings: CPU interface timings for the connected panel, and it contains
> +        following optional properties.
> +          - cs-setup: clock cycles for the active period of address signal
> +                enable until chip select is enable in CPU interface
> +          - wr-setup: clock cycles for the active period of CS signal enable
> +                until write signal is enable in CPU interface
> +          - wr-act: clock cycles for the active period of CS enable in CPU
> +                interface
> +          - wr-hold: clock cycles for the active period of CS disable until
> +                write signal is disable in CPU interface

cpu-timings name does not sound to be related to display.
I wonder if it would not be better to merge cpu-timings into
display-timings but this will require more discussion I guess.

If you want to stay with separate node please consider to make it
optional as whole node or make some properties required. Making node
required with all sub-properties optional is weird.
By the way I hope all timings properties are generic for CPU mode,
if not they should be prefixed by vendor or model.

Regards
Andrzej

> +
> +Optional properties:
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +	panel@0 {
> +		compatible = "samsung,s6e3fa0";
> +		reg = <0>;
> +		vdd3-supply = <&vcclcd_reg>;
> +		vci-supply = <&vlcd_reg>;
> +		reset-gpio = <&gpy7 4 0>;
> +		det-gpio = <&gpg0 6 0>;
> +		te-gpio = <&gpd1 7 0>;
> +
> +		display-timings {
> +			timing0: timing-0 {
> +				clock-frequency = <0>;
> +				hactive = <1080>;
> +				vactive = <1920>;
> +				hfront-porch = <2>;
> +				hback-porch = <2>;
> +				hsync-len = <1>;
> +				vfront-porch = <1>;
> +				vback-porch = <4>;
> +				vsync-len = <1>;
> +			};
> +		};
> +
> +		cpu-timings {
> +			cs-setup = <0>;
> +			wr-setup = <0>;
> +			wr-act = <1>;
> +			wr-hold = <0>;
> +		};
> +	};
> 

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Laurent Pinchart]

Hi Andrzej,

On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> > This patch adds DT bindings for s6e3fa0 panel.
> > The bindings describes panel resources, display timings and cpu timings.
> > 
> > Changelog v2:
> > - Adds unit address (commented by Sachin Kamat)
> > Changelog v3:
> > - Removes optional delay, size properties (commented by Laurent Pinchart)
> > - Adds OLED detection, TE gpio properties
> > Changelog v4:
> > - Moves CPU timings relevant properties from FIMD DT
> > 
> >   (commeted by Laurent Pinchart, Andrzej Hajda)
> > 
> > Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> > Acked-by: Inki Dae <inki.dae@samsung.com>
> > Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> > 
> >  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 +++++++++++++++
> > 1 file changed, 63 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt> 
> > diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> > b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
> > mode 100644
> > index 0000000..9eeb38b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> > @@ -0,0 +1,63 @@
> > +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> > +
> > +Required properties:
> > +  - compatible: "samsung,s6e3fa0"
> > +  - reg: the virtual channel number of a DSI peripheral
> > +  - vdd3-supply: core voltage supply
> > +  - vci-supply: voltage supply for analog circuits
> > +  - reset-gpio: a GPIO spec for the reset pin
> > +  - det-gpio: a GPIO spec for the OLED detection pin
> > +  - te-gpio: a GPIO spec for the TE pin
> > +  - display-timings: timings for the connected panel as described by [1]
> 
> Which properties of display-timings are relevant for CPU mode?
> I guess width and height. Anything more?
> 
> > +  - cpu-timings: CPU interface timings for the connected panel, and it
> > contains
> > +        following optional properties.
> > +          - cs-setup: clock cycles for the active period of address
> > signal
> > +                enable until chip select is enable in CPU interface
> > +          - wr-setup: clock cycles for the active period of CS signal
> > enable
> > +                until write signal is enable in CPU interface
> > +          - wr-act: clock cycles for the active period of CS enable in
> > CPU
> > +                interface

What about calling this property wr-active ? I had called this wr-cycle in a 
previous implementation, that could be an option as well.

> > +          - wr-hold: clock cycles for the active period of CS disable
> > until
> > +                write signal is disable in CPU interface
> 
> cpu-timings name does not sound to be related to display.
> I wonder if it would not be better to merge cpu-timings into
> display-timings but this will require more discussion I guess.

The panel has a memory-like interface with chip select, read/write and access 
strobe, address (1 bit) and data signals. The interface is defined in the MIPI 
DBI specification (a quick search turned up 
http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be 
direct PDF downloads available), even if some panels implement a similar 
interface that predates MIPI DBI (with names such as i80 or SYS-80 probably 
due to the similarities with the 8051 external bus).

The cpu-timings properties describe the read and write access timings for 
those signals, unrelated to the display video timings. I thus believe that 
they should be separate from the display timings. We will probably need to add 
properties for the read signal as well, but that can be done later.

> If you want to stay with separate node please consider to make it
> optional as whole node or make some properties required. Making node
> required with all sub-properties optional is weird.
> By the way I hope all timings properties are generic for CPU mode,
> if not they should be prefixed by vendor or model.

The timings description should be pretty generic I believe, especially given 
that the interface is standardized by the MIPI alliance. Could you have a 
quick look at the spec and share your opinion ?

> > +
> > +Optional properties:
> > +
> > +The device node can contain one 'port' child node with one child
> > +'endpoint' node, according to the bindings defined in [2]. This
> > +node should describe panel's video bus.
> > +
> > +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> > +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> > +
> > +Example:
> > +
> > +	panel@0 {
> > +		compatible = "samsung,s6e3fa0";
> > +		reg = <0>;
> > +		vdd3-supply = <&vcclcd_reg>;
> > +		vci-supply = <&vlcd_reg>;
> > +		reset-gpio = <&gpy7 4 0>;
> > +		det-gpio = <&gpg0 6 0>;
> > +		te-gpio = <&gpd1 7 0>;
> > +
> > +		display-timings {
> > +			timing0: timing-0 {
> > +				clock-frequency = <0>;
> > +				hactive = <1080>;
> > +				vactive = <1920>;
> > +				hfront-porch = <2>;
> > +				hback-porch = <2>;
> > +				hsync-len = <1>;
> > +				vfront-porch = <1>;
> > +				vback-porch = <4>;
> > +				vsync-len = <1>;
> > +			};
> > +		};
> > +
> > +		cpu-timings {
> > +			cs-setup = <0>;
> > +			wr-setup = <0>;
> > +			wr-act = <1>;
> > +			wr-hold = <0>;
> > +		};
> > +	};

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>> This patch adds DT bindings for s6e3fa0 panel.
>>> The bindings describes panel resources, display timings and cpu timings.
>>>
>>> Changelog v2:
>>> - Adds unit address (commented by Sachin Kamat)
>>> Changelog v3:
>>> - Removes optional delay, size properties (commented by Laurent Pinchart)
>>> - Adds OLED detection, TE gpio properties
>>> Changelog v4:
>>> - Moves CPU timings relevant properties from FIMD DT
>>>
>>>   (commeted by Laurent Pinchart, Andrzej Hajda)
>>>
>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>> ---
>>>
>>>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 +++++++++++++++
>>> 1 file changed, 63 insertions(+)
>>>  create mode 100644
>>>  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt> 
>>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
>>> mode 100644
>>> index 0000000..9eeb38b
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>> @@ -0,0 +1,63 @@
>>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
>>> +
>>> +Required properties:
>>> +  - compatible: "samsung,s6e3fa0"
>>> +  - reg: the virtual channel number of a DSI peripheral
>>> +  - vdd3-supply: core voltage supply
>>> +  - vci-supply: voltage supply for analog circuits
>>> +  - reset-gpio: a GPIO spec for the reset pin
>>> +  - det-gpio: a GPIO spec for the OLED detection pin
>>> +  - te-gpio: a GPIO spec for the TE pin
>>> +  - display-timings: timings for the connected panel as described by [1]
>> Which properties of display-timings are relevant for CPU mode?
>> I guess width and height. Anything more?
>>
>>> +  - cpu-timings: CPU interface timings for the connected panel, and it
>>> contains
>>> +        following optional properties.
>>> +          - cs-setup: clock cycles for the active period of address
>>> signal
>>> +                enable until chip select is enable in CPU interface
>>> +          - wr-setup: clock cycles for the active period of CS signal
>>> enable
>>> +                until write signal is enable in CPU interface
>>> +          - wr-act: clock cycles for the active period of CS enable in
>>> CPU
>>> +                interface
> What about calling this property wr-active ? I had called this wr-cycle in a 
> previous implementation, that could be an option as well.
>
>>> +          - wr-hold: clock cycles for the active period of CS disable
>>> until
>>> +                write signal is disable in CPU interface
>> cpu-timings name does not sound to be related to display.
>> I wonder if it would not be better to merge cpu-timings into
>> display-timings but this will require more discussion I guess.
> The panel has a memory-like interface with chip select, read/write and access 
> strobe, address (1 bit) and data signals. The interface is defined in the MIPI 
> DBI specification (a quick search turned up 
> http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be 
> direct PDF downloads available), even if some panels implement a similar 
> interface that predates MIPI DBI (with names such as i80 or SYS-80 probably 
> due to the similarities with the 8051 external bus).
>
> The cpu-timings properties describe the read and write access timings for 
> those signals, unrelated to the display video timings. I thus believe that 
> they should be separate from the display timings. We will probably need to add 
> properties for the read signal as well, but that can be done later.

cpu-timings suggests these timings are for CPU, but they are for display
panel in CPU mode.
I though rather about something like display-cpu-timings or i80-timings,
just to avoid confusion.

Regards
Andrzej

>> If you want to stay with separate node please consider to make it
>> optional as whole node or make some properties required. Making node
>> required with all sub-properties optional is weird.
>> By the way I hope all timings properties are generic for CPU mode,
>> if not they should be prefixed by vendor or model.
> The timings description should be pretty generic I believe, especially given 
> that the interface is standardized by the MIPI alliance. Could you have a 
> quick look at the spec and share your opinion ?
>
>>> +
>>> +Optional properties:
>>> +
>>> +The device node can contain one 'port' child node with one child
>>> +'endpoint' node, according to the bindings defined in [2]. This
>>> +node should describe panel's video bus.
>>> +
>>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> +	panel@0 {
>>> +		compatible = "samsung,s6e3fa0";
>>> +		reg = <0>;
>>> +		vdd3-supply = <&vcclcd_reg>;
>>> +		vci-supply = <&vlcd_reg>;
>>> +		reset-gpio = <&gpy7 4 0>;
>>> +		det-gpio = <&gpg0 6 0>;
>>> +		te-gpio = <&gpd1 7 0>;
>>> +
>>> +		display-timings {
>>> +			timing0: timing-0 {
>>> +				clock-frequency = <0>;
>>> +				hactive = <1080>;
>>> +				vactive = <1920>;
>>> +				hfront-porch = <2>;
>>> +				hback-porch = <2>;
>>> +				hsync-len = <1>;
>>> +				vfront-porch = <1>;
>>> +				vback-porch = <4>;
>>> +				vsync-len = <1>;
>>> +			};
>>> +		};
>>> +
>>> +		cpu-timings {
>>> +			cs-setup = <0>;
>>> +			wr-setup = <0>;
>>> +			wr-act = <1>;
>>> +			wr-hold = <0>;
>>> +		};
>>> +	};

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Laurent Pinchart]

Hi Andrzej,

On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:
> On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
> > On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
> >> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> >>> This patch adds DT bindings for s6e3fa0 panel.
> >>> The bindings describes panel resources, display timings and cpu timings.
> >>> 
> >>> Changelog v2:
> >>> - Adds unit address (commented by Sachin Kamat)
> >>> Changelog v3:
> >>> - Removes optional delay, size properties (commented by Laurent
> >>> Pinchart)
> >>> - Adds OLED detection, TE gpio properties
> >>> Changelog v4:
> >>> - Moves CPU timings relevant properties from FIMD DT
> >>> 
> >>>   (commeted by Laurent Pinchart, Andrzej Hajda)
> >>> 
> >>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> >>> Acked-by: Inki Dae <inki.dae@samsung.com>
> >>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> >>> ---
> >>> 
> >>>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63
> >>>  +++++++++++++++
> >>> 
> >>> 1 file changed, 63 insertions(+)
> >>> 
> >>>  create mode 100644
> >>>  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>
> >>> 
> >>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
> >>> mode 100644
> >>> index 0000000..9eeb38b
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>> @@ -0,0 +1,63 @@
> >>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> >>> +
> >>> +Required properties:
> >>> +  - compatible: "samsung,s6e3fa0"
> >>> +  - reg: the virtual channel number of a DSI peripheral
> >>> +  - vdd3-supply: core voltage supply
> >>> +  - vci-supply: voltage supply for analog circuits
> >>> +  - reset-gpio: a GPIO spec for the reset pin
> >>> +  - det-gpio: a GPIO spec for the OLED detection pin
> >>> +  - te-gpio: a GPIO spec for the TE pin
> >>> +  - display-timings: timings for the connected panel as described by
> >>> [1]
> >> 
> >> Which properties of display-timings are relevant for CPU mode?
> >> I guess width and height. Anything more?
> >> 
> >>> +  - cpu-timings: CPU interface timings for the connected panel, and it
> >>> contains
> >>> +        following optional properties.
> >>> +          - cs-setup: clock cycles for the active period of address
> >>> signal
> >>> +                enable until chip select is enable in CPU interface
> >>> +          - wr-setup: clock cycles for the active period of CS signal
> >>> enable
> >>> +                until write signal is enable in CPU interface
> >>> +          - wr-act: clock cycles for the active period of CS enable in
> >>> CPU
> >>> +                interface
> > 
> > What about calling this property wr-active ? I had called this wr-cycle in
> > a previous implementation, that could be an option as well.
> > 
> >>> +          - wr-hold: clock cycles for the active period of CS disable
> >>> until
> >>> +                write signal is disable in CPU interface
> >> 
> >> cpu-timings name does not sound to be related to display.
> >> I wonder if it would not be better to merge cpu-timings into
> >> display-timings but this will require more discussion I guess.
> > 
> > The panel has a memory-like interface with chip select, read/write and
> > access strobe, address (1 bit) and data signals. The interface is defined
> > in the MIPI DBI specification (a quick search turned up
> > http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might
> > be direct PDF downloads available), even if some panels implement a
> > similar interface that predates MIPI DBI (with names such as i80 or
> > SYS-80 probably due to the similarities with the 8051 external bus).
> > 
> > The cpu-timings properties describe the read and write access timings for
> > those signals, unrelated to the display video timings. I thus believe that
> > they should be separate from the display timings. We will probably need to
> > add properties for the read signal as well, but that can be done later.
>
> cpu-timings suggests these timings are for CPU, but they are for display
> panel in CPU mode.
> I though rather about something like display-cpu-timings or i80-timings,
> just to avoid confusion.

mipi-dbi-timings maybe ?

> >> If you want to stay with separate node please consider to make it
> >> optional as whole node or make some properties required. Making node
> >> required with all sub-properties optional is weird.
> >> By the way I hope all timings properties are generic for CPU mode,
> >> if not they should be prefixed by vendor or model.
> > 
> > The timings description should be pretty generic I believe, especially
> > given that the interface is standardized by the MIPI alliance. Could you
> > have a quick look at the spec and share your opinion ?
> > 
> >>> +
> >>> +Optional properties:
> >>> +
> >>> +The device node can contain one 'port' child node with one child
> >>> +'endpoint' node, according to the bindings defined in [2]. This
> >>> +node should describe panel's video bus.
> >>> +
> >>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> >>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> >>> +
> >>> +Example:
> >>> +
> >>> +	panel@0 {
> >>> +		compatible = "samsung,s6e3fa0";
> >>> +		reg = <0>;
> >>> +		vdd3-supply = <&vcclcd_reg>;
> >>> +		vci-supply = <&vlcd_reg>;
> >>> +		reset-gpio = <&gpy7 4 0>;
> >>> +		det-gpio = <&gpg0 6 0>;
> >>> +		te-gpio = <&gpd1 7 0>;
> >>> +
> >>> +		display-timings {
> >>> +			timing0: timing-0 {
> >>> +				clock-frequency = <0>;
> >>> +				hactive = <1080>;
> >>> +				vactive = <1920>;
> >>> +				hfront-porch = <2>;
> >>> +				hback-porch = <2>;
> >>> +				hsync-len = <1>;
> >>> +				vfront-porch = <1>;
> >>> +				vback-porch = <4>;
> >>> +				vsync-len = <1>;
> >>> +			};
> >>> +		};
> >>> +
> >>> +		cpu-timings {
> >>> +			cs-setup = <0>;
> >>> +			wr-setup = <0>;
> >>> +			wr-act = <1>;
> >>> +			wr-hold = <0>;
> >>> +		};
> >>> +	};

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/23/2014 02:55 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:
>> On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
>>> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
>>>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>>>> This patch adds DT bindings for s6e3fa0 panel.
>>>>> The bindings describes panel resources, display timings and cpu timings.
>>>>>
>>>>> Changelog v2:
>>>>> - Adds unit address (commented by Sachin Kamat)
>>>>> Changelog v3:
>>>>> - Removes optional delay, size properties (commented by Laurent
>>>>> Pinchart)
>>>>> - Adds OLED detection, TE gpio properties
>>>>> Changelog v4:
>>>>> - Moves CPU timings relevant properties from FIMD DT
>>>>>
>>>>>   (commeted by Laurent Pinchart, Andrzej Hajda)
>>>>>
>>>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>> ---
>>>>>
>>>>>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63
>>>>>  +++++++++++++++
>>>>>
>>>>> 1 file changed, 63 insertions(+)
>>>>>
>>>>>  create mode 100644
>>>>>  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>>>> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
>>>>> mode 100644
>>>>> index 0000000..9eeb38b
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>>>> @@ -0,0 +1,63 @@
>>>>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
>>>>> +
>>>>> +Required properties:
>>>>> +  - compatible: "samsung,s6e3fa0"
>>>>> +  - reg: the virtual channel number of a DSI peripheral
>>>>> +  - vdd3-supply: core voltage supply
>>>>> +  - vci-supply: voltage supply for analog circuits
>>>>> +  - reset-gpio: a GPIO spec for the reset pin
>>>>> +  - det-gpio: a GPIO spec for the OLED detection pin
>>>>> +  - te-gpio: a GPIO spec for the TE pin
>>>>> +  - display-timings: timings for the connected panel as described by
>>>>> [1]
>>>> Which properties of display-timings are relevant for CPU mode?
>>>> I guess width and height. Anything more?
>>>>
>>>>> +  - cpu-timings: CPU interface timings for the connected panel, and it
>>>>> contains
>>>>> +        following optional properties.
>>>>> +          - cs-setup: clock cycles for the active period of address
>>>>> signal
>>>>> +                enable until chip select is enable in CPU interface
>>>>> +          - wr-setup: clock cycles for the active period of CS signal
>>>>> enable
>>>>> +                until write signal is enable in CPU interface
>>>>> +          - wr-act: clock cycles for the active period of CS enable in
>>>>> CPU
>>>>> +                interface
>>> What about calling this property wr-active ? I had called this wr-cycle in
>>> a previous implementation, that could be an option as well.
>>>
>>>>> +          - wr-hold: clock cycles for the active period of CS disable
>>>>> until
>>>>> +                write signal is disable in CPU interface
>>>> cpu-timings name does not sound to be related to display.
>>>> I wonder if it would not be better to merge cpu-timings into
>>>> display-timings but this will require more discussion I guess.
>>> The panel has a memory-like interface with chip select, read/write and
>>> access strobe, address (1 bit) and data signals. The interface is defined
>>> in the MIPI DBI specification (a quick search turned up
>>> http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might
>>> be direct PDF downloads available), even if some panels implement a
>>> similar interface that predates MIPI DBI (with names such as i80 or
>>> SYS-80 probably due to the similarities with the 8051 external bus).
>>>
>>> The cpu-timings properties describe the read and write access timings for
>>> those signals, unrelated to the display video timings. I thus believe that
>>> they should be separate from the display timings. We will probably need to
>>> add properties for the read signal as well, but that can be done later.
>> cpu-timings suggests these timings are for CPU, but they are for display
>> panel in CPU mode.
>> I though rather about something like display-cpu-timings or i80-timings,
>> just to avoid confusion.
> mipi-dbi-timings maybe ?

It looks OK.

I guess only hactive, and vactive props of display-timings are used,
maybe some flags?
I wonder if it would not be better to drop display-timings node
and place all props into mipi-dbi-timings or mipi-dbi-settings node.
Or rather all timings props should be put into port/endpoint node with
or without
any container node.

Regards
Andrzej

>
>>>> If you want to stay with separate node please consider to make it
>>>> optional as whole node or make some properties required. Making node
>>>> required with all sub-properties optional is weird.
>>>> By the way I hope all timings properties are generic for CPU mode,
>>>> if not they should be prefixed by vendor or model.
>>> The timings description should be pretty generic I believe, especially
>>> given that the interface is standardized by the MIPI alliance. Could you
>>> have a quick look at the spec and share your opinion ?
>>>
>>>>> +
>>>>> +Optional properties:
>>>>> +
>>>>> +The device node can contain one 'port' child node with one child
>>>>> +'endpoint' node, according to the bindings defined in [2]. This
>>>>> +node should describe panel's video bus.
>>>>> +
>>>>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>>>>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +	panel@0 {
>>>>> +		compatible = "samsung,s6e3fa0";
>>>>> +		reg = <0>;
>>>>> +		vdd3-supply = <&vcclcd_reg>;
>>>>> +		vci-supply = <&vlcd_reg>;
>>>>> +		reset-gpio = <&gpy7 4 0>;
>>>>> +		det-gpio = <&gpg0 6 0>;
>>>>> +		te-gpio = <&gpd1 7 0>;
>>>>> +
>>>>> +		display-timings {
>>>>> +			timing0: timing-0 {
>>>>> +				clock-frequency = <0>;
>>>>> +				hactive = <1080>;
>>>>> +				vactive = <1920>;
>>>>> +				hfront-porch = <2>;
>>>>> +				hback-porch = <2>;
>>>>> +				hsync-len = <1>;
>>>>> +				vfront-porch = <1>;
>>>>> +				vback-porch = <4>;
>>>>> +				vsync-len = <1>;
>>>>> +			};
>>>>> +		};
>>>>> +
>>>>> +		cpu-timings {
>>>>> +			cs-setup = <0>;
>>>>> +			wr-setup = <0>;
>>>>> +			wr-act = <1>;
>>>>> +			wr-hold = <0>;
>>>>> +		};
>>>>> +	};

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

Hi Andrzej,

On 04/23/2014 10:33 PM, Andrzej Hajda wrote:
> On 04/23/2014 02:55 PM, Laurent Pinchart wrote:
>> Hi Andrzej,
>>
>> On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:
>>> On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
>>>> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
>>>>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>>>>> This patch adds DT bindings for s6e3fa0 panel.
>>>>>> The bindings describes panel resources, display timings and cpu timings.
>>>>>>
>>>>>> Changelog v2:
>>>>>> - Adds unit address (commented by Sachin Kamat)
>>>>>> Changelog v3:
>>>>>> - Removes optional delay, size properties (commented by Laurent
>>>>>> Pinchart)
>>>>>> - Adds OLED detection, TE gpio properties
>>>>>> Changelog v4:
>>>>>> - Moves CPU timings relevant properties from FIMD DT
>>>>>>
>>>>>>    (commeted by Laurent Pinchart, Andrzej Hajda)
>>>>>>
>>>>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>>>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>>> ---
>>>>>>
>>>>>>   .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63
>>>>>>   +++++++++++++++
>>>>>>
>>>>>> 1 file changed, 63 insertions(+)
>>>>>>
>>>>>>   create mode 100644
>>>>>>   Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>>>>> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
>>>>>> mode 100644
>>>>>> index 0000000..9eeb38b
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>>>>> @@ -0,0 +1,63 @@
>>>>>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
>>>>>> +
>>>>>> +Required properties:
>>>>>> +  - compatible: "samsung,s6e3fa0"
>>>>>> +  - reg: the virtual channel number of a DSI peripheral
>>>>>> +  - vdd3-supply: core voltage supply
>>>>>> +  - vci-supply: voltage supply for analog circuits
>>>>>> +  - reset-gpio: a GPIO spec for the reset pin
>>>>>> +  - det-gpio: a GPIO spec for the OLED detection pin
>>>>>> +  - te-gpio: a GPIO spec for the TE pin
>>>>>> +  - display-timings: timings for the connected panel as described by
>>>>>> [1]
>>>>> Which properties of display-timings are relevant for CPU mode?
>>>>> I guess width and height. Anything more?
>>>>>
>>>>>> +  - cpu-timings: CPU interface timings for the connected panel, and it
>>>>>> contains
>>>>>> +        following optional properties.
>>>>>> +          - cs-setup: clock cycles for the active period of address
>>>>>> signal
>>>>>> +                enable until chip select is enable in CPU interface
>>>>>> +          - wr-setup: clock cycles for the active period of CS signal
>>>>>> enable
>>>>>> +                until write signal is enable in CPU interface
>>>>>> +          - wr-act: clock cycles for the active period of CS enable in
>>>>>> CPU
>>>>>> +                interface
>>>> What about calling this property wr-active ? I had called this wr-cycle in
>>>> a previous implementation, that could be an option as well.
>>>>
>>>>>> +          - wr-hold: clock cycles for the active period of CS disable
>>>>>> until
>>>>>> +                write signal is disable in CPU interface
>>>>> cpu-timings name does not sound to be related to display.
>>>>> I wonder if it would not be better to merge cpu-timings into
>>>>> display-timings but this will require more discussion I guess.
>>>> The panel has a memory-like interface with chip select, read/write and
>>>> access strobe, address (1 bit) and data signals. The interface is defined
>>>> in the MIPI DBI specification (a quick search turned up
>>>> http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might
>>>> be direct PDF downloads available), even if some panels implement a
>>>> similar interface that predates MIPI DBI (with names such as i80 or
>>>> SYS-80 probably due to the similarities with the 8051 external bus).
>>>>
>>>> The cpu-timings properties describe the read and write access timings for
>>>> those signals, unrelated to the display video timings. I thus believe that
>>>> they should be separate from the display timings. We will probably need to
>>>> add properties for the read signal as well, but that can be done later.
>>> cpu-timings suggests these timings are for CPU, but they are for display
>>> panel in CPU mode.
>>> I though rather about something like display-cpu-timings or i80-timings,
>>> just to avoid confusion.
>> mipi-dbi-timings maybe ?
>
> It looks OK.

Isn't it too generic? I prefer cpu-mode-timings.

>
> I guess only hactive, and vactive props of display-timings are used,
> maybe some flags?
> I wonder if it would not be better to drop display-timings node
> and place all props into mipi-dbi-timings or mipi-dbi-settings node.
> Or rather all timings props should be put into port/endpoint node with
> or without
> any container node.

The current 'display-timings' is for video mode interface,
but cpu mode interface requires it.

If we use mipi-dbi-timings, we should change previous video mode
relevant ones at all.

Thank you.
Best regards YJ

>
> Regards
> Andrzej
>
>>
>>>>> If you want to stay with separate node please consider to make it
>>>>> optional as whole node or make some properties required. Making node
>>>>> required with all sub-properties optional is weird.
>>>>> By the way I hope all timings properties are generic for CPU mode,
>>>>> if not they should be prefixed by vendor or model.
>>>> The timings description should be pretty generic I believe, especially
>>>> given that the interface is standardized by the MIPI alliance. Could you
>>>> have a quick look at the spec and share your opinion ?
>>>>
>>>>>> +
>>>>>> +Optional properties:
>>>>>> +
>>>>>> +The device node can contain one 'port' child node with one child
>>>>>> +'endpoint' node, according to the bindings defined in [2]. This
>>>>>> +node should describe panel's video bus.
>>>>>> +
>>>>>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>>>>>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>>>>> +
>>>>>> +Example:
>>>>>> +
>>>>>> +	panel@0 {
>>>>>> +		compatible = "samsung,s6e3fa0";
>>>>>> +		reg = <0>;
>>>>>> +		vdd3-supply = <&vcclcd_reg>;
>>>>>> +		vci-supply = <&vlcd_reg>;
>>>>>> +		reset-gpio = <&gpy7 4 0>;
>>>>>> +		det-gpio = <&gpg0 6 0>;
>>>>>> +		te-gpio = <&gpd1 7 0>;
>>>>>> +
>>>>>> +		display-timings {
>>>>>> +			timing0: timing-0 {
>>>>>> +				clock-frequency = <0>;
>>>>>> +				hactive = <1080>;
>>>>>> +				vactive = <1920>;
>>>>>> +				hfront-porch = <2>;
>>>>>> +				hback-porch = <2>;
>>>>>> +				hsync-len = <1>;
>>>>>> +				vfront-porch = <1>;
>>>>>> +				vback-porch = <4>;
>>>>>> +				vsync-len = <1>;
>>>>>> +			};
>>>>>> +		};
>>>>>> +
>>>>>> +		cpu-timings {
>>>>>> +			cs-setup = <0>;
>>>>>> +			wr-setup = <0>;
>>>>>> +			wr-act = <1>;
>>>>>> +			wr-hold = <0>;
>>>>>> +		};
>>>>>> +	};
>
>

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

Hi Laurent,

Thank you for comments.

On 04/23/2014 08:34 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>> This patch adds DT bindings for s6e3fa0 panel.
>>> The bindings describes panel resources, display timings and cpu timings.
>>>
>>> Changelog v2:
>>> - Adds unit address (commented by Sachin Kamat)
>>> Changelog v3:
>>> - Removes optional delay, size properties (commented by Laurent Pinchart)
>>> - Adds OLED detection, TE gpio properties
>>> Changelog v4:
>>> - Moves CPU timings relevant properties from FIMD DT
>>>
>>>    (commeted by Laurent Pinchart, Andrzej Hajda)
>>>
>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>> ---
>>>
>>>   .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 +++++++++++++++
>>> 1 file changed, 63 insertions(+)
>>>   create mode 100644
>>>   Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>
>>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
>>> mode 100644
>>> index 0000000..9eeb38b
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>> @@ -0,0 +1,63 @@
>>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
>>> +
>>> +Required properties:
>>> +  - compatible: "samsung,s6e3fa0"
>>> +  - reg: the virtual channel number of a DSI peripheral
>>> +  - vdd3-supply: core voltage supply
>>> +  - vci-supply: voltage supply for analog circuits
>>> +  - reset-gpio: a GPIO spec for the reset pin
>>> +  - det-gpio: a GPIO spec for the OLED detection pin
>>> +  - te-gpio: a GPIO spec for the TE pin
>>> +  - display-timings: timings for the connected panel as described by [1]
>>
>> Which properties of display-timings are relevant for CPU mode?
>> I guess width and height. Anything more?
>>
>>> +  - cpu-timings: CPU interface timings for the connected panel, and it
>>> contains
>>> +        following optional properties.
>>> +          - cs-setup: clock cycles for the active period of address
>>> signal
>>> +                enable until chip select is enable in CPU interface
>>> +          - wr-setup: clock cycles for the active period of CS signal
>>> enable
>>> +                until write signal is enable in CPU interface
>>> +          - wr-act: clock cycles for the active period of CS enable in
>>> CPU
>>> +                interface
>
> What about calling this property wr-active ? I had called this wr-cycle in a
> previous implementation, that could be an option as well.

Okay, I'll use wr-active. It's better.

>
>>> +          - wr-hold: clock cycles for the active period of CS disable
>>> until
>>> +                write signal is disable in CPU interface
>>
>> cpu-timings name does not sound to be related to display.
>> I wonder if it would not be better to merge cpu-timings into
>> display-timings but this will require more discussion I guess.
>
> The panel has a memory-like interface with chip select, read/write and access
> strobe, address (1 bit) and data signals. The interface is defined in the MIPI
> DBI specification (a quick search turned up
> http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be
> direct PDF downloads available), even if some panels implement a similar
> interface that predates MIPI DBI (with names such as i80 or SYS-80 probably
> due to the similarities with the 8051 external bus).
>
> The cpu-timings properties describe the read and write access timings for
> those signals, unrelated to the display video timings. I thus believe that
> they should be separate from the display timings. We will probably need to add
> properties for the read signal as well, but that can be done later.

Yes, as I wrote another thread before, this cpu interface timings is
additional one. The video timings is required also.

Thank you.
Best regards YJ

>
>> If you want to stay with separate node please consider to make it
>> optional as whole node or make some properties required. Making node
>> required with all sub-properties optional is weird.
>> By the way I hope all timings properties are generic for CPU mode,
>> if not they should be prefixed by vendor or model.
>
> The timings description should be pretty generic I believe, especially given
> that the interface is standardized by the MIPI alliance. Could you have a
> quick look at the spec and share your opinion ?
>
>>> +
>>> +Optional properties:
>>> +
>>> +The device node can contain one 'port' child node with one child
>>> +'endpoint' node, according to the bindings defined in [2]. This
>>> +node should describe panel's video bus.
>>> +
>>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> +	panel@0 {
>>> +		compatible = "samsung,s6e3fa0";
>>> +		reg = <0>;
>>> +		vdd3-supply = <&vcclcd_reg>;
>>> +		vci-supply = <&vlcd_reg>;
>>> +		reset-gpio = <&gpy7 4 0>;
>>> +		det-gpio = <&gpg0 6 0>;
>>> +		te-gpio = <&gpd1 7 0>;
>>> +
>>> +		display-timings {
>>> +			timing0: timing-0 {
>>> +				clock-frequency = <0>;
>>> +				hactive = <1080>;
>>> +				vactive = <1920>;
>>> +				hfront-porch = <2>;
>>> +				hback-porch = <2>;
>>> +				hsync-len = <1>;
>>> +				vfront-porch = <1>;
>>> +				vback-porch = <4>;
>>> +				vsync-len = <1>;
>>> +			};
>>> +		};
>>> +
>>> +		cpu-timings {
>>> +			cs-setup = <0>;
>>> +			wr-setup = <0>;
>>> +			wr-act = <1>;
>>> +			wr-hold = <0>;
>>> +		};
>>> +	};
>

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

Hi Andrzej,

Thank you for comments.

On 04/23/2014 06:02 PM, Andrzej Hajda wrote:
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>> This patch adds DT bindings for s6e3fa0 panel.
>> The bindings describes panel resources, display timings and cpu timings.
>>
>> Changelog v2:
>> - Adds unit address (commented by Sachin Kamat)
>> Changelog v3:
>> - Removes optional delay, size properties (commented by Laurent Pinchart)
>> - Adds OLED detection, TE gpio properties
>> Changelog v4:
>> - Moves CPU timings relevant properties from FIMD DT
>>    (commeted by Laurent Pinchart, Andrzej Hajda)
>>
>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>> Acked-by: Inki Dae <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 ++++++++++++++++++++
>>   1 file changed, 63 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>>
>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>> new file mode 100644
>> index 0000000..9eeb38b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>> @@ -0,0 +1,63 @@
>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
>> +
>> +Required properties:
>> +  - compatible: "samsung,s6e3fa0"
>> +  - reg: the virtual channel number of a DSI peripheral
>> +  - vdd3-supply: core voltage supply
>> +  - vci-supply: voltage supply for analog circuits
>> +  - reset-gpio: a GPIO spec for the reset pin
>> +  - det-gpio: a GPIO spec for the OLED detection pin
>> +  - te-gpio: a GPIO spec for the TE pin
>> +  - display-timings: timings for the connected panel as described by [1]
>
> Which properties of display-timings are relevant for CPU mode?
> I guess width and height. Anything more?

The CPU interface panel also requires hfront-porch, hback-porch,
hsync-len, vfront-porch, vback-porch and vsync-len.

>
>> +  - cpu-timings: CPU interface timings for the connected panel, and it contains
>> +        following optional properties.
>> +          - cs-setup: clock cycles for the active period of address signal
>> +                enable until chip select is enable in CPU interface
>> +          - wr-setup: clock cycles for the active period of CS signal enable
>> +                until write signal is enable in CPU interface
>> +          - wr-act: clock cycles for the active period of CS enable in CPU
>> +                interface
>> +          - wr-hold: clock cycles for the active period of CS disable until
>> +                write signal is disable in CPU interface
>
> cpu-timings name does not sound to be related to display.
> I wonder if it would not be better to merge cpu-timings into
> display-timings but this will require more discussion I guess.
>
> If you want to stay with separate node please consider to make it
> optional as whole node or make some properties required. Making node
> required with all sub-properties optional is weird.

Yes, I'll fix.

Thank you.
Best regards YJ

> By the way I hope all timings properties are generic for CPU mode,
> if not they should be prefixed by vendor or model.
>
> Regards
> Andrzej
>
>> +
>> +Optional properties:
>> +
>> +The device node can contain one 'port' child node with one child
>> +'endpoint' node, according to the bindings defined in [2]. This
>> +node should describe panel's video bus.
>> +
>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +
>> +	panel@0 {
>> +		compatible = "samsung,s6e3fa0";
>> +		reg = <0>;
>> +		vdd3-supply = <&vcclcd_reg>;
>> +		vci-supply = <&vlcd_reg>;
>> +		reset-gpio = <&gpy7 4 0>;
>> +		det-gpio = <&gpg0 6 0>;
>> +		te-gpio = <&gpd1 7 0>;
>> +
>> +		display-timings {
>> +			timing0: timing-0 {
>> +				clock-frequency = <0>;
>> +				hactive = <1080>;
>> +				vactive = <1920>;
>> +				hfront-porch = <2>;
>> +				hback-porch = <2>;
>> +				hsync-len = <1>;
>> +				vfront-porch = <1>;
>> +				vback-porch = <4>;
>> +				vsync-len = <1>;
>> +			};
>> +		};
>> +
>> +		cpu-timings {
>> +			cs-setup = <0>;
>> +			wr-setup = <0>;
>> +			wr-act = <1>;
>> +			wr-hold = <0>;
>> +		};
>> +	};
>>
>
>

[RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.

Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU timings relevant properties from FIMD DT
  (commented by Laurent Pinchart, Andrzej Hajda)

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/gpu/drm/panel/Kconfig         |    7 +
 drivers/gpu/drm/panel/Makefile        |    1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 +++++++++++++++++++++++++++++++++
 3 files changed, 577 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
 	select DRM_MIPI_DSI
 	select VIDEOMODE_HELPERS
 
+config DRM_PANEL_S6E3FA0
+	tristate "S6E3FA0 DSI command mode panel"
+	depends on DRM && DRM_PANEL
+	depends on OF
+	select DRM_MIPI_DSI
+	select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 0000000..1282678
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
+/*
+ * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho <yj44.cho@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <drm/drmP.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_panel.h>
+
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/regulator/consumer.h>
+
+#include <video/mipi_display.h>
+#include <video/of_videomode.h>
+#include <video/videomode.h>
+
+#define MTP_ID_LEN		3
+#define GAMMA_LEVEL_NUM		30
+
+struct s6e3fa0 {
+	struct device			*dev;
+	struct drm_panel		panel;
+
+	struct regulator_bulk_data	supplies[2];
+	struct gpio_desc		*reset_gpio;
+	struct gpio_desc		*det_gpio;
+	struct gpio_desc		*te_gpio;
+	struct videomode		vm;
+	struct drm_panel_cpu_timings	cpu_timings;
+
+	unsigned int			power_on_delay;
+	unsigned int			reset_delay;
+	unsigned int			init_delay;
+	unsigned int			width_mm;
+	unsigned int			height_mm;
+
+	unsigned char			id;
+	unsigned char			vddm;
+	unsigned int			brightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+	{0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+	{0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+	{0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+	{0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+	{0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+	{0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+	{0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+	{0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+	{0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+	{0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+	{0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+	{0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+	{0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+	{0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+	{0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
+	{0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
+	{0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
+	{0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
+	{0x5a, 0x4e}, {0x5b, 0x4f}, {0x5c, 0x50}, {0x5d, 0x51}, {0x5e, 0x52},
+	{0x5f, 0x53}, {0x60, 0x54}, {0x61, 0x55}, {0x62, 0x56}, {0x63, 0x57},
+	{0x64, 0x58}, {0x65, 0x59}, {0x66, 0x5a}, {0x67, 0x5b}, {0x68, 0x5c},
+	{0x69, 0x5d}, {0x6a, 0x5e}, {0x6b, 0x5f}, {0x6c, 0x60}, {0x6d, 0x61},
+	{0x6e, 0x62}, {0x6f, 0x63}, {0x70, 0x64}, {0x71, 0x65}, {0x72, 0x66},
+	{0x73, 0x67}, {0x74, 0x68}, {0x75, 0x69}, {0x76, 0x6a}, {0x77, 0x6b},
+	{0x78, 0x6c}, {0x79, 0x6d}, {0x7a, 0x6e}, {0x7b, 0x6f}, {0x7c, 0x70},
+	{0x7d, 0x71}, {0x7e, 0x72}, {0x7f, 0x73},
+};
+
+static int s6e3fa0_dcs_read(struct s6e3fa0 *ctx, unsigned char cmd,
+							void *data, size_t len)
+{
+	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+	return mipi_dsi_dcs_read(dsi, dsi->channel, cmd, data, len);
+}
+
+static void s6e3fa0_dcs_write(struct s6e3fa0 *ctx, const void *data, size_t len)
+{
+	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+	mipi_dsi_dcs_write(dsi, dsi->channel, data, len);
+}
+
+#define s6e3fa0_dcs_write_seq(ctx, seq...)				\
+do {									\
+	const unsigned char d[] = { seq };				\
+	BUILD_BUG_ON_MSG(ARRAY_SIZE(d) > 64, "too big seq for stack");	\
+	s6e3fa0_dcs_write(ctx, d, ARRAY_SIZE(d));			\
+} while (0)
+
+#define s6e3fa0_dcs_write_seq_static(ctx, seq...)			\
+do {									\
+	static const unsigned char d[] = { seq };			\
+	s6e3fa0_dcs_write(ctx, d, ARRAY_SIZE(d));			\
+} while (0)
+
+static void s6e3fa0_apply_level_1_key(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xf0, 0x5a, 0x5a);
+}
+
+static void s6e3fa0_apply_level_2_key(struct s6e3fa0 *ctx, bool on)
+{
+	if (on)
+		s6e3fa0_dcs_write_seq_static(ctx, 0xfc, 0x5a, 0x5a);
+	else
+		s6e3fa0_dcs_write_seq_static(ctx, 0xfc, 0xa5, 0xa5);
+}
+
+static void s6e3fa0_set_maximum_return_packet_size(struct s6e3fa0 *ctx,
+							unsigned int size)
+{
+	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+	const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+	if (ops && ops->transfer) {
+		unsigned char buf[] = {size, 0};
+		struct mipi_dsi_msg msg = {
+			.channel = dsi->channel,
+			.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
+			.tx_len = sizeof(buf),
+			.tx_buf = buf
+		};
+
+		ops->transfer(dsi->host, &msg);
+	}
+}
+
+static void s6e3fa0_read_mtp_id(struct s6e3fa0 *ctx)
+{
+	unsigned char id[MTP_ID_LEN];
+	int ret;
+
+	s6e3fa0_set_maximum_return_packet_size(ctx, MTP_ID_LEN);
+	ret = s6e3fa0_dcs_read(ctx, 0x04, id, MTP_ID_LEN);
+	if (ret < MTP_ID_LEN || id[0] == 0x00) {
+		dev_err(ctx->dev, "failed to read id\n");
+		return;
+	}
+
+	dev_info(ctx->dev, "ID: 0x%02x, 0x%02x, 0x%02x\n", id[0], id[1], id[2]);
+
+	ctx->id = id[2];
+}
+
+static void s6e3fa0_read_vddm(struct s6e3fa0 *ctx)
+{
+	unsigned char vddm;
+	int ret;
+
+	s6e3fa0_apply_level_2_key(ctx, true);
+	s6e3fa0_dcs_write_seq_static(ctx, 0xb0, 0x16);
+	s6e3fa0_set_maximum_return_packet_size(ctx, 1);
+	ret = s6e3fa0_dcs_read(ctx, 0xd7, &vddm, 1);
+	s6e3fa0_apply_level_2_key(ctx, false);
+
+	if (ret < 1 || vddm > 0x7f) {
+		dev_err(ctx->dev, "failed to read vddm\n");
+		return;
+	}
+
+	ctx->vddm = s6e3fa0_vddm_lut[vddm][1];
+}
+
+static void s6e3fa0_set_pentile_control(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xc0, 0x00, 0x02, 0x03, 0x32, 0x03,
+				0x44, 0x44, 0xc0, 0x00, 0x1c, 0x20, 0xe8);
+}
+
+static void s6e3fa0_write_als(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xe3, 0xff, 0xff, 0xff, 0xff);
+}
+
+static void s6e3fa0_set_readability_enhancement(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xfe, 0x00, 0x03, 0xb0, 0x2b, 0xfe,
+									0xe4);
+}
+
+static void s6e3fa0_set_common_control(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_set_pentile_control(ctx);
+	s6e3fa0_write_als(ctx);
+	s6e3fa0_set_readability_enhancement(ctx);
+}
+
+static void s6e3fa0_set_gamma(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xca, 0x01, 0x00, 0x01, 0x00, 0x01,
+					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
+					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
+					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
+					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
+					0x00, 0x00, 0x00);
+}
+
+static void s6e3fa0_set_aid(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xb2, 0x00, 0x06, 0x00, 0x06);
+}
+
+static void s6e3fa0_set_elvss(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xb6, 0x88, 0x0a);
+}
+
+static void s6e3fa0_update_panel(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xf7, 0x03);
+}
+
+static void s6e3fa0_write_acl(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0x55, 0x02);
+}
+
+static void s6e3fa0_set_brightness_control(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_set_gamma(ctx);
+	s6e3fa0_set_aid(ctx);
+	s6e3fa0_set_elvss(ctx);
+	s6e3fa0_update_panel(ctx);
+	s6e3fa0_write_acl(ctx);
+}
+
+static void s6e3fa0_set_temperature(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0xb0, 0x05, 0xb8, 0x19);
+}
+
+static void s6e3fa0_set_elvss_control(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_set_temperature(ctx);
+	s6e3fa0_set_elvss(ctx);
+}
+
+static void s6e3fa0_set_te_on(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_dcs_write_seq_static(ctx, 0x35, 0x00);
+}
+
+static void s6e3fa0_set_etc_and_write_vddm(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_apply_level_2_key(ctx, true);
+	s6e3fa0_dcs_write_seq(ctx, 0xed, 0x0c, 0x04, 0xff, 0x01, 0xb0, 0x16,
+							0xd7, ctx->vddm);
+	s6e3fa0_apply_level_2_key(ctx, false);
+}
+
+static void s6e3fa0_set_etc_condition(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_set_te_on(ctx);
+	s6e3fa0_set_etc_and_write_vddm(ctx);
+}
+
+static void s6e3fa0_panel_init(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_set_common_control(ctx);
+	s6e3fa0_set_brightness_control(ctx);
+	s6e3fa0_set_elvss_control(ctx);
+	s6e3fa0_set_etc_condition(ctx);
+
+	msleep(ctx->init_delay);
+}
+
+static int s6e3fa0_power_off(struct s6e3fa0 *ctx)
+{
+	gpiod_set_value(ctx->reset_gpio, 0);
+
+	return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+}
+
+static int s6e3fa0_power_on(struct s6e3fa0 *ctx)
+{
+	int ret;
+
+	ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+	if (ret)
+		return ret;
+
+	msleep(ctx->power_on_delay);
+
+	gpiod_set_value(ctx->reset_gpio, 1);
+	gpiod_set_value(ctx->reset_gpio, 0);
+	usleep_range(1000, 2000);
+	gpiod_set_value(ctx->reset_gpio, 1);
+
+	msleep(ctx->reset_delay);
+
+	return 0;
+}
+
+static void s6e3fa0_set_sequence(struct s6e3fa0 *ctx)
+{
+	s6e3fa0_apply_level_1_key(ctx);
+	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE);
+	msleep(20);
+
+	s6e3fa0_read_mtp_id(ctx);
+	s6e3fa0_read_vddm(ctx);
+
+	s6e3fa0_panel_init(ctx);
+
+	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_ON);
+}
+
+static int s6e3fa0_disable(struct drm_panel *panel)
+{
+	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
+
+	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE);
+	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_OFF);
+	msleep(35);
+
+	return s6e3fa0_power_off(ctx);
+}
+
+static int s6e3fa0_enable(struct drm_panel *panel)
+{
+	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
+	int ret;
+
+	ret = s6e3fa0_power_on(ctx);
+	if (ret)
+		return ret;
+
+	s6e3fa0_set_sequence(ctx);
+
+	return ret;
+}
+
+static int s6e3fa0_get_modes(struct drm_panel *panel)
+{
+	struct drm_connector *connector = panel->connector;
+	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
+	struct drm_display_mode *mode;
+
+	mode = drm_mode_create(connector->dev);
+	if (!mode) {
+		DRM_ERROR("failed to create a new display mode\n");
+		return 0;
+	}
+
+	drm_display_mode_from_videomode(&ctx->vm, mode);
+	mode->width_mm = ctx->width_mm;
+	mode->height_mm = ctx->height_mm;
+	connector->display_info.width_mm = mode->width_mm;
+	connector->display_info.height_mm = mode->height_mm;
+
+	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+	mode->private = (void *)&ctx->cpu_timings;
+	drm_mode_probed_add(connector, mode);
+
+	return 1;
+}
+
+static const struct drm_panel_funcs s6e3fa0_drm_funcs = {
+	.disable	= s6e3fa0_disable,
+	.enable		= s6e3fa0_enable,
+	.get_modes	= s6e3fa0_get_modes,
+};
+
+static int s6e3fa0_parse_dt(struct s6e3fa0 *ctx)
+{
+	struct device *dev = ctx->dev;
+	struct device_node *np = dev->of_node, *cpu_timing_np;
+	struct drm_panel_cpu_timings *cpu_timings = &ctx->cpu_timings;
+	int ret;
+
+	ret = of_get_videomode(np, &ctx->vm, 0);
+	if (ret) {
+		dev_err(dev, "failed to get video mode: %d\n", ret);
+		return ret;
+	}
+
+	cpu_timing_np = of_find_node_by_name(np, "cpu-timings");
+	if (!cpu_timing_np) {
+		dev_err(dev, "failed to get cpu timings\n");
+		return -EINVAL;
+	}
+	if (of_property_read_u32(cpu_timing_np, "cs-setup",
+					&cpu_timings->cs_setup))
+		cpu_timings->cs_setup = 0;
+	if (of_property_read_u32(cpu_timing_np, "wr-setup",
+					&cpu_timings->wr_setup))
+		cpu_timings->wr_setup = 0;
+	if (of_property_read_u32(cpu_timing_np, "wr-act",
+					&cpu_timings->wr_act))
+		cpu_timings->wr_act = 1;
+	if (of_property_read_u32(cpu_timing_np, "wr-hold",
+					&cpu_timings->wr_hold))
+		cpu_timings->wr_hold = 0;
+	of_node_put(cpu_timing_np);
+
+	return 0;
+}
+
+irqreturn_t s6e3fa0_det_interrupt(int irq, void *dev_id)
+{
+	/* TODO */
+	return IRQ_HANDLED;
+}
+
+irqreturn_t s6e3fa0_te_interrupt(int irq, void *dev_id)
+{
+	struct s6e3fa0 *ctx = dev_id;
+	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+	struct mipi_dsi_host *host = dsi->host;
+	const struct mipi_dsi_host_ops *ops = host->ops;
+
+	if (ops && ops->te_handler)
+		ops->te_handler(host);
+
+	return IRQ_HANDLED;
+}
+
+static int s6e3fa0_probe(struct mipi_dsi_device *dsi)
+{
+	struct device *dev = &dsi->dev;
+	struct s6e3fa0 *ctx;
+	int ret;
+
+	ctx = devm_kzalloc(dev, sizeof(struct s6e3fa0), GFP_KERNEL);
+	if (!ctx) {
+		dev_err(dev, "failed to allocate s6e3fa0 structure.\n");
+		return -ENOMEM;
+	}
+
+	mipi_dsi_set_drvdata(dsi, ctx);
+
+	ctx->dev = dev;
+
+	dsi->lanes = 4;
+	dsi->format = MIPI_DSI_FMT_RGB888;
+
+	ret = s6e3fa0_parse_dt(ctx);
+	if (ret)
+		return ret;
+
+	ctx->supplies[0].supply = "vdd3";
+	ctx->supplies[1].supply = "vci";
+	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
+					ctx->supplies);
+	if (ret) {
+		dev_err(dev, "failed to get regulators: %d\n", ret);
+		return ret;
+	}
+
+	ctx->reset_gpio = devm_gpiod_get(dev, "reset");
+	if (IS_ERR(ctx->reset_gpio)) {
+		dev_err(dev, "failed to get reset gpio: %ld\n",
+						PTR_ERR(ctx->reset_gpio));
+		return PTR_ERR(ctx->reset_gpio);
+	}
+	ret = gpiod_direction_output(ctx->reset_gpio, 1);
+	if (ret < 0) {
+		dev_err(dev, "failed to configure reset gpio: %d\n", ret);
+		return ret;
+	}
+
+	ctx->det_gpio = devm_gpiod_get(dev, "det");
+	if (IS_ERR(ctx->det_gpio)) {
+		dev_err(dev, "failed to get det gpio: %ld\n",
+						PTR_ERR(ctx->det_gpio));
+		return PTR_ERR(ctx->det_gpio);
+	}
+	ret = gpiod_direction_input(ctx->det_gpio);
+	if (ret < 0) {
+		dev_err(dev, "failed to configure det gpio: %d\n", ret);
+		return ret;
+	}
+	ret = devm_request_irq(dev, gpiod_to_irq(ctx->det_gpio),
+						s6e3fa0_det_interrupt,
+						IRQF_TRIGGER_FALLING,
+						"oled-det", ctx);
+	if (ret) {
+		dev_err(dev, "failed to request det irq: %d\n", ret);
+		return ret;
+	}
+
+	ctx->te_gpio = devm_gpiod_get(dev, "te");
+	if (IS_ERR(ctx->te_gpio)) {
+		dev_err(dev, "failed to get te gpio: %ld\n",
+						PTR_ERR(ctx->te_gpio));
+		return PTR_ERR(ctx->te_gpio);
+	}
+	ret = gpiod_direction_input(ctx->te_gpio);
+	if (ret < 0) {
+		dev_err(dev, "failed to configure te gpio: %d\n", ret);
+		return ret;
+	}
+	ret = devm_request_irq(dev, gpiod_to_irq(ctx->te_gpio),
+						s6e3fa0_te_interrupt,
+						IRQF_TRIGGER_RISING,
+						"TE", ctx);
+	if (ret) {
+		dev_err(dev, "failed to request det irq: %d\n", ret);
+		return ret;
+	}
+
+	ctx->power_on_delay = 10;
+	ctx->reset_delay = 5;
+	ctx->init_delay = 120;
+	ctx->width_mm = 71;
+	ctx->height_mm = 126;
+
+	ctx->brightness = GAMMA_LEVEL_NUM - 1;
+
+	drm_panel_init(&ctx->panel);
+	ctx->panel.dev = dev;
+	ctx->panel.funcs = &s6e3fa0_drm_funcs;
+
+	ret = drm_panel_add(&ctx->panel);
+	if (ret)
+		return ret;
+
+	ret = mipi_dsi_attach(dsi);
+	if (ret)
+		drm_panel_remove(&ctx->panel);
+
+	return ret;
+}
+
+static int s6e3fa0_remove(struct mipi_dsi_device *dsi)
+{
+	struct s6e3fa0 *ctx = mipi_dsi_get_drvdata(dsi);
+
+	s6e3fa0_power_off(ctx);
+
+	mipi_dsi_detach(dsi);
+	drm_panel_remove(&ctx->panel);
+
+	return 0;
+}
+
+static struct of_device_id s6e3fa0_of_match[] = {
+	{ .compatible = "samsung,s6e3fa0" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, s6e3fa0_of_match);
+
+static struct mipi_dsi_driver s6e3fa0_driver = {
+	.probe = s6e3fa0_probe,
+	.remove = s6e3fa0_remove,
+	.driver = {
+		.name = "panel_s6e3fa0",
+		.owner = THIS_MODULE,
+		.of_match_table = s6e3fa0_of_match,
+	},
+};
+module_mipi_dsi_driver(s6e3fa0_driver);
+
+MODULE_AUTHOR("YoungJun Cho <yj44.cho@samsung.com>");
+MODULE_DESCRIPTION("MIPI-DSI based s6e3fa0 AMOLED LCD Panel Driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Laurent Pinchart]

Hi YoungJun,

Thank you for the patch.

On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
> 
> Changelog v2:
> - Declares delay, size properties in probe routine instead of DT
> Changelog v3:
> - Moves CPU timings relevant properties from FIMD DT
>   (commented by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> Acked-by: Inki Dae <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  drivers/gpu/drm/panel/Kconfig         |    7 +
>  drivers/gpu/drm/panel/Makefile        |    1 +
>  drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++++++++++++++++++++++++++++++
>  3 files changed, 577 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

[snip]

> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> index 0000000..1282678
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> @@ -0,0 +1,569 @@

[snip]

> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> +{
> +	struct drm_connector *connector = panel->connector;
> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> +	struct drm_display_mode *mode;
> +
> +	mode = drm_mode_create(connector->dev);
> +	if (!mode) {
> +		DRM_ERROR("failed to create a new display mode\n");
> +		return 0;
> +	}
> +
> +	drm_display_mode_from_videomode(&ctx->vm, mode);
> +	mode->width_mm = ctx->width_mm;
> +	mode->height_mm = ctx->height_mm;
> +	connector->display_info.width_mm = mode->width_mm;
> +	connector->display_info.height_mm = mode->height_mm;
> +
> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> +	mode->private = (void *)&ctx->cpu_timings;

Wouldn't it make sense to create a new get_interface_params (or similar) 
operation for drm_panel to query interface configuration parameters instead of 
shoving it in the mode private field ?

> +	drm_mode_probed_add(connector, mode);
> +
> +	return 1;
> +}

[snip]

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

Hi Laurent,

Thank you for the comment.

On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> Hi YoungJun,
>
> Thank you for the patch.
>
> On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
>> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
>>
>> Changelog v2:
>> - Declares delay, size properties in probe routine instead of DT
>> Changelog v3:
>> - Moves CPU timings relevant properties from FIMD DT
>>    (commented by Laurent Pinchart, Andrzej Hajda)
>>
>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>> Acked-by: Inki Dae <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   drivers/gpu/drm/panel/Kconfig         |    7 +
>>   drivers/gpu/drm/panel/Makefile        |    1 +
>>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++++++++++++++++++++++++++++++
>>   3 files changed, 577 insertions(+)
>>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
>
> [snip]
>
>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
>> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
>> index 0000000..1282678
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>> @@ -0,0 +1,569 @@
>
> [snip]
>
>> +static int s6e3fa0_get_modes(struct drm_panel *panel)
>> +{
>> +	struct drm_connector *connector = panel->connector;
>> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>> +	struct drm_display_mode *mode;
>> +
>> +	mode = drm_mode_create(connector->dev);
>> +	if (!mode) {
>> +		DRM_ERROR("failed to create a new display mode\n");
>> +		return 0;
>> +	}
>> +
>> +	drm_display_mode_from_videomode(&ctx->vm, mode);
>> +	mode->width_mm = ctx->width_mm;
>> +	mode->height_mm = ctx->height_mm;
>> +	connector->display_info.width_mm = mode->width_mm;
>> +	connector->display_info.height_mm = mode->height_mm;
>> +
>> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>> +	mode->private = (void *)&ctx->cpu_timings;
>
> Wouldn't it make sense to create a new get_interface_params (or similar)
> operation for drm_panel to query interface configuration parameters instead of
> shoving it in the mode private field ?

You mean "new get_interface_params operation" is different from
get_modes() ?

Till now, struct drm_display_mode and most of mode relevant APIs are
only for video interface.
And CPU interface also needs video mode configurations.

I have a plan to implement the CPU interface relevant APIs like video
mode ones, but I think they should be used under current DRM mode APIs
like fill_modes, get_modes and so on.
So after that implementation, this private field will be replaced by
new ones.

Could you explain it in more detail?

Thank you.
Best regards YJ

>
>> +	drm_mode_probed_add(connector, mode);
>> +
>> +	return 1;
>> +}
>
> [snip]
>

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Laurent Pinchart]

Hi YoungJun,

On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
> On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> > Hi YoungJun,
> > 
> > Thank you for the patch.
> > 
> > On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> >> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
> >> driver.
> >> 
> >> Changelog v2:
> >> - Declares delay, size properties in probe routine instead of DT
> >> Changelog v3:
> >> - Moves CPU timings relevant properties from FIMD DT
> >> 
> >>    (commented by Laurent Pinchart, Andrzej Hajda)
> >> 
> >> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> >> Acked-by: Inki Dae <inki.dae@samsung.com>
> >> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> >> ---
> >> 
> >>   drivers/gpu/drm/panel/Kconfig         |    7 +
> >>   drivers/gpu/drm/panel/Makefile        |    1 +
> >>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++++++++++++++++++++++++++
> >>   3 files changed, 577 insertions(+)
> >>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
> > 
> > [snip]
> > 
> >> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> >> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> >> index 0000000..1282678
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> >> @@ -0,0 +1,569 @@
> > 
> > [snip]
> > 
> >> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> >> +{
> >> +	struct drm_connector *connector = panel->connector;
> >> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> >> +	struct drm_display_mode *mode;
> >> +
> >> +	mode = drm_mode_create(connector->dev);
> >> +	if (!mode) {
> >> +		DRM_ERROR("failed to create a new display mode\n");
> >> +		return 0;
> >> +	}
> >> +
> >> +	drm_display_mode_from_videomode(&ctx->vm, mode);
> >> +	mode->width_mm = ctx->width_mm;
> >> +	mode->height_mm = ctx->height_mm;
> >> +	connector->display_info.width_mm = mode->width_mm;
> >> +	connector->display_info.height_mm = mode->height_mm;
> >> +
> >> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> >> +	mode->private = (void *)&ctx->cpu_timings;
> > 
> > Wouldn't it make sense to create a new get_interface_params (or similar)
> > operation for drm_panel to query interface configuration parameters
> > instead of shoving it in the mode private field ?
> 
> You mean "new get_interface_params operation" is different from
> get_modes() ?
> 
> Till now, struct drm_display_mode and most of mode relevant APIs are
> only for video interface.
> And CPU interface also needs video mode configurations.
> 
> I have a plan to implement the CPU interface relevant APIs like video
> mode ones, but I think they should be used under current DRM mode APIs
> like fill_modes, get_modes and so on.
> So after that implementation, this private field will be replaced by
> new ones.
> 
> Could you explain it in more detail?

The idea is that the interface parameters (RD/WR signals timings in this case, 
but this could also include MIPI DSI lane configuration or any other kind of 
physical interface parameters) are distinct from the video modes.

Do you see a need to tie tie interface parameters with drm_display_mode ? Can 
they be mode-specific ? In any case I'd like not to use the private field of 
drm_display_mode. If we need to tie both information together then it should 
be done in a standard way.

-- 
Regards,

Laurent Pinchart

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]

On Mon, Apr 28, 2014 at 05:05:24PM +0200, Laurent Pinchart wrote:
> Hi YoungJun,
> 
> On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
> > On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> > > Hi YoungJun,
> > > 
> > > Thank you for the patch.
> > > 
> > > On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> > >> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
> > >> driver.
> > >> 
> > >> Changelog v2:
> > >> - Declares delay, size properties in probe routine instead of DT
> > >> Changelog v3:
> > >> - Moves CPU timings relevant properties from FIMD DT
> > >> 
> > >>    (commented by Laurent Pinchart, Andrzej Hajda)
> > >> 
> > >> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> > >> Acked-by: Inki Dae <inki.dae@samsung.com>
> > >> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> > >> ---
> > >> 
> > >>   drivers/gpu/drm/panel/Kconfig         |    7 +
> > >>   drivers/gpu/drm/panel/Makefile        |    1 +
> > >>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++++++++++++++++++++++++++
> > >>   3 files changed, 577 insertions(+)
> > >>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > 
> > > [snip]
> > > 
> > >> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> > >> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> > >> index 0000000..1282678
> > >> --- /dev/null
> > >> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> > >> @@ -0,0 +1,569 @@
> > > 
> > > [snip]
> > > 
> > >> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> > >> +{
> > >> +	struct drm_connector *connector = panel->connector;
> > >> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> > >> +	struct drm_display_mode *mode;
> > >> +
> > >> +	mode = drm_mode_create(connector->dev);
> > >> +	if (!mode) {
> > >> +		DRM_ERROR("failed to create a new display mode\n");
> > >> +		return 0;
> > >> +	}
> > >> +
> > >> +	drm_display_mode_from_videomode(&ctx->vm, mode);
> > >> +	mode->width_mm = ctx->width_mm;
> > >> +	mode->height_mm = ctx->height_mm;
> > >> +	connector->display_info.width_mm = mode->width_mm;
> > >> +	connector->display_info.height_mm = mode->height_mm;
> > >> +
> > >> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> > >> +	mode->private = (void *)&ctx->cpu_timings;
> > > 
> > > Wouldn't it make sense to create a new get_interface_params (or similar)
> > > operation for drm_panel to query interface configuration parameters
> > > instead of shoving it in the mode private field ?
> > 
> > You mean "new get_interface_params operation" is different from
> > get_modes() ?
> > 
> > Till now, struct drm_display_mode and most of mode relevant APIs are
> > only for video interface.
> > And CPU interface also needs video mode configurations.
> > 
> > I have a plan to implement the CPU interface relevant APIs like video
> > mode ones, but I think they should be used under current DRM mode APIs
> > like fill_modes, get_modes and so on.
> > So after that implementation, this private field will be replaced by
> > new ones.
> > 
> > Could you explain it in more detail?
> 
> The idea is that the interface parameters (RD/WR signals timings in this case, 
> but this could also include MIPI DSI lane configuration or any other kind of 
> physical interface parameters) are distinct from the video modes.

We already have the lanes field in struct mipi_dsi_device. I think in
general I'd prefer to not spread these parameters around too wildly. If
this is a general requirement for DBI devices, perhaps what we need is
struct mipi_dbi_device?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

Hi Thierry,

Thank you for the comments.

On 04/29/2014 06:25 AM, Thierry Reding wrote:
> On Mon, Apr 28, 2014 at 05:05:24PM +0200, Laurent Pinchart wrote:
>> Hi YoungJun,
>>
>> On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
>>> On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
>>>> Hi YoungJun,
>>>>
>>>> Thank you for the patch.
>>>>
>>>> On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
>>>>> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
>>>>> driver.
>>>>>
>>>>> Changelog v2:
>>>>> - Declares delay, size properties in probe routine instead of DT
>>>>> Changelog v3:
>>>>> - Moves CPU timings relevant properties from FIMD DT
>>>>>
>>>>>     (commented by Laurent Pinchart, Andrzej Hajda)
>>>>>
>>>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>> ---
>>>>>
>>>>>    drivers/gpu/drm/panel/Kconfig         |    7 +
>>>>>    drivers/gpu/drm/panel/Makefile        |    1 +
>>>>>    drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++++++++++++++++++++++++++
>>>>>    3 files changed, 577 insertions(+)
>>>>>    create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>
>>>> [snip]
>>>>
>>>>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
>>>>> index 0000000..1282678
>>>>> --- /dev/null
>>>>> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>> @@ -0,0 +1,569 @@
>>>>
>>>> [snip]
>>>>
>>>>> +static int s6e3fa0_get_modes(struct drm_panel *panel)
>>>>> +{
>>>>> +	struct drm_connector *connector = panel->connector;
>>>>> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>>>>> +	struct drm_display_mode *mode;
>>>>> +
>>>>> +	mode = drm_mode_create(connector->dev);
>>>>> +	if (!mode) {
>>>>> +		DRM_ERROR("failed to create a new display mode\n");
>>>>> +		return 0;
>>>>> +	}
>>>>> +
>>>>> +	drm_display_mode_from_videomode(&ctx->vm, mode);
>>>>> +	mode->width_mm = ctx->width_mm;
>>>>> +	mode->height_mm = ctx->height_mm;
>>>>> +	connector->display_info.width_mm = mode->width_mm;
>>>>> +	connector->display_info.height_mm = mode->height_mm;
>>>>> +
>>>>> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>>>>> +	mode->private = (void *)&ctx->cpu_timings;
>>>>
>>>> Wouldn't it make sense to create a new get_interface_params (or similar)
>>>> operation for drm_panel to query interface configuration parameters
>>>> instead of shoving it in the mode private field ?
>>>
>>> You mean "new get_interface_params operation" is different from
>>> get_modes() ?
>>>
>>> Till now, struct drm_display_mode and most of mode relevant APIs are
>>> only for video interface.
>>> And CPU interface also needs video mode configurations.
>>>
>>> I have a plan to implement the CPU interface relevant APIs like video
>>> mode ones, but I think they should be used under current DRM mode APIs
>>> like fill_modes, get_modes and so on.
>>> So after that implementation, this private field will be replaced by
>>> new ones.
>>>
>>> Could you explain it in more detail?
>>
>> The idea is that the interface parameters (RD/WR signals timings in this case,
>> but this could also include MIPI DSI lane configuration or any other kind of
>> physical interface parameters) are distinct from the video modes.
>
> We already have the lanes field in struct mipi_dsi_device. I think in
> general I'd prefer to not spread these parameters around too wildly. If
> this is a general requirement for DBI devices, perhaps what we need is
> struct mipi_dbi_device?
>

Even though it requires CPU mode relevant parameters,
this is also mipi dsi interface.

So I think struct mipi_dsi_device is enough.

Thank you.
Best regards YJ

> Thierry
>

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Laurent Pinchart]

[-- Attachment #1.1: Type: text/plain, Size: 4563 bytes --]

Hi Thierry,

On Monday 28 April 2014 23:25:50 Thierry Reding wrote:
> On Mon, Apr 28, 2014 at 05:05:24PM +0200, Laurent Pinchart wrote:
> > On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
> > > On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> > > > Hi YoungJun,
> > > > 
> > > > Thank you for the patch.
> > > > 
> > > > On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> > > >> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
> > > >> driver.
> > > >> 
> > > >> Changelog v2:
> > > >> - Declares delay, size properties in probe routine instead of DT
> > > >> Changelog v3:
> > > >> - Moves CPU timings relevant properties from FIMD DT
> > > >> 
> > > >>    (commented by Laurent Pinchart, Andrzej Hajda)
> > > >> 
> > > >> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> > > >> Acked-by: Inki Dae <inki.dae@samsung.com>
> > > >> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> > > >> ---
> > > >> 
> > > >>   drivers/gpu/drm/panel/Kconfig         |    7 +
> > > >>   drivers/gpu/drm/panel/Makefile        |    1 +
> > > >>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++++++++++++++++++++++
> > > >>   3 files changed, 577 insertions(+)
> > > >>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > > 
> > > > [snip]
> > > > 
> > > >> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > >> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> > > >> index 0000000..1282678
> > > >> --- /dev/null
> > > >> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > >> @@ -0,0 +1,569 @@
> > > > 
> > > > [snip]
> > > > 
> > > >> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> > > >> +{
> > > >> +	struct drm_connector *connector = panel->connector;
> > > >> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> > > >> +	struct drm_display_mode *mode;
> > > >> +
> > > >> +	mode = drm_mode_create(connector->dev);
> > > >> +	if (!mode) {
> > > >> +		DRM_ERROR("failed to create a new display mode\n");
> > > >> +		return 0;
> > > >> +	}
> > > >> +
> > > >> +	drm_display_mode_from_videomode(&ctx->vm, mode);
> > > >> +	mode->width_mm = ctx->width_mm;
> > > >> +	mode->height_mm = ctx->height_mm;
> > > >> +	connector->display_info.width_mm = mode->width_mm;
> > > >> +	connector->display_info.height_mm = mode->height_mm;
> > > >> +
> > > >> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> > > >> +	mode->private = (void *)&ctx->cpu_timings;
> > > > 
> > > > Wouldn't it make sense to create a new get_interface_params (or
> > > > similar)
> > > > operation for drm_panel to query interface configuration parameters
> > > > instead of shoving it in the mode private field ?
> > > 
> > > You mean "new get_interface_params operation" is different from
> > > get_modes() ?
> > > 
> > > Till now, struct drm_display_mode and most of mode relevant APIs are
> > > only for video interface.
> > > And CPU interface also needs video mode configurations.
> > > 
> > > I have a plan to implement the CPU interface relevant APIs like video
> > > mode ones, but I think they should be used under current DRM mode APIs
> > > like fill_modes, get_modes and so on.
> > > So after that implementation, this private field will be replaced by
> > > new ones.
> > > 
> > > Could you explain it in more detail?
> > 
> > The idea is that the interface parameters (RD/WR signals timings in this
> > case, but this could also include MIPI DSI lane configuration or any
> > other kind of physical interface parameters) are distinct from the video
> > modes.
> 
> We already have the lanes field in struct mipi_dsi_device.

Seems I've missed the addition of mipi_dsi_device to DRM.

> I think in general I'd prefer to not spread these parameters around too
> wildly. If this is a general requirement for DBI devices, perhaps what we
> need is struct mipi_dbi_device?

That could be done, but I'm not sure we should expose the nature of the panel 
device (i.e. "I'm a mipi_dsi_device") to the display controller. I would be 
worried about using container_of() on panel->dev to get a mipi_dsi_device 
pointer, as we would then need a strict guarantee that the panel->dev pointer 
is embedded directly in a mipi_dsi_device. This might be doable for DSI, but 
other kind of panels might be connected to different control busses (I'm 
thinking about I2C and SPI in particular) and still need to expose video 
interface parameters to the display controller driver.

-- 
Regards,

Laurent Pinchart

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

Hi Laurent,

Thank you for sharing your idea.

On 04/29/2014 12:05 AM, Laurent Pinchart wrote:
> Hi YoungJun,
>
> On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
>> On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
>>> Hi YoungJun,
>>>
>>> Thank you for the patch.
>>>
>>> On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
>>>> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
>>>> driver.
>>>>
>>>> Changelog v2:
>>>> - Declares delay, size properties in probe routine instead of DT
>>>> Changelog v3:
>>>> - Moves CPU timings relevant properties from FIMD DT
>>>>
>>>>     (commented by Laurent Pinchart, Andrzej Hajda)
>>>>
>>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>> ---
>>>>
>>>>    drivers/gpu/drm/panel/Kconfig         |    7 +
>>>>    drivers/gpu/drm/panel/Makefile        |    1 +
>>>>    drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++++++++++++++++++++++++++
>>>>    3 files changed, 577 insertions(+)
>>>>    create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>
>>> [snip]
>>>
>>>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
>>>> index 0000000..1282678
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>> @@ -0,0 +1,569 @@
>>>
>>> [snip]
>>>
>>>> +static int s6e3fa0_get_modes(struct drm_panel *panel)
>>>> +{
>>>> +	struct drm_connector *connector = panel->connector;
>>>> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>>>> +	struct drm_display_mode *mode;
>>>> +
>>>> +	mode = drm_mode_create(connector->dev);
>>>> +	if (!mode) {
>>>> +		DRM_ERROR("failed to create a new display mode\n");
>>>> +		return 0;
>>>> +	}
>>>> +
>>>> +	drm_display_mode_from_videomode(&ctx->vm, mode);
>>>> +	mode->width_mm = ctx->width_mm;
>>>> +	mode->height_mm = ctx->height_mm;
>>>> +	connector->display_info.width_mm = mode->width_mm;
>>>> +	connector->display_info.height_mm = mode->height_mm;
>>>> +
>>>> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>>>> +	mode->private = (void *)&ctx->cpu_timings;
>>>
>>> Wouldn't it make sense to create a new get_interface_params (or similar)
>>> operation for drm_panel to query interface configuration parameters
>>> instead of shoving it in the mode private field ?
>>
>> You mean "new get_interface_params operation" is different from
>> get_modes() ?
>>
>> Till now, struct drm_display_mode and most of mode relevant APIs are
>> only for video interface.
>> And CPU interface also needs video mode configurations.
>>
>> I have a plan to implement the CPU interface relevant APIs like video
>> mode ones, but I think they should be used under current DRM mode APIs
>> like fill_modes, get_modes and so on.
>> So after that implementation, this private field will be replaced by
>> new ones.
>>
>> Could you explain it in more detail?
>
> The idea is that the interface parameters (RD/WR signals timings in this case,
> but this could also include MIPI DSI lane configuration or any other kind of
> physical interface parameters) are distinct from the video modes.

Yes. The RD/WR signals timings are distinct from the video modes,
but in my opinion, others are covered by video mode already.

>
> Do you see a need to tie tie interface parameters with drm_display_mode ? Can
> they be mode-specific ? In any case I'd like not to use the private field of
> drm_display_mode. If we need to tie both information together then it should
> be done in a standard way.

I think this cpu-mode-timings is in struct drm_display_mode
(NOT by *private) and requires drm_display_mode_from_cpumode()
because the drm_display_mode_from_videomode() covers only video mode.

I'll try implement it as soon as possible.

Thank you,
Best regards YJ.
>

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

On 04/29/2014 03:02 PM, YoungJun Cho wrote:
> Hi Laurent,
>
> Thank you for sharing your idea.
>
> On 04/29/2014 12:05 AM, Laurent Pinchart wrote:
>> Hi YoungJun,
>>
>> On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
>>> On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
>>>> Hi YoungJun,
>>>>
>>>> Thank you for the patch.
>>>>
>>>> On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
>>>>> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
>>>>> driver.
>>>>>
>>>>> Changelog v2:
>>>>> - Declares delay, size properties in probe routine instead of DT
>>>>> Changelog v3:
>>>>> - Moves CPU timings relevant properties from FIMD DT
>>>>>
>>>>>     (commented by Laurent Pinchart, Andrzej Hajda)
>>>>>
>>>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>> ---
>>>>>
>>>>>    drivers/gpu/drm/panel/Kconfig         |    7 +
>>>>>    drivers/gpu/drm/panel/Makefile        |    1 +
>>>>>    drivers/gpu/drm/panel/panel-s6e3fa0.c |  569
>>>>> ++++++++++++++++++++++++++
>>>>>    3 files changed, 577 insertions(+)
>>>>>    create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>
>>>> [snip]
>>>>
>>>>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
>>>>> index 0000000..1282678
>>>>> --- /dev/null
>>>>> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>> @@ -0,0 +1,569 @@
>>>>
>>>> [snip]
>>>>
>>>>> +static int s6e3fa0_get_modes(struct drm_panel *panel)
>>>>> +{
>>>>> +    struct drm_connector *connector = panel->connector;
>>>>> +    struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>>>>> +    struct drm_display_mode *mode;
>>>>> +
>>>>> +    mode = drm_mode_create(connector->dev);
>>>>> +    if (!mode) {
>>>>> +        DRM_ERROR("failed to create a new display mode\n");
>>>>> +        return 0;
>>>>> +    }
>>>>> +
>>>>> +    drm_display_mode_from_videomode(&ctx->vm, mode);
>>>>> +    mode->width_mm = ctx->width_mm;
>>>>> +    mode->height_mm = ctx->height_mm;
>>>>> +    connector->display_info.width_mm = mode->width_mm;
>>>>> +    connector->display_info.height_mm = mode->height_mm;
>>>>> +
>>>>> +    mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>>>>> +    mode->private = (void *)&ctx->cpu_timings;
>>>>
>>>> Wouldn't it make sense to create a new get_interface_params (or
>>>> similar)
>>>> operation for drm_panel to query interface configuration parameters
>>>> instead of shoving it in the mode private field ?
>>>
>>> You mean "new get_interface_params operation" is different from
>>> get_modes() ?
>>>
>>> Till now, struct drm_display_mode and most of mode relevant APIs are
>>> only for video interface.
>>> And CPU interface also needs video mode configurations.
>>>
>>> I have a plan to implement the CPU interface relevant APIs like video
>>> mode ones, but I think they should be used under current DRM mode APIs
>>> like fill_modes, get_modes and so on.
>>> So after that implementation, this private field will be replaced by
>>> new ones.
>>>
>>> Could you explain it in more detail?
>>
>> The idea is that the interface parameters (RD/WR signals timings in
>> this case,
>> but this could also include MIPI DSI lane configuration or any other
>> kind of
>> physical interface parameters) are distinct from the video modes.
>
> Yes. The RD/WR signals timings are distinct from the video modes,
> but in my opinion, others are covered by video mode already.
>
>>
>> Do you see a need to tie tie interface parameters with
>> drm_display_mode ? Can
>> they be mode-specific ? In any case I'd like not to use the private
>> field of
>> drm_display_mode. If we need to tie both information together then it
>> should
>> be done in a standard way.
>
> I think this cpu-mode-timings is in struct drm_display_mode
> (NOT by *private) and requires drm_display_mode_from_cpumode()
> because the drm_display_mode_from_videomode() covers only video mode.
>
> I'll try implement it as soon as possible.
>

For your information, there are two modes in MIPI DSI specification,
which are video mode and command mode.
And CS, RD/WR timings are related with MIPI DBI specification,
VSYNC, HSYNC timings are related with MIPI DPI specification.

So I think all things relevant with command mode should be arranged
the name of command mode(NOT CPU mode, like video mode NOT RGB mode)
in MIPI DSI, and we don't need to consider MIPI DBI like we do MIPI DPI 
for video mode.

Thank you.
Best regards YJ

> Thank you,
> Best regards YJ.
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

Hi Andrzej, Laurent, Thierry.

CCing Steffen Trumtrar,

On 04/29/2014 05:35 PM, YoungJun Cho wrote:
> On 04/29/2014 03:02 PM, YoungJun Cho wrote:
>> Hi Laurent,
>>
>> Thank you for sharing your idea.
>>
>> On 04/29/2014 12:05 AM, Laurent Pinchart wrote:
>>> Hi YoungJun,
>>>
>>> On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
>>>> On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
>>>>> Hi YoungJun,
>>>>>
>>>>> Thank you for the patch.
>>>>>
>>>>> On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
>>>>>> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
>>>>>> driver.
>>>>>>
>>>>>> Changelog v2:
>>>>>> - Declares delay, size properties in probe routine instead of DT
>>>>>> Changelog v3:
>>>>>> - Moves CPU timings relevant properties from FIMD DT
>>>>>>
>>>>>>     (commented by Laurent Pinchart, Andrzej Hajda)
>>>>>>
>>>>>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>>>>>> Acked-by: Inki Dae <inki.dae@samsung.com>
>>>>>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>>>> ---
>>>>>>
>>>>>>    drivers/gpu/drm/panel/Kconfig         |    7 +
>>>>>>    drivers/gpu/drm/panel/Makefile        |    1 +
>>>>>>    drivers/gpu/drm/panel/panel-s6e3fa0.c |  569
>>>>>> ++++++++++++++++++++++++++
>>>>>>    3 files changed, 577 insertions(+)
>>>>>>    create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>>
>>>>> [snip]
>>>>>
>>>>>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>>> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
>>>>>> index 0000000..1282678
>>>>>> --- /dev/null
>>>>>> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>>>>> @@ -0,0 +1,569 @@
>>>>>
>>>>> [snip]
>>>>>
>>>>>> +static int s6e3fa0_get_modes(struct drm_panel *panel)
>>>>>> +{
>>>>>> +    struct drm_connector *connector = panel->connector;
>>>>>> +    struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>>>>>> +    struct drm_display_mode *mode;
>>>>>> +
>>>>>> +    mode = drm_mode_create(connector->dev);
>>>>>> +    if (!mode) {
>>>>>> +        DRM_ERROR("failed to create a new display mode\n");
>>>>>> +        return 0;
>>>>>> +    }
>>>>>> +
>>>>>> +    drm_display_mode_from_videomode(&ctx->vm, mode);
>>>>>> +    mode->width_mm = ctx->width_mm;
>>>>>> +    mode->height_mm = ctx->height_mm;
>>>>>> +    connector->display_info.width_mm = mode->width_mm;
>>>>>> +    connector->display_info.height_mm = mode->height_mm;
>>>>>> +
>>>>>> +    mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>>>>>> +    mode->private = (void *)&ctx->cpu_timings;
>>>>>
>>>>> Wouldn't it make sense to create a new get_interface_params (or
>>>>> similar)
>>>>> operation for drm_panel to query interface configuration parameters
>>>>> instead of shoving it in the mode private field ?
>>>>
>>>> You mean "new get_interface_params operation" is different from
>>>> get_modes() ?
>>>>
>>>> Till now, struct drm_display_mode and most of mode relevant APIs are
>>>> only for video interface.
>>>> And CPU interface also needs video mode configurations.
>>>>
>>>> I have a plan to implement the CPU interface relevant APIs like video
>>>> mode ones, but I think they should be used under current DRM mode APIs
>>>> like fill_modes, get_modes and so on.
>>>> So after that implementation, this private field will be replaced by
>>>> new ones.
>>>>
>>>> Could you explain it in more detail?
>>>
>>> The idea is that the interface parameters (RD/WR signals timings in
>>> this case,
>>> but this could also include MIPI DSI lane configuration or any other
>>> kind of
>>> physical interface parameters) are distinct from the video modes.
>>
>> Yes. The RD/WR signals timings are distinct from the video modes,
>> but in my opinion, others are covered by video mode already.
>>
>>>
>>> Do you see a need to tie tie interface parameters with
>>> drm_display_mode ? Can
>>> they be mode-specific ? In any case I'd like not to use the private
>>> field of
>>> drm_display_mode. If we need to tie both information together then it
>>> should
>>> be done in a standard way.
>>
>> I think this cpu-mode-timings is in struct drm_display_mode
>> (NOT by *private) and requires drm_display_mode_from_cpumode()
>> because the drm_display_mode_from_videomode() covers only video mode.
>>
>> I'll try implement it as soon as possible.
>>
>
> For your information, there are two modes in MIPI DSI specification,
> which are video mode and command mode.
> And CS, RD/WR timings are related with MIPI DBI specification,
> VSYNC, HSYNC timings are related with MIPI DPI specification.
>
> So I think all things relevant with command mode should be arranged
> the name of command mode(NOT CPU mode, like video mode NOT RGB mode)
> in MIPI DSI, and we don't need to consider MIPI DBI like we do MIPI DPI
> for video mode.
>

First, for MIPI command mode, hactive and vactive are only required.
Sorry Andrzej for confusing reply.
I have to modify exynos fimd pixel clock calculating function.

Second, for generic MIPI command mode timing support, commandmode.c and
of_commandmode.c are required in drivers/video.
And the struct drm_panel_command_mode_timings should be moved into 
commandmode.h as struct commandmode.

And the last(this is important and I need your ideas), adds this command 
mode timings into struct display_timing.
 From hierarchical aspects, display_timing(s) should contain command 
mode timings too, but it only contains video mode timings.
If I do it, current video mode relevant DTs will be broken.

So IMHO it is required to rename of_*_display_timing() as 
of_*_videomode_timing() and add of_*_commandmode_timing() into 
of_display_timing.c.
And should add command mode timings into DT like display-timings-command
to distinguish it from display-timings(for videomode).

What do you think about it?

Thank you.
Best regards YJ

> Thank you.
> Best regards YJ
>
>> Thank you,
>> Best regards YJ.
>>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Andrzej Hajda]

Hi YoungJun,


On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
> 
> Changelog v2:
> - Declares delay, size properties in probe routine instead of DT
> Changelog v3:
> - Moves CPU timings relevant properties from FIMD DT
>   (commented by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
> Acked-by: Inki Dae <inki.dae@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  drivers/gpu/drm/panel/Kconfig         |    7 +
>  drivers/gpu/drm/panel/Makefile        |    1 +
>  drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 +++++++++++++++++++++++++++++++++
>  3 files changed, 577 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4ec874d..be1392e 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
>  	select DRM_MIPI_DSI
>  	select VIDEOMODE_HELPERS
>  
> +config DRM_PANEL_S6E3FA0
> +	tristate "S6E3FA0 DSI command mode panel"
> +	depends on DRM && DRM_PANEL
> +	depends on OF
> +	select DRM_MIPI_DSI
> +	select VIDEOMODE_HELPERS
> +
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 8b92921..85c6738 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>  obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
>  obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
> +obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> new file mode 100644
> index 0000000..1282678
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> @@ -0,0 +1,569 @@
> +/*
> + * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd
> + *
> + * YoungJun Cho <yj44.cho@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_panel.h>
> +
> +#include <linux/gpio.h>
> +#include <linux/of_gpio.h>


#include <linux/gpio/consumer.h> should be enough.


> +#include <linux/regulator/consumer.h>
> +
> +#include <video/mipi_display.h>
> +#include <video/of_videomode.h>
> +#include <video/videomode.h>
> +
> +#define MTP_ID_LEN		3
> +#define GAMMA_LEVEL_NUM		30
> +
> +struct s6e3fa0 {
> +	struct device			*dev;
> +	struct drm_panel		panel;
> +
> +	struct regulator_bulk_data	supplies[2];
> +	struct gpio_desc		*reset_gpio;
> +	struct gpio_desc		*det_gpio;
> +	struct gpio_desc		*te_gpio;
> +	struct videomode		vm;
> +	struct drm_panel_cpu_timings	cpu_timings;
> +
> +	unsigned int			power_on_delay;
> +	unsigned int			reset_delay;
> +	unsigned int			init_delay;
> +	unsigned int			width_mm;
> +	unsigned int			height_mm;
> +
> +	unsigned char			id;
> +	unsigned char			vddm;
> +	unsigned int			brightness;
> +};
> +
> +#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
> +
> +static const unsigned char s6e3fa0_vddm_lut[][2] = {
> +	{0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
> +	{0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
> +	{0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
> +	{0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
> +	{0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
> +	{0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
> +	{0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
> +	{0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
> +	{0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
> +	{0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
> +	{0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
> +	{0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
> +	{0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
> +	{0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
> +	{0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
> +	{0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
> +	{0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
> +	{0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
> +	{0x5a, 0x4e}, {0x5b, 0x4f}, {0x5c, 0x50}, {0x5d, 0x51}, {0x5e, 0x52},
> +	{0x5f, 0x53}, {0x60, 0x54}, {0x61, 0x55}, {0x62, 0x56}, {0x63, 0x57},
> +	{0x64, 0x58}, {0x65, 0x59}, {0x66, 0x5a}, {0x67, 0x5b}, {0x68, 0x5c},
> +	{0x69, 0x5d}, {0x6a, 0x5e}, {0x6b, 0x5f}, {0x6c, 0x60}, {0x6d, 0x61},
> +	{0x6e, 0x62}, {0x6f, 0x63}, {0x70, 0x64}, {0x71, 0x65}, {0x72, 0x66},
> +	{0x73, 0x67}, {0x74, 0x68}, {0x75, 0x69}, {0x76, 0x6a}, {0x77, 0x6b},
> +	{0x78, 0x6c}, {0x79, 0x6d}, {0x7a, 0x6e}, {0x7b, 0x6f}, {0x7c, 0x70},
> +	{0x7d, 0x71}, {0x7e, 0x72}, {0x7f, 0x73},
> +};


Some comment would be helpful.


> +
> +static int s6e3fa0_dcs_read(struct s6e3fa0 *ctx, unsigned char cmd,
> +							void *data, size_t len)
> +{
> +	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> +	return mipi_dsi_dcs_read(dsi, dsi->channel, cmd, data, len);
> +}
> +
> +static void s6e3fa0_dcs_write(struct s6e3fa0 *ctx, const void *data, size_t len)
> +{
> +	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> +	mipi_dsi_dcs_write(dsi, dsi->channel, data, len);
> +}
> +
> +#define s6e3fa0_dcs_write_seq(ctx, seq...)				\
> +do {									\
> +	const unsigned char d[] = { seq };				\
> +	BUILD_BUG_ON_MSG(ARRAY_SIZE(d) > 64, "too big seq for stack");	\
> +	s6e3fa0_dcs_write(ctx, d, ARRAY_SIZE(d));			\
> +} while (0)
> +
> +#define s6e3fa0_dcs_write_seq_static(ctx, seq...)			\
> +do {									\
> +	static const unsigned char d[] = { seq };			\
> +	s6e3fa0_dcs_write(ctx, d, ARRAY_SIZE(d));			\
> +} while (0)
> +
> +static void s6e3fa0_apply_level_1_key(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xf0, 0x5a, 0x5a);
> +}
> +
> +static void s6e3fa0_apply_level_2_key(struct s6e3fa0 *ctx, bool on)
> +{
> +	if (on)
> +		s6e3fa0_dcs_write_seq_static(ctx, 0xfc, 0x5a, 0x5a);
> +	else
> +		s6e3fa0_dcs_write_seq_static(ctx, 0xfc, 0xa5, 0xa5);
> +}
> +
> +static void s6e3fa0_set_maximum_return_packet_size(struct s6e3fa0 *ctx,
> +							unsigned int size)
> +{
> +	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +	const struct mipi_dsi_host_ops *ops = dsi->host->ops;
> +
> +	if (ops && ops->transfer) {
> +		unsigned char buf[] = {size, 0};
> +		struct mipi_dsi_msg msg = {
> +			.channel = dsi->channel,
> +			.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
> +			.tx_len = sizeof(buf),
> +			.tx_buf = buf
> +		};
> +
> +		ops->transfer(dsi->host, &msg);
> +	}
> +}
> +
> +static void s6e3fa0_read_mtp_id(struct s6e3fa0 *ctx)
> +{
> +	unsigned char id[MTP_ID_LEN];
> +	int ret;
> +
> +	s6e3fa0_set_maximum_return_packet_size(ctx, MTP_ID_LEN);
> +	ret = s6e3fa0_dcs_read(ctx, 0x04, id, MTP_ID_LEN);
> +	if (ret < MTP_ID_LEN || id[0] == 0x00) {
> +		dev_err(ctx->dev, "failed to read id\n");
> +		return;
> +	}
> +
> +	dev_info(ctx->dev, "ID: 0x%02x, 0x%02x, 0x%02x\n", id[0], id[1], id[2]);
> +
> +	ctx->id = id[2];
> +}
> +
> +static void s6e3fa0_read_vddm(struct s6e3fa0 *ctx)
> +{
> +	unsigned char vddm;
> +	int ret;
> +
> +	s6e3fa0_apply_level_2_key(ctx, true);
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xb0, 0x16);

It seems little bit cryptic, it would be better to document somehow
what this sequence is for. I guess datasheet provides at least
information what first byte means and standard says clearly that it is
DCS for values < 0xb0 and MCS (manufacturer command set) for values >=
0xb0. You can use defines to make it more readable. Please look at
panel-ld9040.c how it could be done.

s6e3fa0_dcs_write_seq_static(ctx, MCS_MANPWR, 0x16);

looks better. The same for other sequences.


> +	s6e3fa0_set_maximum_return_packet_size(ctx, 1);
> +	ret = s6e3fa0_dcs_read(ctx, 0xd7, &vddm, 1);
> +	s6e3fa0_apply_level_2_key(ctx, false);
> +
> +	if (ret < 1 || vddm > 0x7f) {
> +		dev_err(ctx->dev, "failed to read vddm\n");
> +		return;
> +	}
> +
> +	ctx->vddm = s6e3fa0_vddm_lut[vddm][1];

In case of error ctx->vddm is zero, and this value is used later by
s6e3fa0_set_etc_and_write_vddm. Is it OK?

Anyway it seems you do not care about DSI transmission errors at all in
most places. Maybe it will not hurt but IMO it is asking for troubles.


> +}
> +
> +static void s6e3fa0_set_pentile_control(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xc0, 0x00, 0x02, 0x03, 0x32, 0x03,
> +				0x44, 0x44, 0xc0, 0x00, 0x1c, 0x20, 0xe8);
> +}
> +
> +static void s6e3fa0_write_als(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xe3, 0xff, 0xff, 0xff, 0xff);
> +}
> +
> +static void s6e3fa0_set_readability_enhancement(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xfe, 0x00, 0x03, 0xb0, 0x2b, 0xfe,
> +									0xe4);
> +}
> +
> +static void s6e3fa0_set_common_control(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_set_pentile_control(ctx);
> +	s6e3fa0_write_als(ctx);
> +	s6e3fa0_set_readability_enhancement(ctx);
> +}
> +
> +static void s6e3fa0_set_gamma(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xca, 0x01, 0x00, 0x01, 0x00, 0x01,
> +					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
> +					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
> +					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
> +					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
> +					0x00, 0x00, 0x00);
> +}
> +
> +static void s6e3fa0_set_aid(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xb2, 0x00, 0x06, 0x00, 0x06);
> +}
> +
> +static void s6e3fa0_set_elvss(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xb6, 0x88, 0x0a);
> +}
> +
> +static void s6e3fa0_update_panel(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xf7, 0x03);
> +}
> +
> +static void s6e3fa0_write_acl(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0x55, 0x02);


That's strange beast. It should be DCS command but I do not see it in
spec. Specification violation???


> +}
> +
> +static void s6e3fa0_set_brightness_control(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_set_gamma(ctx);
> +	s6e3fa0_set_aid(ctx);
> +	s6e3fa0_set_elvss(ctx);
> +	s6e3fa0_update_panel(ctx);
> +	s6e3fa0_write_acl(ctx);
> +}
> +
> +static void s6e3fa0_set_temperature(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0xb0, 0x05, 0xb8, 0x19);
> +}
> +
> +static void s6e3fa0_set_elvss_control(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_set_temperature(ctx);
> +	s6e3fa0_set_elvss(ctx);
> +}
> +
> +static void s6e3fa0_set_te_on(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_dcs_write_seq_static(ctx, 0x35, 0x00);


s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_SET_TEAR_ON, 0x00);


> +}
> +
> +static void s6e3fa0_set_etc_and_write_vddm(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_apply_level_2_key(ctx, true);
> +	s6e3fa0_dcs_write_seq(ctx, 0xed, 0x0c, 0x04, 0xff, 0x01, 0xb0, 0x16,
> +							0xd7, ctx->vddm);
> +	s6e3fa0_apply_level_2_key(ctx, false);
> +}
> +
> +static void s6e3fa0_set_etc_condition(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_set_te_on(ctx);
> +	s6e3fa0_set_etc_and_write_vddm(ctx);
> +}
> +
> +static void s6e3fa0_panel_init(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_set_common_control(ctx);
> +	s6e3fa0_set_brightness_control(ctx);
> +	s6e3fa0_set_elvss_control(ctx);
> +	s6e3fa0_set_etc_condition(ctx);
> +
> +	msleep(ctx->init_delay);
> +}
> +
> +static int s6e3fa0_power_off(struct s6e3fa0 *ctx)
> +{
> +	gpiod_set_value(ctx->reset_gpio, 0);
> +
> +	return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +}
> +
> +static int s6e3fa0_power_on(struct s6e3fa0 *ctx)
> +{
> +	int ret;
> +
> +	ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +	if (ret)
> +		return ret;
> +
> +	msleep(ctx->power_on_delay);
> +
> +	gpiod_set_value(ctx->reset_gpio, 1);
> +	gpiod_set_value(ctx->reset_gpio, 0);
> +	usleep_range(1000, 2000);
> +	gpiod_set_value(ctx->reset_gpio, 1);
> +
> +	msleep(ctx->reset_delay);
> +
> +	return 0;
> +}
> +
> +static void s6e3fa0_set_sequence(struct s6e3fa0 *ctx)
> +{
> +	s6e3fa0_apply_level_1_key(ctx);
> +	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE);
> +	msleep(20);
> +
> +	s6e3fa0_read_mtp_id(ctx);
> +	s6e3fa0_read_vddm(ctx);
> +
> +	s6e3fa0_panel_init(ctx);
> +
> +	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_ON);
> +}
> +
> +static int s6e3fa0_disable(struct drm_panel *panel)
> +{
> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> +
> +	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE);
> +	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_OFF);
> +	msleep(35);
> +
> +	return s6e3fa0_power_off(ctx);
> +}
> +
> +static int s6e3fa0_enable(struct drm_panel *panel)
> +{
> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> +	int ret;
> +
> +	ret = s6e3fa0_power_on(ctx);
> +	if (ret)
> +		return ret;
> +
> +	s6e3fa0_set_sequence(ctx);
> +
> +	return ret;
> +}
> +
> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> +{
> +	struct drm_connector *connector = panel->connector;
> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> +	struct drm_display_mode *mode;
> +
> +	mode = drm_mode_create(connector->dev);
> +	if (!mode) {
> +		DRM_ERROR("failed to create a new display mode\n");
> +		return 0;
> +	}
> +
> +	drm_display_mode_from_videomode(&ctx->vm, mode);
> +	mode->width_mm = ctx->width_mm;
> +	mode->height_mm = ctx->height_mm;
> +	connector->display_info.width_mm = mode->width_mm;
> +	connector->display_info.height_mm = mode->height_mm;
> +
> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> +	mode->private = (void *)&ctx->cpu_timings;
> +	drm_mode_probed_add(connector, mode);
> +
> +	return 1;
> +}
> +
> +static const struct drm_panel_funcs s6e3fa0_drm_funcs = {
> +	.disable	= s6e3fa0_disable,
> +	.enable		= s6e3fa0_enable,
> +	.get_modes	= s6e3fa0_get_modes,
> +};
> +
> +static int s6e3fa0_parse_dt(struct s6e3fa0 *ctx)
> +{
> +	struct device *dev = ctx->dev;
> +	struct device_node *np = dev->of_node, *cpu_timing_np;
> +	struct drm_panel_cpu_timings *cpu_timings = &ctx->cpu_timings;
> +	int ret;
> +
> +	ret = of_get_videomode(np, &ctx->vm, 0);
> +	if (ret) {
> +		dev_err(dev, "failed to get video mode: %d\n", ret);
> +		return ret;
> +	}
> +
> +	cpu_timing_np = of_find_node_by_name(np, "cpu-timings");
> +	if (!cpu_timing_np) {
> +		dev_err(dev, "failed to get cpu timings\n");
> +		return -EINVAL;
> +	}
> +	if (of_property_read_u32(cpu_timing_np, "cs-setup",
> +					&cpu_timings->cs_setup))
> +		cpu_timings->cs_setup = 0;
> +	if (of_property_read_u32(cpu_timing_np, "wr-setup",
> +					&cpu_timings->wr_setup))
> +		cpu_timings->wr_setup = 0;
> +	if (of_property_read_u32(cpu_timing_np, "wr-act",
> +					&cpu_timings->wr_act))
> +		cpu_timings->wr_act = 1;
> +	if (of_property_read_u32(cpu_timing_np, "wr-hold",
> +					&cpu_timings->wr_hold))
> +		cpu_timings->wr_hold = 0;

If I remember default values were not provided in bindings, please fix it.


> +	of_node_put(cpu_timing_np);
> +
> +	return 0;
> +}
> +
> +irqreturn_t s6e3fa0_det_interrupt(int irq, void *dev_id)
> +{
> +	/* TODO */
> +	return IRQ_HANDLED;
> +}
> +
> +irqreturn_t s6e3fa0_te_interrupt(int irq, void *dev_id)
> +{
> +	struct s6e3fa0 *ctx = dev_id;
> +	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +	struct mipi_dsi_host *host = dsi->host;
> +	const struct mipi_dsi_host_ops *ops = host->ops;
> +
> +	if (ops && ops->te_handler)
> +		ops->te_handler(host);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int s6e3fa0_probe(struct mipi_dsi_device *dsi)
> +{
> +	struct device *dev = &dsi->dev;
> +	struct s6e3fa0 *ctx;
> +	int ret;
> +
> +	ctx = devm_kzalloc(dev, sizeof(struct s6e3fa0), GFP_KERNEL);
> +	if (!ctx) {
> +		dev_err(dev, "failed to allocate s6e3fa0 structure.\n");
> +		return -ENOMEM;
> +	}
> +
> +	mipi_dsi_set_drvdata(dsi, ctx);
> +
> +	ctx->dev = dev;
> +
> +	dsi->lanes = 4;
> +	dsi->format = MIPI_DSI_FMT_RGB888;
> +
> +	ret = s6e3fa0_parse_dt(ctx);
> +	if (ret)
> +		return ret;
> +
> +	ctx->supplies[0].supply = "vdd3";
> +	ctx->supplies[1].supply = "vci";
> +	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
> +					ctx->supplies);
> +	if (ret) {
> +		dev_err(dev, "failed to get regulators: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ctx->reset_gpio = devm_gpiod_get(dev, "reset");
> +	if (IS_ERR(ctx->reset_gpio)) {
> +		dev_err(dev, "failed to get reset gpio: %ld\n",
> +						PTR_ERR(ctx->reset_gpio));
> +		return PTR_ERR(ctx->reset_gpio);
> +	}
> +	ret = gpiod_direction_output(ctx->reset_gpio, 1);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to configure reset gpio: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ctx->det_gpio = devm_gpiod_get(dev, "det");
> +	if (IS_ERR(ctx->det_gpio)) {
> +		dev_err(dev, "failed to get det gpio: %ld\n",
> +						PTR_ERR(ctx->det_gpio));
> +		return PTR_ERR(ctx->det_gpio);
> +	}
> +	ret = gpiod_direction_input(ctx->det_gpio);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to configure det gpio: %d\n", ret);
> +		return ret;
> +	}
> +	ret = devm_request_irq(dev, gpiod_to_irq(ctx->det_gpio),
> +						s6e3fa0_det_interrupt,
> +						IRQF_TRIGGER_FALLING,
> +						"oled-det", ctx);
> +	if (ret) {
> +		dev_err(dev, "failed to request det irq: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ctx->te_gpio = devm_gpiod_get(dev, "te");
> +	if (IS_ERR(ctx->te_gpio)) {
> +		dev_err(dev, "failed to get te gpio: %ld\n",
> +						PTR_ERR(ctx->te_gpio));
> +		return PTR_ERR(ctx->te_gpio);
> +	}
> +	ret = gpiod_direction_input(ctx->te_gpio);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to configure te gpio: %d\n", ret);
> +		return ret;
> +	}
> +	ret = devm_request_irq(dev, gpiod_to_irq(ctx->te_gpio),
> +						s6e3fa0_te_interrupt,
> +						IRQF_TRIGGER_RISING,
> +						"TE", ctx);
> +	if (ret) {
> +		dev_err(dev, "failed to request det irq: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ctx->power_on_delay = 10;
> +	ctx->reset_delay = 5;
> +	ctx->init_delay = 120;
> +	ctx->width_mm = 71;
> +	ctx->height_mm = 126;
> +
> +	ctx->brightness = GAMMA_LEVEL_NUM - 1;
> +
> +	drm_panel_init(&ctx->panel);
> +	ctx->panel.dev = dev;
> +	ctx->panel.funcs = &s6e3fa0_drm_funcs;
> +
> +	ret = drm_panel_add(&ctx->panel);
> +	if (ret)
> +		return ret;
> +
> +	ret = mipi_dsi_attach(dsi);
> +	if (ret)
> +		drm_panel_remove(&ctx->panel);
> +
> +	return ret;
> +}
> +
> +static int s6e3fa0_remove(struct mipi_dsi_device *dsi)
> +{
> +	struct s6e3fa0 *ctx = mipi_dsi_get_drvdata(dsi);
> +
> +	s6e3fa0_power_off(ctx);


In case panel is off this will lead to double disable of regulators.

In general mipi_dsi_detach should be enough, it will trigger hpd,
which will set dpms to off, which will call s6e3fa0_power_off.


Regards
Andrzej


> +
> +	mipi_dsi_detach(dsi);
> +	drm_panel_remove(&ctx->panel);
> +
> +	return 0;
> +}
> +
> +static struct of_device_id s6e3fa0_of_match[] = {
> +	{ .compatible = "samsung,s6e3fa0" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, s6e3fa0_of_match);
> +
> +static struct mipi_dsi_driver s6e3fa0_driver = {
> +	.probe = s6e3fa0_probe,
> +	.remove = s6e3fa0_remove,
> +	.driver = {
> +		.name = "panel_s6e3fa0",
> +		.owner = THIS_MODULE,
> +		.of_match_table = s6e3fa0_of_match,
> +	},
> +};
> +module_mipi_dsi_driver(s6e3fa0_driver);
> +
> +MODULE_AUTHOR("YoungJun Cho <yj44.cho@samsung.com>");
> +MODULE_DESCRIPTION("MIPI-DSI based s6e3fa0 AMOLED LCD Panel Driver");
> +MODULE_LICENSE("GPL v2");
> 

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

Hi Andrzej,

Thank you for kind comments.

On 04/23/2014 07:16 PM, Andrzej Hajda wrote:
> Hi YoungJun,
>
>
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
>>
>> Changelog v2:
>> - Declares delay, size properties in probe routine instead of DT
>> Changelog v3:
>> - Moves CPU timings relevant properties from FIMD DT
>>    (commented by Laurent Pinchart, Andrzej Hajda)
>>
>> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
>> Acked-by: Inki Dae <inki.dae@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   drivers/gpu/drm/panel/Kconfig         |    7 +
>>   drivers/gpu/drm/panel/Makefile        |    1 +
>>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 +++++++++++++++++++++++++++++++++
>>   3 files changed, 577 insertions(+)
>>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 4ec874d..be1392e 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
>>   	select DRM_MIPI_DSI
>>   	select VIDEOMODE_HELPERS
>>
>> +config DRM_PANEL_S6E3FA0
>> +	tristate "S6E3FA0 DSI command mode panel"
>> +	depends on DRM && DRM_PANEL
>> +	depends on OF
>> +	select DRM_MIPI_DSI
>> +	select VIDEOMODE_HELPERS
>> +
>>   endmenu
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index 8b92921..85c6738 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -1,3 +1,4 @@
>>   obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>>   obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
>>   obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
>> +obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>> new file mode 100644
>> index 0000000..1282678
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>> @@ -0,0 +1,569 @@
>> +/*
>> + * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd
>> + *
>> + * YoungJun Cho <yj44.cho@samsung.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include <drm/drmP.h>
>> +#include <drm/drm_mipi_dsi.h>
>> +#include <drm/drm_panel.h>
>> +
>> +#include <linux/gpio.h>
>> +#include <linux/of_gpio.h>
>
>
> #include <linux/gpio/consumer.h> should be enough.

Ok, I'll check.

>
>
>> +#include <linux/regulator/consumer.h>
>> +
>> +#include <video/mipi_display.h>
>> +#include <video/of_videomode.h>
>> +#include <video/videomode.h>
>> +
>> +#define MTP_ID_LEN		3
>> +#define GAMMA_LEVEL_NUM		30
>> +
>> +struct s6e3fa0 {
>> +	struct device			*dev;
>> +	struct drm_panel		panel;
>> +
>> +	struct regulator_bulk_data	supplies[2];
>> +	struct gpio_desc		*reset_gpio;
>> +	struct gpio_desc		*det_gpio;
>> +	struct gpio_desc		*te_gpio;
>> +	struct videomode		vm;
>> +	struct drm_panel_cpu_timings	cpu_timings;
>> +
>> +	unsigned int			power_on_delay;
>> +	unsigned int			reset_delay;
>> +	unsigned int			init_delay;
>> +	unsigned int			width_mm;
>> +	unsigned int			height_mm;
>> +
>> +	unsigned char			id;
>> +	unsigned char			vddm;
>> +	unsigned int			brightness;
>> +};
>> +
>> +#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
>> +
>> +static const unsigned char s6e3fa0_vddm_lut[][2] = {
>> +	{0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
>> +	{0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
>> +	{0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
>> +	{0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
>> +	{0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
>> +	{0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
>> +	{0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
>> +	{0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
>> +	{0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
>> +	{0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
>> +	{0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
>> +	{0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
>> +	{0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
>> +	{0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
>> +	{0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
>> +	{0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
>> +	{0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
>> +	{0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
>> +	{0x5a, 0x4e}, {0x5b, 0x4f}, {0x5c, 0x50}, {0x5d, 0x51}, {0x5e, 0x52},
>> +	{0x5f, 0x53}, {0x60, 0x54}, {0x61, 0x55}, {0x62, 0x56}, {0x63, 0x57},
>> +	{0x64, 0x58}, {0x65, 0x59}, {0x66, 0x5a}, {0x67, 0x5b}, {0x68, 0x5c},
>> +	{0x69, 0x5d}, {0x6a, 0x5e}, {0x6b, 0x5f}, {0x6c, 0x60}, {0x6d, 0x61},
>> +	{0x6e, 0x62}, {0x6f, 0x63}, {0x70, 0x64}, {0x71, 0x65}, {0x72, 0x66},
>> +	{0x73, 0x67}, {0x74, 0x68}, {0x75, 0x69}, {0x76, 0x6a}, {0x77, 0x6b},
>> +	{0x78, 0x6c}, {0x79, 0x6d}, {0x7a, 0x6e}, {0x7b, 0x6f}, {0x7c, 0x70},
>> +	{0x7d, 0x71}, {0x7e, 0x72}, {0x7f, 0x73},
>> +};
>
>
> Some comment would be helpful.

Okay.

>
>
>> +
>> +static int s6e3fa0_dcs_read(struct s6e3fa0 *ctx, unsigned char cmd,
>> +							void *data, size_t len)
>> +{
>> +	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>> +
>> +	return mipi_dsi_dcs_read(dsi, dsi->channel, cmd, data, len);
>> +}
>> +
>> +static void s6e3fa0_dcs_write(struct s6e3fa0 *ctx, const void *data, size_t len)
>> +{
>> +	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>> +
>> +	mipi_dsi_dcs_write(dsi, dsi->channel, data, len);
>> +}
>> +
>> +#define s6e3fa0_dcs_write_seq(ctx, seq...)				\
>> +do {									\
>> +	const unsigned char d[] = { seq };				\
>> +	BUILD_BUG_ON_MSG(ARRAY_SIZE(d) > 64, "too big seq for stack");	\
>> +	s6e3fa0_dcs_write(ctx, d, ARRAY_SIZE(d));			\
>> +} while (0)
>> +
>> +#define s6e3fa0_dcs_write_seq_static(ctx, seq...)			\
>> +do {									\
>> +	static const unsigned char d[] = { seq };			\
>> +	s6e3fa0_dcs_write(ctx, d, ARRAY_SIZE(d));			\
>> +} while (0)
>> +
>> +static void s6e3fa0_apply_level_1_key(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xf0, 0x5a, 0x5a);
>> +}
>> +
>> +static void s6e3fa0_apply_level_2_key(struct s6e3fa0 *ctx, bool on)
>> +{
>> +	if (on)
>> +		s6e3fa0_dcs_write_seq_static(ctx, 0xfc, 0x5a, 0x5a);
>> +	else
>> +		s6e3fa0_dcs_write_seq_static(ctx, 0xfc, 0xa5, 0xa5);
>> +}
>> +
>> +static void s6e3fa0_set_maximum_return_packet_size(struct s6e3fa0 *ctx,
>> +							unsigned int size)
>> +{
>> +	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>> +	const struct mipi_dsi_host_ops *ops = dsi->host->ops;
>> +
>> +	if (ops && ops->transfer) {
>> +		unsigned char buf[] = {size, 0};
>> +		struct mipi_dsi_msg msg = {
>> +			.channel = dsi->channel,
>> +			.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
>> +			.tx_len = sizeof(buf),
>> +			.tx_buf = buf
>> +		};
>> +
>> +		ops->transfer(dsi->host, &msg);
>> +	}
>> +}
>> +
>> +static void s6e3fa0_read_mtp_id(struct s6e3fa0 *ctx)
>> +{
>> +	unsigned char id[MTP_ID_LEN];
>> +	int ret;
>> +
>> +	s6e3fa0_set_maximum_return_packet_size(ctx, MTP_ID_LEN);
>> +	ret = s6e3fa0_dcs_read(ctx, 0x04, id, MTP_ID_LEN);
>> +	if (ret < MTP_ID_LEN || id[0] == 0x00) {
>> +		dev_err(ctx->dev, "failed to read id\n");
>> +		return;
>> +	}
>> +
>> +	dev_info(ctx->dev, "ID: 0x%02x, 0x%02x, 0x%02x\n", id[0], id[1], id[2]);
>> +
>> +	ctx->id = id[2];
>> +}
>> +
>> +static void s6e3fa0_read_vddm(struct s6e3fa0 *ctx)
>> +{
>> +	unsigned char vddm;
>> +	int ret;
>> +
>> +	s6e3fa0_apply_level_2_key(ctx, true);
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xb0, 0x16);
>
> It seems little bit cryptic, it would be better to document somehow
> what this sequence is for. I guess datasheet provides at least
> information what first byte means and standard says clearly that it is
> DCS for values < 0xb0 and MCS (manufacturer command set) for values >=
> 0xb0. You can use defines to make it more readable. Please look at
> panel-ld9040.c how it could be done.
>
> s6e3fa0_dcs_write_seq_static(ctx, MCS_MANPWR, 0x16);
>
> looks better. The same for other sequences.

Okay, I'll fix it.
We need to update panel-s6e8aa0 also before long.

>
>
>> +	s6e3fa0_set_maximum_return_packet_size(ctx, 1);
>> +	ret = s6e3fa0_dcs_read(ctx, 0xd7, &vddm, 1);
>> +	s6e3fa0_apply_level_2_key(ctx, false);
>> +
>> +	if (ret < 1 || vddm > 0x7f) {
>> +		dev_err(ctx->dev, "failed to read vddm\n");
>> +		return;
>> +	}
>> +
>> +	ctx->vddm = s6e3fa0_vddm_lut[vddm][1];
>
> In case of error ctx->vddm is zero, and this value is used later by
> s6e3fa0_set_etc_and_write_vddm. Is it OK?

Right, I have to reinforce this.

>
> Anyway it seems you do not care about DSI transmission errors at all in
> most places. Maybe it will not hurt but IMO it is asking for troubles.

ditto

>
>
>> +}
>> +
>> +static void s6e3fa0_set_pentile_control(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xc0, 0x00, 0x02, 0x03, 0x32, 0x03,
>> +				0x44, 0x44, 0xc0, 0x00, 0x1c, 0x20, 0xe8);
>> +}
>> +
>> +static void s6e3fa0_write_als(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xe3, 0xff, 0xff, 0xff, 0xff);
>> +}
>> +
>> +static void s6e3fa0_set_readability_enhancement(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xfe, 0x00, 0x03, 0xb0, 0x2b, 0xfe,
>> +									0xe4);
>> +}
>> +
>> +static void s6e3fa0_set_common_control(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_set_pentile_control(ctx);
>> +	s6e3fa0_write_als(ctx);
>> +	s6e3fa0_set_readability_enhancement(ctx);
>> +}
>> +
>> +static void s6e3fa0_set_gamma(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xca, 0x01, 0x00, 0x01, 0x00, 0x01,
>> +					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
>> +					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
>> +					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
>> +					0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
>> +					0x00, 0x00, 0x00);
>> +}
>> +
>> +static void s6e3fa0_set_aid(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xb2, 0x00, 0x06, 0x00, 0x06);
>> +}
>> +
>> +static void s6e3fa0_set_elvss(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xb6, 0x88, 0x0a);
>> +}
>> +
>> +static void s6e3fa0_update_panel(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xf7, 0x03);
>> +}
>> +
>> +static void s6e3fa0_write_acl(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0x55, 0x02);
>
>
> That's strange beast. It should be DCS command but I do not see it in
> spec. Specification violation???

Uhm, I referred s6e3fa0 data sheet.
The 0x55 command is used to set parameters for Automatic Current Limit
functionality.
I'll explain in more detail by comment.

>
>
>> +}
>> +
>> +static void s6e3fa0_set_brightness_control(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_set_gamma(ctx);
>> +	s6e3fa0_set_aid(ctx);
>> +	s6e3fa0_set_elvss(ctx);
>> +	s6e3fa0_update_panel(ctx);
>> +	s6e3fa0_write_acl(ctx);
>> +}
>> +
>> +static void s6e3fa0_set_temperature(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0xb0, 0x05, 0xb8, 0x19);
>> +}
>> +
>> +static void s6e3fa0_set_elvss_control(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_set_temperature(ctx);
>> +	s6e3fa0_set_elvss(ctx);
>> +}
>> +
>> +static void s6e3fa0_set_te_on(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_dcs_write_seq_static(ctx, 0x35, 0x00);
>
>
> s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_SET_TEAR_ON, 0x00);
>
>
>> +}
>> +
>> +static void s6e3fa0_set_etc_and_write_vddm(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_apply_level_2_key(ctx, true);
>> +	s6e3fa0_dcs_write_seq(ctx, 0xed, 0x0c, 0x04, 0xff, 0x01, 0xb0, 0x16,
>> +							0xd7, ctx->vddm);
>> +	s6e3fa0_apply_level_2_key(ctx, false);
>> +}
>> +
>> +static void s6e3fa0_set_etc_condition(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_set_te_on(ctx);
>> +	s6e3fa0_set_etc_and_write_vddm(ctx);
>> +}
>> +
>> +static void s6e3fa0_panel_init(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_set_common_control(ctx);
>> +	s6e3fa0_set_brightness_control(ctx);
>> +	s6e3fa0_set_elvss_control(ctx);
>> +	s6e3fa0_set_etc_condition(ctx);
>> +
>> +	msleep(ctx->init_delay);
>> +}
>> +
>> +static int s6e3fa0_power_off(struct s6e3fa0 *ctx)
>> +{
>> +	gpiod_set_value(ctx->reset_gpio, 0);
>> +
>> +	return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
>> +}
>> +
>> +static int s6e3fa0_power_on(struct s6e3fa0 *ctx)
>> +{
>> +	int ret;
>> +
>> +	ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
>> +	if (ret)
>> +		return ret;
>> +
>> +	msleep(ctx->power_on_delay);
>> +
>> +	gpiod_set_value(ctx->reset_gpio, 1);
>> +	gpiod_set_value(ctx->reset_gpio, 0);
>> +	usleep_range(1000, 2000);
>> +	gpiod_set_value(ctx->reset_gpio, 1);
>> +
>> +	msleep(ctx->reset_delay);
>> +
>> +	return 0;
>> +}
>> +
>> +static void s6e3fa0_set_sequence(struct s6e3fa0 *ctx)
>> +{
>> +	s6e3fa0_apply_level_1_key(ctx);
>> +	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE);
>> +	msleep(20);
>> +
>> +	s6e3fa0_read_mtp_id(ctx);
>> +	s6e3fa0_read_vddm(ctx);
>> +
>> +	s6e3fa0_panel_init(ctx);
>> +
>> +	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_ON);
>> +}
>> +
>> +static int s6e3fa0_disable(struct drm_panel *panel)
>> +{
>> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>> +
>> +	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE);
>> +	s6e3fa0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_OFF);
>> +	msleep(35);
>> +
>> +	return s6e3fa0_power_off(ctx);
>> +}
>> +
>> +static int s6e3fa0_enable(struct drm_panel *panel)
>> +{
>> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>> +	int ret;
>> +
>> +	ret = s6e3fa0_power_on(ctx);
>> +	if (ret)
>> +		return ret;
>> +
>> +	s6e3fa0_set_sequence(ctx);
>> +
>> +	return ret;
>> +}
>> +
>> +static int s6e3fa0_get_modes(struct drm_panel *panel)
>> +{
>> +	struct drm_connector *connector = panel->connector;
>> +	struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
>> +	struct drm_display_mode *mode;
>> +
>> +	mode = drm_mode_create(connector->dev);
>> +	if (!mode) {
>> +		DRM_ERROR("failed to create a new display mode\n");
>> +		return 0;
>> +	}
>> +
>> +	drm_display_mode_from_videomode(&ctx->vm, mode);
>> +	mode->width_mm = ctx->width_mm;
>> +	mode->height_mm = ctx->height_mm;
>> +	connector->display_info.width_mm = mode->width_mm;
>> +	connector->display_info.height_mm = mode->height_mm;
>> +
>> +	mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>> +	mode->private = (void *)&ctx->cpu_timings;
>> +	drm_mode_probed_add(connector, mode);
>> +
>> +	return 1;
>> +}
>> +
>> +static const struct drm_panel_funcs s6e3fa0_drm_funcs = {
>> +	.disable	= s6e3fa0_disable,
>> +	.enable		= s6e3fa0_enable,
>> +	.get_modes	= s6e3fa0_get_modes,
>> +};
>> +
>> +static int s6e3fa0_parse_dt(struct s6e3fa0 *ctx)
>> +{
>> +	struct device *dev = ctx->dev;
>> +	struct device_node *np = dev->of_node, *cpu_timing_np;
>> +	struct drm_panel_cpu_timings *cpu_timings = &ctx->cpu_timings;
>> +	int ret;
>> +
>> +	ret = of_get_videomode(np, &ctx->vm, 0);
>> +	if (ret) {
>> +		dev_err(dev, "failed to get video mode: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	cpu_timing_np = of_find_node_by_name(np, "cpu-timings");
>> +	if (!cpu_timing_np) {
>> +		dev_err(dev, "failed to get cpu timings\n");
>> +		return -EINVAL;
>> +	}
>> +	if (of_property_read_u32(cpu_timing_np, "cs-setup",
>> +					&cpu_timings->cs_setup))
>> +		cpu_timings->cs_setup = 0;
>> +	if (of_property_read_u32(cpu_timing_np, "wr-setup",
>> +					&cpu_timings->wr_setup))
>> +		cpu_timings->wr_setup = 0;
>> +	if (of_property_read_u32(cpu_timing_np, "wr-act",
>> +					&cpu_timings->wr_act))
>> +		cpu_timings->wr_act = 1;
>> +	if (of_property_read_u32(cpu_timing_np, "wr-hold",
>> +					&cpu_timings->wr_hold))
>> +		cpu_timings->wr_hold = 0;
>
> If I remember default values were not provided in bindings, please fix it.

Okay

>
>
>> +	of_node_put(cpu_timing_np);
>> +
>> +	return 0;
>> +}
>> +
>> +irqreturn_t s6e3fa0_det_interrupt(int irq, void *dev_id)
>> +{
>> +	/* TODO */
>> +	return IRQ_HANDLED;
>> +}
>> +
>> +irqreturn_t s6e3fa0_te_interrupt(int irq, void *dev_id)
>> +{
>> +	struct s6e3fa0 *ctx = dev_id;
>> +	struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>> +	struct mipi_dsi_host *host = dsi->host;
>> +	const struct mipi_dsi_host_ops *ops = host->ops;
>> +
>> +	if (ops && ops->te_handler)
>> +		ops->te_handler(host);
>> +
>> +	return IRQ_HANDLED;
>> +}
>> +
>> +static int s6e3fa0_probe(struct mipi_dsi_device *dsi)
>> +{
>> +	struct device *dev = &dsi->dev;
>> +	struct s6e3fa0 *ctx;
>> +	int ret;
>> +
>> +	ctx = devm_kzalloc(dev, sizeof(struct s6e3fa0), GFP_KERNEL);
>> +	if (!ctx) {
>> +		dev_err(dev, "failed to allocate s6e3fa0 structure.\n");
>> +		return -ENOMEM;
>> +	}
>> +
>> +	mipi_dsi_set_drvdata(dsi, ctx);
>> +
>> +	ctx->dev = dev;
>> +
>> +	dsi->lanes = 4;
>> +	dsi->format = MIPI_DSI_FMT_RGB888;
>> +
>> +	ret = s6e3fa0_parse_dt(ctx);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ctx->supplies[0].supply = "vdd3";
>> +	ctx->supplies[1].supply = "vci";
>> +	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
>> +					ctx->supplies);
>> +	if (ret) {
>> +		dev_err(dev, "failed to get regulators: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	ctx->reset_gpio = devm_gpiod_get(dev, "reset");
>> +	if (IS_ERR(ctx->reset_gpio)) {
>> +		dev_err(dev, "failed to get reset gpio: %ld\n",
>> +						PTR_ERR(ctx->reset_gpio));
>> +		return PTR_ERR(ctx->reset_gpio);
>> +	}
>> +	ret = gpiod_direction_output(ctx->reset_gpio, 1);
>> +	if (ret < 0) {
>> +		dev_err(dev, "failed to configure reset gpio: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	ctx->det_gpio = devm_gpiod_get(dev, "det");
>> +	if (IS_ERR(ctx->det_gpio)) {
>> +		dev_err(dev, "failed to get det gpio: %ld\n",
>> +						PTR_ERR(ctx->det_gpio));
>> +		return PTR_ERR(ctx->det_gpio);
>> +	}
>> +	ret = gpiod_direction_input(ctx->det_gpio);
>> +	if (ret < 0) {
>> +		dev_err(dev, "failed to configure det gpio: %d\n", ret);
>> +		return ret;
>> +	}
>> +	ret = devm_request_irq(dev, gpiod_to_irq(ctx->det_gpio),
>> +						s6e3fa0_det_interrupt,
>> +						IRQF_TRIGGER_FALLING,
>> +						"oled-det", ctx);
>> +	if (ret) {
>> +		dev_err(dev, "failed to request det irq: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	ctx->te_gpio = devm_gpiod_get(dev, "te");
>> +	if (IS_ERR(ctx->te_gpio)) {
>> +		dev_err(dev, "failed to get te gpio: %ld\n",
>> +						PTR_ERR(ctx->te_gpio));
>> +		return PTR_ERR(ctx->te_gpio);
>> +	}
>> +	ret = gpiod_direction_input(ctx->te_gpio);
>> +	if (ret < 0) {
>> +		dev_err(dev, "failed to configure te gpio: %d\n", ret);
>> +		return ret;
>> +	}
>> +	ret = devm_request_irq(dev, gpiod_to_irq(ctx->te_gpio),
>> +						s6e3fa0_te_interrupt,
>> +						IRQF_TRIGGER_RISING,
>> +						"TE", ctx);
>> +	if (ret) {
>> +		dev_err(dev, "failed to request det irq: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	ctx->power_on_delay = 10;
>> +	ctx->reset_delay = 5;
>> +	ctx->init_delay = 120;
>> +	ctx->width_mm = 71;
>> +	ctx->height_mm = 126;
>> +
>> +	ctx->brightness = GAMMA_LEVEL_NUM - 1;
>> +
>> +	drm_panel_init(&ctx->panel);
>> +	ctx->panel.dev = dev;
>> +	ctx->panel.funcs = &s6e3fa0_drm_funcs;
>> +
>> +	ret = drm_panel_add(&ctx->panel);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = mipi_dsi_attach(dsi);
>> +	if (ret)
>> +		drm_panel_remove(&ctx->panel);
>> +
>> +	return ret;
>> +}
>> +
>> +static int s6e3fa0_remove(struct mipi_dsi_device *dsi)
>> +{
>> +	struct s6e3fa0 *ctx = mipi_dsi_get_drvdata(dsi);
>> +
>> +	s6e3fa0_power_off(ctx);
>
>
> In case panel is off this will lead to double disable of regulators.
>
> In general mipi_dsi_detach should be enough, it will trigger hpd,
> which will set dpms to off, which will call s6e3fa0_power_off.

Okay, I'll check again.

Thank you.
Best regards YJ

>
>
> Regards
> Andrzej
>
>
>> +
>> +	mipi_dsi_detach(dsi);
>> +	drm_panel_remove(&ctx->panel);
>> +
>> +	return 0;
>> +}
>> +
>> +static struct of_device_id s6e3fa0_of_match[] = {
>> +	{ .compatible = "samsung,s6e3fa0" },
>> +	{ }
>> +};
>> +MODULE_DEVICE_TABLE(of, s6e3fa0_of_match);
>> +
>> +static struct mipi_dsi_driver s6e3fa0_driver = {
>> +	.probe = s6e3fa0_probe,
>> +	.remove = s6e3fa0_remove,
>> +	.driver = {
>> +		.name = "panel_s6e3fa0",
>> +		.owner = THIS_MODULE,
>> +		.of_match_table = s6e3fa0_of_match,
>> +	},
>> +};
>> +module_mipi_dsi_driver(s6e3fa0_driver);
>> +
>> +MODULE_AUTHOR("YoungJun Cho <yj44.cho@samsung.com>");
>> +MODULE_DESCRIPTION("MIPI-DSI based s6e3fa0 AMOLED LCD Panel Driver");
>> +MODULE_LICENSE("GPL v2");
>>
>
>

[RFC v2 PATCH 11/14] ARM: dts: exynos4: add system register node

[YoungJun Cho]

This patch adds sysreg property to fimd device node which is required
to use I80 interface.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 arch/arm/boot/dts/exynos4.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3d14cdb..a10aa50 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -528,6 +528,7 @@
 		clocks = <&clock 140>, <&clock 283>;
 		clock-names = "sclk_fimd", "fimd";
 		samsung,power-domain = <&pd_lcd0>;
+		samsung,sysreg = <&sys_reg>;
 		status = "disabled";
 	};
 };
-- 
1.7.9.5

[RFC v2 PATCH 12/14] ARM: dts: exynos5: add system register support

[YoungJun Cho]

This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 arch/arm/boot/dts/exynos5.dtsi |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 258dca4..f938bbb 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -88,12 +88,18 @@
 		status = "disabled";
 	};
 
+	sys_reg: syscon@10050000 {
+		compatible = "samsung,exynos5-sysreg", "syscon";
+		reg = <0x10050000 0x500>;
+	};
+
 	fimd@14400000 {
 		compatible = "samsung,exynos5250-fimd";
 		interrupt-parent = <&combiner>;
 		reg = <0x14400000 0x40000>;
 		interrupt-names = "fifo", "vsync", "lcd_sys";
 		interrupts = <18 4>, <18 5>, <18 6>;
+		samsung,sysreg = <&sys_reg>;
 		status = "disabled";
 	};
 
-- 
1.7.9.5

[RFC v2 PATCH 13/14] ARM: dts: exynos5420: add mipi-phy node

[YoungJun Cho]

This patch adds mipi-phy node for MIPI-DSI device.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 arch/arm/boot/dts/exynos5420.dtsi |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 8db792b..f0184c7 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -416,6 +416,12 @@
 		phy-names = "dp";
 	};
 
+	mipi_phy: video-phy@10040714 {
+		compatible = "samsung,s5pv210-mipi-video-phy";
+		reg = <0x10040714 12>;
+		#phy-cells = <1>;
+	};
+
 	fimd@14400000 {
 		samsung,power-domain = <&disp_pd>;
 		clocks = <&clock 147>, <&clock 421>;
-- 
1.7.9.5

[RFC v2 PATCH 14/14] ARM: dts: exynos5420: add dsi node

[YoungJun Cho]

This patch adds common part of dsi node.

Changelog v2:
- Uses clock macros instead of numbers (commented by Sachin Kamat)

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 arch/arm/boot/dts/exynos5420.dtsi |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index f0184c7..f1030f5 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -17,6 +17,7 @@
 #include "exynos5420-pinctrl.dtsi"
 
 #include <dt-bindings/clk/exynos-audss-clk.h>
+#include <dt-bindings/clock/exynos5420.h>
 
 / {
 	compatible = "samsung,exynos5420";
@@ -422,6 +423,20 @@
 		#phy-cells = <1>;
 	};
 
+	dsi@14500000 {
+		compatible = "samsung,exynos5420-mipi-dsi";
+		reg = <0x14500000 0x10000>;
+		interrupts = <0 82 0>;
+		samsung,power-domain = <&disp_pd>;
+		phys = <&mipi_phy 1>;
+		phy-names = "dsim";
+		clocks = <&clock CLK_DSIM1>, <&clock CLK_SCLK_MIPI1>;
+		clock-names = "bus_clk", "pll_clk";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
 	fimd@14400000 {
 		samsung,power-domain = <&disp_pd>;
 		clocks = <&clock 147>, <&clock 421>;
-- 
1.7.9.5