[Lenny400] More patches for linux-stable

[Paul Boddie]

On Sunday 3. September 2017 18.20.52 H. Nikolaus Schaller wrote:
> 
> An alternative could be that you manage and git push --force to the two
> relevant branches on the gta04-kernel.git.

After a lot of messing around with git, trying to figure out why it doesn't 
like repositories, getting a clone from David with fewer issues, and mostly 
giving up on troubleshooting it and just getting on with applying patches, 
I've managed to produce some patches which you might be able to work with:

0001-JZ4730-updates.patch should apply to 
a4e95753d1e98914d176932d7370ceda7aedffb0 in 
remotes/origin/work/pboddie/mips/jz4730

0001-Added-more-JZ4730-device-definitions.patch should apply to 
19b9f98f09b72de51f2c6efa2c7612802bb66406 in 
remotes/origin/work/hns/mipsbook400/dt

The latter is the result of manually taking my changes and adding them to the 
mipsbook_400.dts file, since the minipc.dts file wasn't around in the 
repository, so there was no continuity. I also couldn't find the board-
minipc.c file in either branch, and so those changes are not provided, but I 
imagine that the aim is to eliminate this file, anyway.

Although I tried to make sense of the pinctrl stuff, it isn't clear to me how 
the "function" maps to the actual alternate/alternative function setting on 
the pins. Indeed, the pinctrl-ingenic.c file defines function names in a 
static-qualified array which is not referenced in that file, so I suspect that 
the mapping might not work yet. (It doesn't help that "function" is used in 
several different ways in the documentation, so examples of how these things 
are done are very difficult to find.)

I hope these patches apply. There may be divergence in the first branch 
because the patch isn't applied to HEAD, mostly because I was too lazy to deal 
with the conflict that the HEAD introduces when applying my changes.

Paul

P.S. I did find that the following helped when attempting to troubleshoot git:

git config pack.pageSizeLimit 100m

It isn't clear whether 100m, 50m (which I also tried) or any other number is 
"better", but it did then allow the troubleshooting practice of running "git 
unpack-objects" without it complaining about "volatile objects" or some such 
impenetrable nonsense that end-users are not likely to be able to handle. 
After running SMART and RAM tests which succeeded, I have the suspicion that 
git might be running in too little memory, given that I "only" have 1GB to 
play with.