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

Reply via email to