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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
