clockworkpi

[kernel] mainline support evolution

since 5.4.rc8 a mainline patch need to be reversed, else screen flicker

patching file sun4i-i2s.c seem no more needed in recent kernel

compiled 5.4.1 kernel, untested on debian > kernel, headers

3 Likes

I really envy those who understand kernel development

3 Likes

i nearly know about nothing about kernel development ^^"
others like godzil must know pretty much more on the subject

it make me some try & time to find the faulty commit, same thing for tweaking kernel config
since i made a real pkgbuild without (for now) cross compile, each kernel compilation took about 1h on gs …

i still have some trouble with bluetooth and xorg still fall to llvmpipe,
got a full working system but it need some more work :slight_smile:

1 Like

5.5 branch with the latest rc1 release change the backlight driver system, so our ocp8178 driver need to be patched

https://github.com/torvalds/linux/commit/2e7ec69d645210ea8a94cbb91799f57f62418bca

https://github.com/torvalds/linux/commits/master/drivers/video/backlight/gpio_backlight.c

2 Likes

I would honestly not go bleeding edge like that, and avoid RC version as much as possible. Using LTS would be better, but there is no 5.x LTS yet, at least a stable branch, but you would need to move forward until they put a LTS branch if you do so.

The other problem with the stable branch is they are not necessarily that well tested unlike LTS or a bit older branches, and you may encounter some unexpected bugs.

For the TL;DR, I would prefer to avoid too recent kernel for an official OS release, and try to use a reasonably well tested stable version

that’s a valuable point of view but as our hardware mainline support is pretty recent, like lima, use latest release mean latest support & real evolution

but yes it could include problems like the one i point in #1 or this recent backlight driver change

Would backporting the relevant drivers be a possibility? Or are the necessary parts too interlinked to have a go on that?

yes, driver seem to use the “skeleton” of generic one to speak with kernel api, with aside all additional & custom code to interface with our backlight hardware

on a first see we just need applying the same modification of generic driver got to port our one to the new api

i’m not an expert but api change seem to have removed from driver all code related to catch gpio pins, now directly asking kernel to catch them from device tree

Doesn’t the kernel provide legacy bindings for some releases until LTS is over for the older kernel? Or what about (will be difficult though) rewriting the lima driver as a module which can be loaded with dkms? Or adding the gpio pins to a dts file and rewrite the driver to get the necessary pins from that file

it’s the screen backlight driver who need a patch, not the gpu one
for lima, since kernel 5.2 it is hopefully directly included in mainline :slight_smile:

yes i think all kernel before this 5.5 branch will continue support for older api

Oh yeah, sorry, mixed them up. Would be very bad if gpu drivers for a common chip weren’t mainlined (looking at you nVidia). As the backlight driver is smaller it seems even more realistic to backport it without too much hassle

The ClockworkPi/Gameshell are recent devices, yes, the AllWinner chip is not.

@beckerichmika Yes to some extend, but not everything. They back-port driver only and only if that’s a really important thing to support on that LTS. New hardware are generally not added until the next LTS, but well we will see!

@r043v: I have nothing against using a recent kernel version; just that for an official release it is better to stick to the closest stable or LTS release. Of course if we don’t have the choice well…