On 11/21/2014 06:38 PM, Mark Brown wrote:
On Fri, Nov 21, 2014 at 02:10:11PM +0200, Jyri Sarha wrote:
OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec.
The discussion seemed to be about what to do with unplugged connections which isn't what you're talking about there and does seem like an area where we should at least be aiming for common behaviour even if not a common implementation.
In the discussion we recognized three modes of operation, a) try to keep audio device always operational even if audio is not going anywhere (cable is disconnected or video mode does not support audio) b) remove the audio device when audio is not available c) disable audio device if audio is not available and abort any ongoing stream when audio becomes unavailable d) force pause on the stream when audio is not available
The implementation in the patches follows mode c) and in my mind it makes the most sense. The mode is not carved into stone by the current implementation and it can be changed if we decide so. I see no point in keeping the hdmi audio completely broken until we collectively decide on how all HDMI audio devices should behave.
There's also all the stuff about parsing EDIDs for capabilities which would seem to be related to that but seems to have gone off into the weeds.
The idea of the patch set is to restore the old hdmi audio functionality in a form that is easier to use and maintain. Additional functionality can be added later. For instance restricting the allowed sample rates etc. based EDID Short Audio Descriptors.
Best regards, Jyri