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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.