Linux Framebuffer Layer development
 help / color / mirror / Atom feed
* Re: [PATCH 09/13] video/backlight: LP8788 needs PWM
From: Bryan Wu @ 2014-04-24 16:45 UTC (permalink / raw)
  To: Peter Griffin
  Cc: lkml, linaro-kernel, Arnd Bergmann, Milo Kim, Jingoo Han,
	Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
	FBDEV list
In-Reply-To: <1398342509-10243-10-git-send-email-peter.griffin@linaro.org>

On Thu, Apr 24, 2014 at 5:28 AM, Peter Griffin <peter.griffin@linaro.org> wrote:
> The LP8788 driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
>
> Based on Arnd Bergmann patch but split out into seperate
> commits per driver based on feedback.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Milo Kim <milo.kim@ti.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
>  drivers/video/backlight/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 4791af7..ac6bc28 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -393,7 +393,7 @@ config BACKLIGHT_LP855X
>
>  config BACKLIGHT_LP8788
>         tristate "Backlight driver for TI LP8788 MFD"
> -       depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788
> +       depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788 && PWM

Looks good to me,
Acked-by: Bryan Wu <cooloney@gmail.com>

>         help
>           This supports TI LP8788 backlight driver.
>
> --
> 1.7.9.5
>

^ permalink raw reply

* Re: [PATCH 10/13] video/pxa: LCD_CORGI needs BACKLIGHT_CLASS_DEVICE
From: Bryan Wu @ 2014-04-24 16:46 UTC (permalink / raw)
  To: Peter Griffin
  Cc: lkml, linaro-kernel, Arnd Bergmann, Jingoo Han, Lee Jones,
	Jean-Christophe Plagniol-Villard, Tomi Valkeinen, FBDEV list
In-Reply-To: <1398342509-10243-11-git-send-email-peter.griffin@linaro.org>

On Thu, Apr 24, 2014 at 5:28 AM, Peter Griffin <peter.griffin@linaro.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This fixes a randconfig build error when BACKLIGHT_CLASS_DEVICE
> is disabled, by describing the dependency in Kconfig,
> as we do for the other drivers in this directory.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
>  drivers/video/backlight/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index ac6bc28..5675511 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -29,7 +29,7 @@ if LCD_CLASS_DEVICE
>
>  config LCD_CORGI
>         tristate "LCD Panel support for SHARP corgi/spitz model"
> -       depends on SPI_MASTER && PXA_SHARPSL
> +       depends on SPI_MASTER && PXA_SHARPSL && BACKLIGHT_CLASS_DEVICE

Looks good to me,
Acked-by: Bryan Wu <cooloney@gmail.com>

>         help
>           Say y here to support the LCD panels usually found on SHARP
>           corgi (C7x0) and spitz (Cxx00) models.
> --
> 1.7.9.5
>

^ permalink raw reply

* Re: [PATCH 12/13] video/backlight: LP855X needs PWM
From: Bryan Wu @ 2014-04-24 16:48 UTC (permalink / raw)
  To: Peter Griffin
  Cc: lkml, linaro-kernel, Arnd Bergmann, Jingoo Han, Milo Kim,
	Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
	FBDEV list
In-Reply-To: <1398342509-10243-13-git-send-email-peter.griffin@linaro.org>

On Thu, Apr 24, 2014 at 5:28 AM, Peter Griffin <peter.griffin@linaro.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The LP855X driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Milo Kim <milo.kim@ti.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
>  drivers/video/backlight/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 5675511..5d44905 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -386,7 +386,7 @@ config BACKLIGHT_LM3639
>
>  config BACKLIGHT_LP855X
>         tristate "Backlight driver for TI LP855X"
> -       depends on BACKLIGHT_CLASS_DEVICE && I2C
> +       depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM

Looks good to me,
Acked-by: Bryan Wu <cooloney@gmail.com>

>         help
>           This supports TI LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
>           LP8557 backlight driver.
> --
> 1.7.9.5
>

^ permalink raw reply

* Re: [PATCH 11/23] ARM: dts: omap5-uevm.dts: add tca6424a
From: Sergei Shtylyov @ 2014-04-24 16:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5359209F.7000308@ti.com>

Hello.

On 04/24/2014 06:33 PM, Tomi Valkeinen wrote:

>>> omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.

>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> ---
>>>    arch/arm/boot/dts/omap5-uevm.dts | 7 +++++++
>>>    1 file changed, 7 insertions(+)

>>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts
>>> b/arch/arm/boot/dts/omap5-uevm.dts
>>> index 3b99ec25b748..9e7581eaeb23 100644
>>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>>> @@ -434,6 +434,13 @@
>>>        pinctrl-0 = <&i2c5_pins>;
>>>
>>>        clock-frequency = <400000>;
>>> +
>>> +    tca6424a: tca6424a@22 {

>>     The ePAPR standard [1] says: "The name of a node should be somewhat
>> generic,
>> reflecting the function of the device and not its precise programming
>> model.
>> If appropriate, the name should be one of the following choices:
>> [...]
>>     - gpio;"

> Right. I wonder what the name should be... "gpio" is out, as the name
> should be more specific.

    No, it's not out. The name should be "gpio@22", I think it would be unique.

> We already have gpio1-8, which are the gpio
> banks from the SoC.

    I don't understand why you are indexing the names while you probably have 
the address part after @ that makes them unique already.

>   Tomi

WBR, Sergei


^ permalink raw reply

* Re: [PATCH 09/13] video/backlight: LP8788 needs PWM
From: Milo Kim @ 2014-04-24 22:42 UTC (permalink / raw)
  To: Peter Griffin
  Cc: linux-kernel, linaro-kernel, Arnd Bergmann, Jingoo Han, Bryan Wu,
	Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
	linux-fbdev
In-Reply-To: <1398342509-10243-10-git-send-email-peter.griffin@linaro.org>

On 04/24/2014 09:28 PM, Peter Griffin wrote:
> The LP8788 driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
>
> Based on Arnd Bergmann patch but split out into seperate
> commits per driver based on feedback.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>

Thanks!

Acked-by: Milo Kim <milo.kim@ti.com>



^ permalink raw reply

* Re: [PATCH 12/13] video/backlight: LP855X needs PWM
From: Milo Kim @ 2014-04-24 22:43 UTC (permalink / raw)
  To: Peter Griffin
  Cc: linux-kernel, linaro-kernel, Arnd Bergmann, Jingoo Han, Bryan Wu,
	Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
	linux-fbdev
In-Reply-To: <1398342509-10243-13-git-send-email-peter.griffin@linaro.org>

On 04/24/2014 09:28 PM, Peter Griffin wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The LP855X driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
>

Thanks!

Acked-by: Milo Kim <milo.kim@ti.com>



^ permalink raw reply

* Re: [PATCH 09/13] video/backlight: LP8788 needs PWM
From: Jingoo Han @ 2014-04-25  8:54 UTC (permalink / raw)
  To: 'Peter Griffin', linux-kernel
  Cc: linaro-kernel, 'Arnd Bergmann', 'Milo Kim',
	'Bryan Wu', 'Lee Jones',
	'Jean-Christophe Plagniol-Villard',
	'Tomi Valkeinen', linux-fbdev, 'Jingoo Han'
In-Reply-To: <1398342509-10243-10-git-send-email-peter.griffin@linaro.org>

On Thursday, April 24, 2014 9:28 PM, Peter Griffin wrote:
> 
> The LP8788 driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
> 
> Based on Arnd Bergmann patch but split out into seperate
> commits per driver based on feedback.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Milo Kim <milo.kim@ti.com>
> Cc: Jingoo Han <jg1.han@samsung.com>

Acked-by: Jingoo Han <jg1.han@samsung.com>

Best regards,
Jingoo Han

> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
>  drivers/video/backlight/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 4791af7..ac6bc28 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -393,7 +393,7 @@ config BACKLIGHT_LP855X
> 
>  config BACKLIGHT_LP8788
>  	tristate "Backlight driver for TI LP8788 MFD"
> -	depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788
> +	depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788 && PWM
>  	help
>  	  This supports TI LP8788 backlight driver.
> 
> --
> 1.7.9.5


^ permalink raw reply

* Re: [PATCH 10/13] video/pxa: LCD_CORGI needs BACKLIGHT_CLASS_DEVICE
From: Jingoo Han @ 2014-04-25  8:58 UTC (permalink / raw)
  To: 'Peter Griffin', linux-kernel
  Cc: linaro-kernel, 'Arnd Bergmann', 'Bryan Wu',
	'Lee Jones', 'Jean-Christophe Plagniol-Villard',
	'Tomi Valkeinen', linux-fbdev, 'Jingoo Han'
In-Reply-To: <1398342509-10243-11-git-send-email-peter.griffin@linaro.org>

On Thursday, April 24, 2014 9:28 PM, Peter Griffin wrote:
> 
> From: Arnd Bergmann <arnd@arndb.de>
> 
> This fixes a randconfig build error when BACKLIGHT_CLASS_DEVICE
> is disabled, by describing the dependency in Kconfig,
> as we do for the other drivers in this directory.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Jingoo Han <jg1.han@samsung.com>

Acked-by: Jingoo Han <jg1.han@samsung.com>

Best regards,
Jingoo Han

> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
>  drivers/video/backlight/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index ac6bc28..5675511 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -29,7 +29,7 @@ if LCD_CLASS_DEVICE
> 
>  config LCD_CORGI
>  	tristate "LCD Panel support for SHARP corgi/spitz model"
> -	depends on SPI_MASTER && PXA_SHARPSL
> +	depends on SPI_MASTER && PXA_SHARPSL && BACKLIGHT_CLASS_DEVICE
>  	help
>  	  Say y here to support the LCD panels usually found on SHARP
>  	  corgi (C7x0) and spitz (Cxx00) models.
> --
> 1.7.9.5


^ permalink raw reply

* Re: [PATCH 08/13] video/backlight: LM3630A needs PWM
From: Jingoo Han @ 2014-04-25  9:00 UTC (permalink / raw)
  To: 'Peter Griffin', linux-kernel
  Cc: linaro-kernel, 'Arnd Bergmann', 'Bryan Wu',
	'Lee Jones', 'Jean-Christophe Plagniol-Villard',
	'Tomi Valkeinen', linux-fbdev, 'Jingoo Han'
In-Reply-To: <1398342509-10243-9-git-send-email-peter.griffin@linaro.org>

On Thursday, April 24, 2014 9:28 PM, Peter Griffin wrote:
> 
> The LM3630A driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
> 
> Based on Arnd Bergmann patch but split out into seperate
> commits per driver based on feedback.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Jingoo Han <jg1.han@samsung.com>

Acked-by: Jingoo Han <jg1.han@samsung.com>

Best regards,
Jingoo Han

> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
>  drivers/video/backlight/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 5a3eb2e..4791af7 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -370,7 +370,7 @@ config BACKLIGHT_AAT2870
> 
>  config BACKLIGHT_LM3630A
>  	tristate "Backlight Driver for LM3630A"
> -	depends on BACKLIGHT_CLASS_DEVICE && I2C
> +	depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM
>  	select REGMAP_I2C
>  	help
>  	  This supports TI LM3630A Backlight Driver
> --
> 1.7.9.5


^ permalink raw reply

* Re: [PATCH 12/13] video/backlight: LP855X needs PWM
From: Jingoo Han @ 2014-04-25  9:02 UTC (permalink / raw)
  To: 'Peter Griffin', linux-kernel
  Cc: linaro-kernel, 'Arnd Bergmann', 'Milo Kim',
	'Bryan Wu', 'Lee Jones',
	'Jean-Christophe Plagniol-Villard',
	'Tomi Valkeinen', linux-fbdev, 'Jingoo Han'
In-Reply-To: <1398342509-10243-13-git-send-email-peter.griffin@linaro.org>

On Thursday, April 24, 2014 9:28 PM, Peter Griffin wrote:
> 
> From: Arnd Bergmann <arnd@arndb.de>
> 
> The LP855X driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Jingoo Han <jg1.han@samsung.com>

Acked-by: Jingoo Han <jg1.han@samsung.com>

Best regards,
Jingoo Han

> Cc: Milo Kim <milo.kim@ti.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
>  drivers/video/backlight/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 5675511..5d44905 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -386,7 +386,7 @@ config BACKLIGHT_LM3639
> 
>  config BACKLIGHT_LP855X
>  	tristate "Backlight driver for TI LP855X"
> -	depends on BACKLIGHT_CLASS_DEVICE && I2C
> +	depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM
>  	help
>  	  This supports TI LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
>  	  LP8557 backlight driver.
> --
> 1.7.9.5


^ permalink raw reply

* Re: [PATCH 01/23] OMAPDSS: HDMI: lane config support
From: Archit Taneja @ 2014-04-25 10:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1398334639-14172-2-git-send-email-tomi.valkeinen@ti.com>

Hi,

On Thursday 24 April 2014 03:46 PM, Tomi Valkeinen wrote:
> Add support to configure the pins used for the HDMI lanes. The order and
> polarity of the lanes can be defined in the DT data.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---

> +static void hdmi_phy_configure_lanes(struct hdmi_phy_data *phy)
> +{
> +	static const u16 pad_cfg_list[] = {
> +		0x0123,
> +		0x0132,
> +		0x0312,
> +		0x0321,
> +		0x0231,
> +		0x0213,
> +		0x1023,
> +		0x1032,
> +		0x3012,
> +		0x3021,
> +		0x2031,
> +		0x2013,
> +		0x1203,
> +		0x1302,
> +		0x3102,
> +		0x3201,
> +		0x2301,
> +		0x2103,
> +		0x1230,
> +		0x1320,
> +		0x3120,
> +		0x3210,
> +		0x2310,
> +		0x2130,
> +	};
> +
> +	u16 lane_cfg = 0;
> +	int i;
> +	unsigned lane_cfg_val;
> +	u16 pol_val = 0;
> +
> +	for (i = 0; i < 4; ++i)
> +		lane_cfg |= phy->lane_function[i] << ((3 - i) * 4);
> +
> +	pol_val |= phy->lane_polarity[0] << 0;
> +	pol_val |= phy->lane_polarity[1] << 3;
> +	pol_val |= phy->lane_polarity[2] << 2;
> +	pol_val |= phy->lane_polarity[3] << 1;
> +
> +	for (i = 0; i < ARRAY_SIZE(pad_cfg_list); ++i)
> +		if (pad_cfg_list[i] = lane_cfg)
> +			break;
> +
> +	if (WARN_ON(i = ARRAY_SIZE(pad_cfg_list)))
> +		i = 0;
> +
> +	lane_cfg_val = i;

I spent some time to see if we could get create lane_cfg_val without 
having the table above, looks like there is no pattern at all in the 
register field.

> +
> +	REG_FLD_MOD(phy->base, HDMI_TXPHY_PAD_CFG_CTRL, lane_cfg_val, 26, 22);
> +	REG_FLD_MOD(phy->base, HDMI_TXPHY_PAD_CFG_CTRL, pol_val, 30, 27);
> +}
> +
>   int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp,
>   			struct hdmi_config *cfg)
>   {
> @@ -92,8 +183,7 @@ int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp,
>   	/* Setup max LDO voltage */
>   	REG_FLD_MOD(phy->base, HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
>
> -	/* Write to phy address 3 to change the polarity control */
> -	REG_FLD_MOD(phy->base, HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);

wow, didn't realize it was hardcoded like this.

Reviewed-by: Archit Taneja <archit@ti.com?

Archit


^ permalink raw reply

* Re: [PATCH 01/23] OMAPDSS: HDMI: lane config support
From: Tomi Valkeinen @ 2014-04-25 10:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <535A3395.4050106@ti.com>

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

On 25/04/14 13:06, Archit Taneja wrote:

> I spent some time to see if we could get create lane_cfg_val without
> having the table above, looks like there is no pattern at all in the
> register field.

There is a pattern, but I wasn't able to figure out a formula to model
it. And as the array was not very long, and was easy to create with copy
paste and search-replace from the TRM, I thought it's just simplest way
to do it.

>> +
>> +    REG_FLD_MOD(phy->base, HDMI_TXPHY_PAD_CFG_CTRL, lane_cfg_val, 26,
>> 22);
>> +    REG_FLD_MOD(phy->base, HDMI_TXPHY_PAD_CFG_CTRL, pol_val, 30, 27);
>> +}
>> +
>>   int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp,
>>               struct hdmi_config *cfg)
>>   {
>> @@ -92,8 +183,7 @@ int hdmi_phy_enable(struct hdmi_phy_data *phy,
>> struct hdmi_wp_data *wp,
>>       /* Setup max LDO voltage */
>>       REG_FLD_MOD(phy->base, HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
>>
>> -    /* Write to phy address 3 to change the polarity control */
>> -    REG_FLD_MOD(phy->base, HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);
> 
> wow, didn't realize it was hardcoded like this.
> 
> Reviewed-by: Archit Taneja <archit@ti.com?

Thanks!

 Tomi



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

^ permalink raw reply

* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-25 11:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <535A42D6.5090107@ti.com>

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

On 25/04/14 14:11, Archit Taneja wrote:
> Hi,
> 
> On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote:
>> Add support to set OMAP5 DSI pin muxing.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> ---
>>   arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++-
>>   1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/display.c
>> b/arch/arm/mach-omap2/display.c
>> index 16d33d831287..974461441fc3 100644
>> --- a/arch/arm/mach-omap2/display.c
>> +++ b/arch/arm/mach-omap2/display.c
>> @@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id,
>> unsigned lanes)
>>       return 0;
>>   }
>>
>> +#define CONTROL_PAD_BASE    0x4A002800
>> +#define CONTROL_DSIPHY        0x614
>> +
> 
> I guess this is something we can move to our driver, and use sysconf to
> get the register from DT.

I just copied the same method as used for OMAP4.

I guess sysconf is an option. But I really dislike the idea of moving
omap control module code to a display driver... I'm not sure what other
options we have, though. Maybe an OMAP DSI specific pinctrl driver?

 Tomi



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

^ permalink raw reply

* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Archit Taneja @ 2014-04-25 11:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1398334639-14172-7-git-send-email-tomi.valkeinen@ti.com>

Hi,

On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote:
> Add support to set OMAP5 DSI pin muxing.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
>   arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++-
>   1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 16d33d831287..974461441fc3 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
>   	return 0;
>   }
>
> +#define CONTROL_PAD_BASE	0x4A002800
> +#define CONTROL_DSIPHY		0x614
> +

I guess this is something we can move to our driver, and use sysconf to 
get the register from DT.

Archit


^ permalink raw reply

* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Archit Taneja @ 2014-04-25 13:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <535A4470.2000509@ti.com>

On Friday 25 April 2014 04:48 PM, Tomi Valkeinen wrote:
> On 25/04/14 14:11, Archit Taneja wrote:
>> Hi,
>>
>> On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote:
>>> Add support to set OMAP5 DSI pin muxing.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> ---
>>>    arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++-
>>>    1 file changed, 34 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/display.c
>>> b/arch/arm/mach-omap2/display.c
>>> index 16d33d831287..974461441fc3 100644
>>> --- a/arch/arm/mach-omap2/display.c
>>> +++ b/arch/arm/mach-omap2/display.c
>>> @@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id,
>>> unsigned lanes)
>>>        return 0;
>>>    }
>>>
>>> +#define CONTROL_PAD_BASE    0x4A002800
>>> +#define CONTROL_DSIPHY        0x614
>>> +
>>
>> I guess this is something we can move to our driver, and use sysconf to
>> get the register from DT.
>
> I just copied the same method as used for OMAP4.
>
> I guess sysconf is an option. But I really dislike the idea of moving
> omap control module code to a display driver... I'm not sure what other
> options we have, though. Maybe an OMAP DSI specific pinctrl driver?

OMAP4 has CONTROL_DSIPHY for configuring both lane enable/disbale, and 
pull up/down, but OMAP5 has normal PAD_CONF registers for DSI lines(2 
pins per register) for configuring pull up/down, and CONTROL_DSIPHY for 
lane enable/disable.

We would have a very messed up pinctrl driver, but it would probably be 
better than doing all this stuff in the driver.

Archit


^ permalink raw reply

* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-25 14:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <535A5C0A.7040808@ti.com>

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

On 25/04/14 15:58, Archit Taneja wrote:
> On Friday 25 April 2014 04:48 PM, Tomi Valkeinen wrote:
>> On 25/04/14 14:11, Archit Taneja wrote:
>>> Hi,
>>>
>>> On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote:
>>>> Add support to set OMAP5 DSI pin muxing.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> ---
>>>>    arch/arm/mach-omap2/display.c | 35
>>>> ++++++++++++++++++++++++++++++++++-
>>>>    1 file changed, 34 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/display.c
>>>> b/arch/arm/mach-omap2/display.c
>>>> index 16d33d831287..974461441fc3 100644
>>>> --- a/arch/arm/mach-omap2/display.c
>>>> +++ b/arch/arm/mach-omap2/display.c
>>>> @@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id,
>>>> unsigned lanes)
>>>>        return 0;
>>>>    }
>>>>
>>>> +#define CONTROL_PAD_BASE    0x4A002800
>>>> +#define CONTROL_DSIPHY        0x614
>>>> +
>>>
>>> I guess this is something we can move to our driver, and use sysconf to
>>> get the register from DT.
>>
>> I just copied the same method as used for OMAP4.
>>
>> I guess sysconf is an option. But I really dislike the idea of moving
>> omap control module code to a display driver... I'm not sure what other
>> options we have, though. Maybe an OMAP DSI specific pinctrl driver?
> 
> OMAP4 has CONTROL_DSIPHY for configuring both lane enable/disbale, and
> pull up/down, but OMAP5 has normal PAD_CONF registers for DSI lines(2
> pins per register) for configuring pull up/down, and CONTROL_DSIPHY for
> lane enable/disable.
> 
> We would have a very messed up pinctrl driver, but it would probably be
> better than doing all this stuff in the driver.

Actually, this patch is not good. I should've looked at the code more
carefully =).

This one does ioremap every time the function is called, which could be
done multiple times.

And I think omap4_ctrl_pad_readl() can be used to access the registers.
Like this (not tested):

#define OMAP5_CONTROL_DSIPHY		0x614

static int omap5_dsi_mux_pads(int dsi_id, unsigned lanes)
{
	u32 enable_mask, enable_shift, reg;

	if (dsi_id == 0) {
		enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
		enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
	} else if (dsi_id == 1) {
		enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
		enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
	} else {
		return -ENODEV;
	}

	reg = omap4_ctrl_pad_readl(OMAP5_CONTROL_DSIPHY);
	reg &= ~enable_mask;
	reg |= (lanes << enable_shift) & enable_mask;
	omap4_ctrl_pad_writel(reg, OMAP5_CONTROL_DSIPHY);

	return 0;
}

 Tomi



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

^ permalink raw reply

* Re: [PATCH 11/23] ARM: dts: omap5-uevm.dts: add tca6424a
From: Tomi Valkeinen @ 2014-04-25 14:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <53594189.1090508@cogentembedded.com>

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

On 24/04/14 19:53, Sergei Shtylyov wrote:

>> Right. I wonder what the name should be... "gpio" is out, as the name
>> should be more specific.
> 
>    No, it's not out. The name should be "gpio@22", I think it would be
> unique.
> 
>> We already have gpio1-8, which are the gpio
>> banks from the SoC.
> 
>    I don't understand why you are indexing the names while you probably
> have the address part after @ that makes them unique already.

Ah sorry for the confusion, I misunderstood. I was talking about the
label, not the name, of the node.

So the labels for the gpio banks are 'gpio2' etc. The names are
'gpio@123456' etc. And yes, here the name should be 'gpio@22' as you said.

I didn't see any rules about the labels in the ePARP doc, so I guess
'tca6424a' would be a valid one. Maybe not a good one, though,
especially if there are multiple tca6424a chips on the board (I need to
check).

 Tomi



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

^ permalink raw reply

* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tony Lindgren @ 2014-04-25 15:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <535A6C40.10609@ti.com>

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140425 07:08]:
> On 25/04/14 15:58, Archit Taneja wrote:
> > On Friday 25 April 2014 04:48 PM, Tomi Valkeinen wrote:
> >> On 25/04/14 14:11, Archit Taneja wrote:
> >>> Hi,
> >>>
> >>> On Thursday 24 April 2014 03:47 PM, Tomi Valkeinen wrote:
> >>>> Add support to set OMAP5 DSI pin muxing.
> >>>>
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >>>> Cc: Tony Lindgren <tony@atomide.com>
> >>>> ---
> >>>>    arch/arm/mach-omap2/display.c | 35
> >>>> ++++++++++++++++++++++++++++++++++-
> >>>>    1 file changed, 34 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm/mach-omap2/display.c
> >>>> b/arch/arm/mach-omap2/display.c
> >>>> index 16d33d831287..974461441fc3 100644
> >>>> --- a/arch/arm/mach-omap2/display.c
> >>>> +++ b/arch/arm/mach-omap2/display.c
> >>>> @@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id,
> >>>> unsigned lanes)
> >>>>        return 0;
> >>>>    }
> >>>>
> >>>> +#define CONTROL_PAD_BASE    0x4A002800
> >>>> +#define CONTROL_DSIPHY        0x614
> >>>> +
> >>>
> >>> I guess this is something we can move to our driver, and use sysconf to
> >>> get the register from DT.
> >>
> >> I just copied the same method as used for OMAP4.
> >>
> >> I guess sysconf is an option. But I really dislike the idea of moving
> >> omap control module code to a display driver... I'm not sure what other
> >> options we have, though. Maybe an OMAP DSI specific pinctrl driver?
> > 
> > OMAP4 has CONTROL_DSIPHY for configuring both lane enable/disbale, and
> > pull up/down, but OMAP5 has normal PAD_CONF registers for DSI lines(2
> > pins per register) for configuring pull up/down, and CONTROL_DSIPHY for
> > lane enable/disable.
> > 
> > We would have a very messed up pinctrl driver, but it would probably be
> > better than doing all this stuff in the driver.
> 
> Actually, this patch is not good. I should've looked at the code more
> carefully =).
> 
> This one does ioremap every time the function is called, which could be
> done multiple times.
> 
> And I think omap4_ctrl_pad_readl() can be used to access the registers.
> Like this (not tested):
> 
> #define OMAP5_CONTROL_DSIPHY		0x614
> 
> static int omap5_dsi_mux_pads(int dsi_id, unsigned lanes)
> {
> 	u32 enable_mask, enable_shift, reg;
> 
> 	if (dsi_id = 0) {
> 		enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
> 		enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
> 	} else if (dsi_id = 1) {
> 		enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
> 		enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
> 	} else {
> 		return -ENODEV;
> 	}
> 
> 	reg = omap4_ctrl_pad_readl(OMAP5_CONTROL_DSIPHY);
> 	reg &= ~enable_mask;
> 	reg |= (lanes << enable_shift) & enable_mask;
> 	omap4_ctrl_pad_writel(reg, OMAP5_CONTROL_DSIPHY);
> 
> 	return 0;
> }

Chances are any mux register in the syscon area already works with
pinctrl-single,pins or pinctrl-single,bits option. The ones in the
padconf area should be already mapped so the driver just has to
request them.

Regards,

Tony

^ permalink raw reply

* [PATCH RFC 00/17] Rework OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-04-25 21:16 UTC (permalink / raw)
  To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA
  Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
	liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
	peter.ujfalusi-l0cyMroinI0, detheridge-l0cyMroinI0,
	bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
	Jyri Sarha

This set of patches fixes OMAP4+ HDMI audio. The structure of the
implementatin looks a bit different than before. Instead of creating a
driver specific API for a separate ASoC component driver to connect
to, this implementation integrates an the component driver into the
HDMI driver.

The idea is to use an existing ASoC component driver API instead of
creating a new custom API for each HDMI IP and to avoid splitting the
driver to half for separate video and audio parts connected with the
API.

The new implementation also uses simple-audio-card for a machine
driver instead of having its own HW specific machine driver.

The patches are based on 3.15-rc2 merged with
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
and
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-omap5

Everything is pushed here here:
git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git omap-hdmi-audio

Best regards,
Jyri

Jyri Sarha (17):
  ASoC: omap-pcm: Move omap-pcm under include/sound
  OMAPDSS: hdmi-common: Add hdmi_dss_audio_from_hw_params()
  OMAPDSS: hdmi4: Integrated ASoC DAI component driver implementation
  OMAPDSS: Kconfig: Add depencies and help section to
    OMAP4_DSS_HDMI_AUDIO
  OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
  OMAPDSS: hdmi5_core: Fix compilation with OMAP5_DSS_HDMI_AUDIO
  OMAPDSS: hdmi5: Integrated ASoC DAI component driver implementation
  OMAPDSS: Kconfig: Add depencies and help section to
    OMAP5_DSS_HDMI_AUDIO
  ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
  OMAPDSS: Remove obsolete audio code
  ARM: omap4.dtsi: Add audio related parametes to hdmi node
  ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
  ARM: omap5.dtsi: Add audio related parameters to hdmi node
  ARM: omap5-uevm.dts: Add hdmi audio related nodes
  ARM: omap2plus_defconfig: Build DSS HDMI support for OMAP4 in kernel
  ARM: omap2plus_defconfig: Enable OMAP5 HDMI support
  ARM: omap2plus_defconfig: Enable OMAP4+ HDMI audio support

 .../devicetree/bindings/video/ti,omap4-dss.txt     |    4 +
 arch/arm/boot/dts/omap4-panda-common.dtsi          |   21 +-
 arch/arm/boot/dts/omap4.dtsi                       |    2 +
 arch/arm/boot/dts/omap5-uevm.dts                   |   19 +
 arch/arm/boot/dts/omap5.dtsi                       |    2 +
 arch/arm/configs/omap2plus_defconfig               |   20 +-
 .../fbdev/omap2/displays-new/connector-hdmi.c      |   99 ------
 .../fbdev/omap2/displays-new/encoder-tpd12s015.c   |   56 ---
 drivers/video/fbdev/omap2/dss/Kconfig              |   19 +-
 drivers/video/fbdev/omap2/dss/hdmi.h               |    8 +-
 drivers/video/fbdev/omap2/dss/hdmi4.c              |  216 ++++++++----
 drivers/video/fbdev/omap2/dss/hdmi5.c              |  216 ++++++++----
 drivers/video/fbdev/omap2/dss/hdmi5_core.c         |    2 +-
 drivers/video/fbdev/omap2/dss/hdmi_common.c        |  117 ++++++-
 include/sound/omap-pcm.h                           |   30 ++
 include/video/omapdss.h                            |   31 --
 sound/soc/davinci/davinci-mcasp.c                  |    2 +-
 sound/soc/omap/Kconfig                             |   13 -
 sound/soc/omap/Makefile                            |    4 -
 sound/soc/omap/omap-dmic.c                         |    2 +-
 sound/soc/omap/omap-hdmi-card.c                    |   87 -----
 sound/soc/omap/omap-hdmi.c                         |  364 --------------------
 sound/soc/omap/omap-hdmi.h                         |   38 --
 sound/soc/omap/omap-mcbsp.c                        |    2 +-
 sound/soc/omap/omap-mcpdm.c                        |    2 +-
 sound/soc/omap/omap-pcm.h                          |   30 --
 26 files changed, 536 insertions(+), 870 deletions(-)
 create mode 100644 include/sound/omap-pcm.h
 delete mode 100644 sound/soc/omap/omap-hdmi-card.c
 delete mode 100644 sound/soc/omap/omap-hdmi.c
 delete mode 100644 sound/soc/omap/omap-hdmi.h
 delete mode 100644 sound/soc/omap/omap-pcm.h

-- 
1.7.9.5


^ permalink raw reply

* [PATCH RFC 01/17] ASoC: omap-pcm: Move omap-pcm under include/sound
From: Jyri Sarha @ 2014-04-25 21:16 UTC (permalink / raw)
  To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA
  Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
	liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
	peter.ujfalusi-l0cyMroinI0, detheridge-l0cyMroinI0,
	bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
	Jyri Sarha
In-Reply-To: <cover.1398453425.git.jsarha-l0cyMroinI0@public.gmane.org>

Make including the omap-pcm.h outside sound/soc/omap more convenient.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
 include/sound/omap-pcm.h          |   30 ++++++++++++++++++++++++++++++
 sound/soc/davinci/davinci-mcasp.c |    2 +-
 sound/soc/omap/omap-dmic.c        |    2 +-
 sound/soc/omap/omap-hdmi.c        |    2 +-
 sound/soc/omap/omap-mcbsp.c       |    2 +-
 sound/soc/omap/omap-mcpdm.c       |    2 +-
 sound/soc/omap/omap-pcm.h         |   30 ------------------------------
 7 files changed, 35 insertions(+), 35 deletions(-)
 create mode 100644 include/sound/omap-pcm.h
 delete mode 100644 sound/soc/omap/omap-pcm.h

diff --git a/include/sound/omap-pcm.h b/include/sound/omap-pcm.h
new file mode 100644
index 0000000..c1d2f31
--- /dev/null
+++ b/include/sound/omap-pcm.h
@@ -0,0 +1,30 @@
+/*
+ * omap-pcm.h - OMAP PCM driver
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef __OMAP_PCM_H__
+#define __OMAP_PCM_H__
+
+#if IS_ENABLED(CONFIG_SND_OMAP_SOC)
+int omap_pcm_platform_register(struct device *dev);
+#else
+static inline int omap_pcm_platform_register(struct device *dev)
+{
+	return 0;
+}
+#endif /* CONFIG_SND_OMAP_SOC */
+
+#endif /* __OMAP_PCM_H__ */
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
index 14058dc..9afb146 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -33,10 +33,10 @@
 #include <sound/initval.h>
 #include <sound/soc.h>
 #include <sound/dmaengine_pcm.h>
+#include <sound/omap-pcm.h>
 
 #include "davinci-pcm.h"
 #include "davinci-mcasp.h"
-#include "../omap/omap-pcm.h"
 
 #define MCASP_MAX_AFIFO_DEPTH	64
 
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 53da041..6925d71 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -40,9 +40,9 @@
 #include <sound/initval.h>
 #include <sound/soc.h>
 #include <sound/dmaengine_pcm.h>
+#include <sound/omap-pcm.h>
 
 #include "omap-dmic.h"
-#include "omap-pcm.h"
 
 struct omap_dmic {
 	struct device *dev;
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index 537a1ec..eb9c392 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -34,9 +34,9 @@
 #include <sound/asoundef.h>
 #include <sound/dmaengine_pcm.h>
 #include <video/omapdss.h>
+#include <sound/omap-pcm.h>
 
 #include "omap-hdmi.h"
-#include "omap-pcm.h"
 
 #define DRV_NAME "omap-hdmi-audio-dai"
 
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index af2764a..10d6cec 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -34,11 +34,11 @@
 #include <sound/initval.h>
 #include <sound/soc.h>
 #include <sound/dmaengine_pcm.h>
+#include <sound/omap-pcm.h>
 
 #include <linux/platform_data/asoc-ti-mcbsp.h>
 #include "mcbsp.h"
 #include "omap-mcbsp.h"
-#include "omap-pcm.h"
 
 #define OMAP_MCBSP_RATES	(SNDRV_PCM_RATE_8000_96000)
 
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index d8ebb52..f0e2ebe 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -40,9 +40,9 @@
 #include <sound/pcm_params.h>
 #include <sound/soc.h>
 #include <sound/dmaengine_pcm.h>
+#include <sound/omap-pcm.h>
 
 #include "omap-mcpdm.h"
-#include "omap-pcm.h"
 
 struct mcpdm_link_config {
 	u32 link_mask; /* channel mask for the direction */
diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h
deleted file mode 100644
index c1d2f31..0000000
--- a/sound/soc/omap/omap-pcm.h
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * omap-pcm.h - OMAP PCM driver
- *
- * Copyright (C) 2014 Texas Instruments, Inc.
- *
- * Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- */
-
-#ifndef __OMAP_PCM_H__
-#define __OMAP_PCM_H__
-
-#if IS_ENABLED(CONFIG_SND_OMAP_SOC)
-int omap_pcm_platform_register(struct device *dev);
-#else
-static inline int omap_pcm_platform_register(struct device *dev)
-{
-	return 0;
-}
-#endif /* CONFIG_SND_OMAP_SOC */
-
-#endif /* __OMAP_PCM_H__ */
-- 
1.7.9.5


^ permalink raw reply related

* [PATCH RFC 02/17] OMAPDSS: hdmi-common: Add hdmi_dss_audio_from_hw_params()
From: Jyri Sarha @ 2014-04-25 21:16 UTC (permalink / raw)
  To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA
  Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
	liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
	peter.ujfalusi-l0cyMroinI0, detheridge-l0cyMroinI0,
	bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
	Jyri Sarha
In-Reply-To: <cover.1398453425.git.jsarha-l0cyMroinI0@public.gmane.org>

Add common function for struct omap_dss_audio initialization from
struct snd_pcm_hw_params.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
 drivers/video/fbdev/omap2/dss/hdmi.h        |    5 ++
 drivers/video/fbdev/omap2/dss/hdmi_common.c |  117 ++++++++++++++++++++++++++-
 2 files changed, 121 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
index fbee078..65bf072 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -433,6 +433,11 @@ int hdmi_parse_lanes_of(struct platform_device *pdev, struct device_node *ep,
 
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
 int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts);
+struct snd_pcm_hw_params;
+struct snd_soc_dai;
+int hdmi_dss_audio_from_hw_params(struct snd_pcm_hw_params *params,
+				  struct omap_dss_audio *dss_audio,
+				  struct snd_soc_dai *dai);
 int hdmi_wp_audio_enable(struct hdmi_wp_data *wp, bool enable);
 int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable);
 void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_common.c b/drivers/video/fbdev/omap2/dss/hdmi_common.c
index 9a2c39c..85a2407 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_common.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_common.c
@@ -19,6 +19,12 @@
 #include <linux/err.h>
 #include <linux/of.h>
 #include <video/omapdss.h>
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+#include <sound/asound.h>
+#include <sound/asoundef.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+#endif
 
 #include "hdmi.h"
 
@@ -364,7 +370,7 @@ int hdmi_parse_lanes_of(struct platform_device *pdev, struct device_node *ep,
 	return 0;
 }
 
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
 int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts)
 {
 	u32 deep_color;
@@ -463,4 +469,113 @@ int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts)
 
 	return 0;
 }
+
+int hdmi_dss_audio_from_hw_params(struct snd_pcm_hw_params *params,
+				  struct omap_dss_audio *dss_audio,
+				  struct snd_soc_dai *dai)
+{
+	struct snd_aes_iec958 *iec = dss_audio->iec;
+	struct snd_cea_861_aud_if *cea = dss_audio->cea;
+
+	/*
+	 * fill the IEC-60958 channel status word
+	 */
+	/* initialize the word bytes */
+	memset(iec->status, 0, sizeof(iec->status));
+
+	/* specify IEC-60958-3 (commercial use) */
+	iec->status[0] &= ~IEC958_AES0_PROFESSIONAL;
+
+	/* specify that the audio is LPCM*/
+	iec->status[0] &= ~IEC958_AES0_NONAUDIO;
+
+	iec->status[0] |= IEC958_AES0_CON_NOT_COPYRIGHT;
+
+	iec->status[0] |= IEC958_AES0_CON_EMPHASIS_NONE;
+
+	iec->status[0] |= IEC958_AES1_PRO_MODE_NOTID;
+
+	iec->status[1] = IEC958_AES1_CON_GENERAL;
+
+	iec->status[2] |= IEC958_AES2_CON_SOURCE_UNSPEC;
+
+	iec->status[2] |= IEC958_AES2_CON_CHANNEL_UNSPEC;
+
+	switch (params_rate(params)) {
+	case 32000:
+		iec->status[3] |= IEC958_AES3_CON_FS_32000;
+		break;
+	case 44100:
+		iec->status[3] |= IEC958_AES3_CON_FS_44100;
+		break;
+	case 48000:
+		iec->status[3] |= IEC958_AES3_CON_FS_48000;
+		break;
+	case 88200:
+		iec->status[3] |= IEC958_AES3_CON_FS_88200;
+		break;
+	case 96000:
+		iec->status[3] |= IEC958_AES3_CON_FS_96000;
+		break;
+	case 176400:
+		iec->status[3] |= IEC958_AES3_CON_FS_176400;
+		break;
+	case 192000:
+		iec->status[3] |= IEC958_AES3_CON_FS_192000;
+		break;
+	default:
+		dev_err(dai->dev, "rate not supported!\n");
+		return -EINVAL;
+	}
+
+	/* specify the clock accuracy */
+	iec->status[3] |= IEC958_AES3_CON_CLOCK_1000PPM;
+
+	/*
+	 * specify the word length. The same word length value can mean
+	 * two different lengths. Hence, we need to specify the maximum
+	 * word length as well.
+	 */
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		iec->status[4] |= IEC958_AES4_CON_WORDLEN_20_16;
+		iec->status[4] &= ~IEC958_AES4_CON_MAX_WORDLEN_24;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		iec->status[4] |= IEC958_AES4_CON_WORDLEN_24_20;
+		iec->status[4] |= IEC958_AES4_CON_MAX_WORDLEN_24;
+		break;
+	default:
+		dev_err(dai->dev, "format not supported!\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Fill the CEA-861 audio infoframe (see spec for details)
+	 */
+
+	cea->db1_ct_cc = (params_channels(params) - 1)
+		& CEA861_AUDIO_INFOFRAME_DB1CC;
+	cea->db1_ct_cc |= CEA861_AUDIO_INFOFRAME_DB1CT_FROM_STREAM;
+
+	cea->db2_sf_ss = CEA861_AUDIO_INFOFRAME_DB2SF_FROM_STREAM;
+	cea->db2_sf_ss |= CEA861_AUDIO_INFOFRAME_DB2SS_FROM_STREAM;
+
+	cea->db3 = 0; /* not used, all zeros */
+
+	/*
+	 * The OMAP HDMI IP requires to use the 8-channel channel code when
+	 * transmitting more than two channels.
+	 */
+	if (params_channels(params) = 2)
+		cea->db4_ca = 0x0;
+	else
+		cea->db4_ca = 0x13;
+
+	cea->db5_dminh_lsv = CEA861_AUDIO_INFOFRAME_DB5_DM_INH_PROHIBITED;
+	/* the expression is trivial but makes clear what we are doing */
+	cea->db5_dminh_lsv |= (0 & CEA861_AUDIO_INFOFRAME_DB5_LSV);
+
+	return 0;
+}
 #endif
-- 
1.7.9.5


^ permalink raw reply related

* [PATCH RFC 03/17] OMAPDSS: hdmi4: Integrated ASoC DAI component driver implementation
From: Jyri Sarha @ 2014-04-25 21:16 UTC (permalink / raw)
  To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA
  Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
	liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
	peter.ujfalusi-l0cyMroinI0, detheridge-l0cyMroinI0,
	bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
	Jyri Sarha
In-Reply-To: <cover.1398453425.git.jsarha-l0cyMroinI0@public.gmane.org>

Integrate ASoC DAI component driver in to the OMAP4 hdmi driver. The
implementation removes the callbacks for an external audio driver and
the old external DAI driver does not work anymore after this patch.
The patch also updates the relevant entry in ti,omap4-dss DT binding
document.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
 .../devicetree/bindings/video/ti,omap4-dss.txt     |    4 +
 drivers/video/fbdev/omap2/dss/hdmi4.c              |  216 ++++++++++++++------
 2 files changed, 155 insertions(+), 65 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
index b8c29fb..b059640 100644
--- a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -107,6 +107,10 @@ Required properties:
 - clocks: handles to fclk and pll clock
 - clock-names: "fck", "sys_clk"
 
+Required properties if hdmi audio support is enabled:
+- dmas: DMA controller phandle for HDMI audio output
+- dma-names: "audio_tx"
+
 Optional nodes:
 - Video port for HDMI output
 
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 626aad2..dbdb3ed 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -34,6 +34,16 @@
 #include <linux/regulator/consumer.h>
 #include <video/omapdss.h>
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+#include <linux/dmaengine.h>
+#include <sound/dmaengine_pcm.h>
+#include <sound/soc.h>
+#include <sound/pcm_params.h>
+#include <uapi/sound/asound.h>
+#include <sound/asoundef.h>
+#include <sound/omap-pcm.h>
+#endif
+
 #include "hdmi4_core.h"
 #include "dss.h"
 #include "dss_features.h"
@@ -52,6 +62,13 @@ static struct {
 	struct clk *sys_clk;
 	struct regulator *vdda_hdmi_dac_reg;
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+	struct snd_dmaengine_dai_dma_data dma_data;
+	struct omap_dss_audio dss_audio;
+	struct snd_aes_iec958 iec;
+	struct snd_cea_861_aud_if cea;
+#endif
+
 	bool core_enabled;
 
 	struct omap_dss_device output;
@@ -510,7 +527,36 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
 }
 
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
+static int hdmi_dai_startup(struct snd_pcm_substream *substream,
+			    struct snd_soc_dai *dai)
+{
+	int ret;
+	/*
+	 * Make sure that the period bytes are multiple of the DMA packet size.
+	 * Largest packet size we use is 32 32-bit words = 128 bytes
+	 */
+	ret = snd_pcm_hw_constraint_step(substream->runtime, 0,
+					 SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 128);
+	if (ret < 0) {
+		dev_err(dai->dev, "could not apply constraint\n");
+		return ret;
+	}
+
+	mutex_lock(&hdmi.lock);
+	ret = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
+	mutex_unlock(&hdmi.lock);
+	if (!ret) {
+		dev_err(dai->dev, "audio not supported\n");
+		return -ENODEV;
+	}
+
+	snd_soc_dai_set_dma_data(dai, substream, &hdmi.dma_data);
+
+	return 0;
+}
+
+static int hdmi_dai_prepare(struct snd_pcm_substream *substream,
+			    struct snd_soc_dai *dai)
 {
 	int r;
 
@@ -522,96 +568,137 @@ static int hdmi_audio_enable(struct omap_dss_device *dssdev)
 	}
 
 	r = hdmi_wp_audio_enable(&hdmi.wp, true);
-	if (r)
-		goto err;
-
-	mutex_unlock(&hdmi.lock);
-	return 0;
 
 err:
 	mutex_unlock(&hdmi.lock);
 	return r;
 }
 
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-	hdmi_wp_audio_enable(&hdmi.wp, false);
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
-	return hdmi4_audio_start(&hdmi.core, &hdmi.wp);
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
+static int hdmi_dai_hw_params(struct snd_pcm_substream *substream,
+			      struct snd_pcm_hw_params *params,
+			      struct snd_soc_dai *dai)
 {
-	hdmi4_audio_stop(&hdmi.core, &hdmi.wp);
-}
+	int err;
 
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
-	bool r;
-
-	mutex_lock(&hdmi.lock);
-
-	r = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
-
-	mutex_unlock(&hdmi.lock);
-	return r;
-}
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		hdmi.dma_data.maxburst = 16;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		hdmi.dma_data.maxburst = 32;
+		break;
+	default:
+		dev_err(dai->dev, "format not supported!\n");
+		return -EINVAL;
+	}
 
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
-		struct omap_dss_audio *audio)
-{
-	int r;
-	u32 pclk = hdmi.cfg.timings.pixelclock;
+	hdmi.dss_audio.iec = &hdmi.iec;
+	hdmi.dss_audio.cea = &hdmi.cea;
+	err = hdmi_dss_audio_from_hw_params(params, &hdmi.dss_audio, dai);
+	if (err)
+		return err;
 
 	mutex_lock(&hdmi.lock);
 
 	if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
-		r = -EPERM;
+		err = -EPERM;
 		goto err;
 	}
 
-	r = hdmi4_audio_config(&hdmi.core, &hdmi.wp, audio, pclk);
-	if (r)
-		goto err;
-
-	mutex_unlock(&hdmi.lock);
-	return 0;
-
+	err = hdmi4_audio_config(&hdmi.core, &hdmi.wp, &hdmi.dss_audio,
+				 hdmi.cfg.timings.pixelclock);
 err:
 	mutex_unlock(&hdmi.lock);
-	return r;
-}
-#else
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
-	return -EPERM;
+	return err;
+}
+
+static int hdmi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
+			    struct snd_soc_dai *dai)
+{
+	int err = 0;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_RESUME:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		err = hdmi4_audio_start(&hdmi.core, &hdmi.wp);
+		break;
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		hdmi4_audio_stop(&hdmi.core, &hdmi.wp);
+		break;
+	default:
+		err = -EINVAL;
+	}
+	return err;
 }
 
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
+static void hdmi_dai_shutdown(struct snd_pcm_substream *substream,
+			      struct snd_soc_dai *dai)
 {
+	hdmi_wp_audio_enable(&hdmi.wp, false);
 }
 
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
+static const struct snd_soc_dai_ops hdmi_dai_ops = {
+	.startup	= hdmi_dai_startup,
+	.hw_params	= hdmi_dai_hw_params,
+	.prepare	= hdmi_dai_prepare,
+	.trigger	= hdmi_dai_trigger,
+	.shutdown	= hdmi_dai_shutdown,
+};
+
+static struct snd_soc_dai_driver omap_hdmi_dai = {
+	.playback = {
+		.channels_min = 2,
+		.channels_max = 8,
+		.rates = (SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
+			  SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 |
+			  SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_176400 |
+			  SNDRV_PCM_RATE_192000),
+		.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE,
+	},
+	.ops = &hdmi_dai_ops,
+};
+
+static const struct snd_soc_component_driver omap_hdmi_component = {
+	.name = "omapdss_hdmi",
+};
+
+static int hdmi_audio_init(struct platform_device *pdev)
 {
-	return -EPERM;
+	struct resource *res;
+	int ret;
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "wp");
+	if (!res) {
+		dev_err(&pdev->dev, "Cannot obtain IORESOURCE_MEM l4\n");
+		return -ENODEV;
+	}
+	hdmi.dma_data.addr = res->start + HDMI_WP_AUDIO_DATA;
+	hdmi.dma_data.filter_data = "audio_tx";
+	hdmi.dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+
+	ret = snd_soc_register_component(&pdev->dev, &omap_hdmi_component,
+					 &omap_hdmi_dai, 1);
+	if (ret)
+		return ret;
+
+	return omap_pcm_platform_register(&pdev->dev);
 }
 
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
+static void hdmi_audio_remove(struct platform_device *pdev)
 {
+	snd_soc_unregister_component(&pdev->dev);
 }
 
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
+#else
+static int hdmi_audio_init(struct platform_device *pdev)
 {
-	return false;
+	return 0;
 }
 
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
-		struct omap_dss_audio *audio)
+static void hdmi_audio_remove(struct platform_device *pdev)
 {
-	return -EPERM;
 }
 #endif
 
@@ -627,13 +714,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = {
 	.get_timings		= hdmi_display_get_timings,
 
 	.read_edid		= hdmi_read_edid,
-
-	.audio_enable		= hdmi_audio_enable,
-	.audio_disable		= hdmi_audio_disable,
-	.audio_start		= hdmi_audio_start,
-	.audio_stop		= hdmi_audio_stop,
-	.audio_supported	= hdmi_audio_supported,
-	.audio_config		= hdmi_audio_config,
 };
 
 static void hdmi_init_output(struct platform_device *pdev)
@@ -732,6 +812,10 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
 		return r;
 	}
 
+	r = hdmi_audio_init(pdev);
+	if (r)
+		return r;
+
 	pm_runtime_enable(&pdev->dev);
 
 	hdmi_init_output(pdev);
@@ -745,6 +829,8 @@ static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
 {
 	hdmi_uninit_output(pdev);
 
+	hdmi_audio_remove(pdev);
+
 	pm_runtime_disable(&pdev->dev);
 
 	return 0;
-- 
1.7.9.5


^ permalink raw reply related

* [PATCH RFC 04/17] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
From: Jyri Sarha @ 2014-04-25 21:16 UTC (permalink / raw)
  To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA
  Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
	liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
	peter.ujfalusi-l0cyMroinI0, detheridge-l0cyMroinI0,
	bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
	Jyri Sarha
In-Reply-To: <cover.1398453425.git.jsarha-l0cyMroinI0@public.gmane.org>

Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
 drivers/video/fbdev/omap2/dss/Kconfig |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig
index 8921a7a..ecc2f50 100644
--- a/drivers/video/fbdev/omap2/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/dss/Kconfig
@@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI
 	  HDMI support for OMAP4 based SoCs.
 
 config OMAP4_DSS_HDMI_AUDIO
-	bool
+	bool "HDMI audio support for OMAP4"
+	depends on OMAP4_DSS_HDMI
+	depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
+	default y
+	help
+	  HDMI audio support for OMAP4 based SoCs. Adds integrated
+	  ASoC Digital Audio Interface component driver into OMAPDSS
+	  module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with
+	  devicetree description for full HDMI audio support.
 
 config OMAP5_DSS_HDMI
 	bool "HDMI support for OMAP5"
-- 
1.7.9.5


^ permalink raw reply related

* [PATCH RFC 05/17] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
From: Jyri Sarha @ 2014-04-25 21:16 UTC (permalink / raw)
  To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA
  Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
	liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
	peter.ujfalusi-l0cyMroinI0, detheridge-l0cyMroinI0,
	bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
	Jyri Sarha
In-Reply-To: <cover.1398453425.git.jsarha-l0cyMroinI0@public.gmane.org>

The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in
hdmi_core_audio_layout enum. I found the correct value from ti-linux
3.8 tree.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
 drivers/video/fbdev/omap2/dss/hdmi.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
index 65bf072..ea4a168 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -159,7 +159,8 @@ enum hdmi_audio_blk_strt_end_sig {
 
 enum hdmi_core_audio_layout {
 	HDMI_AUDIO_LAYOUT_2CH = 0,
-	HDMI_AUDIO_LAYOUT_8CH = 1
+	HDMI_AUDIO_LAYOUT_8CH = 1,
+	HDMI_AUDIO_LAYOUT_6CH = 2
 };
 
 enum hdmi_core_cts_mode {
-- 
1.7.9.5


^ permalink raw reply related

* [PATCH RFC 06/17] OMAPDSS: hdmi5_core: Fix compilation with OMAP5_DSS_HDMI_AUDIO
From: Jyri Sarha @ 2014-04-25 21:16 UTC (permalink / raw)
  To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA
  Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A,
	liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
	peter.ujfalusi-l0cyMroinI0, detheridge-l0cyMroinI0,
	bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
	Jyri Sarha
In-Reply-To: <cover.1398453425.git.jsarha-l0cyMroinI0@public.gmane.org>

Use correct variable name for base address.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
 drivers/video/fbdev/omap2/dss/hdmi5_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c
index 270ebdd..af88e3c 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c
@@ -786,7 +786,7 @@ static void hdmi5_core_audio_config(struct hdmi_core_data *core,
 	REG_FLD_MOD(base, HDMI_CORE_AUD_GP_POL, 1, 0, 0);
 
 	/* unmute audio */
-	REG_FLD_MOD(core_sys_base, HDMI_CORE_FC_AUDSCONF, 0, 7, 4);
+	REG_FLD_MOD(base, HDMI_CORE_FC_AUDSCONF, 0, 7, 4);
 }
 
 static void hdmi5_core_audio_infoframe_cfg(struct hdmi_core_data *core,
-- 
1.7.9.5


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox