[PATCH] video: rockchip: Add missing dpcd_write() call to link_train_ce()

[Arnaud Patard (Rtp)]

Alper Nebi Yasak <alpernebiyasak at gmail.com> writes:

> On 14/10/2020 22:31, Tom Rini wrote:
>> On Wed, Oct 14, 2020 at 09:58:28PM +0300, Alper Nebi Yasak wrote:
>>> On 14/10/2020 18:24, Tom Rini wrote:
>>>> Ugh.  In so far as anything can be re-licensed, who did it all
>>>> originally?  I suspect coreboot isn't interested in 2.0+ but we can do
>>>> 2.0-only.
>>>
>>> For this patch, coreboot commit b9a7877568cf ("rockchip/*: refactor edp
>>> driver") introduces the related change to src/soc/rockchip/common/edp.c
>>> renamed from .../rk3288/edp.c, which was introduced at coreboot commit
>>> 40f558e8f4f7 ("rockchip: support display").
>> 
>> Right, sorry.  I mean, on the U-Boot side, where did things come from?
>> I wonder how we got a different license text, and perhaps if we
>> shouldn't just re-port the coreboot code over as a clean/clear way to
>> re-license it to GPL-2.0-only.
>
> I'm not sure re-porting is a great idea from the technical perspective.
> I've been reading both drivers to compare them, there are also things in
> U-Boot that're missing from coreboot. Things like DM integration are
> also not there as they're U-Boot specific.
>

I think it would be better to use fixes from the kernel or coreboot (if
license allows it) than copying coreboot blindly. Doing that will
possibly regress support from some systems as I fear that coreboot is
missing some HW support.

tbh, I've not looked at the coreboot code but given most HW vendor
history, it would be not so surprising that only the support for what's
needed on kevin or bob (EDP and CDN DP or HDMI on rk3399) has been added
to coreboot.

I've also seen some uboot sources with rockchip linux drm code
[1]. I've no idea if it's used in practice but this means that people may
even ask "Why merging coreboot code while it's possible to use linux drm
code ?" ...

Arnaud

[1] https://gitlab.collabora.com/nicolas/rockchip-uboot/-/tree/rk3399-roc-pc/drivers/video/drm