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&ie=UTF8&qid=1458282912&sr=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 = <&gpx2 6 0>;
> + hpd-gpios = <&gpx2 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 type declared, cause the previous "platform device type
> support (v4 11/16)" already merge into (v5 02/14).
> - Implement connector registration code. (Thierry)
> - Split binding doc's from driver changes. (Rob)
> - Add eDP hotplug pinctrl property. (Heiko)
>
> Changes in v4:
> - Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
> - Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
> - Create a separate folder for analogix code in bridge/ (Archit)
> - Update commit message more readable. (Jingoo)
> - Adjust the order from 05 to 04
> - Provide backword compatibility with samsung. (Krzysztof)
> - Split all DTS changes, and provide backward compatibility. Mark old
> properties as deprecated but still support them. (Krzysztof)
> - Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
> - Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
> "analogix,color-space" & "analogix,color-depth" &
> "analogix,link-rate" & "analogix,lane-count" &
> "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
> "vsync-active-high" & "hsync-active-high" & "interlaces"
> - Separate all DTS changes to a separate patch. (Krzysztof)
> - Remove some deprecated DT properties in rockchip dp document.
> - Seprate the link-rate and lane-count limit out with the device_type
> flag. (Thierry)
> - Take Jingoo suggest, add commit messages.
> - Call drm_panel_prepare() in .get_modes function, ensure panel should
> power on before driver try to read edid message.
>
> Changes in v3:
> - Move exynos's video_timing code to analogix_dp-exynos platform driver,
> add get_modes method to struct analogix_dp_plat_data. (Thierry)
> - Rename some "samsung*" dts propery to "analogix*". (Heiko)
> - The link_rate and lane_count shouldn't config to the DT property value
> directly, but we can take those as hardware limite. For example, RK3288
> only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
> like "link-rate = 0x0a" "lane-count = 4". (Thierry)
> - Dynamic parse video timing info from struct drm_display_mode and
> struct drm_display_info. (Thierry)
> - Add devicetree binding documents. (Heiko)
> - Remove sync pol & colorimetry properies from the new analogix dp driver
> devicetree binding. (Thierry)
> - Update the exist exynos dtsi file with the latest DP DT properies.
> - Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
> and leave "sclk_edp" to analogix dp core driver which name to "dp",
> and leave "pclk_edp" to rockchip dp platform driver which name to
> "pclk". (Thierry & Heiko)
> - Add devicetree binding document. (Heiko)
> - Remove "rockchip,panel" DT property, take use of remote point to get panel
> node. (Heiko)
> - Add the new function point dp_platdata->get_modes() init.
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
> hpd when hpd detect failed.
> - move dp hpd detect to connector detect function.
> - Add edid modes parse support
>
> Changes in v2:
> - Remove new copyright (Jingoo)
> - Fix compiled failed due to analogix_dp_device misspell
> - Improved commit message more readable, and avoid using some
> uncommon style like bellow: (Joe Preches)
> - retval = exynos_dp_read_bytes_from_i2c(...
> ...);
> + retval =
> + exynos_dp_read_bytes_from_i2c(......);
> - Get panel node with remote-endpoint method, and create devicetree binding
> for driver. (Heiko)
> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
> leave those clock to rockchip dp phy driver.
> - Fix compile failed dut to phy_pd_addr variable misspell error
>
> Heiko Stuebner (2):
> drm/exynos: dp: rename implementation specific driver part
> drm: bridge: analogix/dp: rename register constants
>
> Yakir Yang (15):
> drm: bridge: analogix/dp: split exynos dp driver to bridge directory
> drm: bridge: analogix/dp: fix some obvious code style
> drm: bridge: analogix/dp: remove duplicate configuration of link rate
> and link count
> drm: bridge: analogix/dp: dynamic parse sync_pol & interlace &
> dynamic_range
> dt-bindings: add document for analogix display port driver
> ARM: dts: exynos/dp: remove some properties that deprecated by
> analogix_dp driver
> drm: rockchip: dp: add rockchip platform dp driver
> dt-bindings: add document for rockchip variant of analogix_dp
> drm: bridge: analogix/dp: add some rk3288 special registers setting
> drm: bridge: analogix/dp: add max link rate and lane count limit for
> RK3288
> drm: bridge: analogix/dp: try force hpd after plug in lookup failed
> drm: bridge: analogix/dp: move hpd detect to connector detect function
> drm: bridge: analogix/dp: add edid modes parse in get_modes method
> drm: bridge: analogix/dp: add panel prepare/unprepare in
> suspend/resume time
> drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable
> time
>
> .../bindings/display/bridge/analogix_dp.txt | 52 +
> .../bindings/display/exynos/exynos_dp.txt | 93 +-
> .../display/rockchip/analogix_dp-rockchip.txt | 92 ++
> arch/arm/boot/dts/exynos5250-arndale.dts | 2 -
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 -
> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +-
> arch/arm/boot/dts/exynos5250-spring.dts | 4 +-
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +-
> arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 -
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 -
> drivers/gpu/drm/bridge/Kconfig | 2 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/analogix/Kconfig | 3 +
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1430 ++++++++++++++++++
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 281 ++++
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 1320 +++++++++++++++++
> .../analogix/analogix_dp_reg.h} | 270 ++--
> drivers/gpu/drm/exynos/Kconfig | 3 +-
> drivers/gpu/drm/exynos/Makefile | 2 +-
> drivers/gpu/drm/exynos/exynos_dp.c | 324 +++++
> drivers/gpu/drm/exynos/exynos_dp_core.c | 1510 --------------------
> drivers/gpu/drm/exynos/exynos_dp_core.h | 282 ----
> drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263 ----------------
> drivers/gpu/drm/rockchip/Kconfig | 9 +
> drivers/gpu/drm/rockchip/Makefile | 1 +
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 384 +++++
> include/drm/bridge/analogix_dp.h | 41 +
> 28 files changed, 4115 insertions(+), 3269 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> create mode 100644 Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> rename drivers/gpu/drm/{exynos/exynos_dp_reg.h => bridge/analogix/analogix_dp_reg.h} (62%)
> create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
> create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> create mode 100644 include/drm/bridge/analogix_dp.h
>
--
Thanks,
Caesar
Hi,
On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang <[email protected]> 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&ie=UTF8&qid=1458282912&sr=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
<https://patchwork.kernel.org/patch/6959211/> 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 <[email protected]>
-Doug
Hello,
On 03/18/2016 07:53 PM, Doug Anderson wrote:
> Hi,
>
> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang <[email protected]> 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&ie=UTF8&qid=1458282912&sr=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
> <https://patchwork.kernel.org/patch/6959211/> 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 <[email protected]>
>
Tested-by: Javier Martinez Canillas <[email protected]>
>
> -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
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 <[email protected]>
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 <[email protected]>
> Tested-by: Javier Martinez Canillas <[email protected]>
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
+ 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 <[email protected]>
> 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 <[email protected]>
>> Tested-by: Javier Martinez Canillas <[email protected]>
>
> 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
>
>
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
> >>> <[email protected]>
> >
> > 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 <[email protected]>
> >>
> >> Tested-by: Javier Martinez Canillas <[email protected]>
> >
> > 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
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
>>>>> <[email protected]>
>>>
>>> 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 <[email protected]>
>>>>
>>>> Tested-by: Javier Martinez Canillas <[email protected]>
>>>
>>> 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
>
>
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.
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".
>
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.
>
>> 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.
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.
--
Ｍark Yao
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
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