[PATCH v3 0/5] Beaglebone-Black HDMI audio

[PATCH v3 0/5] Beaglebone-Black HDMI audio

[Jyri Sarha]

Changes since v2:
- Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock"
- Some minor cleanups

The code has a functional dependency to:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html

Without the above patch the audio card does not probe.

The code has been rebased on top of Linux 3.17-rc5. The patches
bellow, the above dependency, and couple of commits to add BBB HDMI audio
support to omap2plus_defconfig can be pulled from:

https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio

Cheers,
Jyri

Jyri Sarha (5):
  clk: ti: add "ti,gpio-gate-clock" controlled clock
  drm/tilcdc: Add I2S HDMI audio config for tda998x
  ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S
    bus
  ASoC: davinci: HDMI audio build for AM33XX and TDA998x
  ARM: dts: am335x-boneblack: Add HDMI audio support

 .../bindings/clock/ti/gpio-gate-clock.txt          |   21 ++
 .../bindings/sound/davinci-evm-audio.txt           |    6 +-
 arch/arm/boot/dts/am335x-boneblack.dts             |   52 +++++
 drivers/clk/ti/Makefile                            |    2 +-
 drivers/clk/ti/gpio.c                              |  202 ++++++++++++++++++++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c              |   24 ++-
 sound/soc/davinci/Kconfig                          |   12 ++
 sound/soc/davinci/davinci-evm.c                    |   82 +++++++-
 8 files changed, 395 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
 create mode 100644 drivers/clk/ti/gpio.c

-- 
1.7.9.5

[PATCH v3 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock

[Jyri Sarha]

The added ti,gpio-gate-clock 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>
---
 .../bindings/clock/ti/gpio-gate-clock.txt          |   21 ++
 drivers/clk/ti/Makefile                            |    2 +-
 drivers/clk/ti/gpio.c                              |  202 ++++++++++++++++++++
 3 files changed, 224 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
 create mode 100644 drivers/clk/ti/gpio.c

diff --git a/Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt b/Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
new file mode 100644
index 0000000..6156f82
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/gpio-gate-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 "ti,gpio-gate-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 = "ti,gpio-gate-clock";
+		clocks = <&parentclk>;
+		#clock-cells = <0>;
+		enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+	};
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index ed4d0aa..88074d3 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -1,7 +1,7 @@
 ifneq ($(CONFIG_OF),)
 obj-y					+= clk.o autoidle.o clockdomain.o
 clk-common				= dpll.o composite.o divider.o gate.o \
-					  fixed-factor.o mux.o apll.o
+					  fixed-factor.o mux.o apll.o gpio.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(clk-common) clk-33xx.o
 obj-$(CONFIG_ARCH_OMAP2)		+= $(clk-common) interface.o clk-2xxx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= $(clk-common) interface.o clk-3xxx.o
diff --git a/drivers/clk/ti/gpio.c b/drivers/clk/ti/gpio.c
new file mode 100644
index 0000000..b973801
--- /dev/null
+++ b/drivers/clk/ti/gpio.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2012 - 2014 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Jyri Sarha <jsarha@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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>
+
+struct clk_gpio {
+	struct clk_hw	hw;
+	struct gpio_desc *gpiod;
+};
+
+/**
+ * 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 *clk = to_clk_gpio(hw);
+
+	gpiod_set_value(clk->gpiod, 1);
+
+	return 0;
+}
+
+static void clk_gpio_disable(struct clk_hw *hw)
+{
+	struct clk_gpio *clk = to_clk_gpio(hw);
+
+	gpiod_set_value(clk->gpiod, 0);
+}
+
+static int clk_gpio_is_enabled(struct clk_hw *hw)
+{
+	struct clk_gpio *clk = to_clk_gpio(hw);
+
+	return gpiod_get_value(clk->gpiod);
+}
+
+static const struct clk_ops clk_gpio_ops = {
+	.enable = clk_gpio_enable,
+	.disable = clk_gpio_disable,
+	.is_enabled = clk_gpio_is_enabled,
+};
+
+/**
+ * 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
+ * @gpiod: gpio descriptor to control this clock
+ */
+static struct clk *clk_register_gpio(struct device *dev, const char *name,
+		const char *parent_name, struct gpio_desc *gpiod,
+		unsigned long flags)
+{
+	struct clk_gpio *clk_gpio = NULL;
+	struct clk *clk = ERR_PTR(-EINVAL);
+	struct clk_init_data init = { NULL };
+	unsigned long gpio_flags;
+	int err;
+
+	if (gpiod_is_active_low(gpiod))
+		gpio_flags = GPIOF_OUT_INIT_HIGH;
+	else
+		gpio_flags = GPIOF_OUT_INIT_LOW;
+
+	if (dev)
+		err = devm_gpio_request_one(dev, desc_to_gpio(gpiod),
+					    gpio_flags, name);
+	else
+		err = gpio_request_one(desc_to_gpio(gpiod), gpio_flags, name);
+
+	if (err) {
+		pr_err("%s: %s: Error requesting clock control gpio %u\n",
+		       __func__, name, desc_to_gpio(gpiod));
+		return ERR_PTR(err);
+	}
+
+	if (dev)
+		clk_gpio = devm_kzalloc(dev, sizeof(struct clk_gpio),
+					GFP_KERNEL);
+	else
+		clk_gpio = kzalloc(sizeof(struct clk_gpio), GFP_KERNEL);
+
+	if (!clk_gpio)
+		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->gpiod = gpiod;
+	clk_gpio->hw.init = &init;
+
+	clk = clk_register(dev, &clk_gpio->hw);
+
+	if (!IS_ERR(clk))
+		return clk;
+
+	if (!dev)
+		kfree(clk_gpio);
+
+clk_register_gpio_err:
+	gpiod_put(gpiod);
+
+	return clk;
+}
+
+/**
+ * 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;
+	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 = _data;
+	struct clk *clk;
+	const char *clk_name = data->node->name;
+	const char *parent_name;
+	struct gpio_desc *gpiod;
+	int gpio;
+
+	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, NULL);
+	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);
+	}
+	gpiod = gpio_to_desc(gpio);
+
+	parent_name = of_clk_get_parent_name(data->node, 0);
+
+	clk = clk_register_gpio(NULL, clk_name, parent_name, gpiod, 0);
+	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
+ */
+static void __init of_gpio_clk_setup(struct device_node *node)
+{
+	struct clk_gpio_delayed_register_data *data;
+
+	data = kzalloc(sizeof(struct clk_gpio_delayed_register_data),
+		       GFP_KERNEL);
+	if (!data)
+		return;
+
+	data->node = node;
+	mutex_init(&data->lock);
+
+	of_clk_add_provider(node, of_clk_gpio_delayed_register_get, data);
+}
+CLK_OF_DECLARE(gpio_clk, "ti,gpio-gate-clock", of_gpio_clk_setup);
-- 
1.7.9.5

Re: [PATCH v3 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

On 16/09/14 23:40, Jyri Sarha wrote:
> The added ti,gpio-gate-clock 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>
> ---
>  .../bindings/clock/ti/gpio-gate-clock.txt          |   21 ++
>  drivers/clk/ti/Makefile                            |    2 +-
>  drivers/clk/ti/gpio.c                              |  202 ++++++++++++++++++++
>  3 files changed, 224 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
>  create mode 100644 drivers/clk/ti/gpio.c

Why is this a TI clock? Sounds like a generic one to me.

In any case, this should go through Mike.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock

[Nishanth Menon]

On 09/19/2014 08:07 AM, Tomi Valkeinen wrote:
> On 16/09/14 23:40, Jyri Sarha wrote:
>> The added ti,gpio-gate-clock 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>
>> ---
>>  .../bindings/clock/ti/gpio-gate-clock.txt          |   21 ++
>>  drivers/clk/ti/Makefile                            |    2 +-
>>  drivers/clk/ti/gpio.c                              |  202 ++++++++++++++++++++
>>  3 files changed, 224 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
>>  create mode 100644 drivers/clk/ti/gpio.c
> 
> Why is this a TI clock? Sounds like a generic one to me.

Like thread: https://lkml.org/lkml/2014/9/5/284 ?
> 
> In any case, this should go through Mike.
> 
yep - should have been posted independent of this series :).



-- 
Regards,
Nishanth Menon

Re: [PATCH v3 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

On 19/09/14 16:12, Nishanth Menon wrote:
> On 09/19/2014 08:07 AM, Tomi Valkeinen wrote:
>> On 16/09/14 23:40, Jyri Sarha wrote:
>>> The added ti,gpio-gate-clock 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>
>>> ---
>>>  .../bindings/clock/ti/gpio-gate-clock.txt          |   21 ++
>>>  drivers/clk/ti/Makefile                            |    2 +-
>>>  drivers/clk/ti/gpio.c                              |  202 ++++++++++++++++++++
>>>  3 files changed, 224 insertions(+), 1 deletion(-)
>>>  create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
>>>  create mode 100644 drivers/clk/ti/gpio.c
>>
>> Why is this a TI clock? Sounds like a generic one to me.
> 
> Like thread: https://lkml.org/lkml/2014/9/5/284 ?

Right, I should've read the earlier versions before making any smart
comments =).

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock

[Mike Turquette]

Quoting Tomi Valkeinen (2014-09-19 06:25:48)
> On 19/09/14 16:12, Nishanth Menon wrote:
> > On 09/19/2014 08:07 AM, Tomi Valkeinen wrote:
> >> On 16/09/14 23:40, Jyri Sarha wrote:
> >>> The added ti,gpio-gate-clock 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>
> >>> ---
> >>>  .../bindings/clock/ti/gpio-gate-clock.txt          |   21 ++
> >>>  drivers/clk/ti/Makefile                            |    2 +-
> >>>  drivers/clk/ti/gpio.c                              |  202 ++++++++++++++++++++
> >>>  3 files changed, 224 insertions(+), 1 deletion(-)
> >>>  create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
> >>>  create mode 100644 drivers/clk/ti/gpio.c
> >>
> >> Why is this a TI clock? Sounds like a generic one to me.
> > 
> > Like thread: https://lkml.org/lkml/2014/9/5/284 ?
> 
> Right, I should've read the earlier versions before making any smart
> comments =).

No supporters cropped up for the generic gpio clock, but the design is
common enough to merit a common clock type. And all of that stuff I said
about the machine-specific ops isn't that relevant since it is hidden
behing the gpio api.

Regards,
Mike

> 
>  Tomi
> 
> 

[PATCH v3 2/5] drm/tilcdc: Add I2S HDMI audio config for tda998x

[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>
---
 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 3775fd4..5dd8d78 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

[PATCH v3 3/5] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus

[Jyri Sarha]

Add machine driver support for BeagleBone-Black HDMI audio. BBB has
NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The
44100 Hz sample-rate and it's multiples can not be accurately produced
on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.

Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
---
 .../bindings/sound/davinci-evm-audio.txt           |    6 +-
 sound/soc/davinci/davinci-evm.c                    |   82 +++++++++++++++++++-
 2 files changed, 84 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 963e100..7560146 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
+* TI SoC audio using McASP to connect to TLV320AIC3X or HDMI endcoder
 
 Required properties:
-- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx
+- compatible: should contain one of:
+    * "ti,da830-evm-audio" for DM365/DA8xx/OMAPL1x/AM33xx with TLV320AIC3X
+    * "ti,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 a50010e..3d0acba2a 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>
@@ -83,12 +84,46 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
 	return 0;
 }
 
+/* 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_tda998x_startup(struct snd_pcm_substream *substream)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	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);
+
+	return evm_startup(substream);
+}
+
+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_card *soc_card = rtd->card;
+	struct snd_soc_card_drvdata_davinci *drvdata =
+		snd_soc_card_get_drvdata(soc_card);
+
+	return snd_soc_dai_set_sysclk(cpu_dai, 0, drvdata->sysclk,
+				      SND_SOC_CLOCK_IN);
+}
+
 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),
@@ -149,6 +184,35 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
 	return 0;
 }
 
+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->card;
+	int ret;
+
+	ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 1);
+	if (ret < 0)
+		return ret;
+
+	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",
@@ -334,7 +398,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 = {
@@ -347,10 +411,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,beaglebone-black-audio",
+		.data = &evm_dai_tda998x_hdmi,
 	},
 	{ /* sentinel */ }
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 5/5] ARM: dts: am335x-boneblack: Add HDMI audio support

[Jyri Sarha]

Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio,
and sound nodes.

Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/am335x-boneblack.dts |   52 ++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 305975d..1487f7c 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -59,12 +59,35 @@
 			0x1b0 0x03      /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
 		>;
 	};
+
+	mcasp0_pins: mcasp0_pins {
+		pinctrl-single,pins = <
+			0x1ac (PIN_INPUT_PULLUP | MUX_MODE0)	/* mcasp0_ahclkx.mcasp0_ahclkx */
+			0x19c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2 */
+			0x194 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* mcasp0_fsx.mcasp0_fsx */
+			0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)	/* mcasp0_aclkx.mcasp0_aclkx */
+			0x06c (PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* gpmc_a11.GPIO1_27 */
+		>;
+	};
 };
 
 &lcdc {
 	status = "okay";
 };
 
+&mcasp0	{
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcasp0_pins>;
+	status = "okay";
+	op-mode = <0>;	/* MCASP_IIS_MODE */
+	tdm-slots = <2>;
+	serial-dir = <	/* 0: INACTIVE, 1: TX, 2: RX */
+			0 0 1 0
+		>;
+	tx-num-evt = <1>;
+	rx-num-evt = <1>;
+};
+
 / {
 	hdmi {
 		compatible = "ti,tilcdc,slave";
@@ -74,4 +97,33 @@
 		pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
 		status = "okay";
 	};
+
+	clk_mcasp0_fixed: clk_mcasp0_fixed {
+	      #clock-cells = <0>;
+	      compatible = "fixed-clock";
+	      clock-frequency = <24576000>;
+	};
+
+	clk_mcasp0: clk_mcasp0 {
+	      #clock-cells = <0>;
+	      compatible = "ti,gpio-gate-clock";
+	      clocks = <&clk_mcasp0_fixed>;
+	      enable-gpios = <&gpio1 27 0>; /* BeagleBone Black Clk enable on GPIO1_27 */
+	};
+
+	hdmi_audio: hdmi_audio@0 {
+	       compatible = "linux,hdmi-audio";
+	       status = "okay";
+	};
+
+	sound {
+		compatible = "ti,beaglebone-black-audio";
+		ti,model = "TI BeagleBone Black";
+		ti,audio-codec = <&hdmi_audio>;
+		ti,mcasp-controller = <&mcasp0>;
+		ti,audio-routing =
+			"HDMI Out",	"TX";
+		clocks = <&clk_mcasp0>;
+		clock-names = "mclk";
+	};
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/5] ARM: dts: am335x-boneblack: Add HDMI audio support

[Jyri Sarha]

This patch is invalid now that Mike Turquette took the generic 
clk-gpio-gate in. The other patches in the series are still Ok.

I'll mail a new dts patch shortly.

Best regards,
Jyri

On 09/16/2014 11:40 PM, Jyri Sarha wrote:
> Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio,
> and sound nodes.
>
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
>   arch/arm/boot/dts/am335x-boneblack.dts |   52 ++++++++++++++++++++++++++++++++
>   1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
> index 305975d..1487f7c 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -59,12 +59,35 @@
>   			0x1b0 0x03      /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
>   		>;
>   	};
> +
> +	mcasp0_pins: mcasp0_pins {
> +		pinctrl-single,pins = <
> +			0x1ac (PIN_INPUT_PULLUP | MUX_MODE0)	/* mcasp0_ahclkx.mcasp0_ahclkx */
> +			0x19c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2 */
> +			0x194 (PIN_OUTPUT_PULLUP | MUX_MODE0)	/* mcasp0_fsx.mcasp0_fsx */
> +			0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)	/* mcasp0_aclkx.mcasp0_aclkx */
> +			0x06c (PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* gpmc_a11.GPIO1_27 */
> +		>;
> +	};
>   };
>
>   &lcdc {
>   	status = "okay";
>   };
>
> +&mcasp0	{
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mcasp0_pins>;
> +	status = "okay";
> +	op-mode = <0>;	/* MCASP_IIS_MODE */
> +	tdm-slots = <2>;
> +	serial-dir = <	/* 0: INACTIVE, 1: TX, 2: RX */
> +			0 0 1 0
> +		>;
> +	tx-num-evt = <1>;
> +	rx-num-evt = <1>;
> +};
> +
>   / {
>   	hdmi {
>   		compatible = "ti,tilcdc,slave";
> @@ -74,4 +97,33 @@
>   		pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
>   		status = "okay";
>   	};
> +
> +	clk_mcasp0_fixed: clk_mcasp0_fixed {
> +	      #clock-cells = <0>;
> +	      compatible = "fixed-clock";
> +	      clock-frequency = <24576000>;
> +	};
> +
> +	clk_mcasp0: clk_mcasp0 {
> +	      #clock-cells = <0>;
> +	      compatible = "ti,gpio-gate-clock";
> +	      clocks = <&clk_mcasp0_fixed>;
> +	      enable-gpios = <&gpio1 27 0>; /* BeagleBone Black Clk enable on GPIO1_27 */
> +	};
> +
> +	hdmi_audio: hdmi_audio@0 {
> +	       compatible = "linux,hdmi-audio";
> +	       status = "okay";
> +	};
> +
> +	sound {
> +		compatible = "ti,beaglebone-black-audio";
> +		ti,model = "TI BeagleBone Black";
> +		ti,audio-codec = <&hdmi_audio>;
> +		ti,mcasp-controller = <&mcasp0>;
> +		ti,audio-routing =
> +			"HDMI Out",	"TX";
> +		clocks = <&clk_mcasp0>;
> +		clock-names = "mclk";
> +	};
>   };
>

[PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[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 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index d69510c..0c8f143 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -43,6 +43,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_EDMA_SOC && SOC_AM33XX && DRM_I2C_NXP_TDA998X
+	select SND_SOC_HDMI_CODEC
+	select SND_DAVINCI_SOC_MCASP
+	select SND_DAVINCI_SOC_GENERIC_EVM
+	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 && I2C
-- 
1.7.9.5

Re: [PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

On Tue, Sep 16, 2014 at 11:40:17PM +0300, Jyri Sarha wrote:
> 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.

So, Jean-Francois is also trying to do things with the TDA998x - what's
the story with that, is this joined up at all?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[Jyri Sarha]

On 09/17/2014 10:41 PM, Mark Brown wrote:
> On Tue, Sep 16, 2014 at 11:40:17PM +0300, Jyri Sarha wrote:
>> 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.
>
> So, Jean-Francois is also trying to do things with the TDA998x - what's
> the story with that, is this joined up at all?
>

Not really. This basic functionality does not touch tda998x at all on 
the fly, but just sets i2s configuation in the beginning and bangs the 
bits trough McASP. But as long as the old platform data for tda998x 
still works after Jean-Francois' patches I should be safe.

The problem with the Jean-Francois' patches is the DT support. The BBB 
HDMI video is implemented trough tilcdc-slave mechanism without a DT 
node for the tda encoder, which renders Jean-Francois' approach unusable 
for BBB.

The whole tilcdc slave approach may not be the most elegant way to use 
the tda driver, but it does not look like it is going to change any time 
soon.

Best regards,
Jyri

ps. I have been thinking on something similar to Jean-Francois' patch 
for SiI9022 which I have been working on lately. Also I have been 
wondering if it would be possible to come up with a generic ASoC codec 
component driver or library that could be used with any HDMI encoder to 
produce the ASoC codec component. Unfortunately I am in too early stage 
to produce anything more concrete.

Re: [PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[Jean-Francois Moine]

On Thu, 18 Sep 2014 00:13:09 +0300
Jyri Sarha <jsarha@ti.com> wrote:

> > So, Jean-Francois is also trying to do things with the TDA998x - what's
> > the story with that, is this joined up at all?
> 
> Not really. This basic functionality does not touch tda998x at all on 
> the fly, but just sets i2s configuation in the beginning and bangs the 
> bits trough McASP. But as long as the old platform data for tda998x 
> still works after Jean-Francois' patches I should be safe.

It should. And you may test it.

> The problem with the Jean-Francois' patches is the DT support. The BBB 
> HDMI video is implemented trough tilcdc-slave mechanism without a DT 
> node for the tda encoder, which renders Jean-Francois' approach unusable 
> for BBB.

I used the TDA998x with DT support for a long time with a hack by using
parts of drm_i2c_encoder_init(). Now, I think that this function could
be used as it is just setting no platform_data in info.

> The whole tilcdc slave approach may not be the most elegant way to use 
> the tda driver, but it does not look like it is going to change any time 
> soon.

Right: I proposed a patch for that and it was rejected.

> Best regards,
> Jyri
> 
> ps. I have been thinking on something similar to Jean-Francois' patch 
> for SiI9022 which I have been working on lately. Also I have been 
> wondering if it would be possible to come up with a generic ASoC codec 
> component driver or library that could be used with any HDMI encoder to 
> produce the ASoC codec component. Unfortunately I am in too early stage 
> to produce anything more concrete.

Here are some thoughts about this topic.

The video and audio worlds don't know about each other.
The only solution I found is to let the encoder create the codec as
a child device. Then, the codec knows from which encoder it depends.
This could have been done using Russell's components, but the codec
should have been declared in the DT. This is not useful.

The codec interacts with the encoder in 2 ways:
- it uses the HDMI parameters retrieved by the encoder,
- it gives the audio source type to the encoder.
I used exported functions for that, but, for a generic codec, theses
functions could be given through the codec platform_data.

The codec declares the DAI(s) prior to know the encoder. The DAI table
must be in the codec because of the snd_soc_dai_ops.
For a generic codec, this DAI table could be built dynamically from
information (name, id) also given through the codec platform_data.

-- 
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

Re: [PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[Jyri Sarha]

On 09/18/2014 11:25 AM, Jean-Francois Moine wrote:
 > On Thu, 18 Sep 2014 00:13:09 +0300
 > Jyri Sarha <jsarha@ti.com> wrote:
 >
 >>> So, Jean-Francois is also trying to do things with the TDA998x - what's
 >>> the story with that, is this joined up at all?
 >>
 >> Not really. This basic functionality does not touch tda998x at all on
 >> the fly, but just sets i2s configuation in the beginning and bangs the
 >> bits trough McASP. But as long as the old platform data for tda998x
 >> still works after Jean-Francois' patches I should be safe.
 >
 > It should. And you may test it.
 >

I tested by BBB HDMI audio patches with "[PATCH v5] ASoC: tda998x: Add
a codec to the HDMI transmitter", and it works otherwise, but the
default for CTS_N_K has changed from 3 to 2. I just needed to change the
supported format from S32_LE to S24_LE to compensate the change.

 >> The problem with the Jean-Francois' patches is the DT support. The BBB
 >> HDMI video is implemented trough tilcdc-slave mechanism without a DT
 >> node for the tda encoder, which renders Jean-Francois' approach unusable
 >> for BBB.
 >
 > I used the TDA998x with DT support for a long time with a hack by using
 > parts of drm_i2c_encoder_init(). Now, I think that this function could
 > be used as it is just setting no platform_data in info.
 >
 >> The whole tilcdc slave approach may not be the most elegant way to use
 >> the tda driver, but it does not look like it is going to change any time
 >> soon.
 >
 > Right: I proposed a patch for that and it was rejected.
 >

The tilcdc is not actively maintained by anybody ATM and that is why
it is so hard to make any bigger changes to it. I hope we can change
this at some point, but for now I am just trying to get a simple HDMI
audio working on BBB with minimal changes.

 >> Best regards,
 >> Jyri
 >>
 >> ps. I have been thinking on something similar to Jean-Francois' patch
 >> for SiI9022 which I have been working on lately. Also I have been
 >> wondering if it would be possible to come up with a generic ASoC codec
 >> component driver or library that could be used with any HDMI encoder to
 >> produce the ASoC codec component. Unfortunately I am in too early stage
 >> to produce anything more concrete.
 >
 > Here are some thoughts about this topic.
 >
 > The video and audio worlds don't know about each other.
 > The only solution I found is to let the encoder create the codec as
 > a child device. Then, the codec knows from which encoder it depends.
 > This could have been done using Russell's components, but the codec
 > should have been declared in the DT. This is not useful.
 >

There is anothere option of putting the ASoC codec code into an ASoC
library module and registering the ASoC codec component under the HDMI
encoder device. However, this approach does not allow building the
ASoC as modules if the HDMI encoder driver is built in. So a separate
platform device for the codec component is probably better.

 > The codec interacts with the encoder in 2 ways:
 > - it uses the HDMI parameters retrieved by the encoder,
 > - it gives the audio source type to the encoder.
 > I used exported functions for that, but, for a generic codec, theses
 > functions could be given through the codec platform_data.
 >
 > The codec declares the DAI(s) prior to know the encoder. The DAI table
 > must be in the codec because of the snd_soc_dai_ops.
 > For a generic codec, this DAI table could be built dynamically from
 > information (name, id) also given through the codec platform_data.
 >

This is pretty much what I have been thinking too. The API between the
generic ASoC HDMI codec could use already existing the linux headers
derived HDMI standard. The ASoC side code should build the hdmi audio
infoframe and configure the stream header bits etc, so basically do
all the generic stuff coming from HDMI standard. Writing the bits
to the appropriate registers in the encoder chip would be left to the
HDMI encoder driver.

Best regards,
Jyri

Re: [alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Dave Airlie]

On 17 September 2014 06:40, Jyri Sarha <jsarha@ti.com> wrote:
> Changes since v2:
> - Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock"
> - Some minor cleanups
>
> The code has a functional dependency to:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html
>
> Without the above patch the audio card does not probe.
>
> The code has been rebased on top of Linux 3.17-rc5. The patches
> bellow, the above dependency, and couple of commits to add BBB HDMI audio
> support to omap2plus_defconfig can be pulled from:
>
> https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio

How do you intend to get this merge, sending patchsets like this without
indication to maintainers on a merge strategy is kinda messy.

I'm not sure how maintained tilcdc is.

Dave.
>
> Cheers,
> Jyri
>
> Jyri Sarha (5):
>   clk: ti: add "ti,gpio-gate-clock" controlled clock
>   drm/tilcdc: Add I2S HDMI audio config for tda998x
>   ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S
>     bus
>   ASoC: davinci: HDMI audio build for AM33XX and TDA998x
>   ARM: dts: am335x-boneblack: Add HDMI audio support
>
>  .../bindings/clock/ti/gpio-gate-clock.txt          |   21 ++
>  .../bindings/sound/davinci-evm-audio.txt           |    6 +-
>  arch/arm/boot/dts/am335x-boneblack.dts             |   52 +++++
>  drivers/clk/ti/Makefile                            |    2 +-
>  drivers/clk/ti/gpio.c                              |  202 ++++++++++++++++++++
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c              |   24 ++-
>  sound/soc/davinci/Kconfig                          |   12 ++
>  sound/soc/davinci/davinci-evm.c                    |   82 +++++++-
>  8 files changed, 395 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
>  create mode 100644 drivers/clk/ti/gpio.c
>
> --
> 1.7.9.5
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Jyri Sarha]

On 09/17/2014 04:06 AM, Dave Airlie wrote:
> On 17 September 2014 06:40, Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org> wrote:
>> Changes since v2:
>> - Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock"
>> - Some minor cleanups
>>
>> The code has a functional dependency to:
>> http://www.mail-archive.com/linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg109264.html
>>
>> Without the above patch the audio card does not probe.
>>
>> The code has been rebased on top of Linux 3.17-rc5. The patches
>> bellow, the above dependency, and couple of commits to add BBB HDMI audio
>> support to omap2plus_defconfig can be pulled from:
>>
>> https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio
>
> How do you intend to get this merge, sending patchsets like this without
> indication to maintainers on a merge strategy is kinda messy.
>
> I'm not sure how maintained tilcdc is.
>

Well, it is used but AFAIK the people who have been working with it the 
most have left TI. I think eventually someone at TI needs to take it 
over, but I do not know anything about that.

I was hoping that because the change to tilcdc is quite minimal it could 
go in via you. I am sure I could get a reviewed-by and tested-by from 
from Darren how has bit more experience with tilcdc and maybe from Tomi 
too if that helps. (Adding Tomi to cc).

The "drm/tilcdc: Add I2S HDMI audio config for tda998x"-patch itself 
just adds the audio configuration to pda998x pdata and fills the swap, 
and mirr parameters with default values (they are usually coming in hard 
coded at the beginning of tda998x_create()).

Best regards,
Jyri
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 2349 bytes --]

On 17/09/14 10:51, Jyri Sarha wrote:
> On 09/17/2014 04:06 AM, Dave Airlie wrote:
>> On 17 September 2014 06:40, Jyri Sarha <jsarha@ti.com> wrote:
>>> Changes since v2:
>>> - Change compatible property from "ti,gpio-clock" to
>>> "ti,gpio-gate-clock"
>>> - Some minor cleanups
>>>
>>> The code has a functional dependency to:
>>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html
>>>
>>> Without the above patch the audio card does not probe.
>>>
>>> The code has been rebased on top of Linux 3.17-rc5. The patches
>>> bellow, the above dependency, and couple of commits to add BBB HDMI
>>> audio
>>> support to omap2plus_defconfig can be pulled from:
>>>
>>> https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio
>>
>> How do you intend to get this merge, sending patchsets like this without
>> indication to maintainers on a merge strategy is kinda messy.
>>
>> I'm not sure how maintained tilcdc is.
>>
> 
> Well, it is used but AFAIK the people who have been working with it the
> most have left TI. I think eventually someone at TI needs to take it
> over, but I do not know anything about that.
> 
> I was hoping that because the change to tilcdc is quite minimal it could
> go in via you. I am sure I could get a reviewed-by and tested-by from
> from Darren how has bit more experience with tilcdc and maybe from Tomi
> too if that helps. (Adding Tomi to cc).
> 
> The "drm/tilcdc: Add I2S HDMI audio config for tda998x"-patch itself
> just adds the audio configuration to pda998x pdata and fills the swap,
> and mirr parameters with default values (they are usually coming in hard
> coded at the beginning of tda998x_create()).

I think Dave's point was that the series touches three different
subsystems, and you didn't give any thoughts about how this could be merged.

Must this be merged in one piece, because xxx depends on yyy etc? Can
these all be merged separately, via respective trees? If in one piece,
you could ask acks from Mr x and Mr y, for the parts they maintain. Etc.
And of course, it'd be good to include all the maintainers (At least
Mike was missing).

I think the clock patch could be handled totally separate, as it's in no
way related to HDMI. The video and audio part may be handled together,
if they have dependencies.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Jyri Sarha]

On 09/19/2014 04:24 PM, Tomi Valkeinen wrote:
> On 17/09/14 10:51, Jyri Sarha wrote:
>> On 09/17/2014 04:06 AM, Dave Airlie wrote:
>>> On 17 September 2014 06:40, Jyri Sarha <jsarha@ti.com> wrote:
>>>> Changes since v2:
>>>> - Change compatible property from "ti,gpio-clock" to
>>>> "ti,gpio-gate-clock"
>>>> - Some minor cleanups
>>>>
>>>> The code has a functional dependency to:
>>>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html
>>>>
>>>> Without the above patch the audio card does not probe.
>>>>
>>>> The code has been rebased on top of Linux 3.17-rc5. The patches
>>>> bellow, the above dependency, and couple of commits to add BBB HDMI
>>>> audio
>>>> support to omap2plus_defconfig can be pulled from:
>>>>
>>>> https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio
>>>
>>> How do you intend to get this merge, sending patchsets like this without
>>> indication to maintainers on a merge strategy is kinda messy.
>>>
>>> I'm not sure how maintained tilcdc is.
>>>
>>
>> Well, it is used but AFAIK the people who have been working with it the
>> most have left TI. I think eventually someone at TI needs to take it
>> over, but I do not know anything about that.
>>
>> I was hoping that because the change to tilcdc is quite minimal it could
>> go in via you. I am sure I could get a reviewed-by and tested-by from
>> from Darren how has bit more experience with tilcdc and maybe from Tomi
>> too if that helps. (Adding Tomi to cc).
>>
>> The "drm/tilcdc: Add I2S HDMI audio config for tda998x"-patch itself
>> just adds the audio configuration to pda998x pdata and fills the swap,
>> and mirr parameters with default values (they are usually coming in hard
>> coded at the beginning of tda998x_create()).
>
> I think Dave's point was that the series touches three different
> subsystems, and you didn't give any thoughts about how this could be merged.
>
> Must this be merged in one piece, because xxx depends on yyy etc? Can
> these all be merged separately, via respective trees? If in one piece,
> you could ask acks from Mr x and Mr y, for the parts they maintain. Etc.
> And of course, it'd be good to include all the maintainers (At least
> Mike was missing).
>
> I think the clock patch could be handled totally separate, as it's in no
> way related to HDMI. The video and audio part may be handled together,
> if they have dependencies.
>

There should be no build time breakage no matter what is the merging 
order. The BBB HDMI audio functionality simply does not work before all 
the pieces are in.

1. The audio device does not probe if the ti,gpio-gate-clock is misssing.
2. The audio device probes, but there is no sound coming out if the 
tilcdc_slave change is missing.
3. Without ASoC or DTS changes there is no audio device.

Best regards,
Jyri