Open Technology - linux-sh

Busy two months: HDMI, SD/MMC, SDIO on sh-mobile

nospam@example.com (Guennadi Liakhovetski) — Thu, 02 Dec 2010 17:34:57 +0100

Two months is a lot of time, I have been busy working with HDMI and SD host interfaces on sh-mobile SoCs. HDMI should be much more usable on sh-mobile SoCs like sh7372. Support for E-EDID (Enhanced EDID) has been added to the kernel framebuffer subsystem, including parsing of SVD entries. HDMI clock configuration on sh7372 has been improved, various other SH-specific improvements committed to the 2.6.37 kernel.
The MMCIF controller on sh-mobile SoCs now can also use DMA, the tmio_mmc has got a significant performance boost from a trivial patch, adding support for multiple scatter-gather elements in MMC requests. Adding DMA bounce buffers to the tmio_mmc driver also allowed it to use DMA with SDIO cards.
If you really would like to see my patch history, you can try visiting my ohloh.net page even though this has become much more difficult after ohloh acquisition by Black Duck...

HDMI on SH-Mobile

nospam@example.com (Guennadi Liakhovetski) — Fri, 30 Jul 2010 10:11:22 +0200

Some SH-Mobile SoCs, including sh7372, have an integrated HDMI controller, that can be fed with video data from the LCDC and audio data from the FSI2. A set of patches has been developed and submitted to the mailing lists to implement initial support for the video function. At the moment the functionality is limited to a fixed 720p format. Monitor hotplug is supported to the extent, that the interface gets suspended without a monitor and woken up with one attached and turned on. The driver reads out the EDID information from the monitor, but so far it is unused. Working with HDMI proved to be difficult due to a number of reasons:

Different monitors produce different results with equal interface settings.
There are a lot of timing and electrical parameters to be configured on the interface, which all affect the image quality, and, unfortunately, are not all equally well documented. A slightest change in one of parameters can disturb the image quality or draw the monitor completely out of sync.
currently there is practically no support for HDMI in the kernel framebuffer subsystem and also no proper support for dynamic geometry reconfiguration, which is, of course, desirable for HDMI monitor hotplug. Specifically, there is no way to inform user-space applications about the geometry change and, respectively, applications are not prepared to handle such changes.

There is, of course, still a lot to be done:

Add sound support.
Use monitor EDID information to reconfigure the framebuffer.
Consider notifying user-space applications about the geometry change

Patches towards 2.6.35-rc1 - overview

nospam@example.com (Guennadi Liakhovetski) — Mon, 24 May 2010 15:03:29 +0200

With the approaching 2.6.35-rc1 release, it's nice to realise, that all plans have been fulfilled (well, which just means, that we planned wisely;)). All patches, that we wanted to manage in time for rc1, are on their way to the mainline via various respective subsystem and architecture trees. Specifically this means, that huge thanks are in order to all maintainers of those trees, and all who reviewed the patches and helped to get the patches in shape and on their way in time!

Most of the patches I already announced in this blog, the only new development since the last post has been porting of previous work to the SH-mobile ARM architecture. This includes DMA support for SDHI SD-card- and SCI serial-controllers, the latter driver has also been updated to support SCIFB serial ports. The tmio SD-card host driver has also been extended to take into account platform specifics. Impatient readers can look in mailing list archives, most of these patches have been submitted via the linux-sh mailing list. Otherwise just wait for rc1.

SH-mobile MIPI DSI driver submitted

nospam@example.com (Guennadi Liakhovetski) — Fri, 07 May 2010 22:07:45 +0200

Mobile Industry Processor Interface (MIPI(R)) Alliance has developed a number of standards for embedded buses, e.g., MIPI Camera Serial Interface 2 (CSI -2), Display Serial Interface (DSI), Display Command Set (DCS). Several SH-mobile SoCs implement some of these buses and thus can communicate with compliant peripherals. This patch series adds a minimalistic driver, that allows to configure the interface, activate the attached display and enable data transfer via the SoC's LCD Controller. The first implementation has been developed for and tested on the AP4EVB SH7372-based board.

Adding DMA capability to the SDHI driver

nospam@example.com (Guennadi Liakhovetski) — Sun, 25 Apr 2010 21:44:45 +0200

Writing software for undocumented hardware is always fun;) A patch series has been submitted to the MMC and SH Linux kernel lists, adding the DMA capability to the SDHI SD-card host driver, found on various SuperH and sh-mobile ARM SoCs. The SDHI driver consists of a multi-function device (MFD) glue driver and uses the tmio_mmc SD/MMC driver at the bottom level. The tmio_mmc driver is also used by several other MFD drivers. Fortunately, the SuperH DMA driver uses the kernel standard dmaengine API, so, adding support for it to tmio_mmc didn't make this driver platform-dependent. Unfortunately, I have only been able to make DMA work with SDHI by using both DMA and additional SDHI interrupts, which normally shouldn't be necessary with DMA. Usually, once the DMA operation has completed, the next one can be submitted for execution. However, this isn't the case with SDHI: here, after receiving a DMA completion event, you have to first wait for an additional interrupt from SDHI, signaling, that the interface is ready for the next IO operation. Only then you can safely submit the next DMA request. This, of course, slows data transfers down, but shouldn't add significant CPU load, because the overhead of setting up a new IRQ and handling it is minimal. I still have to benchmark SDHI performance in DMA and PIO modes, once done, I'll update this post. In yet another patch I also added SDHI DMA support to an sh-mobile ARM platform.

Pull request of 22.04.2010: V4L/DVB git development

nospam@example.com (Guennadi Liakhovetski) — Sun, 25 Apr 2010 20:14:42 +0200

Some soc-camera patches and two video output drivers:

01/06: sh_mobile_ceu_camera.c: preserve output window on VIDIOC_S_CROP
02/06: soc-camera: update comment
03/06: sh_mobile_ceu_camera.c: update documentation to reflect the new cropping
04/06: videobuf-dma-contig.c: simplify pointer dereference
05/06: V4L: SuperH Video Output Unit (VOU) driver
06/06: V4L: v4l2-subdev driver for AK8813 and AK8814 TV-encoders from AKM

The first of these patches is interesting, because it changes once again the way cropping is handled in the sh_mobile_ceu_camera driver. See patch description and documentation update for more details. Patches 5 and 6 are not related to soc-camera, the host and the client driver communicate with each other, directly using the v4l2-subdev API.

SH serial driver DMA support: part 2

nospam@example.com (Guennadi Liakhovetski) — Fri, 19 Mar 2010 15:22:56 +0100

DMA support for SCI interfaces on SuperH CPUs turned out to be even more interesting than I originally thought it was. A "simple" extension - adding DMA support to the SCIFA variant of the hardware took a couple of days, but is finally ready, and has been submitted to the SH Linux mailing list here and here.

SuperH V4L2 Video Output Unit (VOU) driver

nospam@example.com (Guennadi Liakhovetski) — Sat, 13 Mar 2010 11:16:15 +0100

Several SuperH SoCs, including sh7724, contain a Video Output Unit, which can be used to output video data to a TV video encoder in NTSC or PAL mode, or to an LCD. The sh7724 Solution Engine (ms7724se) platform uses the AK8813 NTSC/PAL TV encoder for this purpose. On one hand, developing drivers for these two units hasn't been completely new to me because of my good familiarity with the V4L2 and v4l2-subdev APIs, on the other hand this has been my first experience with video output drivers, all my previous V4L2 development concerned video capture. After all the usual initial issues with the new hardware and coupling of hardware units have been resolved, the system seems to work pretty well.

Testing of the drivers has been problematic too. The only open-source user-space tool, capable of talking to V4L2 output devices is gstreamer, whose latest version of gst-plugins-bad contains a v4l2sink plugin. However, you need the latest git version of this plugin to work with VOU, besides, using this plugin you can only test 16 and 24-bit RGB image formats, and not NV12 and NV16 formats. To test those I had to use a custom application, written and kindly provided by Laurent Pinchart. With a couple of easy extensions to that program and a patch for the v4l2sink plugin (a newer but unpublished version of that patch uses an enumeration type instead of strings, as has been suggested in a patch review) I have been able to test the set up with various image formats in PAL and NTSC (only as a monochrome image on a PAL TV set) modes.

Links to V4L2 patches:

01/03: V4L: SuperH Video Output Unit (VOU) driver
02/03: V4L: v4l2-subdev driver for AK8813 and AK8814 TV-encoders from AKM
03/03: sh: add Video Output Unit (VOU) and AK8813 TV-encoder support to ms7724se

Adding DMA support to the SuperH serial driver

nospam@example.com (Guennadi Liakhovetski) — Fri, 19 Feb 2010 10:45:09 +0100

Continuing the topic of slave DMA functionality on SuperH, using the shdma.c dmaengine driver, patches have been developed and submitted, adding DMA functionality to the SuperH sh-sci.c serial driver. I started by implementing the transmit direction, and even if that proved to be not very simple, there at least you know in advance the amount of data you're going to send. In the receive case, however, it becomes even more interesting, because we don't know the amount of data that's arriving, and the DMA controller on SH will only trigger an interrupt, when it has filled the receive buffer. So, unless you use a one-byte large buffer, you will not be informed of smaller than your buffer size transactions. So, eventually, I had to use an interrupt on the serial controller to detect the beginning of incoming data, and then use a timer to see, if fewer than buffer size bytes have arrived. In the latter case those bytes have to be collected from the DMA driver forcibly, for which there is currently no support in the dmaengine API. Therefore I had to extend and use the .device_terminate_all() method to retrieve the number of transferred bytes in the incomplete transaction. Review in process...

Audio support for the sh7722 Migo-R platform

nospam@example.com (Guennadi Liakhovetski) — Fri, 22 Jan 2010 20:51:35 +0100

Currently in its second version, the following patchseries has been developed and submitted to relevant mailing lists. It adds ASoC (ALSA SoC) drivers for the Sound Interface Unit (SIU), found on several sh CPUs. The series also adds a driver for the WM8978 stereo audio codec from Wolfson Microelectronics, as well as board support for the sh7722-based Migo-R board. Drivers have been tested with stereo playback and capture with various sampling rates. They are based on earlier work from another author, as can be seen from driver headers, but drivers have been practically completely rewritten. The original driver contained built-in firmware, was a pure ALSA driver, used direct register accesses to configure DMA, pin functions, used physical addresses to access the hardware, used hard-coded register addresses. The new version is an ASoC driver, it uses the dmaengine interface for DMA functionality (see a previous post for slave DMA support for sh), firmware is loaded from the user-space using the standard hotplug functionality, it uses runtime pm and generic clock APIs to manage CPU clocks. Although currently only tested on sh7722, the same SIU hardware is also present on other chips, e.g., sh7343, sh7354, sh7367.

Slave DMA functionality for sh dmaengine driver

nospam@example.com (Guennadi Liakhovetski) — Fri, 22 Jan 2010 20:38:36 +0100

The current sh dmaengine driver supports only public DMA operations, i.e., memcpy offloading to the DMA controller. A patchseries has been submitted to add a DMA slave capability to the driver. This functionality allows the use of the DMA engine on sh processors for data transfers to and from on-board peripheral devices.