[Letux-kernel] AESS / Audio Driver for Pyra

H. Nikolaus Schaller hns at goldelico.com
Mon Oct 29 17:26:46 CET 2018


> Am 29.10.2018 um 16:04 schrieb Michael Mrozek <EvilDragon at 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...

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

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


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)


More information about the Letux-kernel mailing list