* [PATCH RFC v2 REPOST 1/8] clk: add gpio controlled clock
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
@ 2013-12-20 10:37 ` Jyri Sarha
2013-12-20 10:38 ` [PATCH RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings Jyri Sarha
` (7 subsequent siblings)
8 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 10:37 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
bcousson, mturquette
Cc: broonie, Jyri Sarha
The added clk-gpio is a basic clock that can be enabled and disabled
trough a gpio output. The DT binding document for the clock is also
added. For EPROBE_DEFER handling the registering of the clock has to
be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: mturquette@linaro.org
cc: bcousson@baylibre.com
---
.../devicetree/bindings/clock/gpio-clock.txt | 21 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-gpio.c | 210 ++++++++++++++++++++
include/linux/clk-provider.h | 25 +++
4 files changed, 257 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt
create mode 100644 drivers/clk/clk-gpio.c
diff --git a/Documentation/devicetree/bindings/clock/gpio-clock.txt b/Documentation/devicetree/bindings/clock/gpio-clock.txt
new file mode 100644
index 0000000..54fea39
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio controlled clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "gpio-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = "gpio-clock";
+ clocks = <&parentclk>;
+ #clock-cells = <0>;
+ enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7b11106..568b7be 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK) += clk-fixed-rate.o
obj-$(CONFIG_COMMON_CLK) += clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
+obj-$(CONFIG_COMMON_CLK) += clk-gpio.o
# SoCs specific
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
new file mode 100644
index 0000000..e04b0e1
--- /dev/null
+++ b/drivers/clk/clk-gpio.c
@@ -0,0 +1,210 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ * 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.
+ *
+ * Gpio controlled clock implementation
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/err.h>
+#include <linux/device.h>
+
+/**
+ * DOC: basic gpio controlled clock which can be enabled and disabled
+ * with gpio output
+ * Traits of this clock:
+ * prepare - clk_(un)prepare only ensures parent is (un)prepared
+ * enable - clk_enable and clk_disable are functional & control gpio
+ * rate - inherits rate from parent. No clk_set_rate support
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
+
+static int clk_gpio_enable(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio->active_low ? 0 : 1;
+
+ gpio_set_value(gpio->gpio, value);
+
+ return 0;
+}
+
+static void clk_gpio_disable(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio->active_low ? 1 : 0;
+
+ gpio_set_value(gpio->gpio, value);
+}
+
+static int clk_gpio_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio_get_value(gpio->gpio);
+
+ return gpio->active_low ? !value : value;
+}
+
+const struct clk_ops clk_gpio_ops = {
+ .enable = clk_gpio_enable,
+ .disable = clk_gpio_disable,
+ .is_enabled = clk_gpio_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_gpio_ops);
+
+/**
+ * clk_register_gpio - register a gpip clock with the clock framework
+ * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_name: name of this clock's parent
+ * @flags: framework-specific flags for this clock
+ * @gpio: gpio to control this clock
+ * @active_low: gpio polarity
+ */
+struct clk *clk_register_gpio(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ unsigned int gpio, bool active_low)
+{
+ struct clk_gpio *clk_gpio;
+ struct clk *clk = ERR_PTR(-EINVAL);
+ struct clk_init_data init = { NULL };
+ unsigned long gpio_flags;
+ int err;
+
+ if (active_low)
+ gpio_flags = GPIOF_OUT_INIT_LOW;
+ else
+ gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+ err = gpio_request_one(gpio, gpio_flags, name);
+
+ if (err) {
+ pr_err("%s: %s: Error requesting clock control gpio %u\n",
+ __func__, name, gpio);
+ clk = ERR_PTR(err);
+ goto clk_register_gpio_err;
+ }
+
+ clk_gpio = kzalloc(sizeof(*clk_gpio), GFP_KERNEL);
+
+ if (!clk_gpio) {
+ pr_err("%s: %s: could not allocate gpio clk\n", __func__, name);
+ clk = ERR_PTR(-ENOMEM);
+ goto clk_register_gpio_err;
+ }
+
+ init.name = name;
+ init.ops = &clk_gpio_ops;
+ init.flags = flags | CLK_IS_BASIC;
+ init.parent_names = (parent_name ? &parent_name : NULL);
+ init.num_parents = (parent_name ? 1 : 0);
+
+ clk_gpio->gpio = gpio;
+ clk_gpio->active_low = active_low;
+ clk_gpio->hw.init = &init;
+
+ clk = clk_register(dev, &clk_gpio->hw);
+
+ if (!IS_ERR(clk))
+ return clk;
+
+ kfree(clk_gpio);
+
+clk_register_gpio_err:
+ gpio_free(gpio);
+
+ return clk;
+}
+EXPORT_SYMBOL_GPL(clk_register_gpio);
+
+#ifdef CONFIG_OF
+/**
+ * The clk_register_gpio has to be delayed, because the EPROBE_DEFER
+ * can not be handled properly at of_clk_init() call time.
+ */
+
+struct clk_gpio_delayed_register_data {
+ struct device_node *node;
+ struct mutex lock; /* Protect delayed clk registering */
+ struct clk *clk;
+};
+
+static
+struct clk *of_clk_gpio_delayed_register_get(struct of_phandle_args *clkspec,
+ void *_data)
+{
+ struct clk_gpio_delayed_register_data *data =
+ (struct clk_gpio_delayed_register_data *)_data;
+ struct clk *clk;
+ const char *clk_name = data->node->name;
+ const char *parent_name;
+ enum of_gpio_flags gpio_flags;
+ int gpio;
+ bool active_low;
+
+ mutex_lock(&data->lock);
+
+ if (data->clk) {
+ mutex_unlock(&data->lock);
+ return data->clk;
+ }
+
+ gpio = of_get_named_gpio_flags(data->node, "enable-gpios", 0,
+ &gpio_flags);
+
+ if (gpio < 0) {
+ mutex_unlock(&data->lock);
+ if (gpio != -EPROBE_DEFER)
+ pr_err("%s: %s: Can't get 'enable-gpios' DT property\n",
+ __func__, clk_name);
+ return ERR_PTR(gpio);
+ }
+
+ active_low = gpio_flags & OF_GPIO_ACTIVE_LOW;
+
+ parent_name = of_clk_get_parent_name(data->node, 0);
+
+ clk = clk_register_gpio(NULL, clk_name, parent_name, 0,
+ gpio, active_low);
+ if (IS_ERR(clk)) {
+ mutex_unlock(&data->lock);
+ return clk;
+ }
+
+ data->clk = clk;
+ mutex_unlock(&data->lock);
+
+ return clk;
+}
+
+/**
+ * of_gpio_clk_setup() - Setup function for gpio controlled clock
+ */
+void __init of_gpio_clk_setup(struct device_node *node)
+{
+ struct clk_gpio_delayed_register_data *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ pr_err("%s: could not allocate gpio clk\n", __func__);
+ return;
+ }
+
+ data->node = node;
+ mutex_init(&data->lock);
+
+ of_clk_add_provider(node, of_clk_gpio_delayed_register_get, data);
+}
+EXPORT_SYMBOL_GPL(of_gpio_clk_setup);
+CLK_OF_DECLARE(gpio_clk, "gpio-clock", of_gpio_clk_setup);
+#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 73bdb69..9d433f7 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -407,6 +407,31 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
unsigned long flags);
+/***
+ * struct clk_gpio - gpio controlled clock
+ *
+ * @hw: handle between common and hardware-specific interfaces
+ * @gpio: gpio
+ * @active_low: gpio polarity
+ *
+ * Clock with a gpio control for enabling and disabling the parent clock.
+ * Implements .enable, .disable and .is_enabled
+ */
+
+struct clk_gpio {
+ struct clk_hw hw;
+ unsigned int gpio;
+ bool active_low;
+};
+
+extern const struct clk_ops clk_gpio_ops;
+
+struct clk *clk_register_gpio(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ unsigned int gpio, bool active_low);
+
+void of_gpio_clk_setup(struct device_node *node);
+
/**
* clk_register - allocate a new clock, register it and return an opaque cookie
* @dev: device that is registering this clock
--
1.7.9.5
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
2013-12-20 10:37 ` [PATCH RFC v2 REPOST 1/8] clk: add gpio controlled clock Jyri Sarha
@ 2013-12-20 10:38 ` Jyri Sarha
2013-12-31 13:16 ` Mark Brown
2013-12-20 10:39 ` [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus Jyri Sarha
` (6 subsequent siblings)
8 siblings, 1 reply; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 10:38 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
bcousson
Cc: broonie, Jyri Sarha
The referenced clock is used to get codec clock rate and the clock is
disabled and enabled in startup and shutdown snd_soc_ops call
backs. The change is also documented in DT bindigs document.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: bcousson@baylibre.com
---
.../bindings/sound/davinci-evm-audio.txt | 9 ++-
sound/soc/davinci/davinci-evm.c | 60 +++++++++++++++++++-
2 files changed, 66 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 865178d..4aa00f6 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -5,12 +5,19 @@ Required properties:
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
-- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
- ti,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
the second being the connection's source. Valid names for sources and
sinks are the codec's pins, and the jacks on the board:
+Optional properties:
+- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec.
+- clocks : Reference to the clock used as codec clock
+- clock-names : The codec clock should be named "ti,codec-clock"
+- Either codec-clock-rate or the codec-clock reference has to be defined. If
+ the both are defined the driver attempts to set referenced clock to the
+ defined rate and takes the rate from the clock reference.
+
Board connectors:
* Headphone Jack
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 70ff377..b28c9fd 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -17,6 +17,7 @@
#include <linux/platform_data/edma.h>
#include <linux/i2c.h>
#include <linux/of_platform.h>
+#include <linux/clk.h>
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/soc.h>
@@ -30,9 +31,30 @@
#include "davinci-i2s.h"
struct snd_soc_card_drvdata_davinci {
+ struct clk *mclk;
unsigned sysclk;
};
+static int evm_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))->mclk;
+
+ return clk_prepare_enable(mclk);
+}
+
+static void evm_shutdown(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))->mclk;
+
+ clk_disable_unprepare(mclk);
+}
+
static int evm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -59,6 +81,8 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
}
static struct snd_soc_ops evm_ops = {
+ .startup = evm_startup,
+ .shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
@@ -348,6 +372,7 @@ static int davinci_evm_probe(struct platform_device *pdev)
of_match_device(of_match_ptr(davinci_evm_dt_ids), &pdev->dev);
struct snd_soc_dai_link *dai = (struct snd_soc_dai_link *) match->data;
struct snd_soc_card_drvdata_davinci *drvdata = NULL;
+ struct clk *mclk;
int ret = 0;
evm_soc_card.dai_link = dai;
@@ -367,13 +392,38 @@ static int davinci_evm_probe(struct platform_device *pdev)
if (ret)
return ret;
+ mclk = of_clk_get_by_name(np, "ti,codec-clock");
+ if (PTR_ERR(mclk) == -EPROBE_DEFER) {
+ return -EPROBE_DEFER;
+ } else if (IS_ERR(mclk)) {
+ dev_dbg(&pdev->dev, "Codec clock not found.\n");
+ mclk = NULL;
+ }
+
drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
if (!drvdata)
return -ENOMEM;
+ drvdata->mclk = mclk;
+
ret = of_property_read_u32(np, "ti,codec-clock-rate", &drvdata->sysclk);
- if (ret < 0)
- return -EINVAL;
+
+ if (ret < 0) {
+ if (!drvdata->mclk) {
+ dev_err(&pdev->dev,
+ "No clock or clock rate defined.\n");
+ return -EINVAL;
+ }
+ drvdata->sysclk = clk_get_rate(drvdata->mclk);
+ } else if (drvdata->mclk) {
+ unsigned int requestd_rate = drvdata->sysclk;
+ clk_set_rate(drvdata->mclk, drvdata->sysclk);
+ drvdata->sysclk = clk_get_rate(drvdata->mclk);
+ if (drvdata->sysclk != requestd_rate)
+ dev_warn(&pdev->dev,
+ "Could not get requested rate %u using %u.\n",
+ requestd_rate, drvdata->sysclk);
+ }
snd_soc_card_set_drvdata(&evm_soc_card, drvdata);
ret = devm_snd_soc_register_card(&pdev->dev, &evm_soc_card);
@@ -387,6 +437,12 @@ static int davinci_evm_probe(struct platform_device *pdev)
static int davinci_evm_remove(struct platform_device *pdev)
{
struct snd_soc_card *card = platform_get_drvdata(pdev);
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ (struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(card);
+
+ if (drvdata->mclk)
+ clk_put(drvdata->mclk);
snd_soc_unregister_card(card);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
2013-12-20 10:38 ` [PATCH RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings Jyri Sarha
@ 2013-12-31 13:16 ` Mark Brown
2014-01-15 11:12 ` Jyri Sarha
0 siblings, 1 reply; 29+ messages in thread
From: Mark Brown @ 2013-12-31 13:16 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, alsa-devel, dri-devel, bcousson, linux-omap,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1075 bytes --]
On Fri, Dec 20, 2013 at 12:38:27PM +0200, Jyri Sarha wrote:
> +static int evm_startup(struct snd_pcm_substream *substream)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct snd_soc_card *soc_card = rtd->codec->card;
> + struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
> + snd_soc_card_get_drvdata(soc_card))->mclk;
Why do you need to cast away void? Ths indicates something is going
wrong here though I can't see what.
> + mclk = of_clk_get_by_name(np, "ti,codec-clock");
> + if (PTR_ERR(mclk) == -EPROBE_DEFER) {
> + return -EPROBE_DEFER;
> + } else if (IS_ERR(mclk)) {
> + dev_dbg(&pdev->dev, "Codec clock not found.\n");
> + mclk = NULL;
> + }
The driver will unconditionally enable and disable the clock which I'd
not expect to work well if we got an error, I'd expect either NULL checks
on use or a fixed clock to be registered from code in the case where
we're using the old binding.
I'd also expect to see devm_clk_get() used here, with the standard
clock-names based lookup from DT.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
2013-12-31 13:16 ` Mark Brown
@ 2014-01-15 11:12 ` Jyri Sarha
0 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2014-01-15 11:12 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree, alsa-devel, dri-devel, bcousson, linux-omap,
linux-arm-kernel
On 12/31/2013 03:16 PM, Mark Brown wrote:
> On Fri, Dec 20, 2013 at 12:38:27PM +0200, Jyri Sarha wrote:
>
>> +static int evm_startup(struct snd_pcm_substream *substream)
>> +{
>> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> + struct snd_soc_card *soc_card = rtd->codec->card;
>> + struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
>> + snd_soc_card_get_drvdata(soc_card))->mclk;
>
> Why do you need to cast away void? Ths indicates something is going
> wrong here though I can't see what.
I'll fix that.
>> + mclk = of_clk_get_by_name(np, "ti,codec-clock");
>> + if (PTR_ERR(mclk) == -EPROBE_DEFER) {
>> + return -EPROBE_DEFER;
>> + } else if (IS_ERR(mclk)) {
>> + dev_dbg(&pdev->dev, "Codec clock not found.\n");
>> + mclk = NULL;
>> + }
>
> The driver will unconditionally enable and disable the clock which I'd
> not expect to work well if we got an error, I'd expect either NULL checks
> on use or a fixed clock to be registered from code in the case where
> we're using the old binding.
>
In the drivers/clk/clk.c the clk == NULL is always checked before using
the pointer. However, adding NULL checks would save couple of
lock-unlock cycles. I'll add them.
> I'd also expect to see devm_clk_get() used here, with the standard
> clock-names based lookup from DT.
>
I'll fix that.
Best regards,
Jyri
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
2013-12-20 10:37 ` [PATCH RFC v2 REPOST 1/8] clk: add gpio controlled clock Jyri Sarha
2013-12-20 10:38 ` [PATCH RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings Jyri Sarha
@ 2013-12-20 10:39 ` Jyri Sarha
2013-12-31 13:25 ` Mark Brown
2013-12-20 10:40 ` [PATCH RFC v2 REPOST 4/8] ASoC: hdmi-codec: Add devicetree binding with documentation Jyri Sarha
` (5 subsequent siblings)
8 siblings, 1 reply; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 10:39 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
bcousson
Cc: broonie, Jyri Sarha
Add machine driver support for BeagleBone-Black and other boards with
tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
port in I2S mode. The 44100 Hz sample-rate and it's multiples can not
be supported on Beaglebone-Black because of limited clock-rate
support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: bcousson@baylibre.com
---
.../bindings/sound/davinci-evm-audio.txt | 4 +-
sound/soc/davinci/davinci-evm.c | 167 +++++++++++++++++++-
2 files changed, 168 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 4aa00f6..f1e1031 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -1,7 +1,9 @@
* Texas Instruments SoC audio setups with TLV320AIC3X Codec
Required properties:
-- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx
+- compatible :
+ "ti,da830-evm-audio" : for DM365/DA8xx/OMAPL1x/AM33xx
+ "ti,am33xx-beaglebone-black-audio" : for Beaglebone-black HDMI audio
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index b28c9fd..3d3138d 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -21,6 +21,7 @@
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/soc.h>
+#include <sound/pcm_params.h>
#include <asm/dma.h>
#include <asm/mach-types.h>
@@ -33,8 +34,13 @@
struct snd_soc_card_drvdata_davinci {
struct clk *mclk;
unsigned sysclk;
+ struct snd_pcm_hw_constraint_list *rate_constraint;
};
+/* If changing sample format the tda998x configuration (REG_CTS_N) needs
+ to be changed. */
+#define TDA998X_SAMPLE_FORMAT SNDRV_PCM_FORMAT_S32_LE
+
static int evm_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
@@ -80,12 +86,80 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
return 0;
}
+static int evm_tda998x_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ (struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card);
+ struct snd_mask *fmt = constrs_mask(&runtime->hw_constraints,
+ SNDRV_PCM_HW_PARAM_FORMAT);
+ snd_mask_none(fmt);
+ snd_mask_set(fmt, TDA998X_SAMPLE_FORMAT);
+
+ runtime->hw.rate_min = drvdata->rate_constraint->list[0];
+ runtime->hw.rate_max = drvdata->rate_constraint->list[
+ drvdata->rate_constraint->count - 1];
+ runtime->hw.rates = SNDRV_PCM_RATE_KNOT;
+
+ snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+ drvdata->rate_constraint);
+ snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
+ 2, 2);
+
+ return evm_startup(substream);
+}
+
+static unsigned int evm_get_bclk(struct snd_pcm_hw_params *params)
+{
+ int sample_size = snd_pcm_format_width(params_format(params));
+ int rate = params_rate(params);
+ int channels = params_channels(params);
+
+ return sample_size * channels * rate;
+}
+
+static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ struct snd_soc_codec *codec = rtd->codec;
+ struct snd_soc_card *soc_card = codec->card;
+ struct platform_device *pdev = to_platform_device(soc_card->dev);
+ unsigned int bclk_freq = evm_get_bclk(params);
+ unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))->sysclk;
+ int ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, 1, sysclk / bclk_freq);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "can't set CPU DAI clock divider %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
+ if (ret < 0)
+ return ret;
+
+ return ret;
+}
+
static struct snd_soc_ops evm_ops = {
.startup = evm_startup,
.shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
+static struct snd_soc_ops evm_tda998x_ops = {
+ .startup = evm_tda998x_startup,
+ .shutdown = evm_shutdown,
+ .hw_params = evm_tda998x_hw_params,
+};
+
/* davinci-evm machine dapm widgets */
static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = {
SND_SOC_DAPM_HP("Headphone Jack", NULL),
@@ -152,6 +226,81 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
return 0;
}
+static unsigned int tda998x_hdmi_rates[] = {
+ 32000,
+ 44100,
+ 48000,
+ 88200,
+ 96000,
+};
+
+static struct snd_pcm_hw_constraint_list *evm_tda998x_rate_constraint(
+ struct snd_soc_card *soc_card)
+{
+ struct platform_device *pdev = to_platform_device(soc_card->dev);
+ unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))->sysclk;
+ struct snd_pcm_hw_constraint_list *ret;
+ unsigned int *rates;
+ int i = 0, j = 0;
+
+ ret = devm_kzalloc(soc_card->dev, sizeof(*ret) +
+ sizeof(tda998x_hdmi_rates), GFP_KERNEL);
+ if (!ret) {
+ dev_err(&pdev->dev, "Unable to allocate rate constraint!\n");
+ return NULL;
+ }
+
+ rates = (unsigned int *)&ret[1];
+ ret->list = rates;
+ ret->mask = 0;
+ for (; i < ARRAY_SIZE(tda998x_hdmi_rates); i++) {
+ unsigned int bclk_freq = tda998x_hdmi_rates[i] * 2 *
+ snd_pcm_format_width(TDA998X_SAMPLE_FORMAT);
+ if (sysclk % bclk_freq == 0) {
+ rates[j++] = tda998x_hdmi_rates[i];
+ dev_dbg(soc_card->dev, "Allowing rate %u\n",
+ tda998x_hdmi_rates[i]);
+ }
+ }
+ ret->count = j;
+ return ret;
+}
+
+static const struct snd_soc_dapm_widget tda998x_dapm_widgets[] = {
+ SND_SOC_DAPM_OUTPUT("HDMI Out"),
+};
+
+static int evm_tda998x_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ struct snd_soc_dapm_context *dapm = &rtd->codec->dapm;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ (struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card);
+ int ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 1);
+ if (ret < 0)
+ return ret;
+
+ drvdata->rate_constraint = evm_tda998x_rate_constraint(soc_card);
+
+ snd_soc_dapm_new_controls(dapm, tda998x_dapm_widgets,
+ ARRAY_SIZE(tda998x_dapm_widgets));
+
+ ret = snd_soc_of_parse_audio_routing(soc_card, "ti,audio-routing");
+
+ /* not connected */
+ snd_soc_dapm_disable_pin(dapm, "RX");
+
+ /* always connected */
+ snd_soc_dapm_enable_pin(dapm, "HDMI Out");
+
+ return 0;
+}
+
/* davinci-evm digital audio interface glue - connects codec <--> CPU */
static struct snd_soc_dai_link dm6446_evm_dai = {
.name = "TLV320AIC3X",
@@ -337,7 +486,7 @@ static struct snd_soc_card da850_snd_soc_card = {
#if defined(CONFIG_OF)
/*
- * The struct is used as place holder. It will be completely
+ * The structs are used as place holders. They will be completely
* filled with data from dt node.
*/
static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
@@ -350,10 +499,24 @@ static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
SND_SOC_DAIFMT_IB_NF,
};
+static struct snd_soc_dai_link evm_dai_tda998x_hdmi = {
+ .name = "NXP TDA998x HDMI Chip",
+ .stream_name = "HDMI",
+ .codec_dai_name = "hdmi-hifi",
+ .ops = &evm_tda998x_ops,
+ .init = evm_tda998x_init,
+ .dai_fmt = (SND_SOC_DAIFMT_CBS_CFS | SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_IB_NF),
+};
+
static const struct of_device_id davinci_evm_dt_ids[] = {
{
.compatible = "ti,da830-evm-audio",
- .data = (void *) &evm_dai_tlv320aic3x,
+ .data = &evm_dai_tlv320aic3x,
+ },
+ {
+ .compatible = "ti,am33xx-beaglebone-black-audio",
+ .data = &evm_dai_tda998x_hdmi,
},
{ /* sentinel */ }
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2013-12-20 10:39 ` [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus Jyri Sarha
@ 2013-12-31 13:25 ` Mark Brown
2014-01-15 11:27 ` Jyri Sarha
0 siblings, 1 reply; 29+ messages in thread
From: Mark Brown @ 2013-12-31 13:25 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, alsa-devel, dri-devel, bcousson, linux-omap,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 3566 bytes --]
On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote:
> Add machine driver support for BeagleBone-Black and other boards with
> tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
> port in I2S mode. The 44100 Hz sample-rate and it's multiples can not
> be supported on Beaglebone-Black because of limited clock-rate
Can the drivers infer this from the clocks?
> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
> The 8 least significant bits are ignored.
Where does this constraint come from?
> + struct snd_soc_card_drvdata_davinci *drvdata =
> + (struct snd_soc_card_drvdata_davinci *)
> + snd_soc_card_get_drvdata(soc_card);
Again with the casting.
> + runtime->hw.rate_min = drvdata->rate_constraint->list[0];
> + runtime->hw.rate_max = drvdata->rate_constraint->list[
> + drvdata->rate_constraint->count - 1];
> + runtime->hw.rates = SNDRV_PCM_RATE_KNOT;
> +
> + snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
> + drvdata->rate_constraint);
> + snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
> + 2, 2);
Why not just set all this statically when registering the DAI?
> +static unsigned int evm_get_bclk(struct snd_pcm_hw_params *params)
> +{
> + int sample_size = snd_pcm_format_width(params_format(params));
> + int rate = params_rate(params);
> + int channels = params_channels(params);
> +
> + return sample_size * channels * rate;
> +}
snd_soc_params_to_frame_size().
> +static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
> + struct snd_soc_codec *codec = rtd->codec;
> + struct snd_soc_card *soc_card = codec->card;
> + struct platform_device *pdev = to_platform_device(soc_card->dev);
> + unsigned int bclk_freq = evm_get_bclk(params);
> + unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
> + snd_soc_card_get_drvdata(soc_card))->sysclk;
> + int ret;
> +
> + ret = snd_soc_dai_set_clkdiv(cpu_dai, 1, sysclk / bclk_freq);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "can't set CPU DAI clock divider %d\n",
> + ret);
> + return ret;
> + }
This looks like something the DAI driver ought to be able to work out
for itself based on the clock rate and sample format.
> +static unsigned int tda998x_hdmi_rates[] = {
> + 32000,
> + 44100,
> + 48000,
> + 88200,
> + 96000,
> +};
The changelog said that 44.1kHz and its multiples couldn't be supported
- is that just the multiples?
> +static struct snd_pcm_hw_constraint_list *evm_tda998x_rate_constraint(
> + struct snd_soc_card *soc_card)
> +{
> + struct platform_device *pdev = to_platform_device(soc_card->dev);
> + unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
> + snd_soc_card_get_drvdata(soc_card))->sysclk;
> + struct snd_pcm_hw_constraint_list *ret;
> + unsigned int *rates;
> + int i = 0, j = 0;
> +
> + ret = devm_kzalloc(soc_card->dev, sizeof(*ret) +
> + sizeof(tda998x_hdmi_rates), GFP_KERNEL);
> + if (!ret) {
> + dev_err(&pdev->dev, "Unable to allocate rate constraint!\n");
OOM is already very verbose, don't bother.
> + return NULL;
> + }
> +
> + rates = (unsigned int *)&ret[1];
> + ret->list = rates;
> + ret->mask = 0;
> + for (; i < ARRAY_SIZE(tda998x_hdmi_rates); i++) {
This is all very hard to read. Why has the assignment of i been moved
up to the declaration rather than put here as is idiomatic, what's all
the casting going on with ret and in general?
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2013-12-31 13:25 ` Mark Brown
@ 2014-01-15 11:27 ` Jyri Sarha
2014-01-15 13:48 ` Anssi Hannula
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Jyri Sarha @ 2014-01-15 11:27 UTC (permalink / raw)
To: Mark Brown, Ujfalusi, Peter
Cc: devicetree, alsa-devel, dri-devel, bcousson, linux-omap,
linux-arm-kernel
On 12/31/2013 03:25 PM, Mark Brown wrote:
> On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote:
>
>> Add machine driver support for BeagleBone-Black and other boards with
>> tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
>> port in I2S mode. The 44100 Hz sample-rate and it's multiples can not
>> be supported on Beaglebone-Black because of limited clock-rate
>
> Can the drivers infer this from the clocks?
It does. The commit message is referring to a BBB HW specific feature.
Guess I should remove that note from the commit message, since it does
not concern the code itself.
>
>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
>> The 8 least significant bits are ignored.
>
> Where does this constraint come from?
>
From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
register statically to a value that works only with 4 byte samples.
According to my tests it is possible to support 3 and 2 byte samples too
by changing the CTS_N register value, but I am not sure if the
configuration can be changed on the fly. My data sheet of the nxp chip
is very vague about the register definitions, but I suppose the register
configures some clock divider on the chip. HDMI supports only upto 24bit
audio and the data sheet states that any extraneous least significant
bits are ignored.
>> + struct snd_soc_card_drvdata_davinci *drvdata =
>> + (struct snd_soc_card_drvdata_davinci *)
>> + snd_soc_card_get_drvdata(soc_card);
>
> Again with the casting.
>
I'll fix that.
>> + runtime->hw.rate_min = drvdata->rate_constraint->list[0];
>> + runtime->hw.rate_max = drvdata->rate_constraint->list[
>> + drvdata->rate_constraint->count - 1];
>> + runtime->hw.rates = SNDRV_PCM_RATE_KNOT;
>> +
>> + snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
>> + drvdata->rate_constraint);
>> + snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
>> + 2, 2);
>
> Why not just set all this statically when registering the DAI?
Because there is no relevant DAI to where to put these limitations. I
did not want to add yet another dummy codec driver, but decided to use
the already existing ASoC HDMI codec. By default the driver support all
audio params supported by HDMI. The limitations are coming from NXP
chip, the NXP driver, and because the chip is used in i2s mode. In other
words the limitation is coming from machine setup, not from the DAIs.
>
>> +static unsigned int evm_get_bclk(struct snd_pcm_hw_params *params)
>> +{
>> + int sample_size = snd_pcm_format_width(params_format(params));
>> + int rate = params_rate(params);
>> + int channels = params_channels(params);
>> +
>> + return sample_size * channels * rate;
>> +}
>
> snd_soc_params_to_frame_size().
>
Rather snd_soc_params_to_bclk(), but thanks. I'll use that.
>> +static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
>> + struct snd_pcm_hw_params *params)
>> +{
>> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
>> + struct snd_soc_codec *codec = rtd->codec;
>> + struct snd_soc_card *soc_card = codec->card;
>> + struct platform_device *pdev = to_platform_device(soc_card->dev);
>> + unsigned int bclk_freq = evm_get_bclk(params);
>> + unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
>> + snd_soc_card_get_drvdata(soc_card))->sysclk;
>> + int ret;
>> +
>> + ret = snd_soc_dai_set_clkdiv(cpu_dai, 1, sysclk / bclk_freq);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "can't set CPU DAI clock divider %d\n",
>> + ret);
>> + return ret;
>> + }
>
> This looks like something the DAI driver ought to be able to work out
> for itself based on the clock rate and sample format.
>
I guess that could be done.
Peter, what do you say if I set BCLK divider automatically if mcasp
set_sysclk() has been called with SND_SOC_CLOCK_IN?
>> +static unsigned int tda998x_hdmi_rates[] = {
>> + 32000,
>> + 44100,
>> + 48000,
>> + 88200,
>> + 96000,
>> +};
>
> The changelog said that 44.1kHz and its multiples couldn't be supported
> - is that just the multiples?
>
As I mentioned earlier, that is a BBB HW limitation only, the code
bellow is able to decide what rates are available based on the sysclk rate.
>> +static struct snd_pcm_hw_constraint_list *evm_tda998x_rate_constraint(
>> + struct snd_soc_card *soc_card)
>> +{
>> + struct platform_device *pdev = to_platform_device(soc_card->dev);
>> + unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
>> + snd_soc_card_get_drvdata(soc_card))->sysclk;
>> + struct snd_pcm_hw_constraint_list *ret;
>> + unsigned int *rates;
>> + int i = 0, j = 0;
>> +
>> + ret = devm_kzalloc(soc_card->dev, sizeof(*ret) +
>> + sizeof(tda998x_hdmi_rates), GFP_KERNEL);
>> + if (!ret) {
>> + dev_err(&pdev->dev, "Unable to allocate rate constraint!\n");
>
> OOM is already very verbose, don't bother.
>
Ok, I'll remove that.
>> + return NULL;
>> + }
>> +
>> + rates = (unsigned int *)&ret[1];
>> + ret->list = rates;
>> + ret->mask = 0;
>> + for (; i < ARRAY_SIZE(tda998x_hdmi_rates); i++) {
>
> This is all very hard to read. Why has the assignment of i been moved
> up to the declaration rather than put here as is idiomatic, what's all
> the casting going on with ret and in general?
>
No excuse for i initialization, I'll fix that. The casting is just to
survive with just one kmalloc call instead of separate memory blobs for
struct snd_pcm_hw_constraint_list and referred list of supported sample
rates. I'll allocate a second blob, if that is easier to read.
Best regards,
Jyri
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2014-01-15 11:27 ` Jyri Sarha
@ 2014-01-15 13:48 ` Anssi Hannula
2014-01-15 16:28 ` Jyri Sarha
2014-01-15 15:51 ` [alsa-devel] " Jean-Francois Moine
2014-01-21 19:15 ` Mark Brown
2 siblings, 1 reply; 29+ messages in thread
From: Anssi Hannula @ 2014-01-15 13:48 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, alsa-devel, dri-devel, Ujfalusi, Peter, Mark Brown,
bcousson, linux-omap, linux-arm-kernel
15.01.2014 13:27, Jyri Sarha kirjoitti:
> On 12/31/2013 03:25 PM, Mark Brown wrote:
>> On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote:
>>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
>>> The 8 least significant bits are ignored.
>>
>> Where does this constraint come from?
>>
>
> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> register statically to a value that works only with 4 byte samples.
> According to my tests it is possible to support 3 and 2 byte samples too
> by changing the CTS_N register value, but I am not sure if the
> configuration can be changed on the fly. My data sheet of the nxp chip
> is very vague about the register definitions, but I suppose the register
> configures some clock divider on the chip. HDMI supports only upto 24bit
> audio and the data sheet states that any extraneous least significant
> bits are ignored.
That sounds strange, CTS/N values only depend on audio sample rate and
TMDS/video clock, not on the audio format or the size of samples (HDMI
spec sec 7.2 - Audio Sample Clock Capture and Regeneration).
Sure there isn't anything more going on (like the used HDMI sink being
more tolerant to wrong CTS/N with 4-byte samples, or more likely
something else I can't immediately think of)?
BTW, radeon driver has some code that calculates static CTS/N values
since the hw autogeneration is not reliable there:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/r600_hdmi.c
Not that it directly helps now, but just for the record...
--
Anssi Hannula
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2014-01-15 13:48 ` Anssi Hannula
@ 2014-01-15 16:28 ` Jyri Sarha
0 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2014-01-15 16:28 UTC (permalink / raw)
To: Anssi Hannula
Cc: devicetree, alsa-devel, dri-devel, Ujfalusi, Peter, Mark Brown,
bcousson, linux-omap, linux-arm-kernel
On 01/15/2014 03:48 PM, Anssi Hannula wrote:
> 15.01.2014 13:27, Jyri Sarha kirjoitti:
>> On 12/31/2013 03:25 PM, Mark Brown wrote:
>>> On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote:
>>>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
>>>> The 8 least significant bits are ignored.
>>>
>>> Where does this constraint come from?
>>>
>>
>> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
>> register statically to a value that works only with 4 byte samples.
>> According to my tests it is possible to support 3 and 2 byte samples too
>> by changing the CTS_N register value, but I am not sure if the
>> configuration can be changed on the fly. My data sheet of the nxp chip
>> is very vague about the register definitions, but I suppose the register
>> configures some clock divider on the chip. HDMI supports only upto 24bit
>> audio and the data sheet states that any extraneous least significant
>> bits are ignored.
>
> That sounds strange, CTS/N values only depend on audio sample rate and
> TMDS/video clock, not on the audio format or the size of samples (HDMI
> spec sec 7.2 - Audio Sample Clock Capture and Regeneration).
>
> Sure there isn't anything more going on (like the used HDMI sink being
> more tolerant to wrong CTS/N with 4-byte samples, or more likely
> something else I can't immediately think of)?
>
On theoretical level I am not really sure about anything, because have
not been able to get my hands on proper NXP TDA19988 documentation.
However, while playing around with my Beaglebone-Black I have have found
out in practice that by changing CTS_N register's (page 0x11 reg 0x0c)
K_SEL bits (bit 2 to 0)[1] I can get 2, 3 and 4 byte samples to work
consistently by setting:
K_SEL = 1 for SNDRV_PCM_FORMAT_S16_LE
K_SEL = 2 for SNDRV_PCM_FORMAT_S24_3LE
K_SEL = 3 for SNDRV_PCM_FORMAT_S32_LE
Because I do not really know what is going on, I did not want to suggest
any changes to the driver and just use the format that works with the
current driver version.
The HDMI sinks I have been using are a Toshiba 22B2LF1G and Thomson
42E90NF32 televisions. About those I just know that they both behave the
same way.
Best regards,
Jyri
[1] The closest data sheet that has any description about the chip
registers I have found is this:
http://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/TDA9983B.pdf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2014-01-15 11:27 ` Jyri Sarha
2014-01-15 13:48 ` Anssi Hannula
@ 2014-01-15 15:51 ` Jean-Francois Moine
2014-01-22 9:20 ` Jyri Sarha
2014-01-21 19:15 ` Mark Brown
2 siblings, 1 reply; 29+ messages in thread
From: Jean-Francois Moine @ 2014-01-15 15:51 UTC (permalink / raw)
To: Jyri Sarha
Cc: Mark Brown, Ujfalusi, Peter, devicetree, alsa-devel, dri-devel,
bcousson, linux-omap, linux-arm-kernel
On Wed, 15 Jan 2014 13:27:21 +0200
Jyri Sarha <jsarha@ti.com> wrote:
> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> register statically to a value that works only with 4 byte samples.
> According to my tests it is possible to support 3 and 2 byte samples too
> by changing the CTS_N register value, but I am not sure if the
> configuration can be changed on the fly. My data sheet of the nxp chip
> is very vague about the register definitions, but I suppose the register
> configures some clock divider on the chip. HDMI supports only upto 24bit
> audio and the data sheet states that any extraneous least significant
> bits are ignored.
In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
not set).
Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
formats are working well with I2S input at any rate.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2014-01-15 15:51 ` [alsa-devel] " Jean-Francois Moine
@ 2014-01-22 9:20 ` Jyri Sarha
2014-01-22 10:19 ` [alsa-devel] " Jean-Francois Moine
0 siblings, 1 reply; 29+ messages in thread
From: Jyri Sarha @ 2014-01-22 9:20 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: devicetree, alsa-devel, dri-devel, Ujfalusi, Peter, Mark Brown,
bcousson, linux-omap, linux-arm-kernel
On 01/15/2014 05:51 PM, Jean-Francois Moine wrote:
> On Wed, 15 Jan 2014 13:27:21 +0200
> Jyri Sarha <jsarha@ti.com> wrote:
>
>> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
>> register statically to a value that works only with 4 byte samples.
>> According to my tests it is possible to support 3 and 2 byte samples too
>> by changing the CTS_N register value, but I am not sure if the
>> configuration can be changed on the fly. My data sheet of the nxp chip
>> is very vague about the register definitions, but I suppose the register
>> configures some clock divider on the chip. HDMI supports only upto 24bit
>> audio and the data sheet states that any extraneous least significant
>> bits are ignored.
>
> In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
> not set).
>
> Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
> formats are working well with I2S input at any rate.
>
Could you refer the kernel version (main line?) and the involved ASoC
drivers so could take I a look if there is something I could do differently?
Best regards,
Jyri
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2014-01-22 9:20 ` Jyri Sarha
@ 2014-01-22 10:19 ` Jean-Francois Moine
2014-01-22 10:46 ` Jean-Francois Moine
0 siblings, 1 reply; 29+ messages in thread
From: Jean-Francois Moine @ 2014-01-22 10:19 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, alsa-devel, dri-devel, Ujfalusi, Peter, Mark Brown,
bcousson, linux-omap, linux-arm-kernel
On Wed, 22 Jan 2014 11:20:32 +0200
Jyri Sarha <jsarha@ti.com> wrote:
> On 01/15/2014 05:51 PM, Jean-Francois Moine wrote:
> > On Wed, 15 Jan 2014 13:27:21 +0200
> > Jyri Sarha <jsarha@ti.com> wrote:
> >
> >> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> >> register statically to a value that works only with 4 byte samples.
> >> According to my tests it is possible to support 3 and 2 byte samples too
> >> by changing the CTS_N register value, but I am not sure if the
> >> configuration can be changed on the fly. My data sheet of the nxp chip
> >> is very vague about the register definitions, but I suppose the register
> >> configures some clock divider on the chip. HDMI supports only upto 24bit
> >> audio and the data sheet states that any extraneous least significant
> >> bits are ignored.
> >
> > In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
> > not set).
> >
> > Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
> > formats are working well with I2S input at any rate.
> >
>
> Could you refer the kernel version (main line?) and the involved ASoC
> drivers so could take I a look if there is something I could do differently?
Both drivers are in the kernel main line.
The ASoC is in sound/soc/kirkwood/. kirkwood-i2s.c defines the DAIs I2S
and S/PDIF outputs.
As both I2S and S/PDIF may be used for HDMI output in the Cubox,
I wrote a tda998x CODEC which gets the audio ports from the DT and
dynamically sets these ports and the audio type (i2s / spdif) on audio
streaming start. I have not submitted yet this codec and the associated
changes in tda998x, because I am waiting for a first patch series on the
tda998x to be applied
(http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2014-01-22 10:19 ` [alsa-devel] " Jean-Francois Moine
@ 2014-01-22 10:46 ` Jean-Francois Moine
0 siblings, 0 replies; 29+ messages in thread
From: Jean-Francois Moine @ 2014-01-22 10:46 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Jyri Sarha, devicetree, alsa-devel, dri-devel, Ujfalusi, Peter,
Mark Brown, bcousson, linux-omap, linux-arm-kernel
On Wed, 22 Jan 2014 11:19:53 +0100
Jean-Francois Moine <moinejf@free.fr> wrote:
> As both I2S and S/PDIF may be used for HDMI output in the Cubox,
> I wrote a tda998x CODEC which gets the audio ports from the DT and
> dynamically sets these ports and the audio type (i2s / spdif) on audio
> streaming start. I have not submitted yet this codec and the associated
> changes in tda998x, because I am waiting for a first patch series on the
> tda998x to be applied
> (http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).
Sorry, the last patch request is
http://lists.freedesktop.org/archives/dri-devel/2014-January/052201.html
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2014-01-15 11:27 ` Jyri Sarha
2014-01-15 13:48 ` Anssi Hannula
2014-01-15 15:51 ` [alsa-devel] " Jean-Francois Moine
@ 2014-01-21 19:15 ` Mark Brown
2014-01-24 13:01 ` Jyri Sarha
2 siblings, 1 reply; 29+ messages in thread
From: Mark Brown @ 2014-01-21 19:15 UTC (permalink / raw)
To: Jyri Sarha
Cc: Ujfalusi, Peter, linux-arm-kernel, linux-omap, alsa-devel,
dri-devel, devicetree, bcousson
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
On Wed, Jan 15, 2014 at 01:27:21PM +0200, Jyri Sarha wrote:
> On 12/31/2013 03:25 PM, Mark Brown wrote:
> >>support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
> >>The 8 least significant bits are ignored.
> >Where does this constraint come from?
> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> register statically to a value that works only with 4 byte samples.
> According to my tests it is possible to support 3 and 2 byte samples
> too by changing the CTS_N register value, but I am not sure if the
> configuration can be changed on the fly. My data sheet of the nxp
> chip is very vague about the register definitions, but I suppose the
> register configures some clock divider on the chip. HDMI supports
> only upto 24bit audio and the data sheet states that any extraneous
> least significant bits are ignored.
Hrm. This sounds like it ought to be presenting as an ASoC CODEC
driver.
> >>+ snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
> >>+ 2, 2);
> >Why not just set all this statically when registering the DAI?
> Because there is no relevant DAI to where to put these limitations.
> I did not want to add yet another dummy codec driver, but decided to
> use the already existing ASoC HDMI codec. By default the driver
> support all audio params supported by HDMI. The limitations are
> coming from NXP chip, the NXP driver, and because the chip is used
> in i2s mode. In other words the limitation is coming from machine
> setup, not from the DAIs.
OK, but it sounds like it's got register configuration as well? That
really does sound like a device that ought to have a driver...
> No excuse for i initialization, I'll fix that. The casting is just
> to survive with just one kmalloc call instead of separate memory
> blobs for
> struct snd_pcm_hw_constraint_list and referred list of supported
> sample rates. I'll allocate a second blob, if that is easier to
> read.
Yes, please. Unless it's something where memory is getting tight (eg,
due to be allocated a lot) it's more important that we can read the code
than that we save a few bytes.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
2014-01-21 19:15 ` Mark Brown
@ 2014-01-24 13:01 ` Jyri Sarha
0 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2014-01-24 13:01 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree, alsa-devel, dri-devel, Ujfalusi, Peter, bcousson,
linux-omap, linux-arm-kernel
On 01/21/2014 09:15 PM, Mark Brown wrote:
> On Wed, Jan 15, 2014 at 01:27:21PM +0200, Jyri Sarha wrote:
>> On 12/31/2013 03:25 PM, Mark Brown wrote:
>
>>>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
>>>> The 8 least significant bits are ignored.
>
>>> Where does this constraint come from?
>
>> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
>> register statically to a value that works only with 4 byte samples.
>> According to my tests it is possible to support 3 and 2 byte samples
>> too by changing the CTS_N register value, but I am not sure if the
>> configuration can be changed on the fly. My data sheet of the nxp
>> chip is very vague about the register definitions, but I suppose the
>> register configures some clock divider on the chip. HDMI supports
>> only upto 24bit audio and the data sheet states that any extraneous
>> least significant bits are ignored.
>
> Hrm. This sounds like it ought to be presenting as an ASoC CODEC
> driver.
>
I do not disagree. I just do no not have a clear understanding how
something like that should be done. Either the tda998x_drv it self
should provide the ASoC codec driver or there should be some kind of API
that could be accessed by some driver under sound/soc/codecs. Anyway it
sound like Jean-Francois Moine is already doing that. I'll take his
driver into use as soon as his code is merged.
However, for now a simple implementation that I have does not really
need any interaction with the HDMI encoder and thus no codec driver either.
>>>> + snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
>>>> + 2, 2);
>
>>> Why not just set all this statically when registering the DAI?
>
>> Because there is no relevant DAI to where to put these limitations.
>> I did not want to add yet another dummy codec driver, but decided to
>> use the already existing ASoC HDMI codec. By default the driver
>> support all audio params supported by HDMI. The limitations are
>> coming from NXP chip, the NXP driver, and because the chip is used
>> in i2s mode. In other words the limitation is coming from machine
>> setup, not from the DAIs.
>
> OK, but it sounds like it's got register configuration as well? That
> really does sound like a device that ought to have a driver...
>
Sure, but it would not save form making runtime constraints. The usage
of i2s mode, which limits the number of channels, is selected by dai_fmt
call after dai registering.
Best regards,
Jyri
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH RFC v2 REPOST 4/8] ASoC: hdmi-codec: Add devicetree binding with documentation
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
` (2 preceding siblings ...)
2013-12-20 10:39 ` [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus Jyri Sarha
@ 2013-12-20 10:40 ` Jyri Sarha
2013-12-31 13:26 ` Mark Brown
2013-12-20 10:40 ` [PATCH RFC v2 REPOST 5/8] ASoC: davinci: HDMI audio build for AM33XX and TDA998x Jyri Sarha
` (4 subsequent siblings)
8 siblings, 1 reply; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 10:40 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
bcousson
Cc: broonie, Jyri Sarha
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: bcousson@baylibre.com
---
Documentation/devicetree/bindings/sound/hdmi.txt | 17 +++++++++++++++++
sound/soc/codecs/hdmi.c | 10 ++++++++++
2 files changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt
diff --git a/Documentation/devicetree/bindings/sound/hdmi.txt b/Documentation/devicetree/bindings/sound/hdmi.txt
new file mode 100644
index 0000000..31af7bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/hdmi.txt
@@ -0,0 +1,17 @@
+Device-Tree bindings for dummy HDMI codec
+
+Required properties:
+ - compatible: should be "linux,hdmi-audio".
+
+CODEC output pins:
+ * TX
+
+CODEC input pins:
+ * RX
+
+Example node:
+
+ hdmi_audio: hdmi_audio@0 {
+ compatible = "linux,hdmi-audio";
+ status = "okay";
+ };
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
index 32797a8..9cb1c7d 100644
--- a/sound/soc/codecs/hdmi.c
+++ b/sound/soc/codecs/hdmi.c
@@ -20,6 +20,7 @@
*/
#include <linux/module.h>
#include <sound/soc.h>
+#include <linux/of_device.h>
#define DRV_NAME "hdmi-audio-codec"
@@ -60,6 +61,14 @@ static struct snd_soc_dai_driver hdmi_codec_dai = {
};
+#ifdef CONFIG_OF
+static const struct of_device_id hdmi_audio_codec_ids[] = {
+ { .compatible = "linux,hdmi-audio", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids);
+#endif
+
static struct snd_soc_codec_driver hdmi_codec = {
.dapm_widgets = hdmi_widgets,
.num_dapm_widgets = ARRAY_SIZE(hdmi_widgets),
@@ -83,6 +92,7 @@ static struct platform_driver hdmi_codec_driver = {
.driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(hdmi_audio_codec_ids),
},
.probe = hdmi_codec_probe,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH RFC v2 REPOST 4/8] ASoC: hdmi-codec: Add devicetree binding with documentation
2013-12-20 10:40 ` [PATCH RFC v2 REPOST 4/8] ASoC: hdmi-codec: Add devicetree binding with documentation Jyri Sarha
@ 2013-12-31 13:26 ` Mark Brown
0 siblings, 0 replies; 29+ messages in thread
From: Mark Brown @ 2013-12-31 13:26 UTC (permalink / raw)
To: Jyri Sarha
Cc: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
bcousson
[-- Attachment #1: Type: text/plain, Size: 150 bytes --]
On Fri, Dec 20, 2013 at 12:40:16PM +0200, Jyri Sarha wrote:
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> cc: bcousson@baylibre.com
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH RFC v2 REPOST 5/8] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
` (3 preceding siblings ...)
2013-12-20 10:40 ` [PATCH RFC v2 REPOST 4/8] ASoC: hdmi-codec: Add devicetree binding with documentation Jyri Sarha
@ 2013-12-20 10:40 ` Jyri Sarha
2013-12-20 10:41 ` [PATCH RFC v2 REPOST 6/8] drm/tilcdc: Add I2C HDMI audio config for tda998x Jyri Sarha
` (3 subsequent siblings)
8 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 10:40 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree
Cc: broonie, Jyri Sarha
Adds configuration option for HDMI audio support for AM33XX based
boards with NXP TDA998x HDMI transmitter. The audio is connected to
NXP TDA998x trough McASP running in i2s mode.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
sound/soc/davinci/Kconfig | 12 ++++++++++++
sound/soc/davinci/Makefile | 1 +
2 files changed, 13 insertions(+)
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index a8ec1fc..40dd5d1 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -26,6 +26,18 @@ config SND_AM33XX_SOC_EVM
AM335X-EVMSK, and BeagelBone with AudioCape boards have this
setup.
+config SND_AM335X_SOC_NXPTDA_EVM
+ tristate "HDMI Audio for the AM33XX chip based boards with TDA998x"
+ depends on SND_DAVINCI_SOC && SOC_AM33XX
+ depends on DRM_TILCDC && DRM_I2C_NXP_TDA998X
+ select SND_SOC_HDMI_CODEC
+ select SND_DAVINCI_SOC_MCASP
+ help
+ Say Y or M if you want to add support for HDMI SoC audio on
+ AM33XX boards with NXP TDA998x HDMI transmitter. For example
+ BeagleBoneBack. The audio is connected to NXP TDA998x trough
+ McASP running in i2s mode.
+
config SND_DAVINCI_SOC_EVM
tristate "SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM"
depends on SND_DAVINCI_SOC
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
index 744d4d9..7587a70 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o
snd-soc-evm-objs := davinci-evm.o
obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o
+obj-$(CONFIG_SND_AM335X_SOC_NXPTDA_EVM) += snd-soc-evm.o
--
1.7.9.5
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH RFC v2 REPOST 6/8] drm/tilcdc: Add I2C HDMI audio config for tda998x
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
` (4 preceding siblings ...)
2013-12-20 10:40 ` [PATCH RFC v2 REPOST 5/8] ASoC: davinci: HDMI audio build for AM33XX and TDA998x Jyri Sarha
@ 2013-12-20 10:41 ` Jyri Sarha
2013-12-20 10:42 ` [PATCH RFC v2 REPOST 7/8] ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support Jyri Sarha
` (2 subsequent siblings)
8 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 10:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
airlied
Cc: broonie, Jyri Sarha
The configuration is needed for HDMI audio. The "swap" and "mirr"
parameters have to be correctly set in the configuration in order to
have proper colors in the HDMI picture.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: airlied@linux.ie
---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 595068b..e43240a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -19,6 +19,7 @@
#include <linux/pinctrl/pinmux.h>
#include <linux/pinctrl/consumer.h>
#include <drm/drm_encoder_slave.h>
+#include <drm/i2c/tda998x.h>
#include "tilcdc_drv.h"
@@ -111,8 +112,29 @@ static const struct drm_encoder_helper_funcs slave_encoder_helper_funcs = {
.restore = drm_i2c_encoder_restore,
};
+static struct tda998x_encoder_params tda998x_pdata = {
+ .swap_b = 0x3,
+ .mirr_b = 0x0,
+ .swap_a = 0x2,
+ .mirr_a = 0x0,
+ .swap_d = 0x1,
+ .mirr_d = 0x0,
+ .swap_c = 0x0,
+ .mirr_c = 0x0,
+ .swap_f = 0x5,
+ .mirr_f = 0x0,
+ .swap_e = 0x4,
+ .mirr_e = 0x0,
+ .audio_cfg = 0x3, /* I2S mode */
+ .audio_clk_cfg = 1, /* select clock pin */
+ .audio_frame[1] = 1, /* channels - 1 */
+ .audio_format = AFMT_I2S,
+ .audio_sample_rate = 48000,
+};
+
static const struct i2c_board_info info = {
- I2C_BOARD_INFO("tda998x", 0x70)
+ I2C_BOARD_INFO("tda998x", 0x70),
+ .platform_data = &tda998x_pdata,
};
static struct drm_encoder *slave_encoder_create(struct drm_device *dev,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH RFC v2 REPOST 7/8] ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
` (5 preceding siblings ...)
2013-12-20 10:41 ` [PATCH RFC v2 REPOST 6/8] drm/tilcdc: Add I2C HDMI audio config for tda998x Jyri Sarha
@ 2013-12-20 10:42 ` Jyri Sarha
2013-12-20 10:43 ` [PATCH RFC v2 REPOST 8/8] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support Jyri Sarha
2013-12-20 11:30 ` [alsa-devel] [PATCH RFC v2 REPOST 0/8] Beaglebone-Black HDMI audio Mark Brown
8 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 10:42 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
tony
Cc: broonie, Jyri Sarha
This enables HDMI video support on Beaglebone-Black.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: tony@atomide.com
---
arch/arm/configs/omap2plus_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 254cf05..52b0d92 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -176,6 +176,9 @@ CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
CONFIG_REGULATOR_TPS65910=y
+CONFIG_DRM=m
+CONFIG_DRM_I2C_NXP_TDA998X=m
+CONFIG_DRM_TILCDC=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
--
1.7.9.5
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH RFC v2 REPOST 8/8] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
` (6 preceding siblings ...)
2013-12-20 10:42 ` [PATCH RFC v2 REPOST 7/8] ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support Jyri Sarha
@ 2013-12-20 10:43 ` Jyri Sarha
2013-12-20 11:30 ` [alsa-devel] [PATCH RFC v2 REPOST 0/8] Beaglebone-Black HDMI audio Mark Brown
8 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 10:43 UTC (permalink / raw)
To: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
tony
Cc: broonie, Jyri Sarha
Select following:
CONFIG_SND_DAVINCI_SOC=m
CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: tony@atomide.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 52b0d92..c1a9730 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -216,6 +216,8 @@ CONFIG_SND_OMAP_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_DAVINCI_SOC=m
+CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
--
1.7.9.5
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [alsa-devel] [PATCH RFC v2 REPOST 0/8] Beaglebone-Black HDMI audio
2013-12-20 10:36 ` [PATCH RFC v2 REPOST 0/8] " Jyri Sarha
` (7 preceding siblings ...)
2013-12-20 10:43 ` [PATCH RFC v2 REPOST 8/8] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support Jyri Sarha
@ 2013-12-20 11:30 ` Mark Brown
2013-12-20 11:51 ` Jyri Sarha
8 siblings, 1 reply; 29+ messages in thread
From: Mark Brown @ 2013-12-20 11:30 UTC (permalink / raw)
To: Jyri Sarha
Cc: linux-arm-kernel, linux-omap, alsa-devel, dri-devel, devicetree,
bcousson
[-- Attachment #1: Type: text/plain, Size: 218 bytes --]
On Fri, Dec 20, 2013 at 12:36:56PM +0200, Jyri Sarha wrote:
> Changes since the first RFC version of the patches:
Please don't bury your e-mails in the middle of old threads, that's a
good way of getting them missed.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH RFC v2 REPOST 0/8] Beaglebone-Black HDMI audio
2013-12-20 11:30 ` [alsa-devel] [PATCH RFC v2 REPOST 0/8] Beaglebone-Black HDMI audio Mark Brown
@ 2013-12-20 11:51 ` Jyri Sarha
0 siblings, 0 replies; 29+ messages in thread
From: Jyri Sarha @ 2013-12-20 11:51 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree, alsa-devel, dri-devel, bcousson, linux-omap,
linux-arm-kernel
On 12/20/2013 01:30 PM, Mark Brown wrote:
> On Fri, Dec 20, 2013 at 12:36:56PM +0200, Jyri Sarha wrote:
>> Changes since the first RFC version of the patches:
>
> Please don't bury your e-mails in the middle of old threads, that's a
> good way of getting them missed.
>
I have done it for my own convenience to find the history of the patch
set when ever someone is commenting it. But I'll stop doing that from
now on.
Best regards,
Jyri
^ permalink raw reply [flat|nested] 29+ messages in thread