From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH] video: rockchip: Add missing dpcd_write() call to link_train_ce()
Date: Wed, 14 Oct 2020 11:24:33 -0400 [thread overview]
Message-ID: <20201014152433.GV14816@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ2WuagxYZN320aviPns5VOXPELBU3cX=O7mMau7taqV9g@mail.gmail.com>
On Tue, Oct 13, 2020 at 09:54:55AM -0600, Simon Glass wrote:
> Hi Alper,
>
> On Tue, 13 Oct 2020 at 09:01, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >
> > On 12/10/2020 06:34, Simon Glass wrote:
> > > On Tue, 6 Oct 2020 at 14:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> > >>
> > >> Found this by comparing it to the coreboot driver, a form of this call
> > >> was introduced there in their commit b9a7877568cf ("rockchip/*: refactor
> > >> edp driver"). This is copy-pasted from U-Boot's link_train_cr() slightly
> > >> above it.
> > >>
> > >> Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
> > >
> > > Reviewed-by: Simon Glass <sjg@chromium.org>
> >
> > Simon, I noticed the coreboot driver is GPL-2.0-only, but the U-Boot
> > driver is GPL-2.0+, is that a problem for this patch?
> >
> > They also seem to be almost the same especially in their earlier
> > revisions (even had the same typos in some comments). It could be good
> > to sync the two drivers to pick improvements from it e.g. support for
> > rk3399 (though there's an RFC series for that [1]), but the license
> > difference makes it difficult. Could the coreboot parts be relicensed to
> > GPL-2.0+ by Google and/or Rockchip? Alternatively, is it OK to change
> > the U-Boot one to GPL-2.0-only to sync things from coreboot?
>
> I think it is OK to change the file to GPL2. I'm not sure if changing
> coreboot parts to 2.0+ is an option. I believe the use of 2+ in U-Boot
> is for fairly narrow reasons, but I'm not sure if that is documented
> anywhere.
>
> +Tom Rini might have a comment
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201014/f45263c8/attachment.sig>
next prev parent reply other threads:[~2020-10-14 15:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 20:39 [PATCH] video: rockchip: Add missing dpcd_write() call to link_train_ce() Alper Nebi Yasak
2020-10-12 3:34 ` Simon Glass
2020-10-13 15:00 ` Alper Nebi Yasak
2020-10-13 15:54 ` Simon Glass
2020-10-14 15:24 ` Tom Rini [this message]
2020-10-14 18:58 ` Alper Nebi Yasak
2020-10-14 19:31 ` Tom Rini
2020-10-14 20:39 ` Alper Nebi Yasak
2020-10-15 7:19 ` Arnaud Patard
2020-10-15 17:13 ` Alper Nebi Yasak
2020-10-15 18:29 ` Tom Rini
2020-10-30 10:22 ` Kever Yang
2020-10-14 19:17 ` Simon Glass
2020-10-30 10:17 ` Kever Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201014152433.GV14816@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox