* [PATCH v7.1 01/19] OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format()
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
@ 2014-11-12 14:40 ` Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 02/19] OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter Jyri Sarha
` (19 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:40 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 02/19] OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 01/19] OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() Jyri Sarha
@ 2014-11-12 14:40 ` Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 03/19] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value Jyri Sarha
` (18 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:40 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 03/19] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 01/19] OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 02/19] OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter Jyri Sarha
@ 2014-11-12 14:40 ` Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 04/19] OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs Jyri Sarha
` (17 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:40 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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 {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 04/19] OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (2 preceding siblings ...)
2014-11-12 14:40 ` [PATCH v7.1 03/19] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value Jyri Sarha
@ 2014-11-12 14:40 ` Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 05/19] OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() Jyri Sarha
` (16 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:40 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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)
{
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 05/19] OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port()
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (3 preceding siblings ...)
2014-11-12 14:40 ` [PATCH v7.1 04/19] OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs Jyri Sarha
@ 2014-11-12 14:40 ` Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 06/19] OMAPDSS: hdmi_wp: Add function for getting audio dma address Jyri Sarha
` (15 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:40 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 06/19] OMAPDSS: hdmi_wp: Add function for getting audio dma address
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (4 preceding siblings ...)
2014-11-12 14:40 ` [PATCH v7.1 05/19] OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() Jyri Sarha
@ 2014-11-12 14:40 ` Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 07/19] OMAPDSS: hdmi: Make hdmi structure public Jyri Sarha
` (14 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:40 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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;
+}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 07/19] OMAPDSS: hdmi: Make hdmi structure public
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (5 preceding siblings ...)
2014-11-12 14:40 ` [PATCH v7.1 06/19] OMAPDSS: hdmi_wp: Add function for getting audio dma address Jyri Sarha
@ 2014-11-12 14:40 ` Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 08/19] OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data Jyri Sarha
` (13 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:40 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 08/19] OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (6 preceding siblings ...)
2014-11-12 14:40 ` [PATCH v7.1 07/19] OMAPDSS: hdmi: Make hdmi structure public Jyri Sarha
@ 2014-11-12 14:40 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 09/19] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support Jyri Sarha
` (12 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:40 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 09/19] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (7 preceding siblings ...)
2014-11-12 14:40 ` [PATCH v7.1 08/19] OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-29 11:32 ` Mark Brown
2014-11-12 14:41 ` [PATCH v7.1 10/19] OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig Jyri Sarha
` (11 subsequent siblings)
20 siblings, 1 reply; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* Re: [PATCH v7.1 09/19] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support
2014-11-12 14:41 ` [PATCH v7.1 09/19] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support Jyri Sarha
@ 2014-11-29 11:32 ` Mark Brown
2014-12-01 7:15 ` Jyri Sarha
0 siblings, 1 reply; 52+ messages in thread
From: Mark Brown @ 2014-11-29 11:32 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood, tomi.valkeinen
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 09/19] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support
2014-11-29 11:32 ` Mark Brown
@ 2014-12-01 7:15 ` Jyri Sarha
2014-12-01 19:21 ` Mark Brown
0 siblings, 1 reply; 52+ messages in thread
From: Jyri Sarha @ 2014-12-01 7:15 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood, tomi.valkeinen
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 09/19] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support
2014-12-01 7:15 ` Jyri Sarha
@ 2014-12-01 19:21 ` Mark Brown
0 siblings, 0 replies; 52+ messages in thread
From: Mark Brown @ 2014-12-01 19:21 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood, tomi.valkeinen
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v7.1 10/19] OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (8 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 09/19] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly Jyri Sarha
` (10 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (9 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 10/19] OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-14 14:37 ` Vladimir Zapolskiy
2014-11-12 14:41 ` [PATCH v7.1 12/19] OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation Jyri Sarha
` (9 subsequent siblings)
20 siblings, 1 reply; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
2014-11-12 14:41 ` [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly Jyri Sarha
@ 2014-11-14 14:37 ` Vladimir Zapolskiy
2014-11-14 15:05 ` Jyri Sarha
2014-11-15 15:52 ` Vladimir Zapolskiy
0 siblings, 2 replies; 52+ messages in thread
From: Vladimir Zapolskiy @ 2014-11-14 14:37 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen
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
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
2014-11-14 14:37 ` Vladimir Zapolskiy
@ 2014-11-14 15:05 ` Jyri Sarha
2014-11-17 15:12 ` Vladimir Zapolskiy
2014-11-15 15:52 ` Vladimir Zapolskiy
1 sibling, 1 reply; 52+ messages in thread
From: Jyri Sarha @ 2014-11-14 15:05 UTC (permalink / raw)
To: Vladimir Zapolskiy, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, liam.r.girdwood, tomi.valkeinen, broonie
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?
>
> 1) 13/19
> 2) 15/19
> 3) 11/19
> 4) 14/19
> 5) 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
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
2014-11-14 15:05 ` Jyri Sarha
@ 2014-11-17 15:12 ` Vladimir Zapolskiy
0 siblings, 0 replies; 52+ messages in thread
From: Vladimir Zapolskiy @ 2014-11-17 15:12 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen
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?
>>
>> 1) 13/19
>> 2) 15/19
>> 3) 11/19
>> 4) 14/19
>> 5) 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
2014-11-14 14:37 ` Vladimir Zapolskiy
2014-11-14 15:05 ` Jyri Sarha
@ 2014-11-15 15:52 ` Vladimir Zapolskiy
1 sibling, 0 replies; 52+ messages in thread
From: Vladimir Zapolskiy @ 2014-11-15 15:52 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen
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?
>
> 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.
sorry, git bisect of course.
--
With best wishes,
Vladimir
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v7.1 12/19] OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (10 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 13/19] OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver Jyri Sarha
` (8 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 13/19] OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (11 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 12/19] OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 14/19] OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio Jyri Sarha
` (7 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 14/19] OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (12 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 13/19] OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 15/19] OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver Jyri Sarha
` (6 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 15/19] OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (13 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 14/19] OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 16/19] OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio Jyri Sarha
` (5 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 16/19] OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (14 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 15/19] OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 17/19] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options Jyri Sarha
` (4 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 17/19] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (15 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 16/19] OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 18/19] OMAPDSS: Remove all references to obsolete HDMI audio callbacks Jyri Sarha
` (3 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 18/19] OMAPDSS: Remove all references to obsolete HDMI audio callbacks
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (16 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 17/19] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 19/19] OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback Jyri Sarha
` (2 subsequent siblings)
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH v7.1 19/19] OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (17 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 18/19] OMAPDSS: Remove all references to obsolete HDMI audio callbacks Jyri Sarha
@ 2014-11-12 14:41 ` Jyri Sarha
2014-11-12 22:23 ` [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Mark Brown
2014-11-29 11:59 ` Mark Brown
20 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-12 14:41 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
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,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 52+ messages in thread* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (18 preceding siblings ...)
2014-11-12 14:41 ` [PATCH v7.1 19/19] OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback Jyri Sarha
@ 2014-11-12 22:23 ` Mark Brown
2014-11-13 8:05 ` Tomi Valkeinen
2014-11-29 11:59 ` Mark Brown
20 siblings, 1 reply; 52+ messages in thread
From: Mark Brown @ 2014-11-12 22:23 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood, tomi.valkeinen
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
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?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-12 22:23 ` [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Mark Brown
@ 2014-11-13 8:05 ` Tomi Valkeinen
2014-11-13 9:17 ` [alsa-devel] " Jean-Francois Moine
2014-11-20 10:59 ` Tomi Valkeinen
0 siblings, 2 replies; 52+ messages in thread
From: Tomi Valkeinen @ 2014-11-13 8:05 UTC (permalink / raw)
To: Mark Brown, Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-13 8:05 ` Tomi Valkeinen
@ 2014-11-13 9:17 ` Jean-Francois Moine
2014-11-13 10:00 ` Tomi Valkeinen
2014-11-20 10:59 ` Tomi Valkeinen
1 sibling, 1 reply; 52+ messages in thread
From: Jean-Francois Moine @ 2014-11-13 9:17 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mark Brown, Jyri Sarha, peter.ujfalusi, liam.r.girdwood,
alsa-devel, linux-omap, linux-fbdev
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.html
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.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-13 9:17 ` [alsa-devel] " Jean-Francois Moine
@ 2014-11-13 10:00 ` Tomi Valkeinen
2014-11-13 14:54 ` Jyri Sarha
2014-11-13 14:57 ` Jean-Francois Moine
0 siblings, 2 replies; 52+ messages in thread
From: Tomi Valkeinen @ 2014-11-13 10:00 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: liam.r.girdwood, alsa-devel, linux-fbdev, Jyri Sarha,
peter.ujfalusi, Mark Brown, linux-omap
[-- Attachment #1: Type: text/plain, Size: 4617 bytes --]
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.html
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-13 10:00 ` Tomi Valkeinen
@ 2014-11-13 14:54 ` Jyri Sarha
2014-11-13 14:57 ` Jean-Francois Moine
1 sibling, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-13 14:54 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Francois Moine
Cc: Mark Brown, peter.ujfalusi, liam.r.girdwood, alsa-devel,
linux-omap, linux-fbdev
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...
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-13 10:00 ` Tomi Valkeinen
2014-11-13 14:54 ` Jyri Sarha
@ 2014-11-13 14:57 ` Jean-Francois Moine
2014-11-13 15:44 ` Tomi Valkeinen
1 sibling, 1 reply; 52+ messages in thread
From: Jean-Francois Moine @ 2014-11-13 14:57 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mark Brown, Jyri Sarha, peter.ujfalusi, liam.r.girdwood,
alsa-devel, linux-omap, linux-fbdev
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?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-13 14:57 ` Jean-Francois Moine
@ 2014-11-13 15:44 ` Tomi Valkeinen
2014-11-14 10:59 ` Jean-Francois Moine
0 siblings, 1 reply; 52+ messages in thread
From: Tomi Valkeinen @ 2014-11-13 15:44 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Mark Brown, Jyri Sarha, peter.ujfalusi, liam.r.girdwood,
alsa-devel, linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 4763 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-13 15:44 ` Tomi Valkeinen
@ 2014-11-14 10:59 ` Jean-Francois Moine
0 siblings, 0 replies; 52+ messages in thread
From: Jean-Francois Moine @ 2014-11-14 10:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mark Brown, Jyri Sarha, peter.ujfalusi, liam.r.girdwood,
alsa-devel, linux-omap, linux-fbdev
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.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-13 8:05 ` Tomi Valkeinen
2014-11-13 9:17 ` [alsa-devel] " Jean-Francois Moine
@ 2014-11-20 10:59 ` Tomi Valkeinen
2014-11-21 11:23 ` Mark Brown
1 sibling, 1 reply; 52+ messages in thread
From: Tomi Valkeinen @ 2014-11-20 10:59 UTC (permalink / raw)
To: Mark Brown, Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-20 10:59 ` Tomi Valkeinen
@ 2014-11-21 11:23 ` Mark Brown
2014-11-21 12:10 ` Jyri Sarha
2014-11-21 12:35 ` Jyri Sarha
0 siblings, 2 replies; 52+ messages in thread
From: Mark Brown @ 2014-11-21 11:23 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-21 11:23 ` Mark Brown
@ 2014-11-21 12:10 ` Jyri Sarha
2014-11-21 16:38 ` Mark Brown
2014-11-21 12:35 ` Jyri Sarha
1 sibling, 1 reply; 52+ messages in thread
From: Jyri Sarha @ 2014-11-21 12:10 UTC (permalink / raw)
To: Mark Brown, Tomi Valkeinen
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
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.
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-21 12:10 ` Jyri Sarha
@ 2014-11-21 16:38 ` Mark Brown
2014-11-24 8:48 ` Tomi Valkeinen
2014-11-24 14:55 ` Jyri Sarha
0 siblings, 2 replies; 52+ messages in thread
From: Mark Brown @ 2014-11-21 16:38 UTC (permalink / raw)
To: Jyri Sarha
Cc: Tomi Valkeinen, alsa-devel, linux-fbdev, linux-omap,
peter.ujfalusi, liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-21 16:38 ` Mark Brown
@ 2014-11-24 8:48 ` Tomi Valkeinen
2014-11-24 14:55 ` Jyri Sarha
1 sibling, 0 replies; 52+ messages in thread
From: Tomi Valkeinen @ 2014-11-24 8:48 UTC (permalink / raw)
To: Mark Brown, Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-21 16:38 ` Mark Brown
2014-11-24 8:48 ` Tomi Valkeinen
@ 2014-11-24 14:55 ` Jyri Sarha
1 sibling, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-11-24 14:55 UTC (permalink / raw)
To: Mark Brown
Cc: Tomi Valkeinen, alsa-devel, linux-fbdev, linux-omap,
peter.ujfalusi, liam.r.girdwood
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-21 11:23 ` Mark Brown
2014-11-21 12:10 ` Jyri Sarha
@ 2014-11-21 12:35 ` Jyri Sarha
2014-11-21 16:14 ` Mark Brown
1 sibling, 1 reply; 52+ messages in thread
From: Jyri Sarha @ 2014-11-21 12:35 UTC (permalink / raw)
To: Mark Brown, Tomi Valkeinen
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-21 12:35 ` Jyri Sarha
@ 2014-11-21 16:14 ` Mark Brown
2014-11-24 8:18 ` Tomi Valkeinen
0 siblings, 1 reply; 52+ messages in thread
From: Mark Brown @ 2014-11-21 16:14 UTC (permalink / raw)
To: Jyri Sarha
Cc: Tomi Valkeinen, alsa-devel, linux-fbdev, linux-omap,
peter.ujfalusi, liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-21 16:14 ` Mark Brown
@ 2014-11-24 8:18 ` Tomi Valkeinen
2014-11-24 17:39 ` Mark Brown
0 siblings, 1 reply; 52+ messages in thread
From: Tomi Valkeinen @ 2014-11-24 8:18 UTC (permalink / raw)
To: Mark Brown, Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-24 8:18 ` Tomi Valkeinen
@ 2014-11-24 17:39 ` Mark Brown
2014-11-25 9:26 ` Tomi Valkeinen
0 siblings, 1 reply; 52+ messages in thread
From: Mark Brown @ 2014-11-24 17:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 2730 bytes --]
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).
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-24 17:39 ` Mark Brown
@ 2014-11-25 9:26 ` Tomi Valkeinen
2014-11-25 18:10 ` Mark Brown
0 siblings, 1 reply; 52+ messages in thread
From: Tomi Valkeinen @ 2014-11-25 9:26 UTC (permalink / raw)
To: Mark Brown
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 3767 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-25 9:26 ` Tomi Valkeinen
@ 2014-11-25 18:10 ` Mark Brown
2014-11-26 11:02 ` Tomi Valkeinen
0 siblings, 1 reply; 52+ messages in thread
From: Mark Brown @ 2014-11-25 18:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-25 18:10 ` Mark Brown
@ 2014-11-26 11:02 ` Tomi Valkeinen
0 siblings, 0 replies; 52+ messages in thread
From: Tomi Valkeinen @ 2014-11-26 11:02 UTC (permalink / raw)
To: Mark Brown
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
` (19 preceding siblings ...)
2014-11-12 22:23 ` [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Mark Brown
@ 2014-11-29 11:59 ` Mark Brown
2014-12-01 9:07 ` Tomi Valkeinen
20 siblings, 1 reply; 52+ messages in thread
From: Mark Brown @ 2014-11-29 11:59 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood, tomi.valkeinen
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-11-29 11:59 ` Mark Brown
@ 2014-12-01 9:07 ` Tomi Valkeinen
2014-12-01 19:31 ` Mark Brown
0 siblings, 1 reply; 52+ messages in thread
From: Tomi Valkeinen @ 2014-12-01 9:07 UTC (permalink / raw)
To: Mark Brown, Jyri Sarha
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-12-01 9:07 ` Tomi Valkeinen
@ 2014-12-01 19:31 ` Mark Brown
2014-12-02 8:52 ` Jyri Sarha
0 siblings, 1 reply; 52+ messages in thread
From: Mark Brown @ 2014-12-01 19:31 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
2014-12-01 19:31 ` Mark Brown
@ 2014-12-02 8:52 ` Jyri Sarha
0 siblings, 0 replies; 52+ messages in thread
From: Jyri Sarha @ 2014-12-02 8:52 UTC (permalink / raw)
To: Mark Brown, Tomi Valkeinen
Cc: alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
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
^ permalink raw reply [flat|nested] 52+ messages in thread