Hello everybody Thank you very much for having me for this year's FOSTAM. I Am Martin and I'm a kernel developer. I'm working with purism on the librem5 phone and in this little talk

I want to give you a Kind of a feeling about how we do kernel development what we did Over the last months and What we are planning to do and

I Think it was Daniel Stanford from the curl project who used to choke That there are many successful projects but kind of You know when your project really won is when it's being used as a verb and when we talk about mainlining

this always reminds me of that and I guess in that sense the the mainline country really won Okay Here on the left side, of course, that's the librem5 phone I personally use it actually for a few months now as my only phone and

It's a really fun device it's actually funny calling it a phone because it's Really similar actually to my workstation technically So What we have on

Source dot puri.sm. There is a gitlab instance and we host The librem5 kernel tree there, which is a kind of a development tree against the main line and What we do is we use the gitlab workflow to create merge requests for changes want against our tree

But these days it even happens That we do changes We test of course to development in the usual way but two changes against the main line directly and

Since we use stable kernels to base our tree on We can just basically do changes without ever being inside of our out of tree patch set so What we do with our patch set we kind of

Mimic the the upstream development cycles so When roughly when a merge window for a new? kernel closes we rebase our patch set on top of an RC

kernel and Use basically the the RC stabilization phase to Debug and stabilize our patch set during that time as well and By the time that Linus tags a kernel as stable

We make sure that our patch set on top of that again rebased is Ready to be used by our users and we release it. So in the end

Of course the goal is for our patch set that's not in the main line to become smaller and in the end It will be something like the Debian army64 kernel At least as close as possible to that so

What we did in 2020 there are more things and I forget To mention things. It's just a few Pieces of work that came to my mind Mostly kiddo of our kernel team wrote a driver for the me BTSI host controller

for iMX8 MQ We did a lot of device read descriptions that's important to us to maintain them Inside of the mainline kernel to support the device directly. I wrote this edge driver for the accelerometer and gyroscope driver

We Focused on supporting the panels and runtime power management is very important in our case To this day basically, that's All we do if you will For example, if you would turn off the screen on the phone right now

Nothing special happens actually. It's just that At this point that the display stack doesn't need to be powered anymore that results in DRAM a frequency to be lower

It can it can it can at least run lower and that saves a lot of power, but Linux runs currently As it always runs. It just powers down devices in 21 To give you some numbers we use the 5.7 base tree with roughly 40,000 lines of code insertations in our downstream tree

We did quite some work on the USB type-c side the Battery charger and also towards the battery the battery core controller, but also the type-c power delivery and stuff like that And

What we then did when we were on a 5.9 base tree We added another 10,000 lines of code roughly in order to support the cameras We did that in order to have it quickly and we use drivers from the NXP BSP kernel tree And over the course of 21 we mainlineed almost all of it and actually today

We use a 516 based kernel that has everything We need except for one driver. That's the backside Camera sensor driver. That's the only thing that's Missing that through at the very edge and that's a very good position to be in actually

from a maintenance point of view What we did is we improve power management for SD card readers in general so that this event polling mechanism that distributions currently use is technically not needed anymore and

Run time power management can just be enabled instead and the last line shows that really the bulk most of our tree out of three Editions is really the Wi-Fi driver. That's a kind of our blind spot if you will currently

Because the worst thing is that? There is a mainline driver That's supposed to to work with the cart we ship We just haven't taken time to use it and to improve it to be as good as the driver we include We really need to do it I put up this site because I really I want to thank

Kind of the wider development community that helped me personally to do my work not only in mainlining but really without It Laurent for example from the camera Development side lip camera or Sean from the arm 64

Device three parts many many other people it doesn't really make sense to start list listing people, but I Myself hope to be as helpful to others as well and of course The the cuddle team that I work with with Angus and keto and Sebastian or an anterota is extremely extremely helpful

In 22, I guess we will do quite some work in the DRAM subsystem Where we have drivers that are not yet in the main line that we need for the HDMI and display port output

I think there's still work needed For the touchscreen driver We of course the mentioned Wi-Fi driver is really something we should change a

Tiny bit actually is the the backside LED that can be used as the flash for the camera needs video for Linux to support and I have been working on system suspend and that's actually something that It's going to be ready

For users to test very soon right now and That's going to I think that's going to start an interesting discussion about how to really Use it and what policies to create and out how how to best make use of system suspend for

a phone I I Put up this slide because I really spent a lot of my time on the camera stack last year and One driver I wrote is the the sensor driver for the selfie cam in this case and

I Have a question basically for you or for the session later later on Because I have the datasheet for this sensor and I could have never written this driver based on a datasheet. I only could do so because there is an Android device out there with the same sensor and

therefore there's a kernel out there with the sources and The reason is that there are literally hundreds of registers That are not documented at all being written to in order to support Support the resolution modes and stuff like that and that becomes a problem because as soon as I want to do changes or support

Different resolution modes or stuff like that. I Have no real basis to to work against and really if I know that there are Many sensor drivers kind of that

Are in this situation and Android kernel trees often hosted somewhere and on github and are not really good at preserving get history So I really would appreciate any Insight in how they are written actually Yeah, so really that's the question

Yeah, when we talk about mainlining that's just one thing that comes to my mind That's going to be especially hard to do because the imx8mq sock Has a hardware bug that simplified speaking CPU cores

Cannot be woken up from the deepest sleep state it's a problem where we have a software workaround for but that's basically pretty ugly and not really suitable for The mainline kernel and that's going to be one of the last pieces I think we Will try to support in mainland, but that's going to be hard and

Lastly let me Think about mainlining a bit in general What I want to say is let's not see mainlining as a goal I think

It's important to have the mainline tree and the really ties our community together and make us write good code and and need to communicate and and a Related word of community of course is communication and we should really try to

Hold that up high if you will and try to communicate in a good and in a nice way and respond in time and Explain openly why we do things why we want things And mainlining is one piece one kind of natural piece of our work

as part of our community But it's never where development stops for example, it's often the opposite actually And I know we are sometimes really busy in our jobs and want to get

To-do lists ticked off or something, but it I just want to kind of encourage to Try to sometimes take a step back and even look at what's What might be good for the project itself? Not really for your own task you need to get done, but

Whatever be it why a driver is in staging and a question everything but Of course Listen to other people question everything and really try to improve our project and community

so And with that I think I'm at the end and yes, I have a Few minutes Still for questions later on Of course if you own the phone

There are no secrets at all our GitLab instance is there I Usually write a blog post about About our progress we do for the for the mainline stuff and

We even accept patches at kernel at puree.sm if that's What you want to do, that's my email address down there Really It's really a fun project and that's really something you should remember

To have fun and with that Thank you very much, and I'm looking forward to talking to you. Thank you. Okay?

Thank you very much Martin for your interesting talk. There's a couple of questions

In the channel, I'm going to start with a topmost month from DevRT set And what are the most enjoyable annoying subsystems patch sets you worked with over time? And why? Oh That's hard to say in general I have really good experience with working with maintainers in subsystems

Especially I don't really want to To mention specific ones actually the IIO subsystem was very helpful

Right now I'm starting To dig around in the sound subsystem and people are very helpful. Yeah, I have really Not really bad experiences to be honest The only thing that happened of course if the patch sets are lying around and nobody looks at it, but that's a problem

That will not go away so soon Okay. Yeah, that's that's true, but I think from from what I have seen We've there was pretty good response to most of the patches. I've seen flying around which which which is nice There's another question from DevRT set and you mentioned suspense how much work is still needed on the kernel user space side

I think kind of like until it can be used daily and out of the box So on the kernel side I've made sure that The Suspended resume path technically work. So

At least on my development device you can suspend the phone and resume it pressing either a power button or use basically any a Wake up line that's configured and That should be of course also be the modem receiving a call or SMS and

While that works on my device, I've heard at least one or two reports that there are issues One issue is when you're not using systemd so that's not a purism specific issue, but I'd say The kernel is ready for people

To test this and we will not immediately Configure it to be the default. So we will not immediately say Let's put the phone to suspend when it's not being used, but I want to get there and I think We are at the point where? We can basically ask everybody to

To try it out Okay, and any comments on the user space side. That was part of the question The user space side is something I only started to think about It'll be interesting. I think the first step

There's no There's definitely work needed to be done as far as I know But how a how a Policy could look like in the first step. I think should be very simple like As this

basically instead of Doing plain suspend to something like RTC wake and wake up after a few minutes and see whether something happened See whether any notification comes in or not And if not suspend again, and that's a very simple thing and that's I think something we should work against in the first step

Okay. Yeah, and I am recently in the first channel I saw this work done by other people basically on that pattern. So That's that sounds great. There's a question from Q. It seems much time has been spent on improving the power management How does the battery how long does the battery last now?

Maybe you can say something about kind of like this Without suspend which is kind of like the default at the moment and maybe what you would expect is the very first step with suspend. I So for me it's it highly depends on how you use the phone

So right now if you would work on the phone do something on the phone you the battery Will drain relatively quickly? But for me personally I use the phone and

Without Charging it. I'd say I use it half a day. That's something that's really my use case so It it lies around for an hour or two. I do stuff with it for an hour or two and I

Think half a day is something that it lasts easily If it's lying around all the time it probably would last more than a day or Or baby, maybe one day and for the system suspend case, I think what we can do expect is something like

when the phone is lying around and not being used and We can roughly Roughly double the time the device

Keeps it keeps a powered in that state. So it won't change anything when you use the phone, of course it will definitely improve the being available and powered fine Yeah, sure. That's it can only improve the standby time That's and but I think we also have come maybe some pending

Optimizations and user space for for the running time That's another question. You mentioned you have been using pure method daily driver. What did you use before and How is the experience is there a place we have perhaps can read up about your experience many important? for a phone things so

Basically, kind of like what are you missing on your device? What is the experience towards your old phone? And what was it? Well, I I've been using an Android device. So with a line of choice Image without any Google stuff and

The experience on the Librem 5 is I Don't want to say surprisingly good, but it's it's nice you know, it's in part a psychological thing right now and It's a really good feeling not to use

tons of non free software all the time and So my personal use cases work, I personally don't yet use for example the signal messaging But technically that's something that should work as well What I personally miss is probably good

a GPS GNS s and navigation system probably That's almost the only thing I

Miss I mean I miss one thing but that's a user space gnome issue. That's these Call the office Okay, but I think you should be able to do that actually I have had car tough But you can't configure it but I think it's time to wrap it up. We have 20 seconds left. Thanks again

Martin for your talk and I think the room is going to open up for Others in a couple of minutes and you have five seconds for any last words. No. Thanks for listening My pleasure to be at Boston