Hi Ed, I want to add a few words to support Nikolaus position: On 29.10.18 17:26, H. Nikolaus Schaller wrote:
Hi,
Am 29.10.2018 um 16:04 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Montag, den 29.10.2018, 15:04 +0100 schrieb H. Nikolaus Schaller:
Hi,
Well, do you know when firmware loading changed? Because right now, it seems Kernel 4.16/4.17 broke the audio system even without AESS and 4.16 also broke TILER.
Are you sure? For me, 4.19-rc1 broke the TILER and it is fixed since 4.19- rc6. And I have not seen any difference between 4.15 and 4.16 for display.
At least with 4.15 it already shows and rotates the console output when booting and that didn't work anymore with 4.17 (I'm not sure we've tested 4.16).
The key problem seems to be that nobody did look into that so far and try to find the reason. There was plenty of time (3 months per major release, i.e. ~9 months).
Well, AFAIK, only zmatt really knows what's going on here. He is aware of the issue (also the problem that TILER breaks 3D at the moment), but at the moment, he seems pretty busy :(
So unless someone else has the time / mood to work himself into it, it will take an unknown amount of time.
Maybe, but right now, 4.15 seems to work best for us, at least regarding TILER and audio.
So why not fix these on 4.19ff? Next Monday I expect we will see 4.20-rc1.
I'm perfectly fine if these issues are being fixed, but wo is going to do that?
Anyone is invited... Without any hardware available, it's hard to help.
That is the bigger issue.
Can these patches be applied to 4.15 as well or is that not possible?
Everything is possible. It is just a matter of the energy needed and how much we can and want to invest.
Well, is it more complex to fix TILER of backport the changes you did to Letux? It could also be that TILER broke because of a different configuration issue in Letux (similar to the audio system you just posted about).
Generally, I would prefer if there were a team that invests time to fix the small number of remaining bugs of the latest kernel, rather than backporting fixes to some kernel which is no longer maintained upstream and will be abandoned at some not too far future.
While it's nice to have a bleeding edge kernel, it's also more time consuming keeping all your stuff working with future upgrades.
Especially if these kernel upgrades happen so often these days and literally EVERYthing we have needs to be retested / reassured to be working.
And that's where we all lack manpower at the moment. See the recent issues with TILER or Audio. And who knows what other new bugs have been introduced.
So I think it's more important to decide to use ONE kernel which we'll work on, and make it run perfect with all hardware.
This can also be Kernel 4.19, if you like. (A normal Debian system still runs Kernel 4.9.0).
This stable kernel can be used for productive systems and all new versions being worked on should be in testing / unstable until all issues have been ironed out.
At the moment it feels to me that you fix some things with each kernel version but that new kernel versions introduces multiple new bugs - so we'll never have a kernel where EVERYTHING simply works.
I am waiting for more developers having hardware and helping to fix missing things where we know for long time they are missing. So trying to provide them already with a kernel where EVERYTHING works seems to build a deadlock...
That's the point. We don't need perfect HW/SW all we need to start is HW, which is able to boot. For me there is only one target kernel version and that is Linus prepatch tree. With our lack of man power we have to mainline as much and fast as possible. You already recognized that the Linux community is working pretty fast, and all that work is done on the most recent version. Besides bug fixes (for already supported boards) you won't get any help from the community. If you want someone to look into your patch it has to be against mainline. To keep this pace, we need as much automated testing as possible. This should be the long term target: https://kernelci.org/
As you said yourself: 4.15 is missing some OTG / Charger fixes. 4.16 and later has broken audio (okay, fixed already) and TILER
There is not a single kernel we could use for delivery of the device so far. If the OTG / Charger fixes had been applied to 4.15 and also the later in- development kernels, then 4.15 would be ready for delivery.
But right now, not a simple kernel is fully usable.
Well, that is life with open-source and volunteers. There are always bugs not found for a long time and new ideas introducing new bugs. People live with that and know that they can blame nobody for that.
LetuxOS follows the mainline, stable, long-term scheme of kernel.org:
http://projects.goldelico.com/p/gta04-kernel/
This means that development is done only on the mainline (alpha) branch.
And as soon as it becomes stable upstream, a new development branch is started and upstream patches from Linux/stable are merged in every now and then. With this approach we got e.g. some spectre/meltdown patches (where I hope they are useful for OMAP5) or others fixing unintended root access.
Like with mainline Linux (where not everything is backported to stable), some (not all!) of the Letux specific patches are backported to older stable kernels when they seem to be mature. But not all of them go into every old kernel because not all are compatible from the code basis.
So if we have the Audio fix at some time (at the moment, we have only a work-around for the Pyra but it has negative side-effect on other platforms), we will backport it to older kernels.
Charger and OTG fixes have already been backported to 4.18 and partially to 4.14 because of to too many conflicts. See for example: http://download.goldelico.com/letux-kernel/letux-4.18.15/src/CHANGES (4.18.11 and 4.14.72 have got charger fixes and 4.18.7 got OTG working).
So I'd suggest to take either 4.14 or 4.18 because they will have long-term support from upstream. Maybe fixing critical security holes we all do not expect.
BTW: the lastest official stable release of LetuxOS kernel is the "master" branch, currently 4.18.
If it still has bugs (and there is always another one), we need bug reports and fixes. If it is still not fully useable it is lack of people cooperating to make it fully useable.
Therefore it IMHO makes not much sense to take 4.15 as the basis. It is not maintained anywhere. Unless you want to maintain it yourself. 4.14 would be a better choice but lacks some backports. Or 4.18, as soon as we have a backport of the Audio/Tiler fixes.
IMHO the next tasks are:
- fix CONFIG_IDLE_CPU for OMAP5 (probably any kernel version)
- fix TILER console rotation (recent kernels)
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel