Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-07-31 Thread Yakir Yang


On 07/29/2016 04:38 PM, Tomeu Vizoso wrote:

On 5 April 2016 at 04:06, Yakir Yang  wrote:

Hi Daniel,


On 03/31/2016 06:15 PM, Daniel Vetter wrote:

On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:

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

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so
it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to
splict
the connector init to platform driver anymore, and this is the biggest
change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time
to
upgrade the version number, but I have changed ordering of patches
(adding 2
more, and removing 2 out). Especially to prevent confusing people, so I
updated
the whole series.

So I'm jumping into this part way late, but just noticed (well Thierry
pointed this out to me) that the exynos dp driver reinvents all the dp and
dp-aux helpers we already. That's somewhat okish for a private driver (and
exynos has a reputation for that kind of stuff), but imo not ok for a
shared driver.

Not saying this should block merging this patch, but it really needs to be
addressed. All the dp aux and edid read code in the current
exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
core i2c edid reading code.

Who's going to sign up to do this?


Volunteer to that, after finish this thread, I would send new series to
switch to take use of dp helper.

Hi Yakir,

do you have plans to do this work in the short term? If not, I can tackle it.


Wow, that would be great if you like to tackle it  :-D

I always keep this in my mind, but haven't found an chance
to finish it. I would like to sit in your Cc list when you post
them out  ;)

Best Regards,
- Yakir


Regards,

Tomeu


:-D
- Yakir



-Daniel


Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
  https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function.
(Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper
(Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in
drm_dp_helper.h (Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
 drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
(Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver
should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-07-31 Thread Yakir Yang


On 07/29/2016 04:38 PM, Tomeu Vizoso wrote:

On 5 April 2016 at 04:06, Yakir Yang  wrote:

Hi Daniel,


On 03/31/2016 06:15 PM, Daniel Vetter wrote:

On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:

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

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so
it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to
splict
the connector init to platform driver anymore, and this is the biggest
change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time
to
upgrade the version number, but I have changed ordering of patches
(adding 2
more, and removing 2 out). Especially to prevent confusing people, so I
updated
the whole series.

So I'm jumping into this part way late, but just noticed (well Thierry
pointed this out to me) that the exynos dp driver reinvents all the dp and
dp-aux helpers we already. That's somewhat okish for a private driver (and
exynos has a reputation for that kind of stuff), but imo not ok for a
shared driver.

Not saying this should block merging this patch, but it really needs to be
addressed. All the dp aux and edid read code in the current
exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
core i2c edid reading code.

Who's going to sign up to do this?


Volunteer to that, after finish this thread, I would send new series to
switch to take use of dp helper.

Hi Yakir,

do you have plans to do this work in the short term? If not, I can tackle it.


Wow, that would be great if you like to tackle it  :-D

I always keep this in my mind, but haven't found an chance
to finish it. I would like to sit in your Cc list when you post
them out  ;)

Best Regards,
- Yakir


Regards,

Tomeu


:-D
- Yakir



-Daniel


Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
  https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function.
(Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper
(Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in
drm_dp_helper.h (Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
 drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
(Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver
should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
patch, and update 

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-07-29 Thread Tomeu Vizoso
On 5 April 2016 at 04:06, Yakir Yang  wrote:
> Hi Daniel,
>
>
> On 03/31/2016 06:15 PM, Daniel Vetter wrote:
>>
>> On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
>>>
>>> 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
>>>
>>> But there are still three light registers setting different between
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll registers which not indicate 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).
>>>
>>> Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so
>>> it's
>>> okay to use the ATOMIC helpers functions in connector_funcs. No need to
>>> splict
>>> the connector init to platform driver anymore, and this is the biggest
>>> change
>>> since version 11.
>>>
>>> This v14 didn't have lots of new changes which seems not the correct time
>>> to
>>> upgrade the version number, but I have changed ordering of patches
>>> (adding 2
>>> more, and removing 2 out). Especially to prevent confusing people, so I
>>> updated
>>> the whole series.
>>
>> So I'm jumping into this part way late, but just noticed (well Thierry
>> pointed this out to me) that the exynos dp driver reinvents all the dp and
>> dp-aux helpers we already. That's somewhat okish for a private driver (and
>> exynos has a reputation for that kind of stuff), but imo not ok for a
>> shared driver.
>>
>> Not saying this should block merging this patch, but it really needs to be
>> addressed. All the dp aux and edid read code in the current
>> exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
>> core i2c edid reading code.
>>
>> Who's going to sign up to do this?
>
>
> Volunteer to that, after finish this thread, I would send new series to
> switch to take use of dp helper.

Hi Yakir,

do you have plans to do this work in the short term? If not, I can tackle it.

Regards,

Tomeu

> :-D
> - Yakir
>
>
>> -Daniel
>>
>>> Thanks,
>>> - Yakir
>>>
>>>
>>> Changes in v14:
>>> - Rebase the new changes in imx-dp driver
>>> - Split up this patch into 3 parts, make this easy to review (Heiko)
>>> - Remove the Rockchip DP PHY to an separate thread (Heiko)
>>>  https://patchwork.kernel.org/patch/8312701/
>>>
>>> Changes in v13:
>>> - Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
>>> - Fix the missing parameters with drm_encoder_init() helper function.
>>> (Heiko)
>>>
>>> Changes in v12:
>>> - Move the connector init to analogix_dp driver, and using ATOMIC helper
>>> (Heiko)
>>> - Add the ack from Jingoo
>>> - Remove the enum link_rate_type struct, using the marcos in
>>> drm_dp_helper.h (Jingoo)
>>>
>>> Changes in v11:
>>> - Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
>>> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
>>> - Add the ack from Rob Herring
>>> - Revert parts of Gustavo Padovan's changes in commit:
>>> drm/exynos: do not start enabling DP at bind() phase
>>>Add dp phy poweron function in bind time.
>>> - Move the panel prepare from get_modes time to bind time, and move
>>>the panel unprepare from bridge->disable to unbind time. (Heiko)
>>>
>>> Changes in v10:
>>> - Add the ack from Rob Herring
>>> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
>>> (Heiko)
>>> - Add the ack from Rob Herring
>>> - Remove the surplus "plat_data" check. (Heiko)
>>> -   switch (dp->plat_data && dp->plat_data->dev_type) {
>>> +   switch (dp->plat_data->dev_type) {
>>>
>>> Changes in v9:
>>> - Document more details for 'ports' property.
>>>
>>> Changes in v8:
>>> - Correct the right document path of display-timing.txt (Heiko)
>>> - Correct the misspell of 'from' to 'frm'. (Heiko)
>>> - Modify the commit subject name. (Heiko)
>>>
>>> Changes in v7:
>>> - Back to use the of_property_read_bool() interfacs to provoid backward
>>>compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>>>to avoid -EOVERFLOW error (Krzysztof)
>>>
>>> Changes in v6:
>>> - Fix the Kconfig recursive dependency (Javier)
>>> - Fix Peach Pit hpd property name error:
>>> -   hpd-gpio = < 6 0>;
>>> +   hpd-gpios = < 6 0>;
>>>
>>> Changes in v5:
>>> - Correct the check condition of gpio_is_valid when driver try to get
>>>the "hpd-gpios" DT propery. (Heiko)
>>> - Move the platform attach callback in the front of core driver bridge
>>>attch function. Cause once platform failed at attach, core 

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-07-29 Thread Tomeu Vizoso
On 5 April 2016 at 04:06, Yakir Yang  wrote:
> Hi Daniel,
>
>
> On 03/31/2016 06:15 PM, Daniel Vetter wrote:
>>
>> On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
>>>
>>> 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
>>>
>>> But there are still three light registers setting different between
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll registers which not indicate 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).
>>>
>>> Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so
>>> it's
>>> okay to use the ATOMIC helpers functions in connector_funcs. No need to
>>> splict
>>> the connector init to platform driver anymore, and this is the biggest
>>> change
>>> since version 11.
>>>
>>> This v14 didn't have lots of new changes which seems not the correct time
>>> to
>>> upgrade the version number, but I have changed ordering of patches
>>> (adding 2
>>> more, and removing 2 out). Especially to prevent confusing people, so I
>>> updated
>>> the whole series.
>>
>> So I'm jumping into this part way late, but just noticed (well Thierry
>> pointed this out to me) that the exynos dp driver reinvents all the dp and
>> dp-aux helpers we already. That's somewhat okish for a private driver (and
>> exynos has a reputation for that kind of stuff), but imo not ok for a
>> shared driver.
>>
>> Not saying this should block merging this patch, but it really needs to be
>> addressed. All the dp aux and edid read code in the current
>> exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
>> core i2c edid reading code.
>>
>> Who's going to sign up to do this?
>
>
> Volunteer to that, after finish this thread, I would send new series to
> switch to take use of dp helper.

Hi Yakir,

do you have plans to do this work in the short term? If not, I can tackle it.

Regards,

Tomeu

> :-D
> - Yakir
>
>
>> -Daniel
>>
>>> Thanks,
>>> - Yakir
>>>
>>>
>>> Changes in v14:
>>> - Rebase the new changes in imx-dp driver
>>> - Split up this patch into 3 parts, make this easy to review (Heiko)
>>> - Remove the Rockchip DP PHY to an separate thread (Heiko)
>>>  https://patchwork.kernel.org/patch/8312701/
>>>
>>> Changes in v13:
>>> - Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
>>> - Fix the missing parameters with drm_encoder_init() helper function.
>>> (Heiko)
>>>
>>> Changes in v12:
>>> - Move the connector init to analogix_dp driver, and using ATOMIC helper
>>> (Heiko)
>>> - Add the ack from Jingoo
>>> - Remove the enum link_rate_type struct, using the marcos in
>>> drm_dp_helper.h (Jingoo)
>>>
>>> Changes in v11:
>>> - Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
>>> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
>>> - Add the ack from Rob Herring
>>> - Revert parts of Gustavo Padovan's changes in commit:
>>> drm/exynos: do not start enabling DP at bind() phase
>>>Add dp phy poweron function in bind time.
>>> - Move the panel prepare from get_modes time to bind time, and move
>>>the panel unprepare from bridge->disable to unbind time. (Heiko)
>>>
>>> Changes in v10:
>>> - Add the ack from Rob Herring
>>> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
>>> (Heiko)
>>> - Add the ack from Rob Herring
>>> - Remove the surplus "plat_data" check. (Heiko)
>>> -   switch (dp->plat_data && dp->plat_data->dev_type) {
>>> +   switch (dp->plat_data->dev_type) {
>>>
>>> Changes in v9:
>>> - Document more details for 'ports' property.
>>>
>>> Changes in v8:
>>> - Correct the right document path of display-timing.txt (Heiko)
>>> - Correct the misspell of 'from' to 'frm'. (Heiko)
>>> - Modify the commit subject name. (Heiko)
>>>
>>> Changes in v7:
>>> - Back to use the of_property_read_bool() interfacs to provoid backward
>>>compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>>>to avoid -EOVERFLOW error (Krzysztof)
>>>
>>> Changes in v6:
>>> - Fix the Kconfig recursive dependency (Javier)
>>> - Fix Peach Pit hpd property name error:
>>> -   hpd-gpio = < 6 0>;
>>> +   hpd-gpios = < 6 0>;
>>>
>>> Changes in v5:
>>> - Correct the check condition of gpio_is_valid when driver try to get
>>>the "hpd-gpios" DT propery. (Heiko)
>>> - Move the platform attach callback in the front of core driver bridge
>>>attch function. Cause once platform failed at attach, core driver
>>> should
>>>

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-04-04 Thread Yakir Yang

Hi Daniel,

On 03/31/2016 06:15 PM, Daniel Vetter wrote:

On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:

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

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
the connector init to platform driver anymore, and this is the biggest change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time to
upgrade the version number, but I have changed ordering of patches (adding 2
more, and removing 2 out). Especially to prevent confusing people, so I updated
the whole series.

So I'm jumping into this part way late, but just noticed (well Thierry
pointed this out to me) that the exynos dp driver reinvents all the dp and
dp-aux helpers we already. That's somewhat okish for a private driver (and
exynos has a reputation for that kind of stuff), but imo not ok for a
shared driver.

Not saying this should block merging this patch, but it really needs to be
addressed. All the dp aux and edid read code in the current
exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
core i2c edid reading code.

Who's going to sign up to do this?


Volunteer to that, after finish this thread, I would send new series to
switch to take use of dp helper.

:-D
- Yakir


-Daniel


Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
 https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
(Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
   Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
   the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
   to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-04-04 Thread Yakir Yang

Hi Daniel,

On 03/31/2016 06:15 PM, Daniel Vetter wrote:

On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:

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

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
the connector init to platform driver anymore, and this is the biggest change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time to
upgrade the version number, but I have changed ordering of patches (adding 2
more, and removing 2 out). Especially to prevent confusing people, so I updated
the whole series.

So I'm jumping into this part way late, but just noticed (well Thierry
pointed this out to me) that the exynos dp driver reinvents all the dp and
dp-aux helpers we already. That's somewhat okish for a private driver (and
exynos has a reputation for that kind of stuff), but imo not ok for a
shared driver.

Not saying this should block merging this patch, but it really needs to be
addressed. All the dp aux and edid read code in the current
exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
core i2c edid reading code.

Who's going to sign up to do this?


Volunteer to that, after finish this thread, I would send new series to
switch to take use of dp helper.

:-D
- Yakir


-Daniel


Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
 https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
(Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
   Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
   the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
   to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-31 Thread Thierry Reding
On Thu, Mar 31, 2016 at 12:15:35PM +0200, Daniel Vetter wrote:
> On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
> > 
> > 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
> > 
> > But there are still three light registers setting different between
> > exynos and rk3288.
> > 1. RK3288 have five special pll registers which not indicate 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).
> > 
> > Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
> > okay to use the ATOMIC helpers functions in connector_funcs. No need to 
> > splict
> > the connector init to platform driver anymore, and this is the biggest 
> > change
> > since version 11.
> > 
> > This v14 didn't have lots of new changes which seems not the correct time to
> > upgrade the version number, but I have changed ordering of patches (adding 2
> > more, and removing 2 out). Especially to prevent confusing people, so I 
> > updated
> > the whole series.
> 
> So I'm jumping into this part way late, but just noticed (well Thierry
> pointed this out to me) that the exynos dp driver reinvents all the dp and
> dp-aux helpers we already. That's somewhat okish for a private driver (and
> exynos has a reputation for that kind of stuff), but imo not ok for a
> shared driver.
> 
> Not saying this should block merging this patch, but it really needs to be
> addressed. All the dp aux and edid read code in the current
> exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
> core i2c edid reading code.

Agreed. I think a first step would be to implement and register a
drm_dp_aux object for Analogix DP hardware. That will give you access to
a slew of helpers that allow to read DPCD, parse link status and use the
standard EDID reading routines that the DRM core already has. This
should remove a lot of duplication from this driver.

For extra incentive, doing this might even fix a bug or two.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-31 Thread Thierry Reding
On Thu, Mar 31, 2016 at 12:15:35PM +0200, Daniel Vetter wrote:
> On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
> > 
> > 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
> > 
> > But there are still three light registers setting different between
> > exynos and rk3288.
> > 1. RK3288 have five special pll registers which not indicate 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).
> > 
> > Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
> > okay to use the ATOMIC helpers functions in connector_funcs. No need to 
> > splict
> > the connector init to platform driver anymore, and this is the biggest 
> > change
> > since version 11.
> > 
> > This v14 didn't have lots of new changes which seems not the correct time to
> > upgrade the version number, but I have changed ordering of patches (adding 2
> > more, and removing 2 out). Especially to prevent confusing people, so I 
> > updated
> > the whole series.
> 
> So I'm jumping into this part way late, but just noticed (well Thierry
> pointed this out to me) that the exynos dp driver reinvents all the dp and
> dp-aux helpers we already. That's somewhat okish for a private driver (and
> exynos has a reputation for that kind of stuff), but imo not ok for a
> shared driver.
> 
> Not saying this should block merging this patch, but it really needs to be
> addressed. All the dp aux and edid read code in the current
> exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
> core i2c edid reading code.

Agreed. I think a first step would be to implement and register a
drm_dp_aux object for Analogix DP hardware. That will give you access to
a slew of helpers that allow to read DPCD, parse link status and use the
standard EDID reading routines that the DRM core already has. This
should remove a lot of duplication from this driver.

For extra incentive, doing this might even fix a bug or two.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-31 Thread Daniel Vetter
On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
> 
> 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
> 
> But there are still three light registers setting different between
> exynos and rk3288.
> 1. RK3288 have five special pll registers which not indicate 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).
> 
> Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
> okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
> the connector init to platform driver anymore, and this is the biggest change
> since version 11.
> 
> This v14 didn't have lots of new changes which seems not the correct time to
> upgrade the version number, but I have changed ordering of patches (adding 2
> more, and removing 2 out). Especially to prevent confusing people, so I 
> updated
> the whole series.

So I'm jumping into this part way late, but just noticed (well Thierry
pointed this out to me) that the exynos dp driver reinvents all the dp and
dp-aux helpers we already. That's somewhat okish for a private driver (and
exynos has a reputation for that kind of stuff), but imo not ok for a
shared driver.

Not saying this should block merging this patch, but it really needs to be
addressed. All the dp aux and edid read code in the current
exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
core i2c edid reading code.

Who's going to sign up to do this?
-Daniel

> 
> Thanks,
> - Yakir
> 
> 
> Changes in v14:
> - Rebase the new changes in imx-dp driver
> - Split up this patch into 3 parts, make this easy to review (Heiko)
> - Remove the Rockchip DP PHY to an separate thread (Heiko)
> https://patchwork.kernel.org/patch/8312701/
> 
> Changes in v13:
> - Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
> - Fix the missing parameters with drm_encoder_init() helper function. (Heiko)
> 
> Changes in v12:
> - Move the connector init to analogix_dp driver, and using ATOMIC helper 
> (Heiko)
> - Add the ack from Jingoo
> - Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
> (Jingoo)
> 
> Changes in v11:
> - Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
> - Add the ack from Rob Herring
> - Revert parts of Gustavo Padovan's changes in commit:
>   drm/exynos: do not start enabling DP at bind() phase
>   Add dp phy poweron function in bind time.
> - Move the panel prepare from get_modes time to bind time, and move
>   the panel unprepare from bridge->disable to unbind time. (Heiko)
> 
> Changes in v10:
> - Add the ack from Rob Herring
> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
> - Add the ack from Rob Herring
> - Remove the surplus "plat_data" check. (Heiko)
> -   switch (dp->plat_data && dp->plat_data->dev_type) {
> +   switch (dp->plat_data->dev_type) {
> 
> Changes in v9:
> - Document more details for 'ports' property.
> 
> Changes in v8:
> - Correct the right document path of display-timing.txt (Heiko)
> - Correct the misspell of 'from' to 'frm'. (Heiko)
> - Modify the commit subject name. (Heiko)
> 
> Changes in v7:
> - Back to use the of_property_read_bool() interfacs to provoid backward
>   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>   to avoid -EOVERFLOW error (Krzysztof)
> 
> Changes in v6:
> - Fix the Kconfig recursive dependency (Javier)
> - Fix Peach Pit hpd property name error:
> -   hpd-gpio = < 6 0>;
> +   hpd-gpios = < 6 0>;
> 
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>   the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>   attch function. Cause once platform failed at attach, core driver should
>   still failed, so no need to init connector before platform attached 
> (Krzysztof)
> - Keep code style no changes with the previous exynos_dp_code.c in this
>   patch, and update commit message about the new export symbol (Krzysztof)
> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
> - leave out the connector registration to analogix platform driver. (Thierry)
> - Resequence this patch after analogix_dp driver have been split
>   from exynos_dp code, and rephrase reasonable commit message, and
>   remove some controversial style (Krzysztof)
> - 

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-31 Thread Daniel Vetter
On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
> 
> 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
> 
> But there are still three light registers setting different between
> exynos and rk3288.
> 1. RK3288 have five special pll registers which not indicate 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).
> 
> Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
> okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
> the connector init to platform driver anymore, and this is the biggest change
> since version 11.
> 
> This v14 didn't have lots of new changes which seems not the correct time to
> upgrade the version number, but I have changed ordering of patches (adding 2
> more, and removing 2 out). Especially to prevent confusing people, so I 
> updated
> the whole series.

So I'm jumping into this part way late, but just noticed (well Thierry
pointed this out to me) that the exynos dp driver reinvents all the dp and
dp-aux helpers we already. That's somewhat okish for a private driver (and
exynos has a reputation for that kind of stuff), but imo not ok for a
shared driver.

Not saying this should block merging this patch, but it really needs to be
addressed. All the dp aux and edid read code in the current
exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
core i2c edid reading code.

Who's going to sign up to do this?
-Daniel

> 
> Thanks,
> - Yakir
> 
> 
> Changes in v14:
> - Rebase the new changes in imx-dp driver
> - Split up this patch into 3 parts, make this easy to review (Heiko)
> - Remove the Rockchip DP PHY to an separate thread (Heiko)
> https://patchwork.kernel.org/patch/8312701/
> 
> Changes in v13:
> - Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
> - Fix the missing parameters with drm_encoder_init() helper function. (Heiko)
> 
> Changes in v12:
> - Move the connector init to analogix_dp driver, and using ATOMIC helper 
> (Heiko)
> - Add the ack from Jingoo
> - Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
> (Jingoo)
> 
> Changes in v11:
> - Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
> - Add the ack from Rob Herring
> - Revert parts of Gustavo Padovan's changes in commit:
>   drm/exynos: do not start enabling DP at bind() phase
>   Add dp phy poweron function in bind time.
> - Move the panel prepare from get_modes time to bind time, and move
>   the panel unprepare from bridge->disable to unbind time. (Heiko)
> 
> Changes in v10:
> - Add the ack from Rob Herring
> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
> - Add the ack from Rob Herring
> - Remove the surplus "plat_data" check. (Heiko)
> -   switch (dp->plat_data && dp->plat_data->dev_type) {
> +   switch (dp->plat_data->dev_type) {
> 
> Changes in v9:
> - Document more details for 'ports' property.
> 
> Changes in v8:
> - Correct the right document path of display-timing.txt (Heiko)
> - Correct the misspell of 'from' to 'frm'. (Heiko)
> - Modify the commit subject name. (Heiko)
> 
> Changes in v7:
> - Back to use the of_property_read_bool() interfacs to provoid backward
>   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>   to avoid -EOVERFLOW error (Krzysztof)
> 
> Changes in v6:
> - Fix the Kconfig recursive dependency (Javier)
> - Fix Peach Pit hpd property name error:
> -   hpd-gpio = < 6 0>;
> +   hpd-gpios = < 6 0>;
> 
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>   the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>   attch function. Cause once platform failed at attach, core driver should
>   still failed, so no need to init connector before platform attached 
> (Krzysztof)
> - Keep code style no changes with the previous exynos_dp_code.c in this
>   patch, and update commit message about the new export symbol (Krzysztof)
> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
> - leave out the connector registration to analogix platform driver. (Thierry)
> - Resequence this patch after analogix_dp driver have been split
>   from exynos_dp code, and rephrase reasonable commit message, and
>   remove some controversial style (Krzysztof)
> - 

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-24 Thread Heiko Stübner
Am Montag, 15. Februar 2016, 19:08:05 schrieb 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
> 
> But there are still three light registers setting different between
> exynos and rk3288.
> 1. RK3288 have five special pll registers which not indicate 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).
> 
> Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
> okay to use the ATOMIC helpers functions in connector_funcs. No need to
> splict the connector init to platform driver anymore, and this is the
> biggest change since version 11.
> 
> This v14 didn't have lots of new changes which seems not the correct time to
> upgrade the version number, but I have changed ordering of patches (adding
> 2 more, and removing 2 out). Especially to prevent confusing people, so I
> updated the whole series.

I guess I never said that explicitly, but of course I have tested this 
numerous times, so

This series
Tested-by: Heiko Stuebner 


Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-24 Thread Heiko Stübner
Am Montag, 15. Februar 2016, 19:08:05 schrieb 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
> 
> But there are still three light registers setting different between
> exynos and rk3288.
> 1. RK3288 have five special pll registers which not indicate 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).
> 
> Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
> okay to use the ATOMIC helpers functions in connector_funcs. No need to
> splict the connector init to platform driver anymore, and this is the
> biggest change since version 11.
> 
> This v14 didn't have lots of new changes which seems not the correct time to
> upgrade the version number, but I have changed ordering of patches (adding
> 2 more, and removing 2 out). Especially to prevent confusing people, so I
> updated the whole series.

I guess I never said that explicitly, but of course I have tested this 
numerous times, so

This series
Tested-by: Heiko Stuebner 


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-24 Thread Yakir Yang


On 03/22/2016 08:41 PM, Dave Airlie wrote:

So although it's small framework or just subdirectory, we would need
someone who can manage the framework to avoid further confusion if
necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

The author just send me a pull request with acks from a git tree
that hopefully both people agreed and tested from. No need to
send this via another maintainer layer.

Dave.



Wow, thanks all ! such cool news  :-D  I'll prepare my pull request soon


- Yakir



Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-24 Thread Yakir Yang


On 03/22/2016 08:41 PM, Dave Airlie wrote:

So although it's small framework or just subdirectory, we would need
someone who can manage the framework to avoid further confusion if
necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

The author just send me a pull request with acks from a git tree
that hopefully both people agreed and tested from. No need to
send this via another maintainer layer.

Dave.



Wow, thanks all ! such cool news  :-D  I'll prepare my pull request soon


- Yakir



Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-23 Thread Thierry Reding
On Wed, Mar 23, 2016 at 10:41:58AM +1000, Dave Airlie wrote:
> >
> >> So although it's small framework or just subdirectory, we would need
> >> someone who can manage the framework to avoid further confusion if
> >> necessary.
> >
> > So maybe it just doesn't need a maintainer, and maybe those the owner
> > of the bridge driver should be responsible for choosing the tree which
> > it's merged through along with updates.  That's how dw-hdmi has been
> > managed on the whole.
> >
> > It also means that the bridge driver maintainer is able to test changes
> > to the bridge driver, rather than having some over-arching bridge
> > subdirectory maintainer who doesn't have a clue whether the changes
> > work on the hardware.
> >
> > IMHO, having bridge driver authors/maintainers look after their own
> > code has many advantages.
> 
> The author just send me a pull request with acks from a git tree
> that hopefully both people agreed and tested from. No need to
> send this via another maintainer layer.

I have in the past "maintained" bridge drivers as part of the panel
tree, but I have no objections at all for this to go in via one of the
trees where it is used and can actually be tested.

Thierry


signature.asc
Description: PGP signature


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-23 Thread Thierry Reding
On Wed, Mar 23, 2016 at 10:41:58AM +1000, Dave Airlie wrote:
> >
> >> So although it's small framework or just subdirectory, we would need
> >> someone who can manage the framework to avoid further confusion if
> >> necessary.
> >
> > So maybe it just doesn't need a maintainer, and maybe those the owner
> > of the bridge driver should be responsible for choosing the tree which
> > it's merged through along with updates.  That's how dw-hdmi has been
> > managed on the whole.
> >
> > It also means that the bridge driver maintainer is able to test changes
> > to the bridge driver, rather than having some over-arching bridge
> > subdirectory maintainer who doesn't have a clue whether the changes
> > work on the hardware.
> >
> > IMHO, having bridge driver authors/maintainers look after their own
> > code has many advantages.
> 
> The author just send me a pull request with acks from a git tree
> that hopefully both people agreed and tested from. No need to
> send this via another maintainer layer.

I have in the past "maintained" bridge drivers as part of the panel
tree, but I have no objections at all for this to go in via one of the
trees where it is used and can actually be tested.

Thierry


signature.asc
Description: PGP signature


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Mark yao

On 2016年03月23日 08:41, Dave Airlie wrote:

So although it's small framework or just subdirectory, we would need
someone who can manage the framework to avoid further confusion if
necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

The author just send me a pull request with acks from a git tree
that hopefully both people agreed and tested from. No need to
send this via another maintainer layer.

Dave.





Sure, these patches looks cool, I think it's ready to be merged, I'd 
like to give a Acked-by on rockchip side.


--
Mark Yao




Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Mark yao

On 2016年03月23日 08:41, Dave Airlie wrote:

So although it's small framework or just subdirectory, we would need
someone who can manage the framework to avoid further confusion if
necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

The author just send me a pull request with acks from a git tree
that hopefully both people agreed and tested from. No need to
send this via another maintainer layer.

Dave.





Sure, these patches looks cool, I think it's ready to be merged, I'd 
like to give a Acked-by on rockchip side.


--
Mark Yao




Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Dave Airlie
>
>> So although it's small framework or just subdirectory, we would need
>> someone who can manage the framework to avoid further confusion if
>> necessary.
>
> So maybe it just doesn't need a maintainer, and maybe those the owner
> of the bridge driver should be responsible for choosing the tree which
> it's merged through along with updates.  That's how dw-hdmi has been
> managed on the whole.
>
> It also means that the bridge driver maintainer is able to test changes
> to the bridge driver, rather than having some over-arching bridge
> subdirectory maintainer who doesn't have a clue whether the changes
> work on the hardware.
>
> IMHO, having bridge driver authors/maintainers look after their own
> code has many advantages.

The author just send me a pull request with acks from a git tree
that hopefully both people agreed and tested from. No need to
send this via another maintainer layer.

Dave.


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Dave Airlie
>
>> So although it's small framework or just subdirectory, we would need
>> someone who can manage the framework to avoid further confusion if
>> necessary.
>
> So maybe it just doesn't need a maintainer, and maybe those the owner
> of the bridge driver should be responsible for choosing the tree which
> it's merged through along with updates.  That's how dw-hdmi has been
> managed on the whole.
>
> It also means that the bridge driver maintainer is able to test changes
> to the bridge driver, rather than having some over-arching bridge
> subdirectory maintainer who doesn't have a clue whether the changes
> work on the hardware.
>
> IMHO, having bridge driver authors/maintainers look after their own
> code has many advantages.

The author just send me a pull request with acks from a git tree
that hopefully both people agreed and tested from. No need to
send this via another maintainer layer.

Dave.


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Russell King - ARM Linux
On Wed, Mar 23, 2016 at 08:54:15AM +0900, Inki Dae wrote:
> 

Please wrap your long lines.

> 
> 2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> > On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> >> In this case, someone else may send an email again like you "who is going 
> >> to merge?"
> >> That would be why we need a maintainer.
> >>
> >> drm panel is already managed well by Thierry Reding without such 
> >> confusion. 
> > 
> > You don't need a maintainer for every subdirectory just because it's
> > a subdirectory...
> > 
> > Sometimes, having too many maintainers adds beaurocracy which becomes
> 
> Yes, but... if there is no someone who is responsible for maintainership,
> then we would receive such emails like Heiko sent "who is going to merge" 
> I don't also want adding many maintainers unnecessary but drm bridge -
> although the framework is a thin and small - is used *over the ARM SoC*
> so that many confusions may happen for upstream.

Just because someone asks doesn't mean someone needs to be appointed.
Maybe the question that should be asked instead is whether the original
author is willing to maintain their driver.

> So although it's small framework or just subdirectory, we would need
> someone who can manage the framework to avoid further confusion if
> necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Russell King - ARM Linux
On Wed, Mar 23, 2016 at 08:54:15AM +0900, Inki Dae wrote:
> 

Please wrap your long lines.

> 
> 2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> > On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> >> In this case, someone else may send an email again like you "who is going 
> >> to merge?"
> >> That would be why we need a maintainer.
> >>
> >> drm panel is already managed well by Thierry Reding without such 
> >> confusion. 
> > 
> > You don't need a maintainer for every subdirectory just because it's
> > a subdirectory...
> > 
> > Sometimes, having too many maintainers adds beaurocracy which becomes
> 
> Yes, but... if there is no someone who is responsible for maintainership,
> then we would receive such emails like Heiko sent "who is going to merge" 
> I don't also want adding many maintainers unnecessary but drm bridge -
> although the framework is a thin and small - is used *over the ARM SoC*
> so that many confusions may happen for upstream.

Just because someone asks doesn't mean someone needs to be appointed.
Maybe the question that should be asked instead is whether the original
author is willing to maintain their driver.

> So although it's small framework or just subdirectory, we would need
> someone who can manage the framework to avoid further confusion if
> necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Inki Dae


2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
>> In this case, someone else may send an email again like you "who is going to 
>> merge?"
>> That would be why we need a maintainer.
>>
>> drm panel is already managed well by Thierry Reding without such confusion. 
> 
> You don't need a maintainer for every subdirectory just because it's
> a subdirectory...
> 
> Sometimes, having too many maintainers adds beaurocracy which becomes

Yes, but... if there is no someone who is responsible for maintainership, then 
we would receive such emails like Heiko sent "who is going to merge" 
I don't also want adding many maintainers unnecessary but drm bridge - although 
the framework is a thin and small - is used *over the ARM SoC* so that many 
confusions may happen for upstream.

So although it's small framework or just subdirectory, we would need someone 
who can manage the framework to avoid further confusion if necessary.

Thanks,
Inki Dae

> counter-productive.  dw_hdmi seems to be adequately managed so far
> without there needing to be a "DRM bridge maintainer".
> 


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Inki Dae


2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
>> In this case, someone else may send an email again like you "who is going to 
>> merge?"
>> That would be why we need a maintainer.
>>
>> drm panel is already managed well by Thierry Reding without such confusion. 
> 
> You don't need a maintainer for every subdirectory just because it's
> a subdirectory...
> 
> Sometimes, having too many maintainers adds beaurocracy which becomes

Yes, but... if there is no someone who is responsible for maintainership, then 
we would receive such emails like Heiko sent "who is going to merge" 
I don't also want adding many maintainers unnecessary but drm bridge - although 
the framework is a thin and small - is used *over the ARM SoC* so that many 
confusions may happen for upstream.

So although it's small framework or just subdirectory, we would need someone 
who can manage the framework to avoid further confusion if necessary.

Thanks,
Inki Dae

> counter-productive.  dw_hdmi seems to be adequately managed so far
> without there needing to be a "DRM bridge maintainer".
> 


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Russell King - ARM Linux
On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> In this case, someone else may send an email again like you "who is going to 
> merge?"
> That would be why we need a maintainer.
> 
> drm panel is already managed well by Thierry Reding without such confusion. 

You don't need a maintainer for every subdirectory just because it's
a subdirectory...

Sometimes, having too many maintainers adds beaurocracy which becomes
counter-productive.  dw_hdmi seems to be adequately managed so far
without there needing to be a "DRM bridge maintainer".

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Russell King - ARM Linux
On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> In this case, someone else may send an email again like you "who is going to 
> merge?"
> That would be why we need a maintainer.
> 
> drm panel is already managed well by Thierry Reding without such confusion. 

You don't need a maintainer for every subdirectory just because it's
a subdirectory...

Sometimes, having too many maintainers adds beaurocracy which becomes
counter-productive.  dw_hdmi seems to be adequately managed so far
without there needing to be a "DRM bridge maintainer".

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Inki Dae


2016년 03월 23일 07:52에 Heiko Stübner 이(가) 쓴 글:
> Am Mittwoch, 23. März 2016, 07:44:59 schrieb Inki Dae:
>> + Ajay kumar with Samsung email
>>
>> Hi,
>>
>> 2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
>>> Hi,
>>>
>>> Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
 On 03/18/2016 07:53 PM, Doug Anderson wrote:
> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang
> 
>>>
>>> wrote:
 Same here, this is the second time I tested this series (first time was
 v6 on October 25 [2]) and I think that has been out there for too long.

> Tested-by: Douglas Anderson 

 Tested-by: Javier Martinez Canillas 
>>>
>>> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as
>>> Javier for the Exynos side based on the most recent drm state.
>>>
>>> As said by a lot of people it would be cool to get this merged soon -
>>> hopefully directly after -rc1. The only remaining question is through
>>> which
>>> tree it should go.
>>>
>>> I guess there are two basic options:
>>> - Inki takes the series - we could see the Rockchip-Ack being implied but
>>> maybe Mark can provide an explicit one
>>> - Mark takes the series with an Ack from Inki for the shared parts
>>>
>>> Inki, Mark do you have a preference?
>>
>> The problem would be that there is no drm bridge maintainer. I think the
>> most suitable person as the maintainer would be Ajay Kumar who is an author
>> of drm bridge framework. Of course, I could take them and have pull-request
>> again. But it seems a little late. Dave had already pull-request.
> 
> I really meant that for 4.7, not for the current merge window. I just want to 
> make sure it goes into a maintainer tree shortly after v4.6-rc1, before 
> something else changes the exynos-dp again :-).
> 
> 
>> To Ajay,
>> How about adding you as a drm bridge maintainer? DRM SoC driver maintainers
>> would need a person who can manage the drm bridge relevant pathes.
> 
> The previous example (dw_hdmi generalization between imx and rockchip) did 
> just go through the imx tree. So either the Samsung or Rockchip drm-trees 
> might be enough?

In this case, someone else may send an email again like you "who is going to 
merge?"
That would be why we need a maintainer.

drm panel is already managed well by Thierry Reding without such confusion. 

Thanks,
Inki Dae

> 
> 
> Heiko
> 
> 


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Inki Dae


2016년 03월 23일 07:52에 Heiko Stübner 이(가) 쓴 글:
> Am Mittwoch, 23. März 2016, 07:44:59 schrieb Inki Dae:
>> + Ajay kumar with Samsung email
>>
>> Hi,
>>
>> 2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
>>> Hi,
>>>
>>> Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
 On 03/18/2016 07:53 PM, Doug Anderson wrote:
> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang
> 
>>>
>>> wrote:
 Same here, this is the second time I tested this series (first time was
 v6 on October 25 [2]) and I think that has been out there for too long.

> Tested-by: Douglas Anderson 

 Tested-by: Javier Martinez Canillas 
>>>
>>> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as
>>> Javier for the Exynos side based on the most recent drm state.
>>>
>>> As said by a lot of people it would be cool to get this merged soon -
>>> hopefully directly after -rc1. The only remaining question is through
>>> which
>>> tree it should go.
>>>
>>> I guess there are two basic options:
>>> - Inki takes the series - we could see the Rockchip-Ack being implied but
>>> maybe Mark can provide an explicit one
>>> - Mark takes the series with an Ack from Inki for the shared parts
>>>
>>> Inki, Mark do you have a preference?
>>
>> The problem would be that there is no drm bridge maintainer. I think the
>> most suitable person as the maintainer would be Ajay Kumar who is an author
>> of drm bridge framework. Of course, I could take them and have pull-request
>> again. But it seems a little late. Dave had already pull-request.
> 
> I really meant that for 4.7, not for the current merge window. I just want to 
> make sure it goes into a maintainer tree shortly after v4.6-rc1, before 
> something else changes the exynos-dp again :-).
> 
> 
>> To Ajay,
>> How about adding you as a drm bridge maintainer? DRM SoC driver maintainers
>> would need a person who can manage the drm bridge relevant pathes.
> 
> The previous example (dw_hdmi generalization between imx and rockchip) did 
> just go through the imx tree. So either the Samsung or Rockchip drm-trees 
> might be enough?

In this case, someone else may send an email again like you "who is going to 
merge?"
That would be why we need a maintainer.

drm panel is already managed well by Thierry Reding without such confusion. 

Thanks,
Inki Dae

> 
> 
> Heiko
> 
> 


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Heiko Stübner
Am Mittwoch, 23. März 2016, 07:44:59 schrieb Inki Dae:
> + Ajay kumar with Samsung email
> 
> Hi,
> 
> 2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
> > Hi,
> > 
> > Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
> >> On 03/18/2016 07:53 PM, Doug Anderson wrote:
> >>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang
> >>> 
> > 
> > wrote:
> >> Same here, this is the second time I tested this series (first time was
> >> v6 on October 25 [2]) and I think that has been out there for too long.
> >> 
> >>> Tested-by: Douglas Anderson 
> >> 
> >> Tested-by: Javier Martinez Canillas 
> > 
> > So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as
> > Javier for the Exynos side based on the most recent drm state.
> > 
> > As said by a lot of people it would be cool to get this merged soon -
> > hopefully directly after -rc1. The only remaining question is through
> > which
> > tree it should go.
> > 
> > I guess there are two basic options:
> > - Inki takes the series - we could see the Rockchip-Ack being implied but
> > maybe Mark can provide an explicit one
> > - Mark takes the series with an Ack from Inki for the shared parts
> > 
> > Inki, Mark do you have a preference?
> 
> The problem would be that there is no drm bridge maintainer. I think the
> most suitable person as the maintainer would be Ajay Kumar who is an author
> of drm bridge framework. Of course, I could take them and have pull-request
> again. But it seems a little late. Dave had already pull-request.

I really meant that for 4.7, not for the current merge window. I just want to 
make sure it goes into a maintainer tree shortly after v4.6-rc1, before 
something else changes the exynos-dp again :-) .


> To Ajay,
> How about adding you as a drm bridge maintainer? DRM SoC driver maintainers
> would need a person who can manage the drm bridge relevant pathes.

The previous example (dw_hdmi generalization between imx and rockchip) did 
just go through the imx tree. So either the Samsung or Rockchip drm-trees 
might be enough?


Heiko


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Heiko Stübner
Am Mittwoch, 23. März 2016, 07:44:59 schrieb Inki Dae:
> + Ajay kumar with Samsung email
> 
> Hi,
> 
> 2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
> > Hi,
> > 
> > Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
> >> On 03/18/2016 07:53 PM, Doug Anderson wrote:
> >>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang
> >>> 
> > 
> > wrote:
> >> Same here, this is the second time I tested this series (first time was
> >> v6 on October 25 [2]) and I think that has been out there for too long.
> >> 
> >>> Tested-by: Douglas Anderson 
> >> 
> >> Tested-by: Javier Martinez Canillas 
> > 
> > So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as
> > Javier for the Exynos side based on the most recent drm state.
> > 
> > As said by a lot of people it would be cool to get this merged soon -
> > hopefully directly after -rc1. The only remaining question is through
> > which
> > tree it should go.
> > 
> > I guess there are two basic options:
> > - Inki takes the series - we could see the Rockchip-Ack being implied but
> > maybe Mark can provide an explicit one
> > - Mark takes the series with an Ack from Inki for the shared parts
> > 
> > Inki, Mark do you have a preference?
> 
> The problem would be that there is no drm bridge maintainer. I think the
> most suitable person as the maintainer would be Ajay Kumar who is an author
> of drm bridge framework. Of course, I could take them and have pull-request
> again. But it seems a little late. Dave had already pull-request.

I really meant that for 4.7, not for the current merge window. I just want to 
make sure it goes into a maintainer tree shortly after v4.6-rc1, before 
something else changes the exynos-dp again :-) .


> To Ajay,
> How about adding you as a drm bridge maintainer? DRM SoC driver maintainers
> would need a person who can manage the drm bridge relevant pathes.

The previous example (dw_hdmi generalization between imx and rockchip) did 
just go through the imx tree. So either the Samsung or Rockchip drm-trees 
might be enough?


Heiko


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Inki Dae
+ Ajay kumar with Samsung email

Hi,

2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
> Hi,
> 
> Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
>> On 03/18/2016 07:53 PM, Doug Anderson wrote:
>>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  
> wrote:
>> Same here, this is the second time I tested this series (first time was
>> v6 on October 25 [2]) and I think that has been out there for too long.
>>
>>> Tested-by: Douglas Anderson 
>> Tested-by: Javier Martinez Canillas 
> 
> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as 
> Javier for the Exynos side based on the most recent drm state.
> 
> As said by a lot of people it would be cool to get this merged soon - 
> hopefully directly after -rc1. The only remaining question is through which 
> tree it should go.
> 
> I guess there are two basic options:
> - Inki takes the series - we could see the Rockchip-Ack being implied but 
> maybe Mark can provide an explicit one
> - Mark takes the series with an Ack from Inki for the shared parts
> 
> Inki, Mark do you have a preference?

The problem would be that there is no drm bridge maintainer. I think the most 
suitable person as the maintainer would be Ajay Kumar who is an author of drm 
bridge framework.
Of course, I could take them and have pull-request again. But it seems a little 
late. Dave had already pull-request.

To Ajay,
How about adding you as a drm bridge maintainer? DRM SoC driver maintainers 
would need a person who can manage the drm bridge relevant pathes.

Thanks,
Inki Dae
 
> 
> Thanks
> Heiko
> 
> 


Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Inki Dae
+ Ajay kumar with Samsung email

Hi,

2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
> Hi,
> 
> Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
>> On 03/18/2016 07:53 PM, Doug Anderson wrote:
>>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  
> wrote:
>> Same here, this is the second time I tested this series (first time was
>> v6 on October 25 [2]) and I think that has been out there for too long.
>>
>>> Tested-by: Douglas Anderson 
>> Tested-by: Javier Martinez Canillas 
> 
> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as 
> Javier for the Exynos side based on the most recent drm state.
> 
> As said by a lot of people it would be cool to get this merged soon - 
> hopefully directly after -rc1. The only remaining question is through which 
> tree it should go.
> 
> I guess there are two basic options:
> - Inki takes the series - we could see the Rockchip-Ack being implied but 
> maybe Mark can provide an explicit one
> - Mark takes the series with an Ack from Inki for the shared parts
> 
> Inki, Mark do you have a preference?

The problem would be that there is no drm bridge maintainer. I think the most 
suitable person as the maintainer would be Ajay Kumar who is an author of drm 
bridge framework.
Of course, I could take them and have pull-request again. But it seems a little 
late. Dave had already pull-request.

To Ajay,
How about adding you as a drm bridge maintainer? DRM SoC driver maintainers 
would need a person who can manage the drm bridge relevant pathes.

Thanks,
Inki Dae
 
> 
> Thanks
> Heiko
> 
> 


Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Heiko Stübner
Hi,

Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
> On 03/18/2016 07:53 PM, Doug Anderson wrote:
> > On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  
wrote:
> Same here, this is the second time I tested this series (first time was
> v6 on October 25 [2]) and I think that has been out there for too long.
> 
> > Tested-by: Douglas Anderson 
> Tested-by: Javier Martinez Canillas 

So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as 
Javier for the Exynos side based on the most recent drm state.

As said by a lot of people it would be cool to get this merged soon - 
hopefully directly after -rc1. The only remaining question is through which 
tree it should go.

I guess there are two basic options:
- Inki takes the series - we could see the Rockchip-Ack being implied but 
maybe Mark can provide an explicit one
- Mark takes the series with an Ack from Inki for the shared parts

Inki, Mark do you have a preference?


Thanks
Heiko


Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-22 Thread Heiko Stübner
Hi,

Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
> On 03/18/2016 07:53 PM, Doug Anderson wrote:
> > On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  
wrote:
> Same here, this is the second time I tested this series (first time was
> v6 on October 25 [2]) and I think that has been out there for too long.
> 
> > Tested-by: Douglas Anderson 
> Tested-by: Javier Martinez Canillas 

So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as 
Javier for the Exynos side based on the most recent drm state.

As said by a lot of people it would be cool to get this merged soon - 
hopefully directly after -rc1. The only remaining question is through which 
tree it should go.

I guess there are two basic options:
- Inki takes the series - we could see the Rockchip-Ack being implied but 
maybe Mark can provide an explicit one
- Mark takes the series with an Ack from Inki for the shared parts

Inki, Mark do you have a preference?


Thanks
Heiko


Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-22 Thread Javier Martinez Canillas
Hello,

On 03/18/2016 07:53 PM, Doug Anderson wrote:
> Hi,
> 
> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  
> wrote:
>> Hi all,
>>
>> I pick this series up and test on C101PA chromebook, after Heiko update the
>> 3 patches.
>>
>> [v14.1,09/17] drm: rockchip: dp: add rockchip platform dp driver
>> [v14.1,04/17] drm: bridge: analogix/dp: fix some obvious code style
>> [v14.1,01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge
>> directory
>>
>> C101PA chromebook:
>> http://www.amazon.co.uk/10-1-Inch-Chromebook-Rockchip-Integrated-Graphics/dp/B0107N7WT6/ref=lp_758129031_1_4?s=computers=UTF8=1458282912=1-4
>>
>> So, verified for the rockchip eDp contrller on my github.
>> https://github.com/Caesar-github/rockchip/tree/veyron/next-stable-chromeos
> 
> I did similar to Caesar but I tested on veyron-jerry instead of
> veyron-mickey.  Like Caesar, I picked these together Heiko's v14.1
> patches to resolve merge conflicts.  I also picked into a slightly
> different tree (mine was a 4.4-based tree with backports, including
> Heiko's latest eDP device tree patches).
>

I also tested this series on an Exynos5800 Peach Pi Chromebook, using
Heiko's branch [0] that is based on today's mainline (968f3e374fa).

I've seen no regressions with these patches, DP is working fine and
also comes up after a S2R and DPMS on/off using the exynos-drm sysfs.

NOTE: I had to cherry-pick a SPI core fix [1] in order to make the Pi
to boot. Not related to this series of course but I just mention it in
case someone else wants to do the same test on this machine.
 
> Tough I haven't reviewed the code and am not a graphics expert, I'd
> very much love to see this landed, presumably right after the merge
> window closes.  Yakir's first patch
>  is nearly 1 year old and
> it really seems like if there were any major objections left they'd
> have been stated by now.  v14 appears to be about 1 month old with no
> major comments.
>

Same here, this is the second time I tested this series (first time was
v6 on October 25 [2]) and I think that has been out there for too long.
 
> Tested-by: Douglas Anderson 
> 

Tested-by: Javier Martinez Canillas 

> 
> -Doug
> 

[0]: git://github.com/mmind/linux-rockchip.git tmp/analogix-dp-clean
[1]: http://comments.gmane.org/gmane.linux.kernel.spi.devel/23563
[2]: 
http://lists.infradead.org/pipermail/linux-rockchip/2015-October/004884.html

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-22 Thread Javier Martinez Canillas
Hello,

On 03/18/2016 07:53 PM, Doug Anderson wrote:
> Hi,
> 
> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  
> wrote:
>> Hi all,
>>
>> I pick this series up and test on C101PA chromebook, after Heiko update the
>> 3 patches.
>>
>> [v14.1,09/17] drm: rockchip: dp: add rockchip platform dp driver
>> [v14.1,04/17] drm: bridge: analogix/dp: fix some obvious code style
>> [v14.1,01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge
>> directory
>>
>> C101PA chromebook:
>> http://www.amazon.co.uk/10-1-Inch-Chromebook-Rockchip-Integrated-Graphics/dp/B0107N7WT6/ref=lp_758129031_1_4?s=computers=UTF8=1458282912=1-4
>>
>> So, verified for the rockchip eDp contrller on my github.
>> https://github.com/Caesar-github/rockchip/tree/veyron/next-stable-chromeos
> 
> I did similar to Caesar but I tested on veyron-jerry instead of
> veyron-mickey.  Like Caesar, I picked these together Heiko's v14.1
> patches to resolve merge conflicts.  I also picked into a slightly
> different tree (mine was a 4.4-based tree with backports, including
> Heiko's latest eDP device tree patches).
>

I also tested this series on an Exynos5800 Peach Pi Chromebook, using
Heiko's branch [0] that is based on today's mainline (968f3e374fa).

I've seen no regressions with these patches, DP is working fine and
also comes up after a S2R and DPMS on/off using the exynos-drm sysfs.

NOTE: I had to cherry-pick a SPI core fix [1] in order to make the Pi
to boot. Not related to this series of course but I just mention it in
case someone else wants to do the same test on this machine.
 
> Tough I haven't reviewed the code and am not a graphics expert, I'd
> very much love to see this landed, presumably right after the merge
> window closes.  Yakir's first patch
>  is nearly 1 year old and
> it really seems like if there were any major objections left they'd
> have been stated by now.  v14 appears to be about 1 month old with no
> major comments.
>

Same here, this is the second time I tested this series (first time was
v6 on October 25 [2]) and I think that has been out there for too long.
 
> Tested-by: Douglas Anderson 
> 

Tested-by: Javier Martinez Canillas 

> 
> -Doug
> 

[0]: git://github.com/mmind/linux-rockchip.git tmp/analogix-dp-clean
[1]: http://comments.gmane.org/gmane.linux.kernel.spi.devel/23563
[2]: 
http://lists.infradead.org/pipermail/linux-rockchip/2015-October/004884.html

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-19 Thread Caesar Wang

Hi all,

I pick this series up and test on C101PA chromebook, after Heiko update 
the 3 patches.


[v14.1,09/17] drm: rockchip: dp: add rockchip platform dp driver
[v14.1,04/17] drm: bridge: analogix/dp: fix some obvious code style
[v14.1,01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge 
directory


C101PA chromebook:
http://www.amazon.co.uk/10-1-Inch-Chromebook-Rockchip-Integrated-Graphics/dp/B0107N7WT6/ref=lp_758129031_1_4?s=computers=UTF8=1458282912=1-4

So, verified for the rockchip eDp contrller on my github.
https://github.com/Caesar-github/rockchip/tree/veyron/next-stable-chromeos


在 2016年02月15日 19:08, 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

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
the connector init to platform driver anymore, and this is the biggest change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time to
upgrade the version number, but I have changed ordering of patches (adding 2
more, and removing 2 out). Especially to prevent confusing people, so I updated
the whole series.

Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
 https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
(Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
   Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
   the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
   to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(
 -  dp, DP_TEST_RESPONSE,
 +  analogix_dp_write_byte_to_dpcd(dp,
 +  DP_TEST_RESPONSE,
   

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-19 Thread Caesar Wang

Hi all,

I pick this series up and test on C101PA chromebook, after Heiko update 
the 3 patches.


[v14.1,09/17] drm: rockchip: dp: add rockchip platform dp driver
[v14.1,04/17] drm: bridge: analogix/dp: fix some obvious code style
[v14.1,01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge 
directory


C101PA chromebook:
http://www.amazon.co.uk/10-1-Inch-Chromebook-Rockchip-Integrated-Graphics/dp/B0107N7WT6/ref=lp_758129031_1_4?s=computers=UTF8=1458282912=1-4

So, verified for the rockchip eDp contrller on my github.
https://github.com/Caesar-github/rockchip/tree/veyron/next-stable-chromeos


在 2016年02月15日 19:08, 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

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
the connector init to platform driver anymore, and this is the biggest change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time to
upgrade the version number, but I have changed ordering of patches (adding 2
more, and removing 2 out). Especially to prevent confusing people, so I updated
the whole series.

Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
 https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
(Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
   Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
   the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
   to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(
 -  dp, DP_TEST_RESPONSE,
 +  analogix_dp_write_byte_to_dpcd(dp,
 +  DP_TEST_RESPONSE,
   

Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-18 Thread Doug Anderson
Hi,

On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  wrote:
> Hi all,
>
> I pick this series up and test on C101PA chromebook, after Heiko update the
> 3 patches.
>
> [v14.1,09/17] drm: rockchip: dp: add rockchip platform dp driver
> [v14.1,04/17] drm: bridge: analogix/dp: fix some obvious code style
> [v14.1,01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge
> directory
>
> C101PA chromebook:
> http://www.amazon.co.uk/10-1-Inch-Chromebook-Rockchip-Integrated-Graphics/dp/B0107N7WT6/ref=lp_758129031_1_4?s=computers=UTF8=1458282912=1-4
>
> So, verified for the rockchip eDp contrller on my github.
> https://github.com/Caesar-github/rockchip/tree/veyron/next-stable-chromeos

I did similar to Caesar but I tested on veyron-jerry instead of
veyron-mickey.  Like Caesar, I picked these together Heiko's v14.1
patches to resolve merge conflicts.  I also picked into a slightly
different tree (mine was a 4.4-based tree with backports, including
Heiko's latest eDP device tree patches).

Tough I haven't reviewed the code and am not a graphics expert, I'd
very much love to see this landed, presumably right after the merge
window closes.  Yakir's first patch
 is nearly 1 year old and
it really seems like if there were any major objections left they'd
have been stated by now.  v14 appears to be about 1 month old with no
major comments.

Tested-by: Douglas Anderson 


-Doug


Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-03-18 Thread Doug Anderson
Hi,

On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  wrote:
> Hi all,
>
> I pick this series up and test on C101PA chromebook, after Heiko update the
> 3 patches.
>
> [v14.1,09/17] drm: rockchip: dp: add rockchip platform dp driver
> [v14.1,04/17] drm: bridge: analogix/dp: fix some obvious code style
> [v14.1,01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge
> directory
>
> C101PA chromebook:
> http://www.amazon.co.uk/10-1-Inch-Chromebook-Rockchip-Integrated-Graphics/dp/B0107N7WT6/ref=lp_758129031_1_4?s=computers=UTF8=1458282912=1-4
>
> So, verified for the rockchip eDp contrller on my github.
> https://github.com/Caesar-github/rockchip/tree/veyron/next-stable-chromeos

I did similar to Caesar but I tested on veyron-jerry instead of
veyron-mickey.  Like Caesar, I picked these together Heiko's v14.1
patches to resolve merge conflicts.  I also picked into a slightly
different tree (mine was a 4.4-based tree with backports, including
Heiko's latest eDP device tree patches).

Tough I haven't reviewed the code and am not a graphics expert, I'd
very much love to see this landed, presumably right after the merge
window closes.  Yakir's first patch
 is nearly 1 year old and
it really seems like if there were any major objections left they'd
have been stated by now.  v14 appears to be about 1 month old with no
major comments.

Tested-by: Douglas Anderson 


-Doug


[PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-02-15 Thread 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

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
the connector init to platform driver anymore, and this is the biggest change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time to
upgrade the version number, but I have changed ordering of patches (adding 2
more, and removing 2 out). Especially to prevent confusing people, so I updated
the whole series.

Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
(Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device 

[PATCH v14 0/17] Add Analogix Core Display Port Driver

2016-02-15 Thread 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

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
the connector init to platform driver anymore, and this is the biggest change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time to
upgrade the version number, but I have changed ordering of patches (adding 2
more, and removing 2 out). Especially to prevent confusing people, so I updated
the whole series.

Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
(Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device