[Letux-kernel] [Lenny400] JZ4730/Minibook framebuffer driver updates

H. Nikolaus Schaller hns at goldelico.com
Wed Sep 13 07:43:52 CEST 2017


Hi Paul,

> Am 12.09.2017 um 22:35 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Tuesday 12. September 2017 21.16.22 H. Nikolaus Schaller wrote:
>> 
>> It did apply fine to the work/hns/mips/defconfig branch, but afterwards I
>> could no longer merge all branches without merge-conflicts. So I have left
>> it out for the moment. Because I am working on a better scheme to
>> manage/update the letux_defconfigs.
> 
> Apologies if the patches weren't optimal. I struggled to get git to do the 
> right thing, and then it surprised me by splitting a commit in format-patch 
> for some reason (probably something I don't care about as a user).

It is not your patch sets. Those did apply well.

It is the way I have split up things into feature branches. Quite similar to
linux-next.

> 
> [...]
> 
>> I am still thinking about an easily manageable strategy for this quite
>> fundamental problem (would be easier if we mix back jz4730 and mipsbook
>> into a single branch, but this is not how it should be submitted
>> upstream).
> 
> For the purposes of developing and testing, having the code, configuration and 
> device tree on the same branch is essential. I then have to try and split 
> these things up across several branches, which is annoying but not impossible.
> 
> The other approach is to try and introduce changes on their own feature 
> branches and then merge them into my "work" branch, which really is cumbersome 
> because it doesn't lend itself to rapid development and testing.
> 
> I think it is arguably easier to just split things up at the end. There should 
> be hardly any board-specific stuff, and it is easy to identify. Moreover, the 
> structure of any submitted patches is likely to be different from the 
> repository history, anyway: I can easily see things being divided up into 
> functional groups.
> 
> I have some more patches in the pipeline, but it occurs to me that I might be 
> better off sending you my SSH public key so that I can push directly to 
> various branches, although it worries me that things might not go as planned 
> if I do that.

Basically we do the following:

git checkout $BASE
git merge $FEATURE_BRANCHES

At the moment, $BASE is "letux-base" where I merge in new revisions from linus/master.
Then, all $FEATURE_BRANCHES are rebased on top of $BASE.

FEATURE branches are for example GTA04-device-tree, Pyra-device-tree, GTA04-camera, etc.

The problem is that the git merge $FEATURE_BRANCHES should run without merge conflicts.
(BTW: linux-next also has this problem sometimes).

What makes the split into a jz4730 and a mipsbook branch difficult is the dependencies.

$BASE has some basic letux_defconfig.

Now, the jz4730 branch adds a new Kconfig entry for the JZ4730. If we checkout this
branch and make silentoldconfig, we get a new letux_defconfig that has the CONFIG_JZ4730
disabled.

Next, we take the mipsbook branch (which does NOT contain the jz4730 code since that
is considered a different feature). To that we add another Kconfig for the mipsbook
which depends on CONFIG_JZ4730.

Now the dilemma arrives: we can't (pre)configure the mipsbook branch for mipsbook.
Because the JZ4730 Kconfig is missing.

If we add the JZ4730 Kconfig there, we get a duplicate. And as soon as we configure
for mipsbook, the CONFIG_JZ4730 will be enabled.

Now if we want to merge both features by git merge $FEATURE_BRANCHES we get a merge
conflict that can not be solved automatically.

So with this scheme it is not possible to configure and test the mipsbook feature
branch independently and set both branches up in a way that the mipsbook and
jz4730 are enabled after automatic merge.

Why is this automatic merge important? Because I often do this merge during development
and distribution builds (once every week) and do not want to solve the same merge
conflicts every time manually.

Well, there were other tricks. For example we could add the Kconfig to $BASE - but
that is contrary to my far distance goal of making $BASE == linus/master so that
all features are individual additions on top of kernel.org releases.

Another trick would be to base the mipsbook branch on top of the jz4730 branch,
but that stops automatic git rebase $BASE.

How is my work flow?

After doing the git merge $FEATURE_BRANCHES I git push that as for example letux-4.13
to the public, build everything and upload the binaries to the download server.

And I have a private "mywork" branch, which is rebased to letux-4.13. This are my
experimental additions. There I start new commits. And if they are good, I cherry-pick
them into the feature branches they belong to. After doing the next git merge $FEATURE_BRANCHES
and rebasing "mywork", they will disappear there, because they are already included.

This scheme has worked very well for ca. 2 years now and I want to stay with it.

One more thing for feature branches and upstreaming. The idea to separate things
into feature branches has developed from the [PATCH 1/n] thing how patches are
submitted to LKML.

If you have all your work in a single feature branch, it is very difficult to
form [PATCH 1/n] out of them. Especially if you are asked to modify them a little
to provide [PATCH v2]. If you have piled them up, you have to separate them again
and again. Keeping each such patch-set in a separate branch makes life much easier.

And since I assume that introducing a new CPU support and a specific device should
be separate [PATCH] sets finally, I'd prefer to keep them separate already during
development. One more aspect is that there are different maintainers for different
subsystems and if we touch too many subsystems in a single patch set there are
too many different persons to communicate with during patch review. Sometimes it
is easier to get as small as possible patch-sets upstream.

So back to the jz4730/mipsbook thing there is one question that came up.

Why are CPU and board connected by Kconfig at all?

On ARM I am used to that we can configure the kernel to support OMAP3, OMAP4 and
OMAP5 in parallel. During runtime the DT will choose which code path for CPU
initialization is running.

And independently of that we can configure to build a DT for different OMAP3,
OMAP4 and OMAP5 boards and again only the right DTB is loaded by U-Boot.

So the Kconfigs are independent and the Board-DT config does not automatically
choose a CPU config (select MACH_JZ4730).

Maybe this is historic for MIPS.

BR,
Nikolaus



More information about the Letux-kernel mailing list