On 08/13/2014 08:26 PM, Mark Brown wrote:
On Wed, Aug 13, 2014 at 03:51:54PM +0300, Jyri Sarha wrote:
I guess then the least bad alternative would be cutting the cpu-dai driver away from drivers/video/fbdev/omap2/dss/hdmi_audio.c and placing it under sound/soc/omap and registering it from hdmi_audio.c the same way as hdmi-audio-codec and asoc-simple-card is now registered.
There would be two devices for a single ip, but at least the ASoC side driver would receive its resources directly from the HDMI video driver with necessary tools to synchronize the access.
Just a MFD really.
This approach would work for other HDMI audio situation too, where there would usually (for tda998x and SiI9022 at least) be a need to register an i2s codec driver associated with the HDMI encoder. It would probably be possible to make a single codec driver to work with multiple HDMI encoders if the API between the codec and endcoder drivers is designed that in mind.
How does this sound?
This sounds like a way forward, I definitely think it's a good idea to standardise the interfaces as much as we can.
After discussing with Peter and Tomi I decided to change the approach a bit. There should not be any new device registered, just ASoC components that are implemented under sound/soc as a library rather than a device driver.
The library would export a register and unregister functions to be called from video driver directory. The functions will then register the necessary ASoC components under the video device.
If there are no objections I'll go ahead implementing this approach, first for OMAP HDMI audio, and later for SiI9022 driver we are cooking.
Best regards, Jyri