* [PATCH v7 16/20] OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 15/20] OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 14/20] OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 13/20] OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 12/20] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 11/20] OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 10/20] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 09/20] OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 08/20] OMAPDSS: hdmi: Make hdmi structure public
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 07/20] OMAPDSS: hdmi_wp: Add function for getting audio dma address
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 06/20] OMAPDSS: omapdss.h: Remove audio_state member of struct omap_dss_device
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
The audio_state member is not used.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
include/video/omapdss.h | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 069dfca..9f2699f 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;
@@ -783,8 +776,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;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v7 05/20] OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port()
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 04/20] OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 03/20] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 02/20] OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 01/20] OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format()
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
In-Reply-To: <cover.1415786458.git.jsarha@ti.com>
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
* [PATCH v7 00/20] Rework OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-11-12 10:49 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen,
Jyri Sarha
The patches are based on:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next
The base, the patches, and couple of additional not-to-be-merged
omap2plus_defconfig patches can be found here:
https://github.com/jsarha/linux.git omap-hdmi-audio
It would make the most sense to get these in trough fbdev tree. So it
would be nice to get acked-bys (if the patches are Ok) for ASoC side
changes from appropriate maintainers.
Changes since v6:
- "ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support"
- Fix Kconfig help text
- Remove #include <sound/simple_card.h>
- Use snd-soc-dummy codec instead of hdmi-audio-codec
- Add: OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format()
- Add: OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter
- Add: "OMAPDSS: omapdss.h: Remove audio_state member of struct omap_dss_device"
- "OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio"
- Register "omap-hdmi-audio" with PLATFORM_DEVID_AUTO
- "OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio"
- Register "omap-hdmi-audio" with PLATFORM_DEVID_AUTO
- Add: "OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback"
Jyri Sarha (20):
OMAPDSS: hdmi_wp: Protect reserved bits in
hdmi_wp_audio_config_format()
OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter
OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs
OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port()
OMAPDSS: omapdss.h: Remove audio_state member of struct
omap_dss_device
OMAPDSS: hdmi_wp: Add function for getting audio dma address
OMAPDSS: hdmi: Make hdmi structure public
OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data
ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio
support
OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig
OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation
OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver
OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio
OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver
OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio
ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
OMAPDSS: Remove all references to obsolete HDMI audio callbacks
OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio
playback
.../fbdev/omap2/displays-new/connector-hdmi.c | 99 -----
.../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 ---
drivers/video/fbdev/omap2/dss/Kconfig | 7 -
drivers/video/fbdev/omap2/dss/hdmi.h | 38 +-
drivers/video/fbdev/omap2/dss/hdmi4.c | 269 +++++++------
drivers/video/fbdev/omap2/dss/hdmi4_core.c | 14 -
drivers/video/fbdev/omap2/dss/hdmi4_core.h | 4 -
drivers/video/fbdev/omap2/dss/hdmi5.c | 265 ++++++-------
drivers/video/fbdev/omap2/dss/hdmi5_core.c | 9 +-
drivers/video/fbdev/omap2/dss/hdmi5_core.h | 2 -
drivers/video/fbdev/omap2/dss/hdmi_common.c | 2 -
drivers/video/fbdev/omap2/dss/hdmi_wp.c | 16 +-
include/sound/omap-hdmi-audio.h | 43 +++
include/video/omapdss.h | 40 --
sound/soc/omap/Kconfig | 26 +-
sound/soc/omap/Makefile | 6 +-
sound/soc/omap/omap-hdmi-audio.c | 407 ++++++++++++++++++++
sound/soc/omap/omap-hdmi-card.c | 87 -----
sound/soc/omap/omap-hdmi.c | 364 -----------------
sound/soc/omap/omap-hdmi.h | 38 --
20 files changed, 781 insertions(+), 1011 deletions(-)
create mode 100644 include/sound/omap-hdmi-audio.h
create mode 100644 sound/soc/omap/omap-hdmi-audio.c
delete mode 100644 sound/soc/omap/omap-hdmi-card.c
delete mode 100644 sound/soc/omap/omap-hdmi.c
delete mode 100644 sound/soc/omap/omap-hdmi.h
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Grant Likely @ 2014-11-12 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVX72ve9TqpA9GUtumZGDnCjYqKemMxyNf=a4AxWR44iQ@mail.gmail.com>
On Wed, Nov 12, 2014 at 10:08 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Grant,
>
> On Wed, Nov 12, 2014 at 10:57 AM, Grant Likely <grant.likely@linaro.org> wrote:
>> On Wednesday, November 12, 2014, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely <grant.likely@linaro.org> wrote:
>>> > However, I am concerned about handover. I've lost track over the entire
>>> > thread on whether the handover mechanism has been resolved, and I would
>>> > really like to have a proposed solution to this documented in the
>>> > binding. The fact that there is nothing tying the simple framebuffer to
>>> > the actual hardware backing the framebuffer is concerning. It means the
>>> > kernel needs to guess which graphics device is associated with the
>>> > framebuffer.
>>>
>>> We did discuss handover in Düsseldorf, and concluded that the simplefb's
>>> regs property can be used for this.
>>>
>>> While on a modern system with unified memory this association cannot be
>>> derived in a generic way, a device-specific driver for the graphics hardware
>>> can if the regs property of the simplefb node matches the address the CRTC
>>> engine is configured for.
>>
>> ???
>>
>> Right, I'm going to be blunt here: That's just dumb. All the
>> capability needed is there in the DT to associate a simple FB to a
>> display controller, and the solution chosen is to use a heuristic?
>>
>> The association needs to be explicit. I strongly prefer putting the
>> simple FB directly into the display controller node, but I would
>> consider phandle linkage also.
>
> IFF there's a display controller node, you can put it there.
> I actually proposed to have a minimal/preliminary display controller node,
> but people countered that for various reasons (too many components
> with multiple nodes on many systems, bindings not yet defined, etc.).
>
> And if there's no graphics driver/bindings yet at the time the bootloader
> is written, it doesn't know how to link simplefb with it in DT.
> Hence the heuristic to match regs... Does that make sense?
No, not really. The simplefb binding /should/ make it clear that
handover to the real display controller driver is an expected use
case; therefore the simplefb binding should itemize exactly how that
linkage is supposed to be expressed. When the display controller
binding is written, it should go hand in glove with the simplefb
binding. We want to be sure that generic code can be used to resolve a
display controller with (one of) the simple framebuffers.
It also sounds like some are making the assumption that firmware
should generate the simplefb node from scratch, hence all the hand
wringing about firmware not knowing what extra stuff to put into the
simplefb node. I don't think this is necessary, or even a good
approach. A disabled simplefb node can be put into the dts file with
any dependencies it needs to care about and linkage to the real
display controller. Firmware should be able to locate that node,
update the parameters as needed, and enable it. That gets out of the
cycle of updating firmware in lockstep.
g.
^ permalink raw reply
* Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Geert Uytterhoeven @ 2014-11-12 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6sMF2C6hvRNNnB_i6a44fh0WC7JjjisFOh5GMV66mC6Fw@mail.gmail.com>
Hi Grant,
On Wed, Nov 12, 2014 at 10:57 AM, Grant Likely <grant.likely@linaro.org> wrote:
> On Wednesday, November 12, 2014, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely <grant.likely@linaro.org> wrote:
>> > However, I am concerned about handover. I've lost track over the entire
>> > thread on whether the handover mechanism has been resolved, and I would
>> > really like to have a proposed solution to this documented in the
>> > binding. The fact that there is nothing tying the simple framebuffer to
>> > the actual hardware backing the framebuffer is concerning. It means the
>> > kernel needs to guess which graphics device is associated with the
>> > framebuffer.
>>
>> We did discuss handover in Düsseldorf, and concluded that the simplefb's
>> regs property can be used for this.
>>
>> While on a modern system with unified memory this association cannot be
>> derived in a generic way, a device-specific driver for the graphics hardware
>> can if the regs property of the simplefb node matches the address the CRTC
>> engine is configured for.
>
> ???
>
> Right, I'm going to be blunt here: That's just dumb. All the
> capability needed is there in the DT to associate a simple FB to a
> display controller, and the solution chosen is to use a heuristic?
>
> The association needs to be explicit. I strongly prefer putting the
> simple FB directly into the display controller node, but I would
> consider phandle linkage also.
IFF there's a display controller node, you can put it there.
I actually proposed to have a minimal/preliminary display controller node,
but people countered that for various reasons (too many components
with multiple nodes on many systems, bindings not yet defined, etc.).
And if there's no graphics driver/bindings yet at the time the bootloader
is written, it doesn't know how to link simplefb with it in DT.
Hence the heuristic to match regs... Does that make sense?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Grant Likely @ 2014-11-12 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUoPK_s7OP1Aop4eOyhec+abFij7ZoAAdA5fqpJJy-Dgg@mail.gmail.com>
On Wednesday, November 12, 2014, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Grant,
>
> On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely <grant.likely@linaro.org> wrote:
> > However, I am concerned about handover. I've lost track over the entire
> > thread on whether the handover mechanism has been resolved, and I would
> > really like to have a proposed solution to this documented in the
> > binding. The fact that there is nothing tying the simple framebuffer to
> > the actual hardware backing the framebuffer is concerning. It means the
> > kernel needs to guess which graphics device is associated with the
> > framebuffer.
>
> We did discuss handover in Düsseldorf, and concluded that the simplefb's
> regs property can be used for this.
>
> While on a modern system with unified memory this association cannot be
> derived in a generic way, a device-specific driver for the graphics hardware
> can if the regs property of the simplefb node matches the address the CRTC
> engine is configured for.
???
Right, I'm going to be blunt here: That's just dumb. All the
capability needed is there in the DT to associate a simple FB to a
display controller, and the solution chosen is to use a heuristic?
The association needs to be explicit. I strongly prefer putting the
simple FB directly into the display controller node, but I would
consider phandle linkage also.
g.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Geert Uytterhoeven @ 2014-11-12 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141111214950.7FCABC41610@trevor.secretlab.ca>
Hi Grant,
On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely <grant.likely@linaro.org> wrote:
> However, I am concerned about handover. I've lost track over the entire
> thread on whether the handover mechanism has been resolved, and I would
> really like to have a proposed solution to this documented in the
> binding. The fact that there is nothing tying the simple framebuffer to
> the actual hardware backing the framebuffer is concerning. It means the
> kernel needs to guess which graphics device is associated with the
> framebuffer.
We did discuss handover in Düsseldorf, and concluded that the simplefb's
regs property can be used for this.
While on a modern system with unified memory this association cannot be
derived in a generic way, a device-specific driver for the graphics hardware
can if the regs property of the simplefb node matches the address the CRTC
engine is configured for.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] video: fbdev: Add CVT timing calculations.
From: David Ung @ 2014-11-11 22:54 UTC (permalink / raw)
To: linux-fbdev
Currently fbmon is still relying on the old GTF timings when parsing
the standard timings of the EDID.
This causes problem with some monitor eg DELL U2410 which advertises
high resolutions like 1920x1200@60 and GTF timing gives it 193mhz
clock which is out of spec of the monitor which has dclkmax of 170mhz.
This patch address the above problem by adding support for CVT with
reduced timings.
Signed-off-by: David Ung <davidu@nvidia.com>
---
drivers/video/fbdev/core/fbmon.c | 92 +++++++++++++++++++++++++++++++++-------
1 file changed, 77 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 5b0e313..8d4ec9f 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -21,6 +21,11 @@
* GTF Spreadsheet by Andy Morrish (1/5/97)
* available at http://www.vesa.org
*
+ * Coordinated Video Timing is derived from:
+ *
+ * CVT Spreadsheet by Graham Loveridge (9/Apr/2003)
+ * available at http://www.vesa.org
+ *
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
* for more details.
@@ -383,17 +388,21 @@ static void get_chroma(unsigned char *block, struct fb_monspecs *specs)
}
static void calc_mode_timings(int xres, int yres, int refresh,
- struct fb_videomode *mode)
+ struct fb_videomode *mode,
+ struct fb_monspecs *specs)
{
struct fb_var_screeninfo *var;
+ struct fb_info info;
var = kzalloc(sizeof(struct fb_var_screeninfo), GFP_KERNEL);
+ if (specs)
+ memcpy(&info.monspecs, specs, sizeof(struct fb_monspecs));
if (var) {
var->xres = xres;
var->yres = yres;
- fb_get_mode(FB_VSYNCTIMINGS | FB_IGNOREMON,
- refresh, var, NULL);
+ fb_get_mode(FB_VSYNCTIMINGS | FB_IGNOREMON, refresh, var,
+ specs && !specs->gtf ? &info : NULL);
mode->xres = xres;
mode->yres = yres;
mode->pixclock = var->pixclock;
@@ -417,12 +426,12 @@ static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
c = block[0];
if (c&0x80) {
- calc_mode_timings(720, 400, 70, &mode[num]);
+ calc_mode_timings(720, 400, 70, &mode[num], NULL);
mode[num++].flag = FB_MODE_IS_CALCULATED;
DPRINTK(" 720x400@70Hz\n");
}
if (c&0x40) {
- calc_mode_timings(720, 400, 88, &mode[num]);
+ calc_mode_timings(720, 400, 88, &mode[num], NULL);
mode[num++].flag = FB_MODE_IS_CALCULATED;
DPRINTK(" 720x400@88Hz\n");
}
@@ -431,7 +440,7 @@ static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
DPRINTK(" 640x480@60Hz\n");
}
if (c&0x10) {
- calc_mode_timings(640, 480, 67, &mode[num]);
+ calc_mode_timings(640, 480, 67, &mode[num], NULL);
mode[num++].flag = FB_MODE_IS_CALCULATED;
DPRINTK(" 640x480@67Hz\n");
}
@@ -462,7 +471,7 @@ static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
DPRINTK(" 800x600@75Hz\n");
}
if (c&0x20) {
- calc_mode_timings(832, 624, 75, &mode[num]);
+ calc_mode_timings(832, 624, 75, &mode[num], NULL);
mode[num++].flag = FB_MODE_IS_CALCULATED;
DPRINTK(" 832x624@75Hz\n");
}
@@ -496,7 +505,7 @@ static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
}
static int get_std_timing(unsigned char *block, struct fb_videomode *mode,
- int ver, int rev)
+ int ver, int rev, struct fb_monspecs *specs)
{
int xres, yres = 0, refresh, ratio, i;
@@ -535,7 +544,7 @@ static int get_std_timing(unsigned char *block, struct fb_videomode *mode,
return 1;
}
}
- calc_mode_timings(xres, yres, refresh, mode);
+ calc_mode_timings(xres, yres, refresh, mode, specs);
return 1;
}
@@ -545,7 +554,7 @@ static int get_dst_timing(unsigned char *block,
int j, num = 0;
for (j = 0; j < 6; j++, block += STD_TIMING_DESCRIPTION_SIZE)
- num += get_std_timing(block, &mode[num], ver, rev);
+ num += get_std_timing(block, &mode[num], ver, rev, NULL);
return num;
}
@@ -601,7 +610,8 @@ static void get_detailed_timing(unsigned char *block,
* This function builds a mode database using the contents of the EDID
* data
*/
-static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize)
+static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize,
+ struct fb_monspecs *specs)
{
struct fb_videomode *mode, *m;
unsigned char *block;
@@ -643,7 +653,7 @@ static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize)
DPRINTK(" Standard Timings\n");
block = edid + STD_TIMING_DESCRIPTIONS_START;
for (i = 0; i < STD_TIMING; i++, block += STD_TIMING_DESCRIPTION_SIZE)
- num += get_std_timing(block, &mode[num], ver, rev);
+ num += get_std_timing(block, &mode[num], ver, rev, specs);
block = edid + DETAILED_TIMING_DESCRIPTIONS_START;
for (i = 0; i < 4; i++, block+= DETAILED_TIMING_DESCRIPTION_SIZE) {
@@ -707,7 +717,7 @@ static int fb_get_monitor_limits(unsigned char *edid, struct fb_monspecs *specs)
int num_modes, hz, hscan, pixclock;
int vtotal, htotal;
- modes = fb_create_modedb(edid, &num_modes);
+ modes = fb_create_modedb(edid, &num_modes, NULL);
if (!modes) {
DPRINTK("None Available\n");
return 1;
@@ -964,7 +974,7 @@ void fb_edid_to_monspecs(unsigned char *edid, struct fb_monspecs *specs)
DPRINTK(" Display Characteristics:\n");
get_monspecs(edid, specs);
- specs->modedb = fb_create_modedb(edid, &specs->modedb_len);
+ specs->modedb = fb_create_modedb(edid, &specs->modedb_len, specs);
/*
* Workaround for buggy EDIDs that sets that the first
@@ -1255,6 +1265,55 @@ static void fb_timings_dclk(struct __fb_timings *timings)
}
/*
+ * All calculations are based on the VESA CVT Spreadsheet
+ * available at VESA's public ftp (http://www.vesa.org).
+ *
+ * The names of variables are kept to match as closely to the names
+ * that appears in the spreadsheet.
+ */
+#define RB_MIN_V_BLANK 460
+#define RB_H_BLANK 160
+#define CELL_GRAN 8
+#define CLOCK_STEP 250
+#define RB_V_FPORCH 3
+#define V_SYNC_RND 6
+#define MIN_V_BPORCH 6
+
+static void fb_timings_vfreq_cvt(struct __fb_timings *timings)
+{
+ u32 v_lines_rnd, h_period_est, vbi_line, rb_min_vbi, act_vbi_lines;
+ u32 total_v_lines, h_pixels_rnd, total_active_pixels, total_pixels;
+ u32 act_pixel_freq;
+ u32 v_field_rate_rqd = timings->vfreq;
+ u32 h_pixels = timings->hactive;
+ u32 v_lines = timings->vactive;
+
+ v_lines_rnd = v_lines;
+ h_period_est = 1000000 / v_field_rate_rqd - RB_MIN_V_BLANK;
+ h_period_est = h_period_est / v_lines_rnd;
+ vbi_line = RB_MIN_V_BLANK / h_period_est;
+ rb_min_vbi = RB_V_FPORCH + V_SYNC_RND + MIN_V_BPORCH;
+ if (vbi_line < rb_min_vbi)
+ act_vbi_lines = rb_min_vbi;
+ else
+ act_vbi_lines = vbi_line;
+ total_v_lines = act_vbi_lines + v_lines_rnd;
+ h_pixels_rnd = (h_pixels / CELL_GRAN) * CELL_GRAN;
+ total_active_pixels = h_pixels_rnd;
+ total_pixels = RB_H_BLANK + total_active_pixels;
+ act_pixel_freq = v_field_rate_rqd * total_v_lines * total_pixels;
+ act_pixel_freq /= 1000;
+ act_pixel_freq = act_pixel_freq / CLOCK_STEP * CLOCK_STEP * 1000;
+
+ timings->hfreq = act_pixel_freq / total_pixels;
+ timings->vblank = act_vbi_lines;
+ timings->vtotal = timings->vactive + timings->vblank;
+ timings->hblank = RB_H_BLANK;
+ timings->htotal = timings->hactive + timings->hblank;
+ timings->dclk = timings->htotal * timings->hfreq;
+}
+
+/*
* fb_get_mode - calculates video mode using VESA GTF
* @flags: if: 0 - maximize vertical refresh rate
* 1 - vrefresh-driven calculation;
@@ -1347,7 +1406,10 @@ int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_inf
break;
case FB_VSYNCTIMINGS: /* vrefresh driven */
timings->vfreq = val;
- fb_timings_vfreq(timings);
+ if (info && !info->monspecs.gtf)
+ fb_timings_vfreq_cvt(timings);
+ else
+ fb_timings_vfreq(timings);
break;
case FB_HSYNCTIMINGS: /* hsync driven */
timings->hfreq = val;
--
1.8.1.5
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply related
* Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Grant Likely @ 2014-11-11 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <545B8E29.90807@redhat.com>
On Thu, 06 Nov 2014 16:05:13 +0100
, Hans de Goede <hdegoede@redhat.com>
wrote:
> Hi,
>
> On 11/06/2014 03:18 PM, Tomi Valkeinen wrote:
> > On 31/10/14 10:15, Tomi Valkeinen wrote:
> >> Hi Hans,
> >>
> >> On 22/10/14 19:45, Hans de Goede wrote:
> >>
> >>> -We will add a clocks property to the simplefb devicetree bindings, so
> >>> that u-boot setup framebuffers passed to the kernel (for early console
> >>> support) can properly list the clocks used, and simplefb can claim them to
> >>> avoid them getting turned off, thereby breaking the early console
> >>
> >> Perhaps this has been discussed earlier, but I started to wonder if
> >> managing clocks is enough.
> >>
> >> What about regulators (to power the LCD), gpios (to keep the LCD
> >> enabled) and pinctrl (for video signals)? I guess any those could be
> >> reset by the kernel if no driver uses them.
I'm okay with extending the binding for each of these dependencies
/providing/ it can be argued that the way simplefb uses it is merely to
inhibit the kernel from making any changes to the resource, and then
releasing the resource when it is done. Each resource type will need to
be taken on a case-by-case basis since each has it's own behaviour. I'll
want to see that the simplefb driver doesn't need to do anything special
per device, and that the resource binding is well established and
generic.
g.
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
From: Grant Likely @ 2014-11-11 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKWqq+H5ymUW3n8tkmLJHEUGaKDLX5+orJmGUQ3ECQwUQ@mail.gmail.com>
On Sat, 1 Nov 2014 04:47:56 +0800
, Rob Herring <robherring2@gmail.com>
wrote:
> On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi Hans, Rob,
> >
> > On 28/10/14 13:30, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 10/28/2014 12:11 PM, Rob Herring wrote:
> >
> >>> Yes, I object to the binding still as it has not changed from what was
> >>> previously posted.
> >>
> >> It would be helpful if you could explain why you object. Last time you
> >> said: " You are mixing in a hardware description that is simply inaccurate."
> >>
> >> I then explained that this is not hardware description, but runtime state
> >> information, as it tells the kernel which clocks were chosen to drive the
> >> display (out of typically a list of possible options, depending on which
> >> output is used, etc.). Just like which memory address the bootloader has
> >> chosen to scan out the video image from.
> >>
> >> Then you got quiet, so sorry, but this time your objection really is too
> >> late. You cannot simply go quiet halfway through a discussion and then pop
> >> up again when a new version is posted to say "I object" yet another time,
> >> you've had your chance to make your arguments last time, and chose to stay
> >> quiet after I explained in detail that this is not hardware description but
> >> state information, so now it is simply too late.
> >>
> >> These bindings have been discussed at Plumbers with various interested people
> >> present, and the conclusion was that this really is the best way to handle this,
> >> so this patch is:
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> Reviewed-by: Mike Turquette <mturquette@linaro.org>
> >> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>
> >> And David Herrman who is working on simpledrm, which will be merged soon, which
> >> will also use the simplefb bindings also agrees. So we have the simplefb maintainer,
> >> simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all
> >> agreeing on a way forward, the time for bikeshedding now really really really is
> >> over.
> >>
> >> Tomi, can you please let us know how you plan to proceed with this ?
> >
> > I won't merge DT bindings via fbdev tree, if a DT maintainer says no.
> >
> > I took Rob's silence to the earlier series as a silent ack for your
> > explanation. Obviously that was not the case.
> >
> > Rob, please advice asap what should be done to the bindings to get your
> > ack. As Hans explained above, this discussion has been going on for a
> > long time, and afaik this series is the best way forward of all the
> > options discussed.
>
> I still think for the most part this is a kernel problem. It is a
> kernel policy to turn off unused clocks. The clock framework could
> just as easily decide that any clocks enabled at boot and left
> un-managed (i.e. w/o a driver) are kept on until they are managed. I'm
> not saying this can't be in DT, only that DT is not the only solution
> here. This problem is not unique to simplefb. A serial console could
> stop working if no serial driver is loaded before unused clocks are
> disabled. CPU core clocks have a similar issue as well (often enabled
> in platform code). I want to see this solved in a generic way for any
> clock.
I've spent most of today rereading the entire thread and thinking about
this issue. Given that the clock binding is a well established core
binding at this point, it is entirely reasonable for a generic driver to
have part of the binding specify the clock resources that it depends on
to keep working. The binding needs to be very clear that it is a mere
dependency, and that the OS must not make any attempt to modify the
clock settings, but it is reasonable indicate to the OS that the clocks
are used by the firmware framebuffer, and turning them off will cause
the framebuffer will break. The best place to provide that guidance is
directly in the node.
If we were talking about a resource that didn't have a well established
binding, ie, the video path configuration, then I'd still say no way
because there is no way to do it generically. Claiming clocks on the
other hand is straight forward and simple.
Aside from wanting the documentation to be more explicit about what the
driver does with the clocks, I don't have a problem with doing it.
However, I am concerned about handover. I've lost track over the entire
thread on whether the handover mechanism has been resolved, and I would
really like to have a proposed solution to this documented in the
binding. The fact that there is nothing tying the simple framebuffer to
the actual hardware backing the framebuffer is concerning. It means the
kernel needs to guess which graphics device is associated with the
framebuffer.
The best solution in my opinion is to embed the simplefb properties
directly into the graphics device node (Yes, I know some have argued
that the graphics subsystem is composed of multiple devices; That
doesn't matter. Just choose one of the device nodes; the device that
actually DMAs the video buffer is probably the correct choice). That
makes it crystal clear which graphics controller owns the framebuffer.
There is precedence in DT bindings for putting current state into the
tree. offb.c is trying to solve the exact same problem. It also means
that we can use the driver model to provide mutual exclusion between
probing simplefb and a full-featured driver.
That approach would require some modifications of the binding to make
sure properties don't conflict with the device specific properties. The
easiest way is to allow the properties to live in a sub node so that the
reg property doesn't conflict.
However, I'm not stuck on this approach. The solution must be
unambiguious, and the handover mechanism must be thought through, but it
doesn't /have/ to be what I suggested above if a proposal that can be
well argued as better.
Hans, let's talk about this tomorrow. #devicetree on freenode? It looks like
I'm committed to volunteer at my daughters school tomorrow morning, but
the afternoon looks good.
g.
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Grant Likely @ 2014-11-11 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1413996311-4287-3-git-send-email-hdegoede@redhat.com>
On Wed, 22 Oct 2014 18:45:08 +0200
, Hans de Goede <hdegoede@redhat.com>
wrote:
> A simple-framebuffer node represents a framebuffer setup by the firmware /
> bootloader. Such a framebuffer may have a number of clocks in use, add a
> property to communicate this to the OS.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Reviewed-by: Mike Turquette <mturquette@linaro.org>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> --
> Changes in v2:
> -Added Reviewed-by: Mike Turquette <mturquette@linaro.org>
> Changes in v3:
> -Updated description to make clear simplefb deals with more then just memory
> ---
> Documentation/devicetree/bindings/video/simple-framebuffer.txt | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index 70c26f3..172ad5f 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -1,8 +1,8 @@
> Simple Framebuffer
>
> -A simple frame-buffer describes a raw memory region that may be rendered to,
> -with the assumption that the display hardware has already been set up to scan
> -out from that buffer.
> +A simple frame-buffer describes a frame-buffer setup by firmware or
> +the bootloader, with the assumption that the display hardware has already
> +been set up to scan out from the memory pointed to by the reg property.
>
> Required properties:
> - compatible: "simple-framebuffer"
> @@ -14,6 +14,9 @@ Required properties:
> - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>
> +Optional properties:
> +- clocks : List of clocks used by the framebuffer
Please change to the following:
- clocks : List of clocks used by the framebuffer. Clocks listed here
are expected to already be configured correctly. The OS must
ensure these clocks are not modified or disabled while the
simple framebuffer remains active.
g.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox