[alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next
The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: https://github.com/jsarha/linux.git omap-hdmi-audio
It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers.
Changes since v7: - Squash: - "OMAPDSS: omapdss.h: Remove audio_state member of struct omap_dss_device" - into "OMAPDSS: Remove all references to obsolete HDMI audio callbacks"
Changes since v6: - "ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support" - Fix Kconfig help text - Remove #include <sound/simple_card.h> - Use snd-soc-dummy codec instead of hdmi-audio-codec - Add: OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() - Add: OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter - Add: "OMAPDSS: omapdss.h: Remove audio_state member of struct omap_dss_device" - "OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio" - Register "omap-hdmi-audio" with PLATFORM_DEVID_AUTO - "OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio" - Register "omap-hdmi-audio" with PLATFORM_DEVID_AUTO - Add: "OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback"
Jyri Sarha (19): OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() OMAPDSS: hdmi_wp: Add function for getting audio dma address OMAPDSS: hdmi: Make hdmi structure public OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio ASoC: omap: Remove obsolete HDMI audio code and Kconfig options OMAPDSS: Remove all references to obsolete HDMI audio callbacks OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback
.../fbdev/omap2/displays-new/connector-hdmi.c | 99 ----- .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 --- drivers/video/fbdev/omap2/dss/Kconfig | 7 - drivers/video/fbdev/omap2/dss/hdmi.h | 38 +- drivers/video/fbdev/omap2/dss/hdmi4.c | 269 +++++++------ drivers/video/fbdev/omap2/dss/hdmi4_core.c | 14 - drivers/video/fbdev/omap2/dss/hdmi4_core.h | 4 - drivers/video/fbdev/omap2/dss/hdmi5.c | 265 ++++++------- drivers/video/fbdev/omap2/dss/hdmi5_core.c | 9 +- drivers/video/fbdev/omap2/dss/hdmi5_core.h | 2 - drivers/video/fbdev/omap2/dss/hdmi_common.c | 2 - drivers/video/fbdev/omap2/dss/hdmi_wp.c | 16 +- include/sound/omap-hdmi-audio.h | 43 +++ include/video/omapdss.h | 40 -- sound/soc/omap/Kconfig | 26 +- sound/soc/omap/Makefile | 6 +- sound/soc/omap/omap-hdmi-audio.c | 407 ++++++++++++++++++++ sound/soc/omap/omap-hdmi-card.c | 87 ----- sound/soc/omap/omap-hdmi.c | 364 ----------------- sound/soc/omap/omap-hdmi.h | 38 -- 20 files changed, 781 insertions(+), 1011 deletions(-) create mode 100644 include/sound/omap-hdmi-audio.h create mode 100644 sound/soc/omap/omap-hdmi-audio.c delete mode 100644 sound/soc/omap/omap-hdmi-card.c delete mode 100644 sound/soc/omap/omap-hdmi.c delete mode 100644 sound/soc/omap/omap-hdmi.h
Only OMAP4 DSS has non reserved bits above 6th bit in HDMI_WP_AUDIO_CFG.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi_wp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c b/drivers/video/fbdev/omap2/dss/hdmi_wp.c index 496327e..71b499e 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c +++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c @@ -194,8 +194,12 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp, DSSDBG("Enter hdmi_wp_audio_config_format\n");
r = hdmi_read_reg(wp->base, HDMI_WP_AUDIO_CFG); - r = FLD_MOD(r, aud_fmt->stereo_channels, 26, 24); - r = FLD_MOD(r, aud_fmt->active_chnnls_msk, 23, 16); + if (omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES1 || + omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES2 || + omapdss_get_version() == OMAPDSS_VER_OMAP4) { + r = FLD_MOD(r, aud_fmt->stereo_channels, 26, 24); + r = FLD_MOD(r, aud_fmt->active_chnnls_msk, 23, 16); + } r = FLD_MOD(r, aud_fmt->en_sig_blk_strt_end, 5, 5); r = FLD_MOD(r, aud_fmt->type, 4, 4); r = FLD_MOD(r, aud_fmt->justification, 3, 3);
The hdmi_wp_audio_config_format() expects sample_order of struct hdmi_audio_format to be initialized. The only allowed value is HDMI_AUDIO_SAMPLE_LEFT_FIRST.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi5_core.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c index 83acbf7..9ffa805 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c @@ -879,6 +879,9 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, /* only LPCM atm */ audio_format.type = HDMI_AUDIO_TYPE_LPCM;
+ /* only allowed option */ + audio_format.sample_order = HDMI_AUDIO_SAMPLE_LEFT_FIRST; + /* disable start/stop signals of IEC 60958 blocks */ audio_format.en_sig_blk_strt_end = HDMI_AUDIO_BLOCK_SIG_STARTEND_ON;
The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in hdmi_core_audio_layout enum. I found the correct value from ti-linux 3.8 tree.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 262771b..1f01068 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -160,7 +160,8 @@ enum hdmi_audio_blk_strt_end_sig {
enum hdmi_core_audio_layout { HDMI_AUDIO_LAYOUT_2CH = 0, - HDMI_AUDIO_LAYOUT_8CH = 1 + HDMI_AUDIO_LAYOUT_8CH = 1, + HDMI_AUDIO_LAYOUT_6CH = 2 };
enum hdmi_core_cts_mode {
It does not waste too many bytes to compile all audio related core functions always in with HDMI support. It should help readability and in keeping the audio code in working shape. Leave the options just for disabling and enabling the functionality in hdmi[45].c.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi.h | 3 +-- drivers/video/fbdev/omap2/dss/hdmi4_core.c | 5 ----- drivers/video/fbdev/omap2/dss/hdmi4_core.h | 2 -- drivers/video/fbdev/omap2/dss/hdmi5_core.c | 6 ------ drivers/video/fbdev/omap2/dss/hdmi5_core.h | 2 -- drivers/video/fbdev/omap2/dss/hdmi_common.c | 2 -- drivers/video/fbdev/omap2/dss/hdmi_wp.c | 2 -- 7 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 1f01068..03726b5 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -335,7 +335,7 @@ int hdmi_phy_parse_lanes(struct hdmi_phy_data *phy, const u32 *lanes); int hdmi_parse_lanes_of(struct platform_device *pdev, struct device_node *ep, struct hdmi_phy_data *phy);
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) +/* Audio funcs */ int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts); int hdmi_wp_audio_enable(struct hdmi_wp_data *wp, bool enable); int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable); @@ -348,4 +348,3 @@ static inline bool hdmi_mode_has_audio(int mode) return mode == HDMI_HDMI ? true : false; } #endif -#endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/dss/hdmi4_core.c index 4ad39cf..3b448d9 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.c @@ -31,10 +31,8 @@ #include <linux/platform_device.h> #include <linux/string.h> #include <linux/seq_file.h> -#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) #include <sound/asound.h> #include <sound/asoundef.h> -#endif
#include "hdmi4_core.h" #include "dss_features.h" @@ -530,7 +528,6 @@ void hdmi4_core_dump(struct hdmi_core_data *core, struct seq_file *s) DUMPCOREAV(HDMI_CORE_AV_CEC_ADDR_ID); }
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) static void hdmi_core_audio_config(struct hdmi_core_data *core, struct hdmi_core_audio_config *cfg) { @@ -886,8 +883,6 @@ int hdmi4_audio_get_dma_port(u32 *offset, u32 *size) return 0; }
-#endif - int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core) { struct resource *res; diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.h b/drivers/video/fbdev/omap2/dss/hdmi4_core.h index 827909e..c1959f7 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.h +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.h @@ -266,12 +266,10 @@ void hdmi4_configure(struct hdmi_core_data *core, struct hdmi_wp_data *wp, void hdmi4_core_dump(struct hdmi_core_data *core, struct seq_file *s); int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core);
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) int hdmi4_audio_start(struct hdmi_core_data *core, struct hdmi_wp_data *wp); void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp); int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct omap_dss_audio *audio, u32 pclk); int hdmi4_audio_get_dma_port(u32 *offset, u32 *size); -#endif
#endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c index 9ffa805..a711579 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c @@ -30,10 +30,8 @@ #include <linux/string.h> #include <linux/seq_file.h> #include <drm/drm_edid.h> -#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) #include <sound/asound.h> #include <sound/asoundef.h> -#endif
#include "hdmi5_core.h"
@@ -644,9 +642,6 @@ void hdmi5_configure(struct hdmi_core_data *core, struct hdmi_wp_data *wp, hdmi_core_enable_interrupts(core); }
- -#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) - static void hdmi5_core_audio_config(struct hdmi_core_data *core, struct hdmi_core_audio_config *cfg) { @@ -897,7 +892,6 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp,
return 0; } -#endif
int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data *core) { diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.h b/drivers/video/fbdev/omap2/dss/hdmi5_core.h index ce7e9f3..f2f1022 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.h +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.h @@ -299,8 +299,6 @@ void hdmi5_configure(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct hdmi_config *cfg); int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data *core);
-#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct omap_dss_audio *audio, u32 pclk); #endif -#endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi_common.c b/drivers/video/fbdev/omap2/dss/hdmi_common.c index 7d5f103..1b8fcc6 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi_common.c +++ b/drivers/video/fbdev/omap2/dss/hdmi_common.c @@ -48,7 +48,6 @@ int hdmi_parse_lanes_of(struct platform_device *pdev, struct device_node *ep, return 0; }
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts) { u32 deep_color; @@ -147,4 +146,3 @@ int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts)
return 0; } -#endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c b/drivers/video/fbdev/omap2/dss/hdmi_wp.c index 71b499e..4ead962 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c +++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c @@ -185,7 +185,6 @@ void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt, timings->interlace = param->timings.interlace; }
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp, struct hdmi_audio_format *aud_fmt) { @@ -240,7 +239,6 @@ int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable)
return 0; } -#endif
int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp) {
hdmi4_audio_get_dma_port() is unused and and broken.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi4_core.c | 9 --------- drivers/video/fbdev/omap2/dss/hdmi4_core.h | 2 -- 2 files changed, 11 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/dss/hdmi4_core.c index 3b448d9..7eafea5 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.c @@ -874,15 +874,6 @@ void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp) hdmi_wp_audio_core_req_enable(wp, false); }
-int hdmi4_audio_get_dma_port(u32 *offset, u32 *size) -{ - if (!offset || !size) - return -EINVAL; - *offset = HDMI_WP_AUDIO_DATA; - *size = 4; - return 0; -} - int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core) { struct resource *res; diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.h b/drivers/video/fbdev/omap2/dss/hdmi4_core.h index c1959f7..a069f96 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.h +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.h @@ -270,6 +270,4 @@ int hdmi4_audio_start(struct hdmi_core_data *core, struct hdmi_wp_data *wp); void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp); int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct omap_dss_audio *audio, u32 pclk); -int hdmi4_audio_get_dma_port(u32 *offset, u32 *size); - #endif
The audio dma port is found in the hdmi_wp physical address space.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi.h | 2 ++ drivers/video/fbdev/omap2/dss/hdmi_wp.c | 6 ++++++ 2 files changed, 8 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 03726b5..9ba7c1a 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -250,6 +250,7 @@ struct hdmi_core_audio_config {
struct hdmi_wp_data { void __iomem *base; + phys_addr_t phys_base; };
struct hdmi_pll_data { @@ -317,6 +318,7 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp, void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt, struct omap_video_timings *timings, struct hdmi_config *param); int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp); +phys_addr_t hdmi_wp_get_audio_dma_addr(struct hdmi_wp_data *wp);
/* HDMI PLL funcs */ int hdmi_pll_enable(struct hdmi_pll_data *pll, struct hdmi_wp_data *wp); diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c b/drivers/video/fbdev/omap2/dss/hdmi_wp.c index 4ead962..c15377e 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c +++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c @@ -249,6 +249,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp) DSSERR("can't get WP mem resource\n"); return -EINVAL; } + wp->phys_base = res->start;
wp->base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(wp->base)) { @@ -258,3 +259,8 @@ int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp)
return 0; } + +phys_addr_t hdmi_wp_get_audio_dma_addr(struct hdmi_wp_data *wp) +{ + return wp->phys_base + HDMI_WP_AUDIO_DATA; +}
Unify the private anonymous struct in hdmi4.c and hdmi5.c, name it as struct omap_hdmi, and make it public in hdmi.h.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi.h | 21 +++++++++++++++++++++ drivers/video/fbdev/omap2/dss/hdmi4.c | 31 ++++++++----------------------- drivers/video/fbdev/omap2/dss/hdmi5.c | 20 ++------------------ 3 files changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 9ba7c1a..6bf077b 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -349,4 +349,25 @@ static inline bool hdmi_mode_has_audio(int mode) { return mode == HDMI_HDMI ? true : false; } + +/* HDMI DRV data */ +struct omap_hdmi { + struct mutex lock; + struct platform_device *pdev; + + struct hdmi_wp_data wp; + struct hdmi_pll_data pll; + struct hdmi_phy_data phy; + struct hdmi_core_data core; + + struct hdmi_config cfg; + + struct clk *sys_clk; + struct regulator *vdda_reg; + + bool core_enabled; + + struct omap_dss_device output; +}; + #endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c index 9a8713c..764443e 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4.c @@ -37,25 +37,9 @@ #include "hdmi4_core.h" #include "dss.h" #include "dss_features.h" +#include "hdmi.h"
-static struct { - struct mutex lock; - struct platform_device *pdev; - - struct hdmi_wp_data wp; - struct hdmi_pll_data pll; - struct hdmi_phy_data phy; - struct hdmi_core_data core; - - struct hdmi_config cfg; - - struct clk *sys_clk; - struct regulator *vdda_hdmi_dac_reg; - - bool core_enabled; - - struct omap_dss_device output; -} hdmi; +static struct omap_hdmi hdmi;
static int hdmi_runtime_get(void) { @@ -117,7 +101,7 @@ static int hdmi_init_regulator(void) int r; struct regulator *reg;
- if (hdmi.vdda_hdmi_dac_reg != NULL) + if (hdmi.vdda_reg != NULL) return 0;
reg = devm_regulator_get(&hdmi.pdev->dev, "vdda"); @@ -137,7 +121,7 @@ static int hdmi_init_regulator(void) } }
- hdmi.vdda_hdmi_dac_reg = reg; + hdmi.vdda_reg = reg;
return 0; } @@ -146,7 +130,7 @@ static int hdmi_power_on_core(struct omap_dss_device *dssdev) { int r;
- r = regulator_enable(hdmi.vdda_hdmi_dac_reg); + r = regulator_enable(hdmi.vdda_reg); if (r) return r;
@@ -162,7 +146,7 @@ static int hdmi_power_on_core(struct omap_dss_device *dssdev) return 0;
err_runtime_get: - regulator_disable(hdmi.vdda_hdmi_dac_reg); + regulator_disable(hdmi.vdda_reg);
return r; } @@ -172,7 +156,7 @@ static void hdmi_power_off_core(struct omap_dss_device *dssdev) hdmi.core_enabled = false;
hdmi_runtime_put(); - regulator_disable(hdmi.vdda_hdmi_dac_reg); + regulator_disable(hdmi.vdda_reg); }
static int hdmi_power_on_full(struct omap_dss_device *dssdev) @@ -678,6 +662,7 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev) int irq;
hdmi.pdev = pdev; + dev_set_drvdata(&pdev->dev, &hdmi);
mutex_init(&hdmi.lock);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index 169b764..694cdee 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c @@ -43,24 +43,7 @@ #include "dss.h" #include "dss_features.h"
-static struct { - struct mutex lock; - struct platform_device *pdev; - - struct hdmi_wp_data wp; - struct hdmi_pll_data pll; - struct hdmi_phy_data phy; - struct hdmi_core_data core; - - struct hdmi_config cfg; - - struct clk *sys_clk; - struct regulator *vdda_reg; - - bool core_enabled; - - struct omap_dss_device output; -} hdmi; +static struct omap_hdmi hdmi;
static int hdmi_runtime_get(void) { @@ -703,6 +686,7 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev) int irq;
hdmi.pdev = pdev; + dev_set_drvdata(&pdev->dev, &hdmi);
mutex_init(&hdmi.lock);
This is used to store omap-hdmi-audio pdev for unregistering it.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 6bf077b..a6e08ff 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -368,6 +368,8 @@ struct omap_hdmi { bool core_enabled;
struct omap_dss_device output; + + struct platform_device *audio_pdev; };
#endif
The platform device should only be registered from OMAPDSS HDMI driver. The platform driver registers and unregisters all ASoC components needed for OMAP HDMI audio.
The hdmi 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 codec is used as as codec component. The hdmi audio driver implements also the card and registers it under its own platform device.
Signed-off-by: Jyri Sarha jsarha@ti.com --- include/sound/omap-hdmi-audio.h | 43 ++++ sound/soc/omap/Kconfig | 15 ++ sound/soc/omap/Makefile | 2 + sound/soc/omap/omap-hdmi-audio.c | 407 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 467 insertions(+) create mode 100644 include/sound/omap-hdmi-audio.h create mode 100644 sound/soc/omap/omap-hdmi-audio.c
diff --git a/include/sound/omap-hdmi-audio.h b/include/sound/omap-hdmi-audio.h new file mode 100644 index 0000000..afdb416 --- /dev/null +++ b/include/sound/omap-hdmi-audio.h @@ -0,0 +1,43 @@ +/* + * hdmi-audio.c -- OMAP4+ DSS HDMI audio support library + * + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com + * + * Author: Jyri Sarha jsarha@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + */ + +#include <video/omapdss.h> + +#ifndef __OMAP_HDMI_AUDIO_H__ +#define __OMAP_HDMI_AUDIO_H__ + +struct omap_hdmi_audio_ops { + int (*audio_startup)(struct device *dev, + void (*abort_cb)(struct device *dev)); + int (*audio_shutdown)(struct device *dev); + int (*audio_start)(struct device *dev); + void (*audio_stop)(struct device *dev); + int (*audio_config)(struct device *dev, + struct omap_dss_audio *dss_audio); +}; + +/* HDMI audio initalization data */ +struct omap_hdmi_audio_pdata { + struct device *dev; + enum omapdss_version dss_version; + phys_addr_t audio_dma_addr; + + const struct omap_hdmi_audio_ops *ops; +}; + +#endif /* __OMAP_HDMI_AUDIO_H__ */ diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index d44463a..2b32b3e 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -15,6 +15,21 @@ config SND_OMAP_SOC_MCPDM config SND_OMAP_SOC_HDMI tristate
+config SND_OMAP_SOC_HDMI_AUDIO + tristate "HDMI audio support for OMAP4+ based SoCs" + depends on SND_OMAP_SOC + help + For HDMI audio to work OMAPDSS HDMI support should be + enabled. + The hdmi 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 codec is used as + as codec component. The hdmi audio driver implements also + the card and registers it under its own platform device. + The device for the dirver is registered by OMAPDSS hdmi + driver. + config SND_OMAP_SOC_N810 tristate "SoC Audio support for Nokia N810" depends on SND_OMAP_SOC && MACH_NOKIA_N810 && I2C diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index a725905..40688a6 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -4,12 +4,14 @@ snd-soc-omap-dmic-objs := omap-dmic.o snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o snd-soc-omap-mcpdm-objs := omap-mcpdm.o snd-soc-omap-hdmi-objs := omap-hdmi.o +snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o
obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o obj-$(CONFIG_SND_OMAP_SOC_HDMI) += snd-soc-omap-hdmi.o +obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o
# OMAP Machine Support snd-soc-n810-objs := n810.o diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c new file mode 100644 index 0000000..3f9ac7d --- /dev/null +++ b/sound/soc/omap/omap-hdmi-audio.c @@ -0,0 +1,407 @@ +/* + * omap-hdmi-audio.c -- OMAP4+ DSS HDMI audio support library + * + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com + * + * Author: Jyri Sarha jsarha@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/err.h> +#include <linux/string.h> +#include <linux/platform_device.h> +#include <sound/soc.h> +#include <sound/pcm_params.h> +#include <sound/dmaengine_pcm.h> +#include <uapi/sound/asound.h> +#include <sound/asoundef.h> +#include <sound/omap-pcm.h> +#include <sound/omap-hdmi-audio.h> +#include <video/omapdss.h> + +#define DRV_NAME "omap-hdmi-audio" + +struct hdmi_audio_data { + struct snd_soc_card *card; + + const struct omap_hdmi_audio_ops *ops; + struct device *dssdev; + struct snd_dmaengine_dai_dma_data dma_data; + struct omap_dss_audio dss_audio; + struct snd_aes_iec958 iec; + struct snd_cea_861_aud_if cea; + + struct mutex current_stream_lock; + struct snd_pcm_substream *current_stream; +}; + +static +struct hdmi_audio_data *card_drvdata_substream(struct snd_pcm_substream *ss) +{ + struct snd_soc_pcm_runtime *rtd = ss->private_data; + + return snd_soc_card_get_drvdata(rtd->card); +} + +static void hdmi_dai_abort(struct device *dev) +{ + struct hdmi_audio_data *ad = dev_get_drvdata(dev); + + mutex_lock(&ad->current_stream_lock); + if (ad->current_stream && ad->current_stream->runtime && + snd_pcm_running(ad->current_stream)) { + dev_err(dev, "HDMI display disabled, aborting playback\n"); + snd_pcm_stream_lock_irq(ad->current_stream); + snd_pcm_stop(ad->current_stream, SNDRV_PCM_STATE_DISCONNECTED); + snd_pcm_stream_unlock_irq(ad->current_stream); + } + mutex_unlock(&ad->current_stream_lock); +} + +static int hdmi_dai_startup(struct snd_pcm_substream *substream, + struct snd_soc_dai *dai) +{ + struct hdmi_audio_data *ad = card_drvdata_substream(substream); + int ret; + /* + * Make sure that the period bytes are multiple of the DMA packet size. + * Largest packet size we use is 32 32-bit words = 128 bytes + */ + ret = snd_pcm_hw_constraint_step(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 128); + if (ret < 0) { + dev_err(dai->dev, "could not apply constraint\n"); + return ret; + } + + snd_soc_dai_set_dma_data(dai, substream, &ad->dma_data); + + mutex_lock(&ad->current_stream_lock); + ad->current_stream = substream; + mutex_unlock(&ad->current_stream_lock); + + ret = ad->ops->audio_startup(ad->dssdev, hdmi_dai_abort); + + if (ret) { + mutex_lock(&ad->current_stream_lock); + ad->current_stream = NULL; + mutex_unlock(&ad->current_stream_lock); + } + + return ret; +} + +static int hdmi_dai_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params, + struct snd_soc_dai *dai) +{ + struct hdmi_audio_data *ad = card_drvdata_substream(substream); + struct snd_aes_iec958 *iec = &ad->iec; + struct snd_cea_861_aud_if *cea = &ad->cea; + + WARN_ON(ad->current_stream != substream); + + switch (params_format(params)) { + case SNDRV_PCM_FORMAT_S16_LE: + ad->dma_data.maxburst = 16; + break; + case SNDRV_PCM_FORMAT_S24_LE: + ad->dma_data.maxburst = 32; + break; + default: + dev_err(dai->dev, "format not supported!\n"); + return -EINVAL; + } + + ad->dss_audio.iec = iec; + ad->dss_audio.cea = cea; + /* + * fill the IEC-60958 channel status word + */ + /* initialize the word bytes */ + memset(iec->status, 0, sizeof(iec->status)); + + /* specify IEC-60958-3 (commercial use) */ + iec->status[0] &= ~IEC958_AES0_PROFESSIONAL; + + /* specify that the audio is LPCM*/ + iec->status[0] &= ~IEC958_AES0_NONAUDIO; + + iec->status[0] |= IEC958_AES0_CON_NOT_COPYRIGHT; + + iec->status[0] |= IEC958_AES0_CON_EMPHASIS_NONE; + + iec->status[0] |= IEC958_AES1_PRO_MODE_NOTID; + + iec->status[1] = IEC958_AES1_CON_GENERAL; + + iec->status[2] |= IEC958_AES2_CON_SOURCE_UNSPEC; + + iec->status[2] |= IEC958_AES2_CON_CHANNEL_UNSPEC; + + switch (params_rate(params)) { + case 32000: + iec->status[3] |= IEC958_AES3_CON_FS_32000; + break; + case 44100: + iec->status[3] |= IEC958_AES3_CON_FS_44100; + break; + case 48000: + iec->status[3] |= IEC958_AES3_CON_FS_48000; + break; + case 88200: + iec->status[3] |= IEC958_AES3_CON_FS_88200; + break; + case 96000: + iec->status[3] |= IEC958_AES3_CON_FS_96000; + break; + case 176400: + iec->status[3] |= IEC958_AES3_CON_FS_176400; + break; + case 192000: + iec->status[3] |= IEC958_AES3_CON_FS_192000; + break; + default: + dev_err(dai->dev, "rate not supported!\n"); + return -EINVAL; + } + + /* specify the clock accuracy */ + iec->status[3] |= IEC958_AES3_CON_CLOCK_1000PPM; + + /* + * specify the word length. The same word length value can mean + * two different lengths. Hence, we need to specify the maximum + * word length as well. + */ + switch (params_format(params)) { + case SNDRV_PCM_FORMAT_S16_LE: + iec->status[4] |= IEC958_AES4_CON_WORDLEN_20_16; + iec->status[4] &= ~IEC958_AES4_CON_MAX_WORDLEN_24; + break; + case SNDRV_PCM_FORMAT_S24_LE: + iec->status[4] |= IEC958_AES4_CON_WORDLEN_24_20; + iec->status[4] |= IEC958_AES4_CON_MAX_WORDLEN_24; + break; + default: + dev_err(dai->dev, "format not supported!\n"); + return -EINVAL; + } + + /* + * Fill the CEA-861 audio infoframe (see spec for details) + */ + + cea->db1_ct_cc = (params_channels(params) - 1) + & CEA861_AUDIO_INFOFRAME_DB1CC; + cea->db1_ct_cc |= CEA861_AUDIO_INFOFRAME_DB1CT_FROM_STREAM; + + cea->db2_sf_ss = CEA861_AUDIO_INFOFRAME_DB2SF_FROM_STREAM; + cea->db2_sf_ss |= CEA861_AUDIO_INFOFRAME_DB2SS_FROM_STREAM; + + cea->db3 = 0; /* not used, all zeros */ + + /* + * The OMAP HDMI IP requires to use the 8-channel channel code when + * transmitting more than two channels. + */ + if (params_channels(params) == 2) + cea->db4_ca = 0x0; + else + cea->db4_ca = 0x13; + + cea->db5_dminh_lsv = CEA861_AUDIO_INFOFRAME_DB5_DM_INH_PROHIBITED; + /* the expression is trivial but makes clear what we are doing */ + cea->db5_dminh_lsv |= (0 & CEA861_AUDIO_INFOFRAME_DB5_LSV); + + return ad->ops->audio_config(ad->dssdev, &ad->dss_audio); +} + +static int hdmi_dai_trigger(struct snd_pcm_substream *substream, int cmd, + struct snd_soc_dai *dai) +{ + struct hdmi_audio_data *ad = card_drvdata_substream(substream); + int err = 0; + + WARN_ON(ad->current_stream != substream); + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_RESUME: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + err = ad->ops->audio_start(ad->dssdev); + break; + case SNDRV_PCM_TRIGGER_STOP: + case SNDRV_PCM_TRIGGER_SUSPEND: + case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + ad->ops->audio_stop(ad->dssdev); + break; + default: + err = -EINVAL; + } + return err; +} + +static void hdmi_dai_shutdown(struct snd_pcm_substream *substream, + struct snd_soc_dai *dai) +{ + struct hdmi_audio_data *ad = card_drvdata_substream(substream); + + WARN_ON(ad->current_stream != substream); + + ad->ops->audio_shutdown(ad->dssdev); + + mutex_lock(&ad->current_stream_lock); + ad->current_stream = NULL; + mutex_unlock(&ad->current_stream_lock); +} + +static const struct snd_soc_dai_ops hdmi_dai_ops = { + .startup = hdmi_dai_startup, + .hw_params = hdmi_dai_hw_params, + .trigger = hdmi_dai_trigger, + .shutdown = hdmi_dai_shutdown, +}; + +static const struct snd_soc_component_driver omap_hdmi_component = { + .name = "omapdss_hdmi", +}; + +static struct snd_soc_dai_driver omap5_hdmi_dai = { + .name = "omap5-hdmi-dai", + .playback = { + .channels_min = 2, + .channels_max = 8, + .rates = (SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | + SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | + SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_176400 | + SNDRV_PCM_RATE_192000), + .formats = SNDRV_PCM_FMTBIT_S16_LE, + }, + .ops = &hdmi_dai_ops, +}; + +static struct snd_soc_dai_driver omap4_hdmi_dai = { + .name = "omap4-hdmi-dai", + .playback = { + .channels_min = 2, + .channels_max = 8, + .rates = (SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | + SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | + SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_176400 | + SNDRV_PCM_RATE_192000), + .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE, + }, + .ops = &hdmi_dai_ops, +}; + +static int omap_hdmi_audio_probe(struct platform_device *pdev) +{ + struct omap_hdmi_audio_pdata *ha = pdev->dev.platform_data; + struct device *dev = &pdev->dev; + struct hdmi_audio_data *ad; + struct snd_soc_dai_driver *dai_drv; + struct snd_soc_card *card; + int ret; + + if (!ha) { + dev_err(dev, "No platform data\n"); + return -EINVAL; + } + + ad = devm_kzalloc(dev, sizeof(*ad), GFP_KERNEL); + if (!ad) + return -ENOMEM; + ad->dssdev = ha->dev; + ad->ops = ha->ops; + ad->dma_data.addr = ha->audio_dma_addr; + ad->dma_data.filter_data = "audio_tx"; + ad->dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; + mutex_init(&ad->current_stream_lock); + + switch (ha->dss_version) { + case OMAPDSS_VER_OMAP4430_ES1: + case OMAPDSS_VER_OMAP4430_ES2: + case OMAPDSS_VER_OMAP4: + dai_drv = &omap4_hdmi_dai; + break; + case OMAPDSS_VER_OMAP5: + dai_drv = &omap5_hdmi_dai; + break; + default: + return -EINVAL; + } + ret = snd_soc_register_component(ad->dssdev, &omap_hdmi_component, + dai_drv, 1); + if (ret) + return ret; + + ret = omap_pcm_platform_register(ad->dssdev); + if (ret) + return ret; + + card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL); + card->name = devm_kasprintf(dev, GFP_KERNEL, + "HDMI %s", dev_name(ad->dssdev)); + card->owner = THIS_MODULE; + card->dai_link = + devm_kzalloc(dev, sizeof(*(card->dai_link)), GFP_KERNEL); + card->dai_link->name = card->name; + card->dai_link->stream_name = card->name; + card->dai_link->cpu_dai_name = dev_name(ad->dssdev); + card->dai_link->platform_name = dev_name(ad->dssdev); + card->dai_link->codec_name = "snd-soc-dummy"; + card->dai_link->codec_dai_name = "snd-soc-dummy-dai"; + card->num_links = 1; + card->dev = dev; + + ret = snd_soc_register_card(card); + if (ret) { + dev_err(dev, "snd_soc_register_card failed (%d)\n", ret); + snd_soc_unregister_component(ad->dssdev); + return ret; + } + + ad->card = card; + snd_soc_card_set_drvdata(card, ad); + + dev_set_drvdata(dev, ad); + + return 0; +} + +static int omap_hdmi_audio_remove(struct platform_device *pdev) +{ + struct hdmi_audio_data *ad = platform_get_drvdata(pdev); + + snd_soc_unregister_card(ad->card); + snd_soc_unregister_component(ad->dssdev); + return 0; +} + +static struct platform_driver hdmi_audio_driver = { + .driver = { + .name = DRV_NAME, + .owner = THIS_MODULE, + }, + .probe = omap_hdmi_audio_probe, + .remove = omap_hdmi_audio_remove, +}; + +module_platform_driver(hdmi_audio_driver); + +MODULE_AUTHOR("Jyri Sarha jsarha@ti.com"); +MODULE_DESCRIPTION("OMAP HDMI Audio Driver"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:" DRV_NAME);
On Wed, Nov 12, 2014 at 04:41:00PM +0200, Jyri Sarha wrote:
The platform device should only be registered from OMAPDSS HDMI driver. The platform driver registers and unregisters all ASoC components needed for OMAP HDMI audio.
So, this basically seems fine but I'm looking at this code and I'm not really seeing a huge amount of OMAP specificness here. Why is this an OMAP driver and not something more generic - can't we have other HDMI controllers offering the same interface? There's a few serial numbers that would need filing off but since the ASoC driver is basically just interface matching and not talking to the hardware it looks like it ought to be usable by more than just OMAP.
On 11/29/2014 01:32 PM, Mark Brown wrote:
On Wed, Nov 12, 2014 at 04:41:00PM +0200, Jyri Sarha wrote:
The platform device should only be registered from OMAPDSS HDMI driver. The platform driver registers and unregisters all ASoC components needed for OMAP HDMI audio.
So, this basically seems fine but I'm looking at this code and I'm not really seeing a huge amount of OMAP specificness here. Why is this an OMAP driver and not something more generic - can't we have other HDMI controllers offering the same interface? There's a few serial numbers that would need filing off but since the ASoC driver is basically just interface matching and not talking to the hardware it looks like it ought to be usable by more than just OMAP.
The only reason is that I have not encountered any other audio capable HDMI device falling in this category (cpu-dai integrated within HDMI device block). Without at least two devices utilizing this code it remains questionable whether the code is really generic. At least the dss_version should be replaced with some explicit data to fill struct snd_soc_dai_driver. Also struct omap_dss_audio is coming directly from omap dss code, its contents is generic but I am not sure if the information within struct snd_aes_iec958 and struct snd_cea_861_aud_if is enough to configure the HDMI IP in all possible cases.
I can work on making this API look more generic, but before there is another candidate to use this API it is questionable if the code will ever be used by any other device.
Best regards, Jyri
On Mon, Dec 01, 2014 at 09:15:36AM +0200, Jyri Sarha wrote:
The only reason is that I have not encountered any other audio capable HDMI device falling in this category (cpu-dai integrated within HDMI device block). Without at least two devices utilizing this code it remains questionable whether the code is really generic. At least the dss_version should be replaced with some explicit data to fill struct snd_soc_dai_driver. Also struct omap_dss_audio is coming directly from omap dss code, its contents is generic but I am not sure if the information within struct snd_aes_iec958 and struct snd_cea_861_aud_if is enough to configure the HDMI IP in all possible cases.
It should be no big deal to add extra information if required. Given how poor the upstreaming state is for HDMI I expect we'd get people coming out of the woodwork if there were infrastructure, some of the Exynos stuff looked similar to your situation for example.
I can work on making this API look more generic, but before there is another candidate to use this API it is questionable if the code will ever be used by any other device.
Unless there is something obviously terrible about the hardware design that I'm missing which means nobody else would ever have implemented something like it I'd expect there will be at least one other system that can make use of the code.
The booleans are not used anymore. Just select SND_OMAP_SOC_HDMI_AUDIO to enable OMAP HDMI audio support.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig | 7 ------- 1 file changed, 7 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 3d5eb6c..d1fa730 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -74,9 +74,6 @@ config OMAP4_DSS_HDMI help HDMI support for OMAP4 based SoCs.
-config OMAP4_DSS_HDMI_AUDIO - bool - config OMAP5_DSS_HDMI bool "HDMI support for OMAP5" default n @@ -86,10 +83,6 @@ config OMAP5_DSS_HDMI Definition Multimedia Interface. See http://www.hdmi.org/ for HDMI specification.
-config OMAP5_DSS_HDMI_AUDIO - depends on OMAP5_DSS_HDMI - bool - config OMAP2_DSS_SDI bool "SDI support" default n
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index a6e08ff..6d129f2 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp, struct hdmi_audio_format *aud_fmt); void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp, struct hdmi_audio_dma *aud_dma); -static inline bool hdmi_mode_has_audio(int mode) +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg) { - return mode == HDMI_HDMI ? true : false; + return cfg->hdmi_dvi_mode == HDMI_HDMI ? true : false; }
/* HDMI DRV data */
Hi Jyri,
On 12.11.2014 16:41, Jyri Sarha wrote:
Signed-off-by: Jyri Sarha jsarha@ti.com
drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index a6e08ff..6d129f2 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp, struct hdmi_audio_format *aud_fmt); void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp, struct hdmi_audio_dma *aud_dma); -static inline bool hdmi_mode_has_audio(int mode) +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg) {
- return mode == HDMI_HDMI ? true : false;
- return cfg->hdmi_dvi_mode == HDMI_HDMI ? true : false;
}
/* HDMI DRV data */
would it be possible for you to rearrange the changes preserving the following sequence?
1) 13/19 2) 15/19 3) 11/19 4) 14/19 5) 16/19
Otherwise I'm worried that someone's git rebase may fail.
-- With best wishes, Vladimir
On 11/14/2014 04:37 PM, Vladimir Zapolskiy wrote:
Hi Jyri,
On 12.11.2014 16:41, Jyri Sarha wrote:
Signed-off-by: Jyri Sarha jsarha@ti.com
drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index a6e08ff..6d129f2 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp, struct hdmi_audio_format *aud_fmt); void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp, struct hdmi_audio_dma *aud_dma); -static inline bool hdmi_mode_has_audio(int mode) +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg) {
- return mode == HDMI_HDMI ? true : false;
return cfg->hdmi_dvi_mode == HDMI_HDMI ? true : false; }
/* HDMI DRV data */
would it be possible for you to rearrange the changes preserving the following sequence?
- 13/19
- 15/19
- 11/19
- 14/19
- 16/19
Sure, I can do that. Everything should be fine in that order too.
Otherwise I'm worried that someone's git rebase may fail.
But do not follow why. Did you notice that 10/19 removes the config options that enable the pieces of code that are deleted in 13/19 and 15/19. IOW, the code that uses hdmi_mode_has_audio() (and would become broken by 11/19) is already disabled by 10/19. Git-wise I see no problem either.
I'll rearrange the patches if you still insist there is a problem with current order, but I would like to understand why.
Best regards, Jyri
Hi Jyri,
On 14.11.2014 17:05, Jyri Sarha wrote:
On 11/14/2014 04:37 PM, Vladimir Zapolskiy wrote:
Hi Jyri,
On 12.11.2014 16:41, Jyri Sarha wrote:
Signed-off-by: Jyri Sarha jsarha@ti.com
drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index a6e08ff..6d129f2 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp, struct hdmi_audio_format *aud_fmt); void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp, struct hdmi_audio_dma *aud_dma); -static inline bool hdmi_mode_has_audio(int mode) +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg) {
- return mode == HDMI_HDMI ? true : false;
return cfg->hdmi_dvi_mode == HDMI_HDMI ? true : false; }
/* HDMI DRV data */
would it be possible for you to rearrange the changes preserving the following sequence?
- 13/19
- 15/19
- 11/19
- 14/19
- 16/19
Sure, I can do that. Everything should be fine in that order too.
Otherwise I'm worried that someone's git rebase may fail.
sorry again, I meant git-bisect, git rebase is fine.
But do not follow why. Did you notice that 10/19 removes the config options that enable the pieces of code that are deleted in 13/19 and 15/19. IOW, the code that uses hdmi_mode_has_audio() (and would become broken by 11/19) is already disabled by 10/19. Git-wise I see no problem either.
Right, I was worried by changed hdmi_mode_has_audio() API and still present source code, which uses the old API (it is fixed in the following patches). If the code that uses hdmi_mode_has_audio() is disabled by 10/19 and the kernel can be successfully compiled and working on partial application of the changeset, then there should be no problem with git-bisect, and probably no need to rearrange the commits.
I'll rearrange the patches if you still insist there is a problem with current order, but I would like to understand why.
-- With best wishes, Vladimir
Hi Jyri,
On 14.11.2014 16:37, Vladimir Zapolskiy wrote:
Hi Jyri,
On 12.11.2014 16:41, Jyri Sarha wrote:
Signed-off-by: Jyri Sarha jsarha@ti.com
drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index a6e08ff..6d129f2 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp, struct hdmi_audio_format *aud_fmt); void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp, struct hdmi_audio_dma *aud_dma); -static inline bool hdmi_mode_has_audio(int mode) +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg) {
- return mode == HDMI_HDMI ? true : false;
- return cfg->hdmi_dvi_mode == HDMI_HDMI ? true : false;
}
/* HDMI DRV data */
would it be possible for you to rearrange the changes preserving the following sequence?
- 13/19
- 15/19
- 11/19
- 14/19
- 16/19
Otherwise I'm worried that someone's git rebase may fail.
sorry, git bisect of course.
-- With best wishes, Vladimir
Adds display_enabled flag and audio_abort_cb callback to struct hdmi.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 6d129f2..bfaaf2f 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -366,10 +366,12 @@ struct omap_hdmi { struct regulator *vdda_reg;
bool core_enabled; + bool display_enabled;
struct omap_dss_device output;
struct platform_device *audio_pdev; + void (*audio_abort_cb)(struct device *dev); };
#endif
Removes the OMAP4 HDMI audio callbacks for the old external DAI driver.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi4.c | 113 --------------------------------- 1 file changed, 113 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c index 764443e..6f6764c 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4.c @@ -468,112 +468,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, return r; }
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) -static int hdmi_audio_enable(struct omap_dss_device *dssdev) -{ - int r; - - mutex_lock(&hdmi.lock); - - if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) { - r = -EPERM; - goto err; - } - - r = hdmi_wp_audio_enable(&hdmi.wp, true); - if (r) - goto err; - - mutex_unlock(&hdmi.lock); - return 0; - -err: - mutex_unlock(&hdmi.lock); - return r; -} - -static void hdmi_audio_disable(struct omap_dss_device *dssdev) -{ - hdmi_wp_audio_enable(&hdmi.wp, false); -} - -static int hdmi_audio_start(struct omap_dss_device *dssdev) -{ - return hdmi4_audio_start(&hdmi.core, &hdmi.wp); -} - -static void hdmi_audio_stop(struct omap_dss_device *dssdev) -{ - hdmi4_audio_stop(&hdmi.core, &hdmi.wp); -} - -static bool hdmi_audio_supported(struct omap_dss_device *dssdev) -{ - bool r; - - mutex_lock(&hdmi.lock); - - r = hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode); - - mutex_unlock(&hdmi.lock); - return r; -} - -static int hdmi_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - int r; - u32 pclk = hdmi.cfg.timings.pixelclock; - - mutex_lock(&hdmi.lock); - - if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) { - r = -EPERM; - goto err; - } - - r = hdmi4_audio_config(&hdmi.core, &hdmi.wp, audio, pclk); - if (r) - goto err; - - mutex_unlock(&hdmi.lock); - return 0; - -err: - mutex_unlock(&hdmi.lock); - return r; -} -#else -static int hdmi_audio_enable(struct omap_dss_device *dssdev) -{ - return -EPERM; -} - -static void hdmi_audio_disable(struct omap_dss_device *dssdev) -{ -} - -static int hdmi_audio_start(struct omap_dss_device *dssdev) -{ - return -EPERM; -} - -static void hdmi_audio_stop(struct omap_dss_device *dssdev) -{ -} - -static bool hdmi_audio_supported(struct omap_dss_device *dssdev) -{ - return false; -} - -static int hdmi_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - return -EPERM; -} -#endif - static int hdmi_set_infoframe(struct omap_dss_device *dssdev, const struct hdmi_avi_infoframe *avi) { @@ -602,13 +496,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = { .read_edid = hdmi_read_edid, .set_infoframe = hdmi_set_infoframe, .set_hdmi_mode = hdmi_set_hdmi_mode, - - .audio_enable = hdmi_audio_enable, - .audio_disable = hdmi_audio_disable, - .audio_start = hdmi_audio_start, - .audio_stop = hdmi_audio_stop, - .audio_supported = hdmi_audio_supported, - .audio_config = hdmi_audio_config, };
static void hdmi_init_output(struct platform_device *pdev)
Implements callbacks for OMAP HDMI audio platform driver and registers it in probe function. Unregistering is done in remove function.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi4.c | 125 +++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c index 6f6764c..28a55b2 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4.c @@ -33,6 +33,7 @@ #include <linux/gpio.h> #include <linux/regulator/consumer.h> #include <video/omapdss.h> +#include <sound/omap-hdmi-audio.h>
#include "hdmi4_core.h" #include "dss.h" @@ -336,6 +337,8 @@ static int hdmi_display_enable(struct omap_dss_device *dssdev) goto err0; }
+ hdmi.display_enabled = true; + mutex_unlock(&hdmi.lock); return 0;
@@ -350,8 +353,13 @@ static void hdmi_display_disable(struct omap_dss_device *dssdev)
mutex_lock(&hdmi.lock);
+ if (hdmi.audio_pdev && hdmi.audio_abort_cb) + hdmi.audio_abort_cb(&hdmi.audio_pdev->dev); + hdmi_power_off_full(dssdev);
+ hdmi.display_enabled = false; + mutex_unlock(&hdmi.lock); }
@@ -542,6 +550,112 @@ err: return r; }
+/* Audio callbacks */ +static int hdmi_audio_startup(struct device *dev, + void (*abort_cb)(struct device *dev)) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret = 0; + + mutex_lock(&hd->lock); + + if (!hdmi_mode_has_audio(&hd->cfg) || !hd->display_enabled) { + ret = -EPERM; + goto out; + } + + hd->audio_abort_cb = abort_cb; + +out: + mutex_unlock(&hd->lock); + + return ret; +} + +static int hdmi_audio_shutdown(struct device *dev) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + + mutex_lock(&hd->lock); + hd->audio_abort_cb = NULL; + mutex_unlock(&hd->lock); + + return 0; +} + +static int hdmi_audio_start(struct device *dev) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + + WARN_ON(!hdmi_mode_has_audio(&hd->cfg)); + WARN_ON(!hd->display_enabled); + + hdmi_wp_audio_enable(&hd->wp, true); + hdmi4_audio_start(&hd->core, &hd->wp); + + return 0; +} + +static void hdmi_audio_stop(struct device *dev) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + + WARN_ON(!hdmi_mode_has_audio(&hd->cfg)); + WARN_ON(!hd->display_enabled); + + hdmi4_audio_stop(&hd->core, &hd->wp); + hdmi_wp_audio_enable(&hd->wp, false); +} + +static int hdmi_audio_config(struct device *dev, + struct omap_dss_audio *dss_audio) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret; + + mutex_lock(&hd->lock); + + if (!hdmi_mode_has_audio(&hd->cfg) || !hd->display_enabled) { + ret = -EPERM; + goto out; + } + + ret = hdmi4_audio_config(&hd->core, &hd->wp, dss_audio, + hd->cfg.timings.pixelclock); + +out: + mutex_unlock(&hd->lock); + + return ret; +} + +static const struct omap_hdmi_audio_ops hdmi_audio_ops = { + .audio_startup = hdmi_audio_startup, + .audio_shutdown = hdmi_audio_shutdown, + .audio_start = hdmi_audio_start, + .audio_stop = hdmi_audio_stop, + .audio_config = hdmi_audio_config, +}; + +static int hdmi_audio_register(struct device *dev) +{ + struct omap_hdmi_audio_pdata pdata = { + .dev = dev, + .dss_version = omapdss_get_version(), + .audio_dma_addr = hdmi_wp_get_audio_dma_addr(&hdmi.wp), + .ops = &hdmi_audio_ops, + }; + + hdmi.audio_pdev = platform_device_register_data( + dev, "omap-hdmi-audio", PLATFORM_DEVID_AUTO, + &pdata, sizeof(pdata)); + + if (IS_ERR(hdmi.audio_pdev)) + return PTR_ERR(hdmi.audio_pdev); + + return 0; +} + /* HDMI HW IP initialisation */ static int omapdss_hdmihw_probe(struct platform_device *pdev) { @@ -599,6 +713,14 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
hdmi_init_output(pdev);
+ r = hdmi_audio_register(&pdev->dev); + if (r) { + DSSERR("Registering HDMI audio failed\n"); + hdmi_uninit_output(pdev); + pm_runtime_disable(&pdev->dev); + return r; + } + dss_debugfs_create_file("hdmi", hdmi_dump_regs);
return 0; @@ -606,6 +728,9 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
static int __exit omapdss_hdmihw_remove(struct platform_device *pdev) { + if (hdmi.audio_pdev) + platform_device_unregister(hdmi.audio_pdev); + hdmi_uninit_output(pdev);
pm_runtime_disable(&pdev->dev);
Removes the OMAP5 HDMI audio callbacks for the old external DAI driver.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi5.c | 113 --------------------------------- 1 file changed, 113 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index 694cdee..1b9c86a 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c @@ -492,112 +492,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, return r; }
-#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) -static int hdmi_audio_enable(struct omap_dss_device *dssdev) -{ - int r; - - mutex_lock(&hdmi.lock); - - if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) { - r = -EPERM; - goto err; - } - - r = hdmi_wp_audio_enable(&hdmi.wp, true); - if (r) - goto err; - - mutex_unlock(&hdmi.lock); - return 0; - -err: - mutex_unlock(&hdmi.lock); - return r; -} - -static void hdmi_audio_disable(struct omap_dss_device *dssdev) -{ - hdmi_wp_audio_enable(&hdmi.wp, false); -} - -static int hdmi_audio_start(struct omap_dss_device *dssdev) -{ - return hdmi_wp_audio_core_req_enable(&hdmi.wp, true); -} - -static void hdmi_audio_stop(struct omap_dss_device *dssdev) -{ - hdmi_wp_audio_core_req_enable(&hdmi.wp, false); -} - -static bool hdmi_audio_supported(struct omap_dss_device *dssdev) -{ - bool r; - - mutex_lock(&hdmi.lock); - - r = hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode); - - mutex_unlock(&hdmi.lock); - return r; -} - -static int hdmi_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - int r; - u32 pclk = hdmi.cfg.timings.pixelclock; - - mutex_lock(&hdmi.lock); - - if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) { - r = -EPERM; - goto err; - } - - r = hdmi5_audio_config(&hdmi.core, &hdmi.wp, audio, pclk); - if (r) - goto err; - - mutex_unlock(&hdmi.lock); - return 0; - -err: - mutex_unlock(&hdmi.lock); - return r; -} -#else -static int hdmi_audio_enable(struct omap_dss_device *dssdev) -{ - return -EPERM; -} - -static void hdmi_audio_disable(struct omap_dss_device *dssdev) -{ -} - -static int hdmi_audio_start(struct omap_dss_device *dssdev) -{ - return -EPERM; -} - -static void hdmi_audio_stop(struct omap_dss_device *dssdev) -{ -} - -static bool hdmi_audio_supported(struct omap_dss_device *dssdev) -{ - return false; -} - -static int hdmi_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - return -EPERM; -} -#endif - static int hdmi_set_infoframe(struct omap_dss_device *dssdev, const struct hdmi_avi_infoframe *avi) { @@ -626,13 +520,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = { .read_edid = hdmi_read_edid, .set_infoframe = hdmi_set_infoframe, .set_hdmi_mode = hdmi_set_hdmi_mode, - - .audio_enable = hdmi_audio_enable, - .audio_disable = hdmi_audio_disable, - .audio_start = hdmi_audio_start, - .audio_stop = hdmi_audio_stop, - .audio_supported = hdmi_audio_supported, - .audio_config = hdmi_audio_config, };
static void hdmi_init_output(struct platform_device *pdev)
Implements callbacks for OMAP HDMI audio platform driver and registers it in probe function. Unregistering is done in remove function.
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi5.c | 125 +++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index 1b9c86a..feb76e2 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c @@ -38,6 +38,7 @@ #include <linux/gpio.h> #include <linux/regulator/consumer.h> #include <video/omapdss.h> +#include <sound/omap-hdmi-audio.h>
#include "hdmi5_core.h" #include "dss.h" @@ -360,6 +361,8 @@ static int hdmi_display_enable(struct omap_dss_device *dssdev) goto err0; }
+ hdmi.display_enabled = true; + mutex_unlock(&hdmi.lock); return 0;
@@ -374,8 +377,13 @@ static void hdmi_display_disable(struct omap_dss_device *dssdev)
mutex_lock(&hdmi.lock);
+ if (hdmi.audio_pdev && hdmi.audio_abort_cb) + hdmi.audio_abort_cb(&hdmi.audio_pdev->dev); + hdmi_power_off_full(dssdev);
+ hdmi.display_enabled = false; + mutex_unlock(&hdmi.lock); }
@@ -566,6 +574,112 @@ err: return r; }
+/* Audio callbacks */ +static int hdmi_audio_startup(struct device *dev, + void (*abort_cb)(struct device *dev)) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret = 0; + + mutex_lock(&hd->lock); + + if (!hdmi_mode_has_audio(&hd->cfg) || !hd->display_enabled) { + ret = -EPERM; + goto out; + } + + hd->audio_abort_cb = abort_cb; + +out: + mutex_unlock(&hd->lock); + + return ret; +} + +static int hdmi_audio_shutdown(struct device *dev) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + + mutex_lock(&hd->lock); + hd->audio_abort_cb = NULL; + mutex_unlock(&hd->lock); + + return 0; +} + +static int hdmi_audio_start(struct device *dev) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + + WARN_ON(!hdmi_mode_has_audio(&hd->cfg)); + WARN_ON(!hd->display_enabled); + + hdmi_wp_audio_enable(&hd->wp, true); + hdmi_wp_audio_core_req_enable(&hd->wp, true); + + return 0; +} + +static void hdmi_audio_stop(struct device *dev) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + + WARN_ON(!hdmi_mode_has_audio(&hd->cfg)); + WARN_ON(!hd->display_enabled); + + hdmi_wp_audio_core_req_enable(&hd->wp, false); + hdmi_wp_audio_enable(&hd->wp, false); +} + +static int hdmi_audio_config(struct device *dev, + struct omap_dss_audio *dss_audio) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret; + + mutex_lock(&hd->lock); + + if (!hdmi_mode_has_audio(&hd->cfg) || !hd->display_enabled) { + ret = -EPERM; + goto out; + } + + ret = hdmi5_audio_config(&hd->core, &hd->wp, dss_audio, + hd->cfg.timings.pixelclock); + +out: + mutex_unlock(&hd->lock); + + return ret; +} + +static const struct omap_hdmi_audio_ops hdmi_audio_ops = { + .audio_startup = hdmi_audio_startup, + .audio_shutdown = hdmi_audio_shutdown, + .audio_start = hdmi_audio_start, + .audio_stop = hdmi_audio_stop, + .audio_config = hdmi_audio_config, +}; + +static int hdmi_audio_register(struct device *dev) +{ + struct omap_hdmi_audio_pdata pdata = { + .dev = dev, + .dss_version = omapdss_get_version(), + .audio_dma_addr = hdmi_wp_get_audio_dma_addr(&hdmi.wp), + .ops = &hdmi_audio_ops, + }; + + hdmi.audio_pdev = platform_device_register_data( + dev, "omap-hdmi-audio", PLATFORM_DEVID_AUTO, + &pdata, sizeof(pdata)); + + if (IS_ERR(hdmi.audio_pdev)) + return PTR_ERR(hdmi.audio_pdev); + + return 0; +} + /* HDMI HW IP initialisation */ static int omapdss_hdmihw_probe(struct platform_device *pdev) { @@ -623,6 +737,14 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
hdmi_init_output(pdev);
+ r = hdmi_audio_register(&pdev->dev); + if (r) { + DSSERR("Registering HDMI audio failed %d\n", r); + hdmi_uninit_output(pdev); + pm_runtime_disable(&pdev->dev); + return r; + } + dss_debugfs_create_file("hdmi", hdmi_dump_regs);
return 0; @@ -630,6 +752,9 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
static int __exit omapdss_hdmihw_remove(struct platform_device *pdev) { + if (hdmi.audio_pdev) + platform_device_unregister(hdmi.audio_pdev); + hdmi_uninit_output(pdev);
pm_runtime_disable(&pdev->dev);
Removes omap-hdmi DAI driver, omap-hdmi-card driver, the related Kconfig options, and Makefile entries. The HDMI DAI drivers has been integrated directly to OMAP4+ HDMI drivers and simple-card driver is used instead of omap-hdmi-card driver.
Signed-off-by: Jyri Sarha jsarha@ti.com --- sound/soc/omap/Kconfig | 13 -- sound/soc/omap/Makefile | 4 - sound/soc/omap/omap-hdmi-card.c | 87 ---------- sound/soc/omap/omap-hdmi.c | 364 --------------------------------------- sound/soc/omap/omap-hdmi.h | 38 ---- 5 files changed, 506 deletions(-) delete mode 100644 sound/soc/omap/omap-hdmi-card.c delete mode 100644 sound/soc/omap/omap-hdmi.c delete mode 100644 sound/soc/omap/omap-hdmi.h
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 2b32b3e..3dfcadf 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -12,9 +12,6 @@ config SND_OMAP_SOC_MCBSP config SND_OMAP_SOC_MCPDM tristate
-config SND_OMAP_SOC_HDMI - tristate - config SND_OMAP_SOC_HDMI_AUDIO tristate "HDMI audio support for OMAP4+ based SoCs" depends on SND_OMAP_SOC @@ -115,16 +112,6 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040 - PandaBoard (4430) - PandaBoardES (4460)
-config SND_OMAP_SOC_OMAP_HDMI - tristate "SoC Audio support for Texas Instruments OMAP HDMI" - depends on SND_OMAP_SOC && OMAP4_DSS_HDMI && OMAP2_DSS - select SND_OMAP_SOC_HDMI - select SND_SOC_HDMI_CODEC - select OMAP4_DSS_HDMI_AUDIO - help - Say Y if you want to add support for SoC HDMI audio on Texas Instruments - OMAP4 chips - config SND_OMAP_SOC_OMAP3_PANDORA tristate "SoC Audio support for OMAP3 Pandora" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3_PANDORA diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 40688a6..db36fbd 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -3,14 +3,12 @@ snd-soc-omap-objs := omap-pcm.o snd-soc-omap-dmic-objs := omap-dmic.o snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o snd-soc-omap-mcpdm-objs := omap-mcpdm.o -snd-soc-omap-hdmi-objs := omap-hdmi.o snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o
obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o -obj-$(CONFIG_SND_OMAP_SOC_HDMI) += snd-soc-omap-hdmi.o obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o
# OMAP Machine Support @@ -22,7 +20,6 @@ snd-soc-am3517evm-objs := am3517evm.o snd-soc-omap-abe-twl6040-objs := omap-abe-twl6040.o snd-soc-omap-twl4030-objs := omap-twl4030.o snd-soc-omap3pandora-objs := omap3pandora.o -snd-soc-omap-hdmi-card-objs := omap-hdmi-card.o
obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o @@ -32,4 +29,3 @@ obj-$(CONFIG_SND_OMAP_SOC_AM3517EVM) += snd-soc-am3517evm.o obj-$(CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040) += snd-soc-omap-abe-twl6040.o obj-$(CONFIG_SND_OMAP_SOC_OMAP_TWL4030) += snd-soc-omap-twl4030.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o -obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap-hdmi-card.o diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c deleted file mode 100644 index f649fe8..0000000 --- a/sound/soc/omap/omap-hdmi-card.c +++ /dev/null @@ -1,87 +0,0 @@ -/* - * omap-hdmi-card.c - * - * OMAP ALSA SoC machine driver for TI OMAP HDMI - * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ - * Author: Ricardo Neri ricardo.neri@ti.com - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * - */ - -#include <linux/module.h> -#include <sound/pcm.h> -#include <sound/soc.h> -#include <asm/mach-types.h> -#include <video/omapdss.h> - -#define DRV_NAME "omap-hdmi-audio" - -static struct snd_soc_dai_link omap_hdmi_dai = { - .name = "HDMI", - .stream_name = "HDMI", - .cpu_dai_name = "omap-hdmi-audio-dai", - .platform_name = "omap-hdmi-audio-dai", - .codec_name = "hdmi-audio-codec", - .codec_dai_name = "hdmi-hifi", -}; - -static struct snd_soc_card snd_soc_omap_hdmi = { - .name = "OMAPHDMI", - .owner = THIS_MODULE, - .dai_link = &omap_hdmi_dai, - .num_links = 1, -}; - -static int omap_hdmi_probe(struct platform_device *pdev) -{ - struct snd_soc_card *card = &snd_soc_omap_hdmi; - int ret; - - card->dev = &pdev->dev; - - ret = snd_soc_register_card(card); - if (ret) { - dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); - card->dev = NULL; - return ret; - } - return 0; -} - -static int omap_hdmi_remove(struct platform_device *pdev) -{ - struct snd_soc_card *card = platform_get_drvdata(pdev); - - snd_soc_unregister_card(card); - card->dev = NULL; - return 0; -} - -static struct platform_driver omap_hdmi_driver = { - .driver = { - .name = DRV_NAME, - .owner = THIS_MODULE, - }, - .probe = omap_hdmi_probe, - .remove = omap_hdmi_remove, -}; - -module_platform_driver(omap_hdmi_driver); - -MODULE_AUTHOR("Ricardo Neri ricardo.neri@ti.com"); -MODULE_DESCRIPTION("OMAP HDMI machine ASoC driver"); -MODULE_LICENSE("GPL"); -MODULE_ALIAS("platform:" DRV_NAME); diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c deleted file mode 100644 index eb9c392..0000000 --- a/sound/soc/omap/omap-hdmi.c +++ /dev/null @@ -1,364 +0,0 @@ -/* - * omap-hdmi.c - * - * OMAP ALSA SoC DAI driver for HDMI audio on OMAP4 processors. - * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/ - * Authors: Jorge Candelaria jorge.candelaria@ti.com - * Ricardo Neri ricardo.neri@ti.com - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * - */ - -#include <linux/init.h> -#include <linux/module.h> -#include <linux/device.h> -#include <sound/core.h> -#include <sound/pcm.h> -#include <sound/pcm_params.h> -#include <sound/initval.h> -#include <sound/soc.h> -#include <sound/asound.h> -#include <sound/asoundef.h> -#include <sound/dmaengine_pcm.h> -#include <video/omapdss.h> -#include <sound/omap-pcm.h> - -#include "omap-hdmi.h" - -#define DRV_NAME "omap-hdmi-audio-dai" - -struct hdmi_priv { - struct snd_dmaengine_dai_dma_data dma_data; - unsigned int dma_req; - struct omap_dss_audio dss_audio; - struct snd_aes_iec958 iec; - struct snd_cea_861_aud_if cea; - struct omap_dss_device *dssdev; -}; - -static int omap_hdmi_dai_startup(struct snd_pcm_substream *substream, - struct snd_soc_dai *dai) -{ - struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai); - int err; - /* - * Make sure that the period bytes are multiple of the DMA packet size. - * Largest packet size we use is 32 32-bit words = 128 bytes - */ - err = snd_pcm_hw_constraint_step(substream->runtime, 0, - SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 128); - if (err < 0) { - dev_err(dai->dev, "could not apply constraint\n"); - return err; - } - - if (!priv->dssdev->driver->audio_supported(priv->dssdev)) { - dev_err(dai->dev, "audio not supported\n"); - return -ENODEV; - } - - snd_soc_dai_set_dma_data(dai, substream, &priv->dma_data); - - return 0; -} - -static int omap_hdmi_dai_prepare(struct snd_pcm_substream *substream, - struct snd_soc_dai *dai) -{ - struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai); - - return priv->dssdev->driver->audio_enable(priv->dssdev); -} - -static int omap_hdmi_dai_hw_params(struct snd_pcm_substream *substream, - struct snd_pcm_hw_params *params, - struct snd_soc_dai *dai) -{ - struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai); - struct snd_aes_iec958 *iec = &priv->iec; - struct snd_cea_861_aud_if *cea = &priv->cea; - int err = 0; - - switch (params_format(params)) { - case SNDRV_PCM_FORMAT_S16_LE: - priv->dma_data.maxburst = 16; - break; - case SNDRV_PCM_FORMAT_S24_LE: - priv->dma_data.maxburst = 32; - break; - default: - dev_err(dai->dev, "format not supported!\n"); - return -EINVAL; - } - - /* - * fill the IEC-60958 channel status word - */ - /* initialize the word bytes */ - memset(iec->status, 0, sizeof(iec->status)); - - /* specify IEC-60958-3 (commercial use) */ - iec->status[0] &= ~IEC958_AES0_PROFESSIONAL; - - /* specify that the audio is LPCM*/ - iec->status[0] &= ~IEC958_AES0_NONAUDIO; - - iec->status[0] |= IEC958_AES0_CON_NOT_COPYRIGHT; - - iec->status[0] |= IEC958_AES0_CON_EMPHASIS_NONE; - - iec->status[0] |= IEC958_AES1_PRO_MODE_NOTID; - - iec->status[1] = IEC958_AES1_CON_GENERAL; - - iec->status[2] |= IEC958_AES2_CON_SOURCE_UNSPEC; - - iec->status[2] |= IEC958_AES2_CON_CHANNEL_UNSPEC; - - switch (params_rate(params)) { - case 32000: - iec->status[3] |= IEC958_AES3_CON_FS_32000; - break; - case 44100: - iec->status[3] |= IEC958_AES3_CON_FS_44100; - break; - case 48000: - iec->status[3] |= IEC958_AES3_CON_FS_48000; - break; - case 88200: - iec->status[3] |= IEC958_AES3_CON_FS_88200; - break; - case 96000: - iec->status[3] |= IEC958_AES3_CON_FS_96000; - break; - case 176400: - iec->status[3] |= IEC958_AES3_CON_FS_176400; - break; - case 192000: - iec->status[3] |= IEC958_AES3_CON_FS_192000; - break; - default: - dev_err(dai->dev, "rate not supported!\n"); - return -EINVAL; - } - - /* specify the clock accuracy */ - iec->status[3] |= IEC958_AES3_CON_CLOCK_1000PPM; - - /* - * specify the word length. The same word length value can mean - * two different lengths. Hence, we need to specify the maximum - * word length as well. - */ - switch (params_format(params)) { - case SNDRV_PCM_FORMAT_S16_LE: - iec->status[4] |= IEC958_AES4_CON_WORDLEN_20_16; - iec->status[4] &= ~IEC958_AES4_CON_MAX_WORDLEN_24; - break; - case SNDRV_PCM_FORMAT_S24_LE: - iec->status[4] |= IEC958_AES4_CON_WORDLEN_24_20; - iec->status[4] |= IEC958_AES4_CON_MAX_WORDLEN_24; - break; - default: - dev_err(dai->dev, "format not supported!\n"); - return -EINVAL; - } - - /* - * Fill the CEA-861 audio infoframe (see spec for details) - */ - - cea->db1_ct_cc = (params_channels(params) - 1) - & CEA861_AUDIO_INFOFRAME_DB1CC; - cea->db1_ct_cc |= CEA861_AUDIO_INFOFRAME_DB1CT_FROM_STREAM; - - cea->db2_sf_ss = CEA861_AUDIO_INFOFRAME_DB2SF_FROM_STREAM; - cea->db2_sf_ss |= CEA861_AUDIO_INFOFRAME_DB2SS_FROM_STREAM; - - cea->db3 = 0; /* not used, all zeros */ - - /* - * The OMAP HDMI IP requires to use the 8-channel channel code when - * transmitting more than two channels. - */ - if (params_channels(params) == 2) - cea->db4_ca = 0x0; - else - cea->db4_ca = 0x13; - - cea->db5_dminh_lsv = CEA861_AUDIO_INFOFRAME_DB5_DM_INH_PROHIBITED; - /* the expression is trivial but makes clear what we are doing */ - cea->db5_dminh_lsv |= (0 & CEA861_AUDIO_INFOFRAME_DB5_LSV); - - priv->dss_audio.iec = iec; - priv->dss_audio.cea = cea; - - err = priv->dssdev->driver->audio_config(priv->dssdev, - &priv->dss_audio); - - return err; -} - -static int omap_hdmi_dai_trigger(struct snd_pcm_substream *substream, int cmd, - struct snd_soc_dai *dai) -{ - struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai); - int err = 0; - - switch (cmd) { - case SNDRV_PCM_TRIGGER_START: - case SNDRV_PCM_TRIGGER_RESUME: - case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: - err = priv->dssdev->driver->audio_start(priv->dssdev); - break; - case SNDRV_PCM_TRIGGER_STOP: - case SNDRV_PCM_TRIGGER_SUSPEND: - case SNDRV_PCM_TRIGGER_PAUSE_PUSH: - priv->dssdev->driver->audio_stop(priv->dssdev); - break; - default: - err = -EINVAL; - } - return err; -} - -static void omap_hdmi_dai_shutdown(struct snd_pcm_substream *substream, - struct snd_soc_dai *dai) -{ - struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai); - - priv->dssdev->driver->audio_disable(priv->dssdev); -} - -static const struct snd_soc_dai_ops omap_hdmi_dai_ops = { - .startup = omap_hdmi_dai_startup, - .hw_params = omap_hdmi_dai_hw_params, - .prepare = omap_hdmi_dai_prepare, - .trigger = omap_hdmi_dai_trigger, - .shutdown = omap_hdmi_dai_shutdown, -}; - -static struct snd_soc_dai_driver omap_hdmi_dai = { - .playback = { - .channels_min = 2, - .channels_max = 8, - .rates = OMAP_HDMI_RATES, - .formats = OMAP_HDMI_FORMATS, - }, - .ops = &omap_hdmi_dai_ops, -}; - -static const struct snd_soc_component_driver omap_hdmi_component = { - .name = DRV_NAME, -}; - -static int omap_hdmi_probe(struct platform_device *pdev) -{ - int ret; - struct resource *hdmi_rsrc; - struct hdmi_priv *hdmi_data; - bool hdmi_dev_found = false; - - hdmi_data = devm_kzalloc(&pdev->dev, sizeof(*hdmi_data), GFP_KERNEL); - if (hdmi_data == NULL) { - dev_err(&pdev->dev, "Cannot allocate memory for HDMI data\n"); - return -ENOMEM; - } - - hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!hdmi_rsrc) { - dev_err(&pdev->dev, "Cannot obtain IORESOURCE_MEM HDMI\n"); - return -ENODEV; - } - - hdmi_data->dma_data.addr = hdmi_rsrc->start + OMAP_HDMI_AUDIO_DMA_PORT; - - hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_DMA, 0); - if (!hdmi_rsrc) { - dev_err(&pdev->dev, "Cannot obtain IORESOURCE_DMA HDMI\n"); - return -ENODEV; - } - - hdmi_data->dma_req = hdmi_rsrc->start; - hdmi_data->dma_data.filter_data = &hdmi_data->dma_req; - hdmi_data->dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; - - /* - * TODO: We assume that there is only one DSS HDMI device. Future - * OMAP implementations may support more than one HDMI devices and - * we should provided separate audio support for all of them. - */ - /* Find an HDMI device. */ - for_each_dss_dev(hdmi_data->dssdev) { - omap_dss_get_device(hdmi_data->dssdev); - - if (!hdmi_data->dssdev->driver) { - omap_dss_put_device(hdmi_data->dssdev); - continue; - } - - if (hdmi_data->dssdev->type == OMAP_DISPLAY_TYPE_HDMI) { - hdmi_dev_found = true; - break; - } - } - - if (!hdmi_dev_found) { - dev_err(&pdev->dev, "no driver for HDMI display found\n"); - return -ENODEV; - } - - dev_set_drvdata(&pdev->dev, hdmi_data); - ret = snd_soc_register_component(&pdev->dev, &omap_hdmi_component, - &omap_hdmi_dai, 1); - - if (ret) - return ret; - - return omap_pcm_platform_register(&pdev->dev); -} - -static int omap_hdmi_remove(struct platform_device *pdev) -{ - struct hdmi_priv *hdmi_data = dev_get_drvdata(&pdev->dev); - - snd_soc_unregister_component(&pdev->dev); - - if (hdmi_data == NULL) { - dev_err(&pdev->dev, "cannot obtain HDMi data\n"); - return -ENODEV; - } - - omap_dss_put_device(hdmi_data->dssdev); - return 0; -} - -static struct platform_driver hdmi_dai_driver = { - .driver = { - .name = DRV_NAME, - .owner = THIS_MODULE, - }, - .probe = omap_hdmi_probe, - .remove = omap_hdmi_remove, -}; - -module_platform_driver(hdmi_dai_driver); - -MODULE_AUTHOR("Jorge Candelaria jorge.candelaria@ti.com"); -MODULE_AUTHOR("Ricardo Neri ricardo.neri@ti.com"); -MODULE_DESCRIPTION("OMAP HDMI SoC Interface"); -MODULE_LICENSE("GPL"); -MODULE_ALIAS("platform:" DRV_NAME); diff --git a/sound/soc/omap/omap-hdmi.h b/sound/soc/omap/omap-hdmi.h deleted file mode 100644 index 6ad2bf4..0000000 --- a/sound/soc/omap/omap-hdmi.h +++ /dev/null @@ -1,38 +0,0 @@ -/* - * omap-hdmi.h - * - * Definitions for OMAP ALSA SoC DAI driver for HDMI audio on OMAP4 processors. - * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/ - * Authors: Jorge Candelaria jorge.candelaria@ti.com - * Ricardo Neri ricardo.neri@ti.com - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * - */ - -#ifndef __OMAP_HDMI_H__ -#define __OMAP_HDMI_H__ - -#define OMAP_HDMI_AUDIO_DMA_PORT 0x8c - -#define OMAP_HDMI_RATES (SNDRV_PCM_RATE_32000 | \ - SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | \ - SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000 | \ - SNDRV_PCM_RATE_176400 | SNDRV_PCM_RATE_192000) - -#define OMAP_HDMI_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \ - SNDRV_PCM_FMTBIT_S24_LE) - -#endif
In new model these callbacks are obsolete since the ASoC component drivers are integrated into the HDMI drivers and no callbacks are needed anymore.
Signed-off-by: Jyri Sarha jsarha@ti.com --- .../fbdev/omap2/displays-new/connector-hdmi.c | 99 -------------------- .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 ----------- include/video/omapdss.h | 40 -------- 3 files changed, 195 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c index 7b25967..219f14f 100644 --- a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c +++ b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c @@ -170,98 +170,6 @@ static bool hdmic_detect(struct omap_dss_device *dssdev) return in->ops.hdmi->detect(in); }
-static int hdmic_audio_enable(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - int r; - - /* enable audio only if the display is active */ - if (!omapdss_device_is_enabled(dssdev)) - return -EPERM; - - r = in->ops.hdmi->audio_enable(in); - if (r) - return r; - - dssdev->audio_state = OMAP_DSS_AUDIO_ENABLED; - - return 0; -} - -static void hdmic_audio_disable(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - in->ops.hdmi->audio_disable(in); - - dssdev->audio_state = OMAP_DSS_AUDIO_DISABLED; -} - -static int hdmic_audio_start(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - int r; - - /* - * No need to check the panel state. It was checked when trasitioning - * to AUDIO_ENABLED. - */ - if (dssdev->audio_state != OMAP_DSS_AUDIO_ENABLED) - return -EPERM; - - r = in->ops.hdmi->audio_start(in); - if (r) - return r; - - dssdev->audio_state = OMAP_DSS_AUDIO_PLAYING; - - return 0; -} - -static void hdmic_audio_stop(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - in->ops.hdmi->audio_stop(in); - - dssdev->audio_state = OMAP_DSS_AUDIO_ENABLED; -} - -static bool hdmic_audio_supported(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - if (!omapdss_device_is_enabled(dssdev)) - return false; - - return in->ops.hdmi->audio_supported(in); -} - -static int hdmic_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - int r; - - /* config audio only if the display is active */ - if (!omapdss_device_is_enabled(dssdev)) - return -EPERM; - - r = in->ops.hdmi->audio_config(in, audio); - if (r) - return r; - - dssdev->audio_state = OMAP_DSS_AUDIO_CONFIGURED; - - return 0; -} - static int hdmic_set_hdmi_mode(struct omap_dss_device *dssdev, bool hdmi_mode) { struct panel_drv_data *ddata = to_panel_data(dssdev); @@ -296,13 +204,6 @@ static struct omap_dss_driver hdmic_driver = { .detect = hdmic_detect, .set_hdmi_mode = hdmic_set_hdmi_mode, .set_hdmi_infoframe = hdmic_set_infoframe, - - .audio_enable = hdmic_audio_enable, - .audio_disable = hdmic_audio_disable, - .audio_start = hdmic_audio_start, - .audio_stop = hdmic_audio_stop, - .audio_supported = hdmic_audio_supported, - .audio_config = hdmic_audio_config, };
static int hdmic_probe_pdata(struct platform_device *pdev) diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c index c4abd56..6fc8b9d 100644 --- a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c +++ b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c @@ -193,55 +193,6 @@ static bool tpd_detect(struct omap_dss_device *dssdev) return gpio_get_value_cansleep(ddata->hpd_gpio); }
-static int tpd_audio_enable(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - return in->ops.hdmi->audio_enable(in); -} - -static void tpd_audio_disable(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - in->ops.hdmi->audio_disable(in); -} - -static int tpd_audio_start(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - return in->ops.hdmi->audio_start(in); -} - -static void tpd_audio_stop(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - in->ops.hdmi->audio_stop(in); -} - -static bool tpd_audio_supported(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - return in->ops.hdmi->audio_supported(in); -} - -static int tpd_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - return in->ops.hdmi->audio_config(in, audio); -} - static int tpd_set_infoframe(struct omap_dss_device *dssdev, const struct hdmi_avi_infoframe *avi) { @@ -275,13 +226,6 @@ static const struct omapdss_hdmi_ops tpd_hdmi_ops = { .detect = tpd_detect, .set_infoframe = tpd_set_infoframe, .set_hdmi_mode = tpd_set_hdmi_mode, - - .audio_enable = tpd_audio_enable, - .audio_disable = tpd_audio_disable, - .audio_start = tpd_audio_start, - .audio_stop = tpd_audio_stop, - .audio_supported = tpd_audio_supported, - .audio_config = tpd_audio_config, };
static int tpd_probe_pdata(struct platform_device *pdev) diff --git a/include/video/omapdss.h b/include/video/omapdss.h index 069dfca..7de6765 100644 --- a/include/video/omapdss.h +++ b/include/video/omapdss.h @@ -166,13 +166,6 @@ enum omap_dss_display_state { OMAP_DSS_DISPLAY_ACTIVE, };
-enum omap_dss_audio_state { - OMAP_DSS_AUDIO_DISABLED = 0, - OMAP_DSS_AUDIO_ENABLED, - OMAP_DSS_AUDIO_CONFIGURED, - OMAP_DSS_AUDIO_PLAYING, -}; - struct omap_dss_audio { struct snd_aes_iec958 *iec; struct snd_cea_861_aud_if *cea; @@ -635,19 +628,6 @@ struct omapdss_hdmi_ops { int (*set_hdmi_mode)(struct omap_dss_device *dssdev, bool hdmi_mode); int (*set_infoframe)(struct omap_dss_device *dssdev, const struct hdmi_avi_infoframe *avi); - - /* - * Note: These functions might sleep. Do not call while - * holding a spinlock/readlock. - */ - int (*audio_enable)(struct omap_dss_device *dssdev); - void (*audio_disable)(struct omap_dss_device *dssdev); - bool (*audio_supported)(struct omap_dss_device *dssdev); - int (*audio_config)(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio); - /* Note: These functions may not sleep */ - int (*audio_start)(struct omap_dss_device *dssdev); - void (*audio_stop)(struct omap_dss_device *dssdev); };
struct omapdss_dsi_ops { @@ -783,8 +763,6 @@ struct omap_dss_device {
enum omap_dss_display_state state;
- enum omap_dss_audio_state audio_state; - /* OMAP DSS output specific fields */
struct list_head list; @@ -858,24 +836,6 @@ struct omap_dss_driver { int (*set_hdmi_mode)(struct omap_dss_device *dssdev, bool hdmi_mode); int (*set_hdmi_infoframe)(struct omap_dss_device *dssdev, const struct hdmi_avi_infoframe *avi); - - /* - * For display drivers that support audio. This encompasses - * HDMI and DisplayPort at the moment. - */ - /* - * Note: These functions might sleep. Do not call while - * holding a spinlock/readlock. - */ - int (*audio_enable)(struct omap_dss_device *dssdev); - void (*audio_disable)(struct omap_dss_device *dssdev); - bool (*audio_supported)(struct omap_dss_device *dssdev); - int (*audio_config)(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio); - /* Note: These functions may not sleep */ - int (*audio_start)(struct omap_dss_device *dssdev); - void (*audio_stop)(struct omap_dss_device *dssdev); - };
enum omapdss_version omapdss_get_version(void);
Signed-off-by: Jyri Sarha jsarha@ti.com --- drivers/video/fbdev/omap2/dss/hdmi.h | 1 + drivers/video/fbdev/omap2/dss/hdmi5.c | 7 +++++++ 2 files changed, 8 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index bfaaf2f..f991dbf 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -372,6 +372,7 @@ struct omap_hdmi {
struct platform_device *audio_pdev; void (*audio_abort_cb)(struct device *dev); + int wp_idlemode; };
#endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index feb76e2..c91685e 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c @@ -614,6 +614,10 @@ static int hdmi_audio_start(struct device *dev) WARN_ON(!hdmi_mode_has_audio(&hd->cfg)); WARN_ON(!hd->display_enabled);
+ /* No-idle while playing audio, store the old value */ + hd->wp_idlemode = REG_GET(hdmi.wp.base, HDMI_WP_SYSCONFIG, 3, 2); + REG_FLD_MOD(hdmi.wp.base, HDMI_WP_SYSCONFIG, 1, 3, 2); + hdmi_wp_audio_enable(&hd->wp, true); hdmi_wp_audio_core_req_enable(&hd->wp, true);
@@ -629,6 +633,9 @@ static void hdmi_audio_stop(struct device *dev)
hdmi_wp_audio_core_req_enable(&hd->wp, false); hdmi_wp_audio_enable(&hd->wp, false); + + /* Playback stopped, restore original idlemode */ + REG_FLD_MOD(hdmi.wp.base, HDMI_WP_SYSCONFIG, hd->wp_idlemode, 3, 2); }
static int hdmi_audio_config(struct device *dev,
On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote:
It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers.
So, this is a very large series which gets reposted every so often to no apparent interest from the video side, there's been no response at all that I can remember and even the earlier bits of the series before it starts touching audio don't seem to be getting merged. What's going on here?
Hi Mark,
On 13/11/14 00:23, Mark Brown wrote:
On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote:
It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers.
So, this is a very large series which gets reposted every so often to no apparent interest from the video side, there's been no response at all
Sorry for the lack of communication. We've been discussing this series on irc. It's been mostly about how to manage the device/driver split between drivers/video/ and sound/ sides.
that I can remember and even the earlier bits of the series before it starts touching audio don't seem to be getting merged. What's going on here?
The series is all audio in terms of functionality. The first few patches could probably be merged independently, but I've wanted this whole OMAP HDMI audio rewrite to be in one series.
I'll start testing this latest series, and I hope we can merge it for the next merge window so that we'll finally get the OMAP HDMI audio working.
I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions).
As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped -> audio must be stopped also). But if I've understood right, there was no similar existing code to be found.
Tomi
On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkeinen@ti.com wrote: [snip]
I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions).
As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped -> audio must be stopped also). But if I've understood right, there was no similar existing code to be found.
I recently posted a patch on the HDMI CODEC to interface a HDMI transmitter http://mailman.alsa-project.org/pipermail/alsa-devel/2014-October/082745.htm... and I saw only a few dependencies between the 2 subsystems:
- the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -),
- the CODEC must alert the transmitter on audio start and stop.
I don't think that stopping audio streaming on HDMI disconnection is useful. I even let audio streaming start when the HDMI cable is disconnected.
Hi,
On 13/11/14 11:17, Jean-Francois Moine wrote:
On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkeinen@ti.com wrote: [snip]
I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions).
As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped -> audio must be stopped also). But if I've understood right, there was no similar existing code to be found.
I recently posted a patch on the HDMI CODEC to interface a HDMI transmitter http://mailman.alsa-project.org/pipermail/alsa-devel/2014-October/082745.htm...
Jyri or Peter knows this better, but I think one difference with OMAP HDMI case and tda998x is that tda998x is an external encoder, and you transfer audio data to it via i2s or spdif, whereas OMAP HDMI is inside the SoC, and the HDMI IP gets the audio data via system DMA.
The system DMA transfers are triggered by the HDMI IP, and the HDMI IP has to be enabled and properly configured for the DMA ports to function.
So, correct me if I'm wrong, but I think this is the fundamental difference:
In your case, the actual audio playback happens with the i2s or spdif side. You can enable the playback at any time, no matter what is the status of tda998x. If tda998x is not operational, the audio data will just go to /dev/null.
In our case, the actual audio playback happens inside the HDMI block. We need the whole HDMI block to be operational and correctly configured for (fake or real) playback to be possible.
and I saw only a few dependencies between the 2 subsystems:
- the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -),
The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point?
- the CODEC must alert the transmitter on audio start and stop.
I don't think that stopping audio streaming on HDMI disconnection is
And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio?
useful. I even let audio streaming start when the HDMI cable is disconnected.
Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are:
a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere?
b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave?
c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work.
Jyri, were there some other options we discussed?
Currently, the OMAP HDMI version does c). It's the easiest solution for us.
Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side.
I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment.
But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused...
Tomi
On 11/13/2014 12:00 PM, Tomi Valkeinen wrote:
Hi,
On 13/11/14 11:17, Jean-Francois Moine wrote:
On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkeinen@ti.com wrote:
...
and I saw only a few dependencies between the 2 subsystems:
- the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -),
The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point?
- the CODEC must alert the transmitter on audio start and stop.
I don't think that stopping audio streaming on HDMI disconnection is
And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio?
useful. I even let audio streaming start when the HDMI cable is disconnected.
Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are:
a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere?
b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave?
c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work.
Jyri, were there some other options we discussed?
There was the 4th option: the driver forcing pause on the pcm when the cable is disconnected or screen is blanked and resuming it automatically when the picture is back. But I think that is maybe too hackish solution.
Considering the big picture, including the userspace. I think we would need some way to tell the userspace when the HDMI device is available. The problem is the same for both a and c cases. Maybe a read only alsa mixer could be used for that.
Cheers, Jyri
Currently, the OMAP HDMI version does c). It's the easiest solution for us.
Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side.
I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment.
But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused...
On Thu, 13 Nov 2014 12:00:41 +0200 Tomi Valkeinen tomi.valkeinen@ti.com wrote:
[snip]
Jyri or Peter knows this better, but I think one difference with OMAP HDMI case and tda998x is that tda998x is an external encoder, and you transfer audio data to it via i2s or spdif, whereas OMAP HDMI is inside the SoC, and the HDMI IP gets the audio data via system DMA.
The system DMA transfers are triggered by the HDMI IP, and the HDMI IP has to be enabled and properly configured for the DMA ports to function.
So, correct me if I'm wrong, but I think this is the fundamental difference:
In your case, the actual audio playback happens with the i2s or spdif side. You can enable the playback at any time, no matter what is the status of tda998x. If tda998x is not operational, the audio data will just go to /dev/null.
In our case, the actual audio playback happens inside the HDMI block. We need the whole HDMI block to be operational and correctly configured for (fake or real) playback to be possible.
When the tda998x is not operational, the CODEC knows it and reports an error to the audio subsystem on device open. But, once the tda998x has been started, it always stays operational, even without HDMI connection.
and I saw only a few dependencies between the 2 subsystems:
- the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -),
The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point?
Such changes occur only when the HDMI output device (TV) is replaced by an other one (manual cable exchange or HDMI switcher). I wonder if these changes are correctly treated in the HDMI transmitters, DRM core, DRM drivers, X11/wayland...
So, no, actually, once streaming is started, no information go from the HDMI transmitter to the CODEC.
- the CODEC must alert the transmitter on audio start and stop.
I don't think that stopping audio streaming on HDMI disconnection is
And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio?
Bug in my patch: audio playback will be rejected if there will be no audio support.
useful. I even let audio streaming start when the HDMI cable is disconnected.
Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are:
a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere?
b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave?
c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work.
Jyri, were there some other options we discussed?
Currently, the OMAP HDMI version does c). It's the easiest solution for us.
Same for me, but checking the audio capability is done on audio streaming start only.
When the HDMI output device is disconnected, the video and audio outputs don't need to be changed. I often switch off my TV set when I will not use my computer for a while, letting the computer itself running. When I get back and switch on back the TV set, video and audio are still there.
Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side.
I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment.
But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused...
AFAIK, the HDMI transmitters don't know if the video or audio is displayed/played by the external device(s). Only the user knows.
BTW, you are talking about video modes without audio support. What are you thinking about?
On 13/11/14 17:00, Jean-Francois Moine wrote:
When the tda998x is not operational, the CODEC knows it and reports an error to the audio subsystem on device open. But, once the tda998x has been started, it always stays operational, even without HDMI connection.
What does "started" mean here? tda998x device/driver has been probed?
The reason for the above is probably to handle hotplug? I.e. tda998x needs to be enabled always to detect HPD?
Usually for OMAP, the HPD detection happens outside the HDMI IP. Thus the HDMI IP is turned fully off when the video is disabled.
I believe tda998x could be used the same way, if the HPD pin is connected to a SoC GPIO instead of tda998x.
and I saw only a few dependencies between the 2 subsystems:
- the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -),
The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point?
Such changes occur only when the HDMI output device (TV) is replaced by
The user can change the video mode at any time. The audio data packets are sent in the video blanking intervals, and if those intervals are too short, the video mode cannot support audio.
If I'm not mistaken, officially only certain video modes defined in the HDMI spec support audio.
an other one (manual cable exchange or HDMI switcher). I wonder if these changes are correctly treated in the HDMI transmitters, DRM core, DRM drivers, X11/wayland...
HPD (which usually equals to cable change, but not always) is handled.
a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere?
b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave?
c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work.
Jyri, were there some other options we discussed?
Currently, the OMAP HDMI version does c). It's the easiest solution for us.
Same for me, but checking the audio capability is done on audio streaming start only.
Hmm, I understood you have option a)? You said "I even let audio streaming start when the HDMI cable is disconnected".
With "audio support is not available" I mean also the case when the cable is not connected, as then we don't have EDID information, and thus we don't have a HDMI monitor with audio support on the other end.
So to clarify, our driver only has "audio support available" if: - we successfully read EDID - EDID shows it's a HDMI monitor - EDID shows it has audio support for the format we support (this we don't actually do yet)
Otherwise we default to DVI, which means no audio.
If, at any point, the situation changes to "no audio support available", the audio playback is aborted and starting new audio playback fails.
AFAIK, the HDMI transmitters don't know if the video or audio is displayed/played by the external device(s). Only the user knows.
True.
But the HDMI transmitter can know if the audio absolutely cannot be played, because there's no cable, or because the monitor says it doesn't support audio, or because the video mode cannot support audio, or because the HDMI output stream is disabled.
So the question is, do we want/need to inform the userspace about those situations? Should a HDMI transmitted always look like it can play audio, even if it's clear it cannot?
Again, I know very little about audio, but I think it would be nice that if I open the sound configuration window on my desktop, it'd show me that the HDMI audio device is disabled (because there's no cable).
But perhaps that's a separate feature. We could have HDMI audio device always there and functional, but the desktop could get the information about HDMI cable connection some other way (DRM). And if the cable is not there, it knows that this particular audio device is also out, and thus doesn't show it (even if it's functional).
BTW, you are talking about video modes without audio support. What are you thinking about?
This I covered above.
Tomi
On Thu, 13 Nov 2014 17:44:38 +0200 Tomi Valkeinen tomi.valkeinen@ti.com wrote: [snip]
a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere?
b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave?
c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work.
Jyri, were there some other options we discussed?
Currently, the OMAP HDMI version does c). It's the easiest solution for us.
Same for me, but checking the audio capability is done on audio streaming start only.
Hmm, I understood you have option a)? You said "I even let audio streaming start when the HDMI cable is disconnected".
The option a) is the one of the patch, but I am moving towards option c).
With "audio support is not available" I mean also the case when the cable is not connected, as then we don't have EDID information, and thus we don't have a HDMI monitor with audio support on the other end.
What I was saying is: when the cable is connected, all audio/video parameters are known. Then, when the cable is disconnected, there is no reason, a priori, to change these parameters, and audio/video streaming may continue. The problem might be raised later when an other monitor with different parameters will be connected.
So to clarify, our driver only has "audio support available" if:
- we successfully read EDID
- EDID shows it's a HDMI monitor
- EDID shows it has audio support for the format we support (this we
don't actually do yet)
Otherwise we default to DVI, which means no audio.
If, at any point, the situation changes to "no audio support available", the audio playback is aborted and starting new audio playback fails.
[snip]
So, to summarize, you need the information 'audio support available' on the audio side.
It should not be difficult to export a function in the generic HDMI driver for this job. This function would have the following arguments:
- device (child device of the HDMI transmitter) - pin (output widget name) - status (enable/disable)
and would:
- set the pin status so that the HDMI output would be included or not in the audio path, and
- abort audio streaming on disabling audio.
Hi Mark,
On 13/11/14 10:05, Tomi Valkeinen wrote:
Hi Mark,
On 13/11/14 00:23, Mark Brown wrote:
On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote:
It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers.
So, this is a very large series which gets reposted every so often to no apparent interest from the video side, there's been no response at all
Sorry for the lack of communication. We've been discussing this series on irc. It's been mostly about how to manage the device/driver split between drivers/video/ and sound/ sides.
that I can remember and even the earlier bits of the series before it starts touching audio don't seem to be getting merged. What's going on here?
The series is all audio in terms of functionality. The first few patches could probably be merged independently, but I've wanted this whole OMAP HDMI audio rewrite to be in one series.
I'll start testing this latest series, and I hope we can merge it for the next merge window so that we'll finally get the OMAP HDMI audio working.
I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions).
The series looks good to me, and works for me.
Do you have any comments for the sound/ parts? If not, I can merge this series via fbdev tree, and for that I'd like your ack on the sound/ patches.
Tomi
On Thu, Nov 20, 2014 at 12:59:44PM +0200, Tomi Valkeinen wrote:
The series looks good to me, and works for me.
Do you have any comments for the sound/ parts? If not, I can merge this series via fbdev tree, and for that I'd like your ack on the sound/ patches.
I've not reviewed it yet and I'm still seeing some fairly basic discussion between Jiri and Jean-Francois about approaches to integrating HDMI which seem to have ground to a halt (I've not been reading them in any detail). The fact that we're getting no sharing at all between all the different HDMI devices people are supporting and very limited dialogue between them is really setting off alarm bells.
As far as I can tell in order to figure out what to do with all this HDMI stuff I'm going to need to go to square one, get an overview of the hardware that's out there for myself and try to work out what to do with it.
With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code.
On 11/21/2014 01:23 PM, Mark Brown wrote:
On Thu, Nov 20, 2014 at 12:59:44PM +0200, Tomi Valkeinen wrote:
The series looks good to me, and works for me.
Do you have any comments for the sound/ parts? If not, I can merge this series via fbdev tree, and for that I'd like your ack on the sound/ patches.
I've not reviewed it yet and I'm still seeing some fairly basic discussion between Jiri and Jean-Francois about approaches to integrating HDMI which seem to have ground to a halt (I've not been reading them in any detail). The fact that we're getting no sharing at all between all the different HDMI devices people are supporting and very limited dialogue between them is really setting off alarm bells.
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 issue about generic HDMI codec, that Jean-Francois (and soon me) is trying to solve - applies to the cases where a generic cpu-dai is connected to an external HDMI encoder with i2s (or s/pdif, unfortunately do not have such HW). In these cases the structure of the ASoC setup resembles closely the usual pattern of ASoC cards. The main difference is just that the "codec" IP also handling the video and there are no mixers, etc.
I am currently trying to find the common denominator between tda998x and SiI9022 HDMI encoder chips to come up with a generic solution for the external HDMI encoder case. However, this work is completely separate to the omap-hdmi-audio and its review should not be delayed because of the hdmi codec work.
Best regards, Jyri
As far as I can tell in order to figure out what to do with all this HDMI stuff I'm going to need to go to square one, get an overview of the hardware that's out there for myself and try to work out what to do with it.
With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code.
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.
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.
On 21/11/14 18:38, 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.
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.
I agree all these should be studied and worked further. However, I would still like to merge this series in the next merge window:
a) The series does fix the OMAP HDMI audio, so that users can actually use it.
b) The series does make the driver model much better, so that I can actually be bothered to keep it enabled (earlier, even when it more or less worked, it was too much hassle when doing development using modules).
Tomi
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
On 11/21/2014 01:23 PM, Mark Brown wrote:
With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code.
(Sorry, I forgot to comment this part.)
The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is).
Another target was to make configuring the audio as simple as possible. Because everything needed for HDMI audio is always there if the video side is correctly configured, there should be no need for any additional configuration (in DT or otherwise) to get the audio working. Now simply selecting omap-hdmi-audio is enough. There is no complex cross dependencies to the video side any more, the audio driver simply does find its device if the HDMI video driver is not probed.
But indeed, in functional sense the whole series - apart from the couple of fixes in the beginning - is just moving the code around.
Best regards, Jyri
On Fri, Nov 21, 2014 at 02:35:07PM +0200, Jyri Sarha wrote:
On 11/21/2014 01:23 PM, Mark Brown wrote:
With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code.
The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is).
But in what way is it broken and how did this happen? Why are none of the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially.
On 21/11/14 18:14, Mark Brown wrote:
On Fri, Nov 21, 2014 at 02:35:07PM +0200, Jyri Sarha wrote:
On 11/21/2014 01:23 PM, Mark Brown wrote:
With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code.
The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is).
But in what way is it broken and how did this happen? Why are none of
I don't have a clear answer, but it probably involves lack of use, and buggy and hard to use implementation. Things have changed around the original HDMI audio implementation, and it stopped working at some point.
As the original implementation was found rather lacking, and with some fundamental issues, it was deemed better to have a fresh approach.
the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially.
The whole series is about HDMI audio, not video.
The main HDMI driver resides in the fbdev directory, as the video side is the "master" here, and it contains the code to access the registers (including audio related registers). The sound/ part in this series acts as a logic between the asoc and the low level HDMI driver.
This series only touch the parts about HDMI audio, so the fixes early on don't really fix anything without the rest of the series (as the current HDMI audio doesn't work).
And in any case, I don't like applying individual patches from a series. Usually that just complicates things. If I would apply some of the early patches to fbdev, then this series would no longer work on plain mainline kernel, and would instead depend on fbdev tree. The situation would be ever worse if you'd also pick some of the audio patches to sound tree, creating a dependency to two subsystem trees.
So if there's no particular important reason to pick patches from a series, I rather keep it as a whole to simplify merging and testing.
Tomi
On Mon, Nov 24, 2014 at 10:18:31AM +0200, Tomi Valkeinen wrote:
On 21/11/14 18:14, Mark Brown wrote:
But in what way is it broken and how did this happen? Why are none of
I don't have a clear answer, but it probably involves lack of use, and buggy and hard to use implementation. Things have changed around the original HDMI audio implementation, and it stopped working at some point.
As the original implementation was found rather lacking, and with some fundamental issues, it was deemed better to have a fresh approach.
OK... this is all telling me that I *really* need to scrub this in detail. It's all sounding very vague, it's an area which seems to cause lots of problems and I don't want to be sitting here next time around trying to figure out if another rewrite makes things better or worse or if another driver should look similar or different.
the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially.
The whole series is about HDMI audio, not video.
You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies.
This series only touch the parts about HDMI audio, so the fixes early on don't really fix anything without the rest of the series (as the current HDMI audio doesn't work).
And in any case, I don't like applying individual patches from a series. Usually that just complicates things. If I would apply some of the early patches to fbdev, then this series would no longer work on plain mainline kernel, and would instead depend on fbdev tree. The situation
But I thought everyone was saying this hardware doesn't work anyway and that you want to apply all these changes to fbdev?
would be ever worse if you'd also pick some of the audio patches to sound tree, creating a dependency to two subsystem trees.
So if there's no particular important reason to pick patches from a series, I rather keep it as a whole to simplify merging and testing.
This means we're all then stuck reading reposts of the same enormous series over and over again - as a reviewer a really big series that appears from the subject lines to be mostly about another system is really offputting. If you're going to do something like this please at least reply to the messages, that way it's clearer that there's not going to be a dependency problem getting the patches applied (which is part of what makes things offputting).
On 24/11/14 19:39, Mark Brown wrote:
OK... this is all telling me that I *really* need to scrub this in detail. It's all sounding very vague, it's an area which seems to cause lots of problems and I don't want to be sitting here next time around trying to figure out if another rewrite makes things better or worse or if another driver should look similar or different.
I was vague as I don't have the details. I don't know much about the audio side, except from the users side. Jyri can perhaps fill in the details.
But a proper review for sound/ side would be appreciated.
For what it's worth, I can say from a user's perspective that with this series the OMAP HDMI audio finally seems to work so that I'm satisfied with it. While there's still things to improve, it works and I can keep it enabled in the kernel while developing the video side and it doesn't get on my way.
The whole series is about HDMI audio, not video.
You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies.
My point was, there's no particular reason to apply those patches individually. It's an independent series, about HDMI audio, and applying only some of the earlier patches does not improve the kernel in visible manner.
And in any case, I don't like applying individual patches from a series. Usually that just complicates things. If I would apply some of the early patches to fbdev, then this series would no longer work on plain mainline kernel, and would instead depend on fbdev tree. The situation
But I thought everyone was saying this hardware doesn't work anyway and that you want to apply all these changes to fbdev?
I don't particularly _want_ to apply these via fbdev, but I think it's the easiest way. Most of the files touched are in drivers/video/, so hopefully merging via fbdev reduces the chances of conflicts.
And this needs your ack before it can be merged via fbdev tree. Until you've said that you're fine getting this via fbdev, we don't know how this will be merged, and I can't create dependencies to fbdev.
This means we're all then stuck reading reposts of the same enormous series over and over again - as a reviewer a really big series that appears from the subject lines to be mostly about another system is really offputting. If you're going to do something like this please at
Well, yes, I see your point. And I agree that patches that the rest of the series does not depend on should normally be applied individually if the series starts getting multiple revisions (although even those patches could cause conflicts if the rest of the patches touch code nearby).
But that's not the case here, as all the patches are needed to get a working HDMI audio.
least reply to the messages, that way it's clearer that there's not going to be a dependency problem getting the patches applied (which is part of what makes things offputting).
Yes, lack of communication was my mistake.
In any case, how do you want to proceed? As I said, I very much would like to get this into the next merge window and from my point of view the current versions looks good. If you find something to be fixed in the sound/ side, and you're fine with merging this via fbdev, I can start merging the earlier patches in the series so that the next revision is easier to review.
But the merge window is getting close. If you find something very wrong with the series, we can skip this merge window. But if there are only issues that can be easily fixed with follow-up patches, I'd rather merge this revision than do more full review rounds.
Tomi
On Tue, Nov 25, 2014 at 11:26:36AM +0200, Tomi Valkeinen wrote:
On 24/11/14 19:39, Mark Brown wrote:
The whole series is about HDMI audio, not video.
You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies.
My point was, there's no particular reason to apply those patches individually. It's an independent series, about HDMI audio, and applying only some of the earlier patches does not improve the kernel in visible manner.
Can you please apply them, I'll try to get round to reviewing the audio bits soon but either these will need applying if the rest of it's OK or if there does turn out to be a problem they cut down on the size of the series. I really do want to read it closely, but hopefully by the weekend.
On 25/11/14 20:10, Mark Brown wrote:
On Tue, Nov 25, 2014 at 11:26:36AM +0200, Tomi Valkeinen wrote:
On 24/11/14 19:39, Mark Brown wrote:
The whole series is about HDMI audio, not video.
You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies.
My point was, there's no particular reason to apply those patches individually. It's an independent series, about HDMI audio, and applying only some of the earlier patches does not improve the kernel in visible manner.
Can you please apply them, I'll try to get round to reviewing the audio bits soon but either these will need applying if the rest of it's OK or if there does turn out to be a problem they cut down on the size of the series. I really do want to read it closely, but hopefully by the weekend.
Ok, I've picked the following patches:
OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data OMAPDSS: hdmi: Make hdmi structure public OMAPDSS: hdmi_wp: Add function for getting audio dma address OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format()
Tomi
On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote:
The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next
The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: https://github.com/jsarha/linux.git omap-hdmi-audio
I guess I'm OK with these so
Reviewed-by: Mark Brown broonie@kernel.org
but like I said in reply to the patch adding the new driver I think we're going to want to generalize this a bit.
On 29/11/14 13:59, Mark Brown wrote:
On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote:
The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next
The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: https://github.com/jsarha/linux.git omap-hdmi-audio
I guess I'm OK with these so
Reviewed-by: Mark Brown broonie@kernel.org
Thanks. And just to be sure, that's "ok, we can merge these in the next merge window"?
but like I said in reply to the patch adding the new driver I think we're going to want to generalize this a bit.
Yep, if I'm not mistaken I did suggest that to Jyri at some point. We can continue working on that, but I'd rather not do anything big on that front before there is some other SoC that has the same setup.
Tomi
On Mon, Dec 01, 2014 at 11:07:06AM +0200, Tomi Valkeinen wrote:
On 29/11/14 13:59, Mark Brown wrote:
Reviewed-by: Mark Brown broonie@kernel.org
Thanks. And just to be sure, that's "ok, we can merge these in the next merge window"?
Yes.
but like I said in reply to the patch adding the new driver I think we're going to want to generalize this a bit.
Yep, if I'm not mistaken I did suggest that to Jyri at some point. We can continue working on that, but I'd rather not do anything big on that front before there is some other SoC that has the same setup.
I really want to see people making an effort to make code shareable here - I think one of the reasons nobody is upstreaming any of their code is that there's nothing generic in place to handle generic tasks so people just look at their code, think it's too much of a device specific hack and think they'll get back to looking at it later. If this is a sensible set of callbacks to have to pass configuration around let's make that discoverable without requiring people to look through the OMAP drivers.
On 12/01/2014 09:31 PM, Mark Brown wrote:
On Mon, Dec 01, 2014 at 11:07:06AM +0200, Tomi Valkeinen wrote:
On 29/11/14 13:59, Mark Brown wrote:
Reviewed-by: Mark Brown broonie@kernel.org
Thanks. And just to be sure, that's "ok, we can merge these in the next merge window"?
Yes.
but like I said in reply to the patch adding the new driver I think we're going to want to generalize this a bit.
Yep, if I'm not mistaken I did suggest that to Jyri at some point. We can continue working on that, but I'd rather not do anything big on that front before there is some other SoC that has the same setup.
I really want to see people making an effort to make code shareable here
- I think one of the reasons nobody is upstreaming any of their code is
that there's nothing generic in place to handle generic tasks so people just look at their code, think it's too much of a device specific hack and think they'll get back to looking at it later. If this is a sensible set of callbacks to have to pass configuration around let's make that discoverable without requiring people to look through the OMAP drivers.
Ok, I'll make the API more generic after this merge window and maybe move omap-hdmi-audio under sound/soc/generic and rename it. These changes should still be merged under fbdev because of changes to the API header.
Cheers, Jyri
participants (5)
-
Jean-Francois Moine
-
Jyri Sarha
-
Mark Brown
-
Tomi Valkeinen
-
Vladimir Zapolskiy