* [PATCH 09/19] OMAPDSS: hdmi5: Integrated ASoC DAI component driver implementation
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Integrate ASoC DAI component driver in to the OMAP5 hdmi driver. The
patch also updates the relevant entry in ti,omap5-dss DT binding
document.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
.../devicetree/bindings/video/ti,omap5-dss.txt | 4 +
drivers/video/fbdev/omap2/dss/hdmi5.c | 199 ++++++++++++++++++++
2 files changed, 203 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
index 38ffc8f..795f5cf 100644
--- a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
+++ b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
@@ -88,6 +88,10 @@ Required properties:
- clocks: handles to fclk and pll clock
- clock-names: "fck", "sys_clk"
+Required properties if hdmi audio support is enabled:
+- dmas: DMA controller phandle for HDMI audio output
+- dma-names: "audio_tx"
+
Optional nodes:
- Video port for HDMI output
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c
index 49a85c9..c6a8862 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -39,6 +39,16 @@
#include <linux/regulator/consumer.h>
#include <video/omapdss.h>
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+#include <linux/dmaengine.h>
+#include <sound/dmaengine_pcm.h>
+#include <sound/soc.h>
+#include <sound/pcm_params.h>
+#include <uapi/sound/asound.h>
+#include <sound/asoundef.h>
+#include <sound/omap-pcm.h>
+#endif
+
#include "hdmi5_core.h"
#include "dss.h"
#include "dss_features.h"
@@ -57,6 +67,13 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_reg;
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+ 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;
+#endif
+
bool core_enabled;
struct omap_dss_device output;
@@ -534,6 +551,182 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
}
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+static int hdmi_dai_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ 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;
+ }
+
+ mutex_lock(&hdmi.lock);
+ ret = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
+ mutex_unlock(&hdmi.lock);
+ if (!ret) {
+ dev_err(dai->dev, "audio not supported\n");
+ return -ENODEV;
+ }
+
+ snd_soc_dai_set_dma_data(dai, substream, &hdmi.dma_data);
+
+ return 0;
+}
+
+static int hdmi_dai_prepare(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ int r;
+
+ mutex_lock(&hdmi.lock);
+
+ if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
+ r = -EPERM;
+ goto err;
+ }
+
+ r = hdmi_wp_audio_enable(&hdmi.wp, true);
+
+err:
+ mutex_unlock(&hdmi.lock);
+ return r;
+}
+
+static int hdmi_dai_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ int err;
+
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ hdmi.dma_data.maxburst = 16;
+ break;
+ case SNDRV_PCM_FORMAT_S24_LE:
+ hdmi.dma_data.maxburst = 32;
+ break;
+ default:
+ dev_err(dai->dev, "format not supported!\n");
+ return -EINVAL;
+ }
+
+ hdmi.dss_audio.iec = &hdmi.iec;
+ hdmi.dss_audio.cea = &hdmi.cea;
+ err = hdmi_dss_audio_from_hw_params(params, &hdmi.dss_audio, dai);
+ if (err)
+ return err;
+
+ mutex_lock(&hdmi.lock);
+
+ if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
+ err = -EPERM;
+ goto err;
+ }
+
+ err = hdmi5_audio_config(&hdmi.core, &hdmi.wp, &hdmi.dss_audio,
+ hdmi.cfg.timings.pixelclock);
+err:
+ mutex_unlock(&hdmi.lock);
+ return err;
+}
+
+static int hdmi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
+{
+ int err = 0;
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ err = hdmi_wp_audio_core_req_enable(&hdmi.wp, true);
+ break;
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ hdmi_wp_audio_core_req_enable(&hdmi.wp, false);
+ break;
+ default:
+ err = -EINVAL;
+ }
+ return err;
+}
+
+static void hdmi_dai_shutdown(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ hdmi_wp_audio_enable(&hdmi.wp, false);
+}
+
+static const struct snd_soc_dai_ops hdmi_dai_ops = {
+ .startup = hdmi_dai_startup,
+ .hw_params = hdmi_dai_hw_params,
+ .prepare = hdmi_dai_prepare,
+ .trigger = hdmi_dai_trigger,
+ .shutdown = hdmi_dai_shutdown,
+};
+
+static struct snd_soc_dai_driver omap_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 const struct snd_soc_component_driver omap_hdmi_component = {
+ .name = "omapdss_hdmi",
+};
+
+static int hdmi_audio_init(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret;
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "wp");
+ if (!res) {
+ dev_err(&pdev->dev, "Cannot obtain IORESOURCE_MEM l4\n");
+ return -ENODEV;
+ }
+ hdmi.dma_data.addr = res->start + HDMI_WP_AUDIO_DATA;
+ hdmi.dma_data.filter_data = "audio_tx";
+ hdmi.dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+
+ 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 void hdmi_audio_remove(struct platform_device *pdev)
+{
+ snd_soc_unregister_component(&pdev->dev);
+}
+
+#else
+static int hdmi_audio_init(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static void hdmi_audio_remove(struct platform_device *pdev)
+{
+}
+#endif
+
static const struct omapdss_hdmi_ops hdmi_ops = {
.connect = hdmi_connect,
.disconnect = hdmi_disconnect,
@@ -644,6 +837,10 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
return r;
}
+ r = hdmi_audio_init(pdev);
+ if (r)
+ return r;
+
pm_runtime_enable(&pdev->dev);
hdmi_init_output(pdev);
@@ -657,6 +854,8 @@ static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
{
hdmi_uninit_output(pdev);
+ hdmi_audio_remove(pdev);
+
pm_runtime_disable(&pdev->dev);
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 10/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP5_DSS_HDMI_AUDIO
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
drivers/video/fbdev/omap2/dss/Kconfig | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig
index ecc2f50..b28e175 100644
--- a/drivers/video/fbdev/omap2/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/dss/Kconfig
@@ -90,8 +90,15 @@ config OMAP5_DSS_HDMI
specification.
config OMAP5_DSS_HDMI_AUDIO
+ bool "HDMI audio support for OMAP5"
depends on OMAP5_DSS_HDMI
- bool
+ depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
+ default y
+ help
+ HDMI audio support for OMAP5 based SoCs. Adds integrated
+ ASoC Digital Audio Interface component driver into OMAPDSS
+ module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with
+ devicetree description for full HDMI audio support.
config OMAP2_DSS_SDI
bool "SDI support"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 11/19] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
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 e006593..aecd8eb 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_N810
tristate "SoC Audio support for Nokia N810"
depends on SND_OMAP_SOC && MACH_NOKIA_N810 && I2C
@@ -100,16 +97,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 a725905..5832fe1 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -3,13 +3,11 @@ 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
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
# OMAP Machine Support
snd-soc-n810-objs := n810.o
@@ -20,7 +18,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
@@ -30,4 +27,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
* [PATCH 12/19] OMAPDSS: Remove obsolete audio code
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Removes all code related to external audio driver callbacks. There is
no need for those now that sound/soc/omap/omap-hdmi.c is removed.
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 | 31 ------
3 files changed, 186 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
index 4420ccb..aa8231a 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 struct omap_dss_driver hdmic_driver = {
.connect = hdmic_connect,
.disconnect = hdmic_disconnect,
@@ -277,13 +185,6 @@ static struct omap_dss_driver hdmic_driver = {
.read_edid = hdmic_read_edid,
.detect = hdmic_detect,
-
- .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 7e33686..d47e30f 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 const struct omapdss_hdmi_ops tpd_hdmi_ops = {
.connect = tpd_connect,
.disconnect = tpd_disconnect,
@@ -255,13 +206,6 @@ static const struct omapdss_hdmi_ops tpd_hdmi_ops = {
.read_edid = tpd_read_edid,
.detect = tpd_detect,
-
- .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 6adb445..9eefbc7 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -629,19 +629,6 @@ struct omapdss_hdmi_ops {
int (*read_edid)(struct omap_dss_device *dssdev, u8 *buf, int len);
bool (*detect)(struct omap_dss_device *dssdev);
-
- /*
- * 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 {
@@ -848,24 +835,6 @@ struct omap_dss_driver {
int (*read_edid)(struct omap_dss_device *dssdev, u8 *buf, int len);
bool (*detect)(struct omap_dss_device *dssdev);
-
- /*
- * 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
* [PATCH 13/19] ARM: omap4.dtsi: Add audio related parametes to hdmi node
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: peter.ujfalusi-l0cyMroinI0, broonie-DgEjT+Ai2ygdnm+yROfE0A,
liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
detheridge-l0cyMroinI0, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha-l0cyMroinI0@public.gmane.org>
Adds HDMI audio sDMA properties.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 27fcac8..c7f0913 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -919,6 +919,8 @@
ti,hwmods = "dss_hdmi";
clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
clock-names = "fck", "sys_clk";
+ dmas = <&sdma 76>;
+ dma-names = "audio_tx";
};
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 14/19] ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Adds a simple-card sound node for HDMI audio, the associated
hdmi-codec node, and sound-dai-cells propeties to the DAI nodes.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d2c45bf..c04f453 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -41,7 +41,7 @@
};
};
- sound: sound {
+ sound: sound@0 {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
@@ -65,6 +65,24 @@
"AFMR", "Line In";
};
+ sound@1 {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,cpu {
+ sound-dai = <&hdmi>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&hdmi_audio>;
+ };
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,hdmi-audio";
+ status = "okay";
+ };
+
/* HS USB Port 1 Power */
hsusb1_power: hsusb1_power_reg {
compatible = "regulator-fixed";
@@ -512,6 +530,7 @@
};
&hdmi {
+ #sound-dai-cells = <0>;
status = "ok";
vdda-supply = <&vdac>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 15/19] ARM: omap5.dtsi: Add audio related parameters to hdmi node
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Adds HDMI audio sDMA properties.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b2a28e6..bac7d8e 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -931,6 +931,8 @@
ti,hwmods = "dss_hdmi";
clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
clock-names = "fck", "sys_clk";
+ dmas = <&sdma 76>;
+ dma-names = "audio_tx";
};
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 16/19] ARM: omap5-uevm.dts: Add hdmi audio related nodes
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Adds a simple-card sound node for HDMI audio, the associated
hdmi-codec node, and sound-dai-cells propeties to the DAI nodes.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap5-uevm.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index f625a87..42d625b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -561,6 +561,24 @@
};
};
};
+
+ sound@0 {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,cpu {
+ sound-dai = <&hdmi>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&hdmi_audio>;
+ };
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,hdmi-audio";
+ status = "okay";
+ };
};
&dss {
@@ -568,6 +586,7 @@
};
&hdmi {
+ #sound-dai-cells = <0>;
status = "ok";
vdda-supply = <&ldo4_reg>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 17/19] ARM: omap2plus_defconfig: Build DSS HDMI support for OMAP4 in kernel
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
This patch is here only as an example on how to enable HDMI video for
Panda board. In addition to this patch omapdss.def_disp=hdmi parameter
should be added to kernel command line in order to enable HDMI video.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index a966795..35c42aa 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -187,14 +187,14 @@ CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
-CONFIG_OMAP2_DSS=m
+CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_DSS_SDI=y
CONFIG_OMAP2_DSS_DSI=y
-CONFIG_FB_OMAP2=m
+CONFIG_FB_OMAP2=y
CONFIG_DISPLAY_ENCODER_TFP410=m
CONFIG_DISPLAY_ENCODER_TPD12S015=m
-CONFIG_DISPLAY_CONNECTOR_DVI=m
-CONFIG_DISPLAY_CONNECTOR_HDMI=m
+CONFIG_DISPLAY_CONNECTOR_DVI=y
+CONFIG_DISPLAY_CONNECTOR_HDMI=y
CONFIG_DISPLAY_PANEL_DPI=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 18/19] ARM: omap2plus_defconfig: Enable OMAP5 HDMI support
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
This patch is here only as an example on how to enable HDMI video for
OMAP5 uEVM. Adds CONFIG_GPIO_PCA953X=y and CONFIG_OMAP5_DSS_HDMI=y.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 35c42aa..363733e 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -157,6 +157,7 @@ CONFIG_PINCTRL_SINGLE=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_TWL4030=y
+CONFIG_GPIO_PCA953X=y
CONFIG_W1=y
CONFIG_POWER_SUPPLY=y
CONFIG_SENSORS_LM75=m
@@ -190,6 +191,7 @@ CONFIG_FB_TILEBLITTING=y
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_DSS_SDI=y
CONFIG_OMAP2_DSS_DSI=y
+CONFIG_OMAP5_DSS_HDMI=y
CONFIG_FB_OMAP2=y
CONFIG_DISPLAY_ENCODER_TFP410=m
CONFIG_DISPLAY_ENCODER_TPD12S015=m
--
1.7.9.5
^ permalink raw reply related
* [PATCH 19/19] ARM: omap2plus_defconfig: Enable OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
This patch is here only as an example on how to enable HDMI audio for
OMAP4+ HW. Adds CONFIG_SND_SIMPLE_CARD=m and CONFIG_SND_SOC_HDMI_CODEC=m.
Also builds SND_OMAP_SOC in kernel to support in kernel built OMAPDSS
with integrated HDMI DAI driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 363733e..8b512c7 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -204,20 +204,22 @@ CONFIG_LCD_PLATFORM=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_LOGO=y
-CONFIG_SOUND=m
-CONFIG_SND=m
+CONFIG_SOUND=y
+CONFIG_SND=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_SND_USB_AUDIO=m
-CONFIG_SND_SOC=m
-CONFIG_SND_OMAP_SOC=m
+CONFIG_SND_SOC=y
+CONFIG_SND_OMAP_SOC=y
CONFIG_SND_AM33XX_SOC_EVM=m
CONFIG_SND_DAVINCI_SOC=m
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
+CONFIG_SND_SIMPLE_CARD=m
+CONFIG_SND_SOC_HDMI_CODEC=m
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Javier Martinez Canillas @ 2014-05-12 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53707A64.2060203@ti.com>
Hello Tomi,
On Mon, May 12, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 09/05/14 18:55, Tony Lindgren wrote:
>
>>> Although if the MO gpio is not controlled by the driver, we should tell
>>> the driver whether that gpio is high or low.
>>
>> What do you have in mind for telling that? We should also tell the
>> orientation of the panel:
>>
>> EVM VGA omapfb.rotate=3
>> LDP QVGA omapfb.rotate=0
>>
>> Do you have something in mind for that?
>
> Hmm, right. I guess all we can do is have boolean flags in the .dts for
> MO, LR and UD, which tells if the respective pins are hard-wires high or
> low. And say in the documentation that you must either have a proper
> GPIO, or use the flag, but not both.
>
> The panel mounting orientation is a different matter. But I think it is
> also something we should specify in the .dts. However, we don't have any
> SW support to handle it, and it's a bit unclear to me how it should be
> handled, so I think that has to be left for later.
>
>>> At the moment our display drivers are OMAP specific, and for that reason
>>> we should prefix the compatible strings with "omapdss,". For example,
>>> drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
>>>
>>> { .compatible = "omapdss,panel-dsi-cm", },
>>>
>>> But we should still have the right compatible string in the .dts, so we
>>> convert the compatible name in arch/arm/mach-omap2/display.c, with
>>> 'dss_compat_conv_list' array, to which this panel's name should be added.
>>
>> Oh so what do you want to have in the .dts file then?
>
> The .dts should have the proper names. The idea of this hackery is that
> in the .dts we can have the proper compatible string. So in the .dts, we
> have, say:
>
> "sony,panel-foobar"
>
> Then, at boot time, omap's platform code changes that to:
>
> "omapdss,sony,panel-foobar".
>
> And our (omap specific) panel-foobar driver use that
> "omapdss,sony,panel-foobar" string.
>
> This way some other platform could do the same, and have their platform
> specific drivers handle the panel.
>
> At some point in the future we hopefully will have common panel drivers,
> and at that point we can remove that hackery. The .dts files will
> already be correct.
>
Maybe we can remove this hackery by relying on the fact that a
compatible string can have a set of values that goes from more
specific to more general. So you can have something like:
compatible = "sony,panel-foobar", "omapdss,panel-foobar"
So right now only "omapdss,panel-foobar" will be matched and later
when we have common panel drivers then that driver could handle the
"sony,panel-foobar" compatible string.
Other platforms could do something similar and have
compatible = "sony,panel-foobar", "baz,panel-foobar"
That way you won't break DT backward compatible but still not require
hacks on arch/arm/mach-omap2/display.c.
We do the same for OMAP boards, we now have the following compatible string:
compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
There isn't a struct machine_desc that matches "isee,omap3-igep0020"
but later if we find that we need some board specific initialization
we could add one without breaking existing DTS. In fact it used to be
a single machine_desc that matched "ti,omap3" for both omap36xx and
omap34xx but later when some DT clocks changes were introduced we
needed to split both SoC families.
> Tomi
>
>
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-12 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=kwhodeFTHoVpn1nHeh9+kV5fwMN9s3Kbk6h7_xJp4UYA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
On 12/05/14 12:34, Javier Martinez Canillas wrote:
> Maybe we can remove this hackery by relying on the fact that a
> compatible string can have a set of values that goes from more
> specific to more general. So you can have something like:
>
> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
>
> So right now only "omapdss,panel-foobar" will be matched and later
> when we have common panel drivers then that driver could handle the
> "sony,panel-foobar" compatible string.
>
> Other platforms could do something similar and have
>
> compatible = "sony,panel-foobar", "baz,panel-foobar"
>
> That way you won't break DT backward compatible but still not require
> hacks on arch/arm/mach-omap2/display.c.
>
> We do the same for OMAP boards, we now have the following compatible string:
>
> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
>
> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
> but later if we find that we need some board specific initialization
> we could add one without breaking existing DTS. In fact it used to be
> a single machine_desc that matched "ti,omap3" for both omap36xx and
> omap34xx but later when some DT clocks changes were introduced we
> needed to split both SoC families.
I think that's a different thing. "isee,omap3-igep0020" is a proper
compatible string, if the board is "isee,...". No matter what software
you run, that's correct and fine.
The omapdss case is different, there the "omapdss" points to a sw thing,
it does not describe the hardware. It's only needed as we don't have
proper sw drivers for the devices.
That said, I think what you describe would work. But I would rather keep
the .dts files clean and correct, and keep that hacks hidden inside the
kernel.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Javier Martinez Canillas @ 2014-05-12 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53709706.10501@ti.com>
Hello Tomi,
On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 12/05/14 12:34, Javier Martinez Canillas wrote:
>
>> Maybe we can remove this hackery by relying on the fact that a
>> compatible string can have a set of values that goes from more
>> specific to more general. So you can have something like:
>>
>> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
>>
>> So right now only "omapdss,panel-foobar" will be matched and later
>> when we have common panel drivers then that driver could handle the
>> "sony,panel-foobar" compatible string.
>>
>> Other platforms could do something similar and have
>>
>> compatible = "sony,panel-foobar", "baz,panel-foobar"
>>
>> That way you won't break DT backward compatible but still not require
>> hacks on arch/arm/mach-omap2/display.c.
>>
>> We do the same for OMAP boards, we now have the following compatible string:
>>
>> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
>>
>> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
>> but later if we find that we need some board specific initialization
>> we could add one without breaking existing DTS. In fact it used to be
>> a single machine_desc that matched "ti,omap3" for both omap36xx and
>> omap34xx but later when some DT clocks changes were introduced we
>> needed to split both SoC families.
>
> I think that's a different thing. "isee,omap3-igep0020" is a proper
> compatible string, if the board is "isee,...". No matter what software
> you run, that's correct and fine.
>
> The omapdss case is different, there the "omapdss" points to a sw thing,
> it does not describe the hardware. It's only needed as we don't have
> proper sw drivers for the devices.
>
> That said, I think what you describe would work. But I would rather keep
> the .dts files clean and correct, and keep that hacks hidden inside the
> kernel.
>
Thanks for the explanation. Since DT are meant to describe hardware
and not software I agree with you that we shouldn't leak an
implementation detail to the DeviceTrees.
And after all fortunately we don't have a stable API in the kernel
like the one that is enforced in the DT so we can fix it later ;-)
> Tomi
>
>
Bets regards,
Javier
^ permalink raw reply
* Re: [PATCH] uvesafb: abort initialization if video=uvesafb is not set
From: David Herrmann @ 2014-05-12 10:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396791873-22606-1-git-send-email-lxnay@sabayon.org>
Hi
On Sun, Apr 6, 2014 at 3:44 PM, <lxnay@sabayon.org> wrote:
> From: Fabio Erculiani <lxnay@sabayon.org>
>
> This patch makes possible to ship kernels with both vesafb and uvesafb
> in order to guarantee a smooth transition to uvesafb and cope with
> potential incompatibiles introduced by uvesafb making possible to disable
> it via cmdline.
>
> In case both vesafb and uvesafb are built-in, the kernel will try to
> initialize both, which makes possible to select the wanted one using
> either video=vesafb:... or video=uvesafb:....
> In this way, old distro installations will keep working as before while
> new ones can adopt video=uvesafb.
Why would you want vesafb _and_ uvesafb built-in? Ship them as modules
and let users blacklist the modules they don't want. I mean the
problem you describe is specific to distros. Embedded devices or other
specific use-cases can explicitly disable any unwanted module. And for
distros I cannot see why we should support both as built-in modules.
_Iff_ you want this as in-kernel option, I'd recommend looking at the
sysfb stuff. uvesafb could easily claim the vesa-framebuffer and thus
unload any generic drivers like vesafb.
Thanks
David
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-12 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140509143703.GA17814@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]
On 09/05/14 17:37, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:39]:
>> On 30/04/14 02:52, Tony Lindgren wrote:
>>> Otherwise we can get often errors like the following and the
>>> display won't come on:
>>>
>>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>>> the output with video overlays disabled
>>>
>>> There are some earlier references to this issue:
>>>
>>> http://www.spinics.net/lists/linux-omap/msg59511.html
>>> http://www.spinics.net/lists/linux-omap/msg59724.html
>>
>> Those don't sound like the same issue, but it's hard to say. What kind
>> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
>> without this patch?
>
> Without this patch:
> # cat /sys/kernel/debug/omapdss/clk
> [ 24.833831] DSS: dss_runtime_get
> [ 24.837554] DSS: dss_runtime_put
> [ 24.840972] DISPC: dispc_runtime_get
> [ 24.844757] DISPC: dispc_runtime_put
> - DSS -
> DSS_FCK (DSS1_ALWON_FCLK) = 57600000
> - DISPC -
> dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
> fck 57600000
> - LCD -
> LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
> lck 57600000 lck div 1
> pck 19200000 pck div 3
>
>
> With this patch:
> # cat /sys/kernel/debug/omapdss/clk
> [ 34.580688] DSS: dss_runtime_get
> [ 34.584197] DSS: dss_runtime_put
> [ 34.587768] DISPC: dispc_runtime_get
> [ 34.591552] DISPC: dispc_runtime_put
> - DSS -
> DSS_FCK (DSS1_ALWON_FCLK) = 108000000
> - DISPC -
> dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
> fck 108000000
> - LCD -
> LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
> lck 108000000 lck div 1
> pck 18000000 pck div 6
>
>> What resolution do you have? If it's a very high resolution (say, DVI
>> output to a monitor), it could just be an issue of
>> not-enough-memory-bandwidth.
>
> This is just the 3730-evm with the Sharp VGA panel mentioned in
> this series.
Hmm, well, those both look fine. The fck is well below the maximum,
which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
with this patch, but that should affect the GFX overlay.
So you're just booting, and there are no applications that use the
framebuffer? And there is no rotation or such configured?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-12 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140509143748.GB17814@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]
On 09/05/14 17:37, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:02]:
>> On 09/05/14 02:20, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [140429 16:53]:
>>>> Otherwise we can get often errors like the following and the
>>>> display won't come on:
>>>>
>>>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>>>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>>>> the output with video overlays disabled
>>>>
>>>> There are some earlier references to this issue:
>>>>
>>>> http://www.spinics.net/lists/linux-omap/msg59511.html
>>>> http://www.spinics.net/lists/linux-omap/msg59724.html
>>>>
>>>> It seems that it's safe to set the lower values even for 3630.
>>>> If we can confirm that 3630 works with the higher values
>>>> reliably we can add further detection.
>>>
>>> BTW, I'm also seeing this warning on 3730-evm it may be related:
>>>
>>> [ 3.523101] ------------[ cut here ]------------
>>> [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
>>> [ 3.538360] clk rate mismatch: 108000000 != 115200000
>>> [ 3.543518] Modules linked in:
>>
>> Hmm... Can you paste the clk_summary from debugfs? Somehow the clock
>> framework calculates the clock rate differently than the dss. Or do we
>> have different clock.dts files used for 3730 and 3630?
>
> OK pasted to the other email in this thread.
I mean the debugs for clock framework. The above warning means that the
clock framework says the clock rate is X, but the dss had calculated
that it should be Y. So there's a difference how the clock framework
calculates the rate and how the dss calculates it.
And yes, dss shouldn't calculate it. But I don't know how to get good
pixel clocks if we didn't.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=mY0a+yJgmCTPN=BhSQD57Pw022zOd5_KxEgvvF_-=O7Q@mail.gmail.com>
* Javier Martinez Canillas <javier@dowhile0.org> [140512 03:01]:
> Hello Tomi,
>
> On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 12/05/14 12:34, Javier Martinez Canillas wrote:
> >
> >> Maybe we can remove this hackery by relying on the fact that a
> >> compatible string can have a set of values that goes from more
> >> specific to more general. So you can have something like:
> >>
> >> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
> >>
> >> So right now only "omapdss,panel-foobar" will be matched and later
> >> when we have common panel drivers then that driver could handle the
> >> "sony,panel-foobar" compatible string.
> >>
> >> Other platforms could do something similar and have
> >>
> >> compatible = "sony,panel-foobar", "baz,panel-foobar"
> >>
> >> That way you won't break DT backward compatible but still not require
> >> hacks on arch/arm/mach-omap2/display.c.
> >>
> >> We do the same for OMAP boards, we now have the following compatible string:
> >>
> >> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
> >>
> >> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
> >> but later if we find that we need some board specific initialization
> >> we could add one without breaking existing DTS. In fact it used to be
> >> a single machine_desc that matched "ti,omap3" for both omap36xx and
> >> omap34xx but later when some DT clocks changes were introduced we
> >> needed to split both SoC families.
> >
> > I think that's a different thing. "isee,omap3-igep0020" is a proper
> > compatible string, if the board is "isee,...". No matter what software
> > you run, that's correct and fine.
> >
> > The omapdss case is different, there the "omapdss" points to a sw thing,
> > it does not describe the hardware. It's only needed as we don't have
> > proper sw drivers for the devices.
> >
> > That said, I think what you describe would work. But I would rather keep
> > the .dts files clean and correct, and keep that hacks hidden inside the
> > kernel.
> >
>
> Thanks for the explanation. Since DT are meant to describe hardware
> and not software I agree with you that we shouldn't leak an
> implementation detail to the DeviceTrees.
>
> And after all fortunately we don't have a stable API in the kernel
> like the one that is enforced in the DT so we can fix it later ;-)
This remapping of compatible flags sounds smelly to me, please discuss
it first with the device tree people.
I think we're better off just using the compatible properties limited
to the simple-panel.txt for now and actually describe the real
hardware. The fact that the panel is connected to DSS should be possible
to find out based on the phandles.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-05-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5370B222.7050702@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
> On 09/05/14 17:37, Tony Lindgren wrote:
> >
> > This is just the 3730-evm with the Sharp VGA panel mentioned in
> > this series.
>
> Hmm, well, those both look fine. The fck is well below the maximum,
> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
> with this patch, but that should affect the GFX overlay.
>
> So you're just booting, and there are no applications that use the
> framebuffer? And there is no rotation or such configured?
Right. The rotation is set to 3 though.
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-05-12 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALbNGRQpieZ+b-PvC+K2Zxb3hOd6KOCrPVOnveds-fXENn8GJg@mail.gmail.com>
* Andreas Müller <schnitzeltony@googlemail.com> [140512 01:20]:
> On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]:
> >> On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> > On 30/04/14 02:52, Tony Lindgren wrote:
> >> >> Otherwise we can get often errors like the following and the
> >> >> display won't come on:
> >> >>
> >> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> >> >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> >> >> the output with video overlays disabled
> >> >>
> >> >> There are some earlier references to this issue:
> >> >>
> >> >> http://www.spinics.net/lists/linux-omap/msg59511.html
> >> >> http://www.spinics.net/lists/linux-omap/msg59724.html
> >> >
> >> resend - my client had HTML enabled...
> >>
> >> FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had
> >> still the reboot problem on old 600MHz OMAP 3530. Applying this patch
> >> solved the issues. For other versions I had no chance to reproduce the
> >> original wakup issue mentioned in old thread
> >
> > Sorry I'm a bit confused now. Is the reboot issue a separate issue
> > related to the twl4030 generic scripts for 3530?
> >
> > And then this patch fixes dm3730 wake-up (from suspend?) issues?
> >
> > Or do we have some other bug where we wrongly hit omap3630_dss_feats
> > on 3530 somehow?
> (What I think) I have done: Have 3.14.3 still booting with legacy
> board init (please don't kill me for that). Without applying your
> patch old OMAP3530 crashed at every reboot with SYNCH_LOST.
>
> After applying your patch reboot works fine.
>
> Looking into id-code makes me wonder what changes on 36xx-features do
> to 35xx devices (treated as 34xx - right?). The only way that this
> happens is for unknown hawkeye fallthough. I suggest you simply forget
> my note and I will find out what really 'fixed' dss reboot problem.
Yeah 35xx should be treated as 34xx so sounds like there might be
some detection problem if this patch does something for your board.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-12 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140512143934.GC31772@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On 12/05/14 17:39, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
>> On 09/05/14 17:37, Tony Lindgren wrote:
>>>
>>> This is just the 3730-evm with the Sharp VGA panel mentioned in
>>> this series.
>>
>> Hmm, well, those both look fine. The fck is well below the maximum,
>> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
>> with this patch, but that should affect the GFX overlay.
>>
>> So you're just booting, and there are no applications that use the
>> framebuffer? And there is no rotation or such configured?
>
> Right. The rotation is set to 3 though.
Hmm, that's probably the issue then. VRFB rotation is very heavy on the
memory bandwidth, and is generally a very easy way to get sync lost errors.
My opinion is that VRFB should only be used when you know your system
will handle it fine with the clock rates and bandwidth usage you have
for your use cases.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-12 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140512142646.GA31772@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]
On 12/05/14 17:26, Tony Lindgren wrote:
>>> The omapdss case is different, there the "omapdss" points to a sw thing,
>>> it does not describe the hardware. It's only needed as we don't have
>>> proper sw drivers for the devices.
>>>
>>> That said, I think what you describe would work. But I would rather keep
>>> the .dts files clean and correct, and keep that hacks hidden inside the
>>> kernel.
>>>
>>
>> Thanks for the explanation. Since DT are meant to describe hardware
>> and not software I agree with you that we shouldn't leak an
>> implementation detail to the DeviceTrees.
>>
>> And after all fortunately we don't have a stable API in the kernel
>> like the one that is enforced in the DT so we can fix it later ;-)
>
> This remapping of compatible flags sounds smelly to me, please discuss
> it first with the device tree people.
It's already in v3.15.
I agree it's smelly, but it smelly only inside the kernel, not visible
anywhere, and we can remove it when we have common panel drivers,
without any modifications to .dts files.
> I think we're better off just using the compatible properties limited
> to the simple-panel.txt for now and actually describe the real
> hardware. The fact that the panel is connected to DSS should be possible
> to find out based on the phandles.
I'm not sure what you mean. We do describe only the real hardware. The
compatible string in the .dts file is "sharp,ls037v7dw01".
Prepending the "omapdss" to the compatible string is required for the
device/driver matching to work, because we can't use the
"sharp,ls037v7dw01" compatible string in our omap specific panel driver.
I'm not sure what it would give us to try to be compatible with
simple-panel.txt. The simple-panel bindings won't probably be compatible
with the future common display drivers in any case, as the simple-panel
binding is just too limited and doesn't describe the hardware fully.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv2 00/11] improve PWM lookup support without device tree
From: Alexandre Belloni @ 2014-05-12 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1397512793-10325-1-git-send-email-alexandre.belloni@free-electrons.com>
Hello Thierry,
Do you know when you will have some time to review that patch series ?
On 14/04/2014 at 23:59:42 +0200, Alexandre Belloni wrote :
> Hi,
>
> A patch set as suggested by Thierry to make lookup with the lookup table
> instead of device tree behave more like when using device tree.
>
> The first patch adds a period and a polarity member to the lookup table and use
> those to set period and polarity.
>
> Patch 2, 4 and 5 are making use of those new members from the board files.
> Patch 3 removes useless code since setting the polarity is now handled by the
> PWM core.
>
> I couldn't decide on a good name for the extended PWM_LOOKUP macro and I believe
> we won't have to add members to that structure soon so:
> Patch 6 modifies the PWM_LOOKUP macro to also initialize period and polarity
> and
> Patch 7-9 are making use of the new PWM_LOOKUP macro in the board files
>
> Patch 10 and 11 are making the leds-pwm and pwm_bl drivers get the period from
> the PWM before using pwm_period_ns if it is not already set.
>
> Patch 10 will obviously conflict with the series of Russell reworking the
> leds-pwm probing. I can rebase if necessary
>
> The final goal would be to get rid of .pwm_period_ns in leds-pwm and pwm_bl
> after moving all the remaining users (still around 25) to pwm_lookup.
>
> Changes in v2:
> - correctly unlock the pwm_lookup_lock mutex before returning.
> - don't change PWM_LOOKUP atomically
> - remove tpu_pwm_platform_data and the associated header file
> - make the leds-pwm and pwm_bl drivers get the period from the PWM
>
> Alexandre Belloni (11):
> pwm: add period and polarity to struct pwm_lookup
> ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup
> members
> pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data
> ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
> ARM: pxa: hx4700: initialize all the struct pwm_lookup members
> pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members
> ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
> ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct
> pwm_lookup
> ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup
> leds: leds-pwm: retrieve configured pwm period
> backlight: pwm_bl: retrieve configured pwm period
>
> Documentation/pwm.txt | 3 ++-
> arch/arm/mach-omap2/board-omap3beagle.c | 3 ++-
> arch/arm/mach-pxa/hx4700.c | 3 ++-
> arch/arm/mach-shmobile/board-armadillo800eva.c | 14 +++-----------
> drivers/leds/leds-pwm.c | 5 ++++-
> drivers/pwm/core.c | 8 +++++++-
> drivers/pwm/pwm-renesas-tpu.c | 19 +++----------------
> drivers/video/backlight/pwm_bl.c | 8 +++++---
> include/linux/platform_data/pwm-renesas-tpu.h | 16 ----------------
> include/linux/pwm.h | 6 +++++-
> 10 files changed, 33 insertions(+), 52 deletions(-)
> delete mode 100644 include/linux/platform_data/pwm-renesas-tpu.h
>
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Tony Lindgren @ 2014-05-12 15:06 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, peter.ujfalusi,
broonie, liam.r.girdwood, bcousson, tomi.valkeinen, detheridge
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
* Jyri Sarha <jsarha@ti.com> [140512 02:13]:
> Since RFC version of the patch set:
> - Split callbacks removal patch away from "Integrated ASoC DAI
> component driver implementation" patches for easier reading
>
> This set of patches fixes OMAP4+ HDMI audio. The structure of the
> implementatin looks a bit different than before. Instead of creating a
> driver specific API for a separate ASoC component driver to connect
> to, this implementation integrates an the component driver into the
> HDMI driver.
>
> The idea is to use an existing ASoC component driver API instead of
> creating a new custom API for each HDMI IP and to avoid splitting the
> driver to half for separate video and audio parts connected with the
> API.
>
> The new implementation also uses simple-audio-card for a machine
> driver instead of having its own HW specific machine driver.
Can you guys please post this split into the following separate
parts for the maintainers to merge:
- ASoC changes
- DSS changes
- DTS changes
And once those are all in, please post the defconfig changes.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-12 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5370E0C9.8050201@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:55]:
> On 12/05/14 17:26, Tony Lindgren wrote:
>
> >>> The omapdss case is different, there the "omapdss" points to a sw thing,
> >>> it does not describe the hardware. It's only needed as we don't have
> >>> proper sw drivers for the devices.
> >>>
> >>> That said, I think what you describe would work. But I would rather keep
> >>> the .dts files clean and correct, and keep that hacks hidden inside the
> >>> kernel.
> >>>
> >>
> >> Thanks for the explanation. Since DT are meant to describe hardware
> >> and not software I agree with you that we shouldn't leak an
> >> implementation detail to the DeviceTrees.
> >>
> >> And after all fortunately we don't have a stable API in the kernel
> >> like the one that is enforced in the DT so we can fix it later ;-)
> >
> > This remapping of compatible flags sounds smelly to me, please discuss
> > it first with the device tree people.
>
> It's already in v3.15.
Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
even acked it :( Looks like there's also the custom mux hacks. And
custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
_any_ new crap into arch/arm/mach-omap2/display.c.
So please consider this a huge eternal NAK to add any more crap to
arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
the soc_is_am43xx() you have in linux next. No more adding
of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
And no more new panel remapping in this file as soon as you have found
a better solution. Preferrably by v3.17 merge window. This file just
needs to disappear. Yuk.
> I agree it's smelly, but it smelly only inside the kernel, not visible
> anywhere, and we can remove it when we have common panel drivers,
> without any modifications to .dts files.
>
> > I think we're better off just using the compatible properties limited
> > to the simple-panel.txt for now and actually describe the real
> > hardware. The fact that the panel is connected to DSS should be possible
> > to find out based on the phandles.
>
> I'm not sure what you mean. We do describe only the real hardware. The
> compatible string in the .dts file is "sharp,ls037v7dw01".
>
> Prepending the "omapdss" to the compatible string is required for the
> device/driver matching to work, because we can't use the
> "sharp,ls037v7dw01" compatible string in our omap specific panel driver.
>
> I'm not sure what it would give us to try to be compatible with
> simple-panel.txt. The simple-panel bindings won't probably be compatible
> with the future common display drivers in any case, as the simple-panel
> binding is just too limited and doesn't describe the hardware fully.
Hmm what else does a panel need where the existing binding cannot be
extended?
Regards,
Tony
^ 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