[Letux-kernel] jz4730

[H. Nikolaus Schaller]

Hi,

> Am 30.06.2020 um 22:36 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Tuesday, 30 June 2020 08:04:09 CEST H. Nikolaus Schaller wrote:
>> 
>>> Am 30.06.2020 um 00:22 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> 
>>> 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.
> 
> OK.
> 
>>> 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.
> 
> It sounds quite complicated, really. I think I would be most efficient working 
> with a complete set of patches that can then be split into topics if 
> appropriate. Of course, if JZ4730 support is just one topic,

Yes, the jz4730 is one of many topics.

The scheme used for LetuxOS kernel has developed over the years and is the
best compromise I know to handle all the LetuxOS targets in parallel.

The key is IMHO to have small topics that are easy to understand and
"git format-patch letux-base..letux/topic-branch" for submission as a patch
set. Doing it this way allows to continuously integrate and test and use
feedbacks by the review process. E.g. if maintainers suggest something
for [PATCH v3 4/7] it is simply integrated into the patch set and merged
for the next LetuxOS kernel release for testing.

> then there would 
> be only one patchset to work on and to submit, but I think that even device 
> tree definitions end up going down a different channel, necessitating the 
> independent stewardship of different collections of changes.
> 
> [...]
> 
>>> 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 latest patches).
> 
> I neglected to include the device tree files, which would be an obstacle, but 
> the patches I made are applied against this changeset in torvalds/linux:
> 
> commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407 (tag: v5.8-rc1)
> Author: Linus Torvalds <torvalds at linux-foundation.org>
> Date:   Sun Jun 14 12:45:04 2020 -0700
> 
>    Linux 5.8-rc1
> 
> If they don't apply then maybe I did something wrong again.
> 
>>> 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.
> 
> Right. This is probably a good idea.
> 
>> Unfortunately I could not rebase
>> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/
>> jz4730-v2 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
> 
> I think that the best way forward for JZ4730 is to rework the patches 
> entirely. Several things are now rather different in the kernel, and there 
> will be things in our old patches that are now superfluous.

Yes. Basically it is quite irrelevant how a new letux/jz4730-v4 is derived
from the old one. Either by massaging the existing patches by fixing
merge conflicts or squashing the old patches into a single one, then
rebase and split. Or type new code...

BR,
Nikolaus