OMAPDSS: hdmi5: Fix OMAP5 and J6 HDMI audio quality

Enabling idle mode during audio playback causes the glitches on OMAP5
and J6. This patch turnes HDMI warppers idle mode to no-idle for the
duration of the playback.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: Kconfig: Remove OMAP4+ HDMI audio options

Removes OMAP4_DSS_HDMI_AUDIO and OMAP5_DSS_HDMI_AUDIO Kconfig
options. They are not needed in the new HDMI audio model anymore.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: hdmi: Remove registration of the old omap-hdmi-audio

Removes the callbacks for the old omap-hdmi-audio and
register/unregister call to it. Also removes inclusion of all
hdmi-audio related headers and all hdmi audio related data members
from hdmi drvdata.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
ASoC: omap-hdmi-audio: Update implementation to latest mainline version

The new audio driver implements cpu-dai component using the callbacks
provided by OMAPDSS and registers the component under DSS HDMI
device. Omap-pcm is registered for platform component also under DSS
HDMI device. Dummy hdmi-audio-codec is registered for codec component.
The hdmi audio driver implement also the card component and registers
it under its own platform device.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: Remove include/video/omapdss_hdmi_audio_data.h

The new OMAP HDMNI audio implementation stores it's own drvdata.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: hdmi: Register new HDMI audio implementation

Implements audio callbacks for the new HDMI audio implementation and
registers the new omap-hdmi-audio driver.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
OMAPDSS: hdmi5: Initialize hdmi5_aduio_config stack variables

Signed-off-by: Jyri Sarha <jsarha@ti.com>
drm/drm_edid_load: Build in toshiba_edid.bin

Signed-off-by: Jyri Sarha <jsarha@ti.com>
edid hack
dts/dra7-evm: Patch for rev G boards

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Revert "drivercore: deferral race condition fix"

This reverts commit 1636737609d52bc1560bf8189f4d897c9c8c03f4.
drivercore: deferral race condition fix

When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules are loaded but some driver still stuck in the deferred list
and there is a need for external event needed to kick the deferred queue
to probe these drivers.

The issue has been observed on embedded systems with CONFIG_PREEMPT enabled
audio support built as modules and using nfsroot for root filesystem.

The following fragment of a log shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:

...
[   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
[   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
[   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
[   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[   13.346755] davinci_mcasp_driver_init: LEAVE
[   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[   13.592527] platform sound.3: really_probe: probe_count = 0

In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (12.615118) and finishes first as well.
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components and the deferred work is prepared at
13.099026 (not that this time the machine driver is not in the lists so it
is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to the
deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.

The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers probed while this last
driver was probing.

This way we can avoid drivers stuck in the deferred queue.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>