[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Thierry,

On 09/21/2015 07:22 PM, Thierry Reding wrote:
> On Mon, Sep 21, 2015 at 06:27:40PM +0800, Yakir Yang wrote:
>> Hi Thierry,
>>
>> Thanks for your suggest :)
>>
>> On 09/21/2015 05:15 PM, Thierry Reding wrote:
>>> On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
 Hi Heiko,

 On 09/02/2015 10:15 AM, Yakir Yang wrote:
> Hi Heiko,
>
> 在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
>> Hi Yakir,
>>
>> Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
>>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP
>>> controller
>>> share the same IP, so a lot of parts can be re-used. I split the common
>>> code into bridge directory, then rk3288 and exynos only need to keep
>>> some platform code. Cause I can't find the exact IP name of exynos dp
>>> controller, so I decide to name dp core driver with "analogix" which I
>>> find in rk3288 eDP TRM ;)
>>>
>>> Beyond that, there are three light registers setting differents bewteen
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll resigters which not indicata in exynos
>>> dp controller.
>>> 2. The address of DP_PHY_PD(dp phy power manager register) are
>>> different
>>> between rk3288 and exynos.
>>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
>>> debug
>>> register).
>>>
>>> I have verified this series on two kinds of rockchip platform board,
>>> one
>>> is rk3288 sdk board which connect with a 2K display port monitor, the
>>> other
>>> is google jerry chromebook which connect with a eDP screen
>>> "cnm,n116bgeea2",
>>> both of them works rightlly.
>> it looks like during the rebase something did go wrong and I found some
>> issues
>> I mentioned in the replies to individual patches.
>>
>> I did prepare a branch based on mainline [0] with both the old and the
>> new edp
>> driver - rk3288_veyron_defconfig build both drivers into the image.
>>
>> While the old driver still works, I wasn't able to make the new one work
>> yet
>> ... the drm core does find the connector, but not that anything is
>> connected
>> to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
>> interesting before then.
> Many thanks for your comment and debug, I would rebase on your
> "edp-with-veyron" branch and fix the broken, make sure v6 would
> work rightly at least in your side and my side.
 Just like we talk off line, I guess there are two tricky questions which
 make analogix_dp just crash/failed on rockchip platform:

 -  One is how to reach a agreement with the common way to register
 connector. There would be a conflict with Exynos & IMX & Rockchip.
   On analogix_dp thread, Exynos want to register connector when that
 connector is ready.
   On dw_hdmi thread, IMX want to register connector when all component 
 is
 already.
   So Exynos & IMX & Rockchip should reach a common way to register
 connector to fix this issue.

 -  The other is atomic API.
The rockchip drm haven't implemented the atomic API, but the 
 original
 exynos_dp have used the atomic API on connector helper function. That's why
 analogix_dp just keep crash on your side.
>>> There's really no reason not to convert Rockchip to atomic. It will have
>>> to happen eventually anyway.
>> Do agree on this point, and I see Tomasz Figa have done some WIP
>> works on implementing the atomic_commit, maybe would upstream
>> in further.(https://chromium-review.googlesource.com/#/c/284560/1)
>>
>>
>>> That said, there's another option that would allow you to side-step both
>>> of the above problems at the same time. If you turn the common code into
>>> a helper library that should give you enough flexibility to integrate it
>>> into all existing users. For example you could leave out the connector
>>> registration and let the drivers do that. Similarly since the helpers
>>> are only hooked up at registration time you could probably find a way to
>>> share the low-level code but again leave it up to the drivers to glue it
>>> all together at registration time (drivers could wrap the low-level code
>>> with atomic or non-atomic callbacks).
>> Wow, sounds good, but I'm not sure I understand this rightly. Do you
>> mean that I could support two kinds of callbacks in analogix_dp_core
>> driver, and export them out. And move the connector registration code
>> into the helper driver (like exynos_dp.c), so helper driver could chose to
>> use the atomic or non-atomic callbacks. like:
>>
>> -- analogix_dp_core.c
>> 
>> ...
>> struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
>>  .dpms = drm_atomic_helper_connector_dpms,
>>  .fill_modes = 

[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Thierry,

Thanks for your suggest :)

On 09/21/2015 05:15 PM, Thierry Reding wrote:
> On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
>> Hi Heiko,
>>
>> On 09/02/2015 10:15 AM, Yakir Yang wrote:
>>> Hi Heiko,
>>>
>>> 在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
 Hi Yakir,

 Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
> The Samsung Exynos eDP controller and Rockchip RK3288 eDP
> controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM ;)
>
> Beyond that, there are three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
> dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are
> different
> between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
> debug
> register).
>
> I have verified this series on two kinds of rockchip platform board,
> one
> is rk3288 sdk board which connect with a 2K display port monitor, the
> other
> is google jerry chromebook which connect with a eDP screen
> "cnm,n116bgeea2",
> both of them works rightlly.
 it looks like during the rebase something did go wrong and I found some
 issues
 I mentioned in the replies to individual patches.

 I did prepare a branch based on mainline [0] with both the old and the
 new edp
 driver - rk3288_veyron_defconfig build both drivers into the image.

 While the old driver still works, I wasn't able to make the new one work
 yet
 ... the drm core does find the connector, but not that anything is
 connected
 to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
 interesting before then.
>>> Many thanks for your comment and debug, I would rebase on your
>>> "edp-with-veyron" branch and fix the broken, make sure v6 would
>>> work rightly at least in your side and my side.
>> Just like we talk off line, I guess there are two tricky questions which
>> make analogix_dp just crash/failed on rockchip platform:
>>
>> -  One is how to reach a agreement with the common way to register
>> connector. There would be a conflict with Exynos & IMX & Rockchip.
>>   On analogix_dp thread, Exynos want to register connector when that
>> connector is ready.
>>   On dw_hdmi thread, IMX want to register connector when all component is
>> already.
>>   So Exynos & IMX & Rockchip should reach a common way to register
>> connector to fix this issue.
>>
>> -  The other is atomic API.
>>The rockchip drm haven't implemented the atomic API, but the original
>> exynos_dp have used the atomic API on connector helper function. That's why
>> analogix_dp just keep crash on your side.
> There's really no reason not to convert Rockchip to atomic. It will have
> to happen eventually anyway.

Do agree on this point, and I see Tomasz Figa have done some WIP
works on implementing the atomic_commit, maybe would upstream
in further.(https://chromium-review.googlesource.com/#/c/284560/1)


> That said, there's another option that would allow you to side-step both
> of the above problems at the same time. If you turn the common code into
> a helper library that should give you enough flexibility to integrate it
> into all existing users. For example you could leave out the connector
> registration and let the drivers do that. Similarly since the helpers
> are only hooked up at registration time you could probably find a way to
> share the low-level code but again leave it up to the drivers to glue it
> all together at registration time (drivers could wrap the low-level code
> with atomic or non-atomic callbacks).

Wow, sounds good, but I'm not sure I understand this rightly. Do you
mean that I could support two kinds of callbacks in analogix_dp_core
driver, and export them out. And move the connector registration code
into the helper driver (like exynos_dp.c), so helper driver could chose to
use the atomic or non-atomic callbacks. like:

-- analogix_dp_core.c 

...
struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
 .dpms = drm_atomic_helper_connector_dpms,
 .fill_modes = drm_helper_probe_single_connector_modes,
 .detect = analogix_dp_detect,
 .destroy = analogix_dp_connector_destroy,
 .reset = drm_atomic_helper_connector_reset,
 .atomic_duplicate_state = 
drm_atomic_helper_connector_duplicate_state,
 .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};

[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Heiko,

On 09/02/2015 10:15 AM, Yakir Yang wrote:
> Hi Heiko,
>
> 在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
>> Hi Yakir,
>>
>> Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
>>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP 
>>> controller
>>> share the same IP, so a lot of parts can be re-used. I split the common
>>> code into bridge directory, then rk3288 and exynos only need to keep
>>> some platform code. Cause I can't find the exact IP name of exynos dp
>>> controller, so I decide to name dp core driver with "analogix" which I
>>> find in rk3288 eDP TRM ;)
>>>
>>> Beyond that, there are three light registers setting differents bewteen
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll resigters which not indicata in exynos
>>> dp controller.
>>> 2. The address of DP_PHY_PD(dp phy power manager register) are 
>>> different
>>> between rk3288 and exynos.
>>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp 
>>> debug
>>> register).
>>>
>>> I have verified this series on two kinds of rockchip platform board, 
>>> one
>>> is rk3288 sdk board which connect with a 2K display port monitor, 
>>> the other
>>> is google jerry chromebook which connect with a eDP screen 
>>> "cnm,n116bgeea2",
>>> both of them works rightlly.
>> it looks like during the rebase something did go wrong and I found 
>> some issues
>> I mentioned in the replies to individual patches.
>>
>> I did prepare a branch based on mainline [0] with both the old and 
>> the new edp
>> driver - rk3288_veyron_defconfig build both drivers into the image.
>>
>> While the old driver still works, I wasn't able to make the new one 
>> work yet
>> ... the drm core does find the connector, but not that anything is 
>> connected
>> to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
>> interesting before then.
>
> Many thanks for your comment and debug, I would rebase on your
> "edp-with-veyron" branch and fix the broken, make sure v6 would
> work rightly at least in your side and my side.

Just like we talk off line, I guess there are two tricky questions which 
make analogix_dp just crash/failed on rockchip platform:

-  One is how to reach a agreement with the common way to register 
connector. There would be a conflict with Exynos & IMX & Rockchip.
  On analogix_dp thread, Exynos want to register connector when that 
connector is ready.
  On dw_hdmi thread, IMX want to register connector when all 
component is already.
  So Exynos & IMX & Rockchip should reach a common way to register 
connector to fix this issue.

-  The other is atomic API.
   The rockchip drm haven't implemented the atomic API, but the 
original exynos_dp have used the atomic API on connector helper 
function. That's why analogix_dp just keep crash on your side.

I have prepared the v5 version, although those would work directly on 
rockchip side, but I could upload some HACK patches to gerrit  to make 
this works,  hope we can keep the discussion going forward.

Thanks,
- Yakir

>
> - Yakir
>
>>
>> Heiko
>>
>> [0] https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron
>>
>>
>>
>>
>
>
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Thierry Reding]

On Mon, Sep 21, 2015 at 06:27:40PM +0800, Yakir Yang wrote:
> Hi Thierry,
> 
> Thanks for your suggest :)
> 
> On 09/21/2015 05:15 PM, Thierry Reding wrote:
> >On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
> >>Hi Heiko,
> >>
> >>On 09/02/2015 10:15 AM, Yakir Yang wrote:
> >>>Hi Heiko,
> >>>
> >>>在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
> Hi Yakir,
> 
> Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
> >The Samsung Exynos eDP controller and Rockchip RK3288 eDP
> >controller
> >share the same IP, so a lot of parts can be re-used. I split the common
> >code into bridge directory, then rk3288 and exynos only need to keep
> >some platform code. Cause I can't find the exact IP name of exynos dp
> >controller, so I decide to name dp core driver with "analogix" which I
> >find in rk3288 eDP TRM ;)
> >
> >Beyond that, there are three light registers setting differents bewteen
> >exynos and rk3288.
> >1. RK3288 have five special pll resigters which not indicata in exynos
> >dp controller.
> >2. The address of DP_PHY_PD(dp phy power manager register) are
> >different
> >between rk3288 and exynos.
> >3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
> >debug
> >register).
> >
> >I have verified this series on two kinds of rockchip platform board,
> >one
> >is rk3288 sdk board which connect with a 2K display port monitor, the
> >other
> >is google jerry chromebook which connect with a eDP screen
> >"cnm,n116bgeea2",
> >both of them works rightlly.
> it looks like during the rebase something did go wrong and I found some
> issues
> I mentioned in the replies to individual patches.
> 
> I did prepare a branch based on mainline [0] with both the old and the
> new edp
> driver - rk3288_veyron_defconfig build both drivers into the image.
> 
> While the old driver still works, I wasn't able to make the new one work
> yet
> ... the drm core does find the connector, but not that anything is
> connected
> to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
> interesting before then.
> >>>Many thanks for your comment and debug, I would rebase on your
> >>>"edp-with-veyron" branch and fix the broken, make sure v6 would
> >>>work rightly at least in your side and my side.
> >>Just like we talk off line, I guess there are two tricky questions which
> >>make analogix_dp just crash/failed on rockchip platform:
> >>
> >>-  One is how to reach a agreement with the common way to register
> >>connector. There would be a conflict with Exynos & IMX & Rockchip.
> >>  On analogix_dp thread, Exynos want to register connector when that
> >>connector is ready.
> >>  On dw_hdmi thread, IMX want to register connector when all component 
> >> is
> >>already.
> >>  So Exynos & IMX & Rockchip should reach a common way to register
> >>connector to fix this issue.
> >>
> >>-  The other is atomic API.
> >>   The rockchip drm haven't implemented the atomic API, but the original
> >>exynos_dp have used the atomic API on connector helper function. That's why
> >>analogix_dp just keep crash on your side.
> >There's really no reason not to convert Rockchip to atomic. It will have
> >to happen eventually anyway.
> 
> Do agree on this point, and I see Tomasz Figa have done some WIP
> works on implementing the atomic_commit, maybe would upstream
> in further.(https://chromium-review.googlesource.com/#/c/284560/1)
> 
> 
> >That said, there's another option that would allow you to side-step both
> >of the above problems at the same time. If you turn the common code into
> >a helper library that should give you enough flexibility to integrate it
> >into all existing users. For example you could leave out the connector
> >registration and let the drivers do that. Similarly since the helpers
> >are only hooked up at registration time you could probably find a way to
> >share the low-level code but again leave it up to the drivers to glue it
> >all together at registration time (drivers could wrap the low-level code
> >with atomic or non-atomic callbacks).
> 
> Wow, sounds good, but I'm not sure I understand this rightly. Do you
> mean that I could support two kinds of callbacks in analogix_dp_core
> driver, and export them out. And move the connector registration code
> into the helper driver (like exynos_dp.c), so helper driver could chose to
> use the atomic or non-atomic callbacks. like:
> 
> -- analogix_dp_core.c
> 
> ...
> struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
> .dpms = drm_atomic_helper_connector_dpms,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .detect = analogix_dp_detect,
> .destroy = analogix_dp_connector_destroy,
> .reset = 

[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Thierry Reding]

On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
> Hi Heiko,
> 
> On 09/02/2015 10:15 AM, Yakir Yang wrote:
> >Hi Heiko,
> >
> >在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
> >>Hi Yakir,
> >>
> >>Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
> >>>The Samsung Exynos eDP controller and Rockchip RK3288 eDP
> >>>controller
> >>>share the same IP, so a lot of parts can be re-used. I split the common
> >>>code into bridge directory, then rk3288 and exynos only need to keep
> >>>some platform code. Cause I can't find the exact IP name of exynos dp
> >>>controller, so I decide to name dp core driver with "analogix" which I
> >>>find in rk3288 eDP TRM ;)
> >>>
> >>>Beyond that, there are three light registers setting differents bewteen
> >>>exynos and rk3288.
> >>>1. RK3288 have five special pll resigters which not indicata in exynos
> >>>dp controller.
> >>>2. The address of DP_PHY_PD(dp phy power manager register) are
> >>>different
> >>>between rk3288 and exynos.
> >>>3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
> >>>debug
> >>>register).
> >>>
> >>>I have verified this series on two kinds of rockchip platform board,
> >>>one
> >>>is rk3288 sdk board which connect with a 2K display port monitor, the
> >>>other
> >>>is google jerry chromebook which connect with a eDP screen
> >>>"cnm,n116bgeea2",
> >>>both of them works rightlly.
> >>it looks like during the rebase something did go wrong and I found some
> >>issues
> >>I mentioned in the replies to individual patches.
> >>
> >>I did prepare a branch based on mainline [0] with both the old and the
> >>new edp
> >>driver - rk3288_veyron_defconfig build both drivers into the image.
> >>
> >>While the old driver still works, I wasn't able to make the new one work
> >>yet
> >>... the drm core does find the connector, but not that anything is
> >>connected
> >>to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
> >>interesting before then.
> >
> >Many thanks for your comment and debug, I would rebase on your
> >"edp-with-veyron" branch and fix the broken, make sure v6 would
> >work rightly at least in your side and my side.
> 
> Just like we talk off line, I guess there are two tricky questions which
> make analogix_dp just crash/failed on rockchip platform:
> 
> -  One is how to reach a agreement with the common way to register
> connector. There would be a conflict with Exynos & IMX & Rockchip.
>  On analogix_dp thread, Exynos want to register connector when that
> connector is ready.
>  On dw_hdmi thread, IMX want to register connector when all component is
> already.
>  So Exynos & IMX & Rockchip should reach a common way to register
> connector to fix this issue.
> 
> -  The other is atomic API.
>   The rockchip drm haven't implemented the atomic API, but the original
> exynos_dp have used the atomic API on connector helper function. That's why
> analogix_dp just keep crash on your side.

There's really no reason not to convert Rockchip to atomic. It will have
to happen eventually anyway.

That said, there's another option that would allow you to side-step both
of the above problems at the same time. If you turn the common code into
a helper library that should give you enough flexibility to integrate it
into all existing users. For example you could leave out the connector
registration and let the drivers do that. Similarly since the helpers
are only hooked up at registration time you could probably find a way to
share the low-level code but again leave it up to the drivers to glue it
all together at registration time (drivers could wrap the low-level code
with atomic or non-atomic callbacks).

This option may also have the benefit of loosening the coupling between
DRM drivers and the helper code for this IP, which may be handy in case
the drivers diverge again in the future, or ease transitions to new API.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Heiko,

在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
> Hi Yakir,
>
> Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>> share the same IP, so a lot of parts can be re-used. I split the common
>> code into bridge directory, then rk3288 and exynos only need to keep
>> some platform code. Cause I can't find the exact IP name of exynos dp
>> controller, so I decide to name dp core driver with "analogix" which I
>> find in rk3288 eDP TRM ;)
>>
>> Beyond that, there are three light registers setting differents bewteen
>> exynos and rk3288.
>> 1. RK3288 have five special pll resigters which not indicata in exynos
>> dp controller.
>> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>> between rk3288 and exynos.
>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>> register).
>>
>> I have verified this series on two kinds of rockchip platform board, one
>> is rk3288 sdk board which connect with a 2K display port monitor, the other
>> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
>> both of them works rightlly.
> it looks like during the rebase something did go wrong and I found some issues
> I mentioned in the replies to individual patches.
>
> I did prepare a branch based on mainline [0] with both the old and the new edp
> driver - rk3288_veyron_defconfig build both drivers into the image.
>
> While the old driver still works, I wasn't able to make the new one work yet
> ... the drm core does find the connector, but not that anything is connected
> to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
> interesting before then.

Many thanks for your comment and debug, I would rebase on your
"edp-with-veyron" branch and fix the broken, make sure v6 would
work rightly at least in your side and my side.

- Yakir

>
> Heiko
>
> [0] https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron
>
>
>
>

[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Heiko Stuebner]

Hi Yakir,

Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM ;)
> 
> Beyond that, there are three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
>dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>register).
> 
> I have verified this series on two kinds of rockchip platform board, one
> is rk3288 sdk board which connect with a 2K display port monitor, the other
> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
> both of them works rightlly.

it looks like during the rebase something did go wrong and I found some issues 
I mentioned in the replies to individual patches.

I did prepare a branch based on mainline [0] with both the old and the new edp 
driver - rk3288_veyron_defconfig build both drivers into the image.

While the old driver still works, I wasn't able to make the new one work yet 
... the drm core does find the connector, but not that anything is connected 
to it. I'll try to dig deeper tomorrow, but maybe you'll see anything 
interesting before then.


Heiko

[0] https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron

[PATCH v4 0/16] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi all,

   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM ;)

Beyond that, there are three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
   dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
   between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
   register).

I have verified this series on two kinds of rockchip platform board, one
is rk3288 sdk board which connect with a 2K display port monitor, the other
is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
both of them works rightlly.

I haven't verified the dp function on samsung platform, cause I haven't got
exynos boards. I can only ensure that there are no build error on samsung
platform, wish some samsung guys help to test. ;)

Besides, The v4 version have been rebased on linux-next master branch
(git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git), tag name is
next-20150828 (latest is next-2015-0831). So I think if someone try to apply
this series, there would be no conflict  ;)

Thanks,
- Yakir

Changes in v4:
- Take Romain suggest, rebase on linux-next branch.
- Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery.
- Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to "exynos_dp.c"
- Take Archit suggest, create a separate folder for analogix code in bridge/
- Take Jingoo Han suggest, update commit message more readable.
- Adjust the order from 05 to 04
- Take Krzysztof suggest, provide backword compatibility with samsung.
- Take Thierry suggest, add "color-depth" and "color-space" dynamic parsed.
- Take Krzysztof suggest, split all DTS changes, and provide backward 
compatibility.
  Mark old properties as deprecated but still support them.
- Take Rob suggest, update "analogix,hpd-gpio" to "hpd-gpios" prop name.
- Take Thierry suggest, deprecated some properties which could parsed from 
Edid/Mode/DPCD.
"analogix,color-space" & "analogix,color-depth"   &
"analogix,link-rate"   & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high"  & "interlaces"
- Take Krzysztof suggest, separate all DTS changes to a separate patch.
- Remove some deprecated DT properties in rockchip dp document.
- Take Kishon suggest, add commit message, and remove the redundant
  rockchip_dp_phy_init() function, move those code to probe() method.
  And remove driver .owner number.
- Take Thierry suggest, seprate the link-rate and lane-count limit
  out with the device_type flag.
- Take Jingoo suggest, add commit messages.
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Take Thierry Reding suggest, move exynos's video_timing code
  to analogix_dp-exynos platform driver, add get_modes method
  to struct analogix_dp_plat_data.
- Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
- Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
  the DT property value directly, but we can take those as hardware limite.
  For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
  so DT property would like "link-rate = 0x0a" "lane-count = 4".
- Take Thierry Reding suggest, dynamic parse video timing info from
  struct drm_display_mode and struct drm_display_info.
- Take Heiko suggest, add devicetree binding documents.
- Take Thierry Reding suggest, remove sync pol & colorimetry properies
  from the new analogix dp driver devicetree binding.
- Update the exist exynos dtsi file with the latest DP DT properies.
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
  dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
  core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform
  driver which name to "pclk".
- Take Heiko suggest, add devicetree binding document.
- Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
  point to get panel node.
- Add the new function point analogix_dp_platdata.get_modes init.
- Take Heiko suggest, add rockchip dp phy driver,
  collect the phy clocks and power control.
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.
- move dp hpd detect to connector detect function.
- Add edid modes parse support

Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
  avoid using some uncommon style like bellow:
  -  retval =