Hi Tomi,
On 11/16/2012 01:38 AM, Tomi Valkeinen wrote:
Hi,
On 2012-11-16 03:36, Ricardo Neri wrote:
Creating the accessory devices (such as audio) from the HDMI driver, allows to regard HDMI as a single entity with audio an display functionality. This intends to follow the design of drivers such as MFD-type, in which a single entity handles the creation of the accessory devices. Such devices are then used by domain-specific drivers (audio in this case). This is in line with the DT implementation of HDMI, in which we will have a single node to describe this feature of the OMAP SoC. Otherwise, we would need to have separate nodes for audio and video functionality.
Previously, the platform device for the audio driver was created in arch/arm/mach-omap2/devices.c. Thus, this is removed.
Also, as the platform device for audio created by the OMAPDSS HDMI now provides a resource for the DMA port for audio samples, we do not need to specify any offset in the ASoC HDMI CPU DAI driver.
If you notice yourself writing "also, the patch does this" in the patch description, it's usually a sign that the patch needs to be split =).
:)
That's perhaps not so important when a patch only deals with one subsystem or one file, but when the patch changes arch, video and audio drivers at the same time I would like to have the patches as simple as possible.
Here I suggest you handle the DMA port change in a separate patch.
I went ahead and submitted this part in the same patch to make sure that HDMI audio works in every patch.
What I can do is that a first patch creates the platform device for HDMI and just passes the whole register space to the audio platform device to not break ASoC HDMI. Then, a second patch will refine the pdev audio resources and remove the offset from the ASoC HDMI driver. Does that make sense to you?
BR,
Ricardo
Tomi