Year 2022 – It’s a wrap.

Another year is disappearing to the mists of the time. In my case, the mist is usually quite thick quite fast. I tend to forget things pretty easily. So, it’s about the last moments to stop and rewind the highlights while the last rays of memory are still shining on the events of 2022… :)

It was a sad year in my private life. Hence I’d like to focus on the work related topics. Oh, and the other reason is that this is the Linked In – which I think should be mostly kept as a medium for professional writings. Mostly. Sometimes I do appreciate seeing important things pointed out outside the work too.

Deep dive to V4L2

First half of the year I spent working on the camera and display SerDes drivers. It was a steep learning curve for me. I had never before looked at the video for linux stack, or a format in which the media data is delivered. Also, the IC I was supposed to be working with had no real documentation written – so, I could say the task turned out being … challenging :) Luckily I had a lot of help from various colleagues in ROHM and also from people outside the company! I do owe a big time for example to the folks of Ideas on Board!

The whole SerDes demo exercise was actually a set of drawbacks. When I was at school I was forced to read a book from “classic tragedy”-genre. I remember how I fought with it – a book where everyone just suffered until they died. Reading was terrible experience. To tell the truth, after reading a few chapters I gave up and wrote the crappiest essay I have ever written just based on the first few chapters and the text on the backside. Luckily the teacher did almost always judge my essays the same. Grade 7? – no matter what the text was :) Anyways, I think it has been pretty much the only book I have started to read and never completed.

When impossible is conquered by creativity

So, I don’t want to write a complete tragedy here. Hence, I’ll just tell the HW was delayed roughly for 4 months for ... reasons. Then I just fast-forward to the last week before the intended exhibition where these SerDes devices were supposed be demonstrated. This is when the first two sets of presumably working demo hardware was finally manufactured. Instead of 4 months and a week I now had a week to test the graphics stack we had written. And unfortunately, demo boards were in Germany – while I was in Finland.

I admit, I was ready to give up. It was my anonymous, stubborn colleague called Mikko (who had done major part of design and the user-space work – and who never gives up) who, during a weekend, invented a way for us to remotely access the demo setup. I won’t go into details but among other things a creative setup with a mobile phone and a Raspberry PI was involved… Oh, and another persistent colleague in Germany who did connect things and for example measure the hardware signals etc. And actually, during the last weekend he did for example notice we had to change the on board oscillator for the demo...

Monday was the day when the exhibition area was prepared. So, Monday EOB was the last moment to get the working software to the exhibition area. The work with the remote access was slow and clumsy. It was a tedious process and took quite a while to test each of the changes on the remote demo board - and I was on a very foul mood while trying to get things working… I may again have invented a few new swearwords while trying to upload the binaries thru our remote test setup... In any case, we got the display SerDes working with this very innovative remote test setup, and finally, at Thursday we got another piece of demo HW at Oulu.

When nothing goes as planned

I prepared to work over-time at weekend so that I might be able to get the camera working. Well, guess what – at Friday morning I was feeling sick. I was weighing the options and eventually, after making a phone-call to my colleague, I decided not to go to the office. Well, we had the 'proof of concept' solution for a remote work with Raspberry Pi and stuff - and a colleague at the office did set-up the same remote work option for the demo board at Oulu office as we had for the board at Germany.

I was still working remotely with the board, until around 2PM my head was really hurting like hell and I gave up and went to sleep. Yep, COVID-19 had finally found me in 2022. So much for the over-time.

Luckily the symptoms weren’t that bad. I was again back at (remote) work at Monday. It was the last chance of getting the camera working. Another colleague of mine had the faulty oscillator found by our German colleague changed for our demo setup at Oulu – and I did hastily go through the device-tree I had created. I quickly studied my new and shiny previously untested Ser and Des v4l2 drivers. I rushed investigating my MFD, I2C-ATR, GPIO and pincontrol drivers. And finally the more or less dummy camera-sensor driver I had written. I did find a few bugs and fixed them. I changed the clockings, PLLs and pixel formats. Then compiled and loaded the new binaries. No avail, no matter what changes I did the MIPI on the SOC stayed silent.

So, I failed. I know, many things went wrong, and a week of time to do remote debugging for such a largish untested set of code on previously unknown area is not much. The failure was not unexpected – but still it was a failure. The demo had to be presented without the camera and camera SerDes.

"Don't panic" - says vim :help!

At the next morning I started another day of working. Now I did not need to rush. The hurry had gone and I just decided that I might take a cup of coffee and once again look through the code. Still remotely as I did not want to spread the COVID at the office. I opened my vim editor and started systematically to go through the of_graph path while sipping my coffee. And yes – it was so obvious. One of the device-tree graph nodes was wrong. I fixed the node, compiled the device-tree and upload the binaries. Board booted nicely and now I saw MIPI being alive in the logs. I just threw in a "could be correct"-command for launching a gstreamer pipe – but as I did not see the demo setup I just decided to have a lunch. I could later ask the colleagues in the office if they could visit the place where the demo was set-up, and check if there was anything on the screen…

Meanwhile the colleague who had been doing most of the work for the demo was asked to move the demo-setup located at Oulu away from the room where it was located. You can only imagine his surprize when he went to tear down the setup and saw the video from camera on the display. We finally got it working – just a single day too late.

What to pick up from 2022?

Lessons learned? Many... But maybe the most obvious one for me – try not to hurry. Try to stay calm and help also everyone else to stay calm. It was not a new lesson for me, but once again I saw the importance of not working under pressure. And I hope I could also learn something from my stubborn colleague. His ability of inventing workarounds in hopeless situations is awesome. And finally, failing is part of the job. It sucks, but it still happens at times. You'd better sleep a lot if you never want to fail.

Other experiences from 2022, in no particular order... I got my first IIO accelerometer driver (for ROHM/Kionix KX022A) written and upstreamed. And while I was at it I decided to fix couple of bugs from some IIO tools and also from some other IIO drivers, while also hardening the IIO framework against certain type of bugs. I do really believe that investing some time in improving the common code is just “the right thing to do”. I’ve also been writing a Linux driver for a new PMIC which is not yet out – and an u-boot driver for another one. I am positive at least the Linux driver will be sent to upstream to allow everyone benefit from the IC without extra support. It’s just a bit too early to say whether the u-boot (or a Linux) driver for the other PMIC can be beneficial for general products. In any case, there is some more upstream work from me to be expected in 2023.

I was also for the first time participating in the Embedded Linux Europe conference - and I really enjoyed meeting some of the kernel hackers in person – as well as I did enjoy some Guinness. The conference was truly inspiring, and I am on a verge of sending a proposal for a presentation to the next Embedded Linux conference. I just wonder if PMICs and the regulator framework safety features are interesting enough – and if my skill level is high enough. And maybe most importantly – do I dare? I am always so terrified when I am presenting something. Well – maybe I do – sending a proposal is still far away from being accepted on stage, right ;) Besides – even though some part of me is so terrified, the rest of me is excited from such an opportunity. The same tickling feeling I had when holding the Linux kernel/driver trainings/labs for colleagues at Nokia.

I could say the 2022 was yet another year of learning and collaborating. I think this is a solid foundation for proceeding towards the 2023.

Wow, you read all the way down here! It shows the persistence ;) Thank you for your time, and Happy New (for now) Year 2023!