Pengutronix' Activities in Linux 3.13
During our embedded linux projects, the kernel engineers at Pengutronix do a lot of improvements which end up in the mainline kernel. Here's a short story about what went into the recently released 3.13:
SocketCAN maintainer Marc Kleine-Budde fixed a memory leak in the peak_usb driver. He found out that the flexcan driver used the wrong clock on MX5, which resulted in wrongly calculated bit rates. In the c_can driver, he fixed a "scheduling while atomic" bug. Other janitorial work has been done to the ti_hecc CAN driver and the CAN core.
Philipp Zabel works on graphics tasks on MX5 and MX6, both related ot the DRM driver and to the Video parts. He submitted a patch to the v4l2 subsystem which makes it possible to map DMABUF buffers with write permission. A spec violation regarding the setting of the pixel format and with invalid pixel formats for v4l2 has been fixed. He also implemented try_decoder_cmd to let userspace determine available commands and flags. For the CODA video encoder/decoder found on i.MX27/53/6, debugging was improved. The picture type reported by the CODA unit is now properly propagated into the software framework, and the driver does now correctly detect different CODA hardware types. The compressed flag is now fixed in output buffers and the buffer handling in case of a stream-off is improved. On CODA7541, the video encoder/decoder component in MX5 and MX6, the driver is now able to handle more than 4 concurrent accesses. In the v4l2 driver core, Philipp added patches which improve DMABUF and user pointer handling. For the i.MX DRM driver which is currently in staging, Philipp added support to make use of the PRIME functionality introduced by the "drm: GEM CMA: Add DRM PRIME support" patch and added DRM plane support. He removed the old ipu_framebuffer data structure from the kernel and added suport for the BGR888 graphics format to the IPU driver and its display controller and for the BGR565 format. In order to support small displays on MX6, he improved the end of line handling. As the IPU is used both on the display output and video input side, he improved the handling of drm_fourcc format description.
Michael Grzeschik fixed a bug in the USB gadget subsystem for composite drivers, which happened when an USB device got unplugged while still being used. Michael is working on improving the ci13xxx USB controller driver, which had a lot of issues recently. A lot more patches are currently pending for this controller.
During the 3.13 cycle, Uwe Kleine-König mainlined the EFM32 Cortex-M3 processor platform. During this work, EFM32 got DEBUG_LL functionality and proper timekeeping, and a bug with GPIO bitbanging was fixed. Uwe started to package the CAN utilities for debian. As a preparation, he went through the CAN files in mainline and improved the copyrights in the headers. Uwe also fixed some issues in the fsl-dspi driver. Uwe helped the transition to clockevents_config_and_register function, which had to be reverted for AT91RM9200 some time ago. At that time, a rounding problem let this driver fail, due to the bug in the driver core; the mechanism was also added for the DaVinci processor family. Other janitorial work has been done in the CSR SiRF watchdog driver.
Markus Pargmann hunted several audio issues this time. One of them was caused by locking issues in the mxs-dma driver for MX28. A patch hit mainline which fixes the locking in this driver. A second bug in this driver happened after a channel reset. Now that the issue is fixed, the state is set correctly after a reset occured. The channel reset does also seem to have a hardware issue: when being in READ_FLUSH state, the dma controller could stop working. A fix was added to the kernel to avoid this situation. Another patch fixes the correct residuum reporting for cyclic DMA; the DMA interrupt handler so far formerly handled all available channel interrupts it could finde; now the interrupt handling was fixed to handle only the relevant channels. On AM335x, Markus fixed an error with rx handling in the c_can driver and improved the IRQ register checking. The w1-gpio driver was changed to use devm_* functions. While doing so, the error handling for this driver was improved. All in all, the mainline situation improves slow but constantly for AM335x. For i.MX27, Markus added the pincontrol driver, with a core driver to access registers on MX1/21/27. On MX28, Markus fixed the error handling of the serial audio interface (SAIF) and improved the consumption of trigger commands and its state handling.
Steffen Trumtrar mainly worked on mainline support for the SoCFPGA FPGA plus ARM-SOC made by Altera. He improved the clock management and improved the devicetrees: an important part of this work was to distribute the right devicetree nodes to the different dtsi files. He added support for the Terasic SoCkit board, a whitespread development kit for the SoCFPGA. Additionally, he fixed a bug to handle PWM correctly when being initialized from oftree. He also worked on the MC13783 power controller and added more infrastructure (i.e. routes, muxes, switches) and more mixer controls to the audio part to the mc13783.
Jan Lübbe added support for oftree initialisation to the AT25 SPI EEPROM driver.
Sascha Hauer fixed the event clearing in the i.MX6 DRM driver for the rare case when a userspace program exits exactly during a page flip.
Jürgen Beisert improved the i.MX23/i.MX28 I2C controller driver and split up the functionality for the two different chips. The PIO mode does not work. He also worked on the Low Rate ADC driver currently in staging and added devicetree initialisation and interrupt support. He made it also possible now to distinguish MX23 and MX28 on runtime, so the same driver can now be used for both chips. As it was not possible to fix all remaining issues, he improved the TODO list in staging.
All in all, 3.13 was a busy cycle for the Pengutronix kernel team. The patch rate hitting mainline is nevertheless decreasing, as we are working on more complex components (i.e. the IPU graphics unit on MX6).
Today it has been 15 years since we mainlined support for Freescale/NXP's i.MX architecture in the Linux kernel! That was one small step for [a] man, one giant leap for (industrial Linux users') mankind :-) Here is some background about why it happened and what you might want to learn from history for your next embedded Linux project.
Some days ago, Greg Kroah-Hartmann wrote a great blogpost about Which Stable Kernel One Should Use?. I fully agree with his position; however, I'd like to make some additions for the industry device manufacturer use case and some common pitfalls and misunderstandings we see in that area.