H. Nikolaus Schaller
hns at goldelico.com
Tue Jun 30 08:04:09 CEST 2020
> Am 30.06.2020 um 00:22 schrieb Paul Boddie <paul at boddie.org.uk>:
> On Saturday, 20 June 2020 23:08:43 CEST H. Nikolaus Schaller wrote:
>>> Am 20.06.2020 um 21:42 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> So far, I have reviewed the CGU/clock, TCU and pinctrl functionality, made
>>> some fixes to the earlier work, and it compiles fine in a branch rooted on
>>> the v5.8-rc1 tag in the torvalds/linux repository.
>> Great. Then it should likely also build fine within the Letux repo (since it
>> is also based on linus/master - that is how I call it :)
> You may have to remind me what I should be checking out and pulling from since
> I don't remember and couldn't find it readily in my mails. I have cloned the
> letux-kernel repository but the origin/master branch seems to be tracking
> Linux 4.19.
Yes, the "master" branch follows the latest good enough "stable" tree and is not
related to the latest work in progress.
> I did think that since I was going to review everything, I should start with a
> very recent kernel, hence the decision to choose something in torvalds/linux
> instead of continuing with the origin/letux/jz4730-v2 branch in letux-kernel.
There are latest branches as e.g. letux-5.8-rc1 or letux-5.8-rc3 but they
are composed like linux-next from components (ca. 50 feature/topic branches
to get patch sets for single topics).
This is done by a script Letux/scripts/merge and its associated Letux/scripts/mergefile.
I did have a nice picture some years ago but could not find it quickly.
What is missing is a fix to make letux/jz4730 part of that.
>>> I'm going to try and work through the other functionality. Some things are
>>> now obsolete: for example, the GPIO driver is now incorporated into
>>> pinctrl. There will also be a need to fix up the device tree files, with
>>> jz4730.dtsi probably being in fairly good shape, but with
>>> mipsbook_400.dts likely to need a bit more work.
>>> I'm also aiming to try and incorporate my recently acquired knowledge
>>> about HDMI and the LCD controller to make a recent kernel work in these
>>> respects on the CI20. Hopefully, I will make some progress there as well.
>> As soon as you have something to pick as letux/jz4730-v4 for the Letux tree,
>> please let me know.
> Unfortunately, I haven't spent any more time on the JZ4730 effort in the last
> few available days for potentially doing anything.
No problem. I recently found that I also have no time left over for anything :(
Corona is making us sick even if we are not infected...
> As communicated in other
> messages, I did update and test recent Linux kernel code in order to try and
> get the CI20 HDMI to work, but the last mysterious piece of the puzzle
> (specific to Linux since it works in L4Re) needs to be found and applied.
Well, I wasn't able to pick or compile your latest code - and worse, the CI20
doesn't boot any more with v5.8-rc1 or letux-5.8-rc1 (even without your
> So, I am sorry not to have made any progress as such, but I thought that I
> should communicate an intent to resume the review of the JZ4730 code when time
> and energy permit.
Letux feature branches are merged into letux-5.8. They must be (re)based on v5.8-rc1
(or later) to be valid patch sets for upstream submission.
Unfortunately I could not rebase
to v5.8-rc1 and make it compile. So it is still based on v5.7.
And I had to drop letux/jz4730-v2 from the merge process to not stop other architectures.
The trick was to create a letux/jz4730-v3 which is (almost) identical to what Linus
provides upstream. Sort of "add 0".
You can also see it like removing some staging repo from integration into linux-next.
So the task we should discuss is:
git checkout -b letux/jz4730-v4 letux/jz4730-v2
git rebase v5.8-rc1 # or -rc3
this fails with a lot of rebase conflicts
fix issues (I do not understand the jz4730 well enough to do it myself)
git checkout -B temp
git merge letux-5.8-rc3 # this should now work and build w/o issues
More information about the Letux-kernel