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

[Paul Boddie]

On Wednesday 13. September 2017 07.43.52 H. Nikolaus Schaller wrote:
> 
> 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.

I think I understand this: you have each feature branch that was presumably 
branched off originally from $BASE, and is then refreshed (with some kind of 
merge) periodically from $BASE; these branches are then merged back for 
periodic releases of the Letux kernel; each branch forms a kind of patch set 
for eventual mainlining.

Warning: ASCII art diagram!

linus/master -->
 \
  -- letux-base ------o--------------o----o-->
      \                \            /    /
       \                \          /    /
        \- feature0 -----o--------o--> /
         \                            /
          \                \         /
           \- feature1 -----o-------o-->

> 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.

Right. I'd forgotten about this, tried to configure, and kept seeing the Ben 
NanoNote selected instead. Then I realised that it just isn't possible to have 
the JZ4730 and the Minibook separate and to test the latter without the 
former.

> 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.

Can we not merge the JZ4730 branch (I guess this is the "defconfig" branch) 
into the Minibook ("mipsbook" branch) for testing of the latter? I guess you 
answer this later...

[...]

> 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.

I guess this really answers my questions. I should also have a branch for 
testing (which I do, in fact), and then also cherry-pick things for the 
different feature branches (which I have also tried to do).

> 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.

I see what you mean here.

[...]

> 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 there are no specific board configuration settings at all? Just the device 
tree definitions?

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

Surely it has to select something like MACH_OMAP, though. I can't see there 
being one configuration for all ARM 32-bit devices, certainly.

> Maybe this is historic for MIPS.

Having read your other message, I think that you can see that the Ingenic 
stuff has been merged to an extent. Just like OMAP is a family of sorts, the 
Ingenic stuff is similar enough within its own family, but different enough 
from other MIPS products, that it might also be configured in a similar way to 
the way OMAP is done.

Indeed, I have approached things from this perspective, and I use the device 
tree definitions to effectively select the appropriate driver behaviour 
without any #ifdef CONFIG_MACH_JZ4730 or whatever. I'm not sure whether we can 
avoid selecting a particular product entirely because the JZ4780 has slightly 
different capabilities (as have the JZ477x devices), but I don't know enough 
about kernel mechanisms to be sure.

Paul