Re: [PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-19 Thread Mark Brown 
On Fri, Sep 18, 2015 at 02:06:39PM +0300, Jyri Sarha wrote:
> Add IEC958 channel status helper that gets the audio properties from
> snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
> produce the channel status bits already in audio stream configuration
> phase.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  include/sound/pcm_iec958.h |  2 ++
>  sound/core/pcm_iec958.c| 52 
> +++---

This is core ALSA code, you need to CC Takashi (added him, not cutting
context).

>  2 files changed, 37 insertions(+), 17 deletions(-)
> 
> diff --git a/include/sound/pcm_iec958.h b/include/sound/pcm_iec958.h
> index 0eed397..36f023a 100644
> --- a/include/sound/pcm_iec958.h
> +++ b/include/sound/pcm_iec958.h
> @@ -6,4 +6,6 @@
>  int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
>   size_t len);
>  
> +int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params 
> *params,
> +  u8 *cs, size_t len);
>  #endif
> diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
> index 36b2d7a..c9f8b66 100644
> --- a/sound/core/pcm_iec958.c
> +++ b/sound/core/pcm_iec958.c
> @@ -9,30 +9,18 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> -/**
> - * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
> status
> - * @runtime: pcm runtime structure with ->rate filled in
> - * @cs: channel status buffer, at least four bytes
> - * @len: length of channel status buffer
> - *
> - * Create the consumer format channel status data in @cs of maximum size
> - * @len corresponding to the parameters of the PCM runtime @runtime.
> - *
> - * Drivers may wish to tweak the contents of the buffer after creation.
> - *
> - * Returns: length of buffer, or negative error code if something failed.
> - */
> -int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
> - size_t len)
> +static int create_iec958_consumer(uint rate, uint sample_width,
> +   u8 *cs, size_t len)
>  {
>   unsigned int fs, ws;
>  
>   if (len < 4)
>   return -EINVAL;
>  
> - switch (runtime->rate) {
> + switch (rate) {
>   case 32000:
>   fs = IEC958_AES3_CON_FS_32000;
>   break;
> @@ -59,7 +47,7 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
> *runtime, u8 *cs,
>   }
>  
>   if (len > 4) {
> - switch (snd_pcm_format_width(runtime->format)) {
> + switch (sample_width) {
>   case 16:
>   ws = IEC958_AES4_CON_WORDLEN_20_16;
>   break;
> @@ -92,4 +80,34 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
> *runtime, u8 *cs,
>  
>   return len;
>  }
> +
> +/**
> + * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
> status
> + * @runtime: pcm runtime structure with ->rate filled in
> + * @cs: channel status buffer, at least four bytes
> + * @len: length of channel status buffer
> + *
> + * Create the consumer format channel status data in @cs of maximum size
> + * @len corresponding to the parameters of the PCM runtime @runtime.
> + *
> + * Drivers may wish to tweak the contents of the buffer after creation.
> + *
> + * Returns: length of buffer, or negative error code if something failed.
> + */
> +int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
> + size_t len)
> +{
> + return create_iec958_consumer(runtime->rate,
> +   snd_pcm_format_width(runtime->format),
> +   cs, len);
> +}
>  EXPORT_SYMBOL(snd_pcm_create_iec958_consumer);
> +
> +
> +int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params 
> *params,
> +  u8 *cs, size_t len)
> +{
> + return create_iec958_consumer(params_rate(params), params_width(params),
> +   cs, len);
> +}
> +EXPORT_SYMBOL(snd_pcm_create_iec958_consumer_hw_params);
> -- 
> 1.9.1
> 
> 


signature.asc
Description: Digital signature

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

2015-09-19 Thread Grazvydas Ignotas 
On Fri, Sep 18, 2015 at 9:39 PM, Robert Nelson  wrote:
> On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren  wrote:
>> * Robert Nelson  [150918 09:45]:
>>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren  wrote:
>>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
>>> > device tree bindings for the TI WLAN SDIO on many omap variants.
>>> >
>>> > I recall wondering how come omap5-uevm did not have the WLAN
>>> > added and this issue has been bugging me for a while now, and
>>> > I finally tracked it down to a bad pinmux regression, and a missing
>>> > deferred probe handling for the 32k clock from palmas that's
>>> > requested by twl6040.
>>> >
>>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
>>> > added pin muxing for mcspi4 that conflicts with the onboard
>>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
>>> > this was probably only the case for initial prototypes. Both
>>> > omap5-uevm boards I have have WLAN populated.
>>>
>>> Production boards from svtronics don't populate the wlan..
>>>
>>> http://www.svtronics.com/EVM/OMAP5432/5432
>>>
>>> quote: "WiFi not available on this model"
>
> Okay, got an email back from svtronics, there was a special omap5_uevm
> + wlan order option for production units.

The boards we bought came without wlan, so that seems to be the
"default" configuration.

I vote for using separate DT overlay for the wlan version to avoid
unnecessary probing. OTOH the pins are not exposed on expansion
connectors and should not conflict with custom peripherals, so no
strong opinion here.

Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mfd: Add battery charger as subdevice to the tps65217.

2015-09-19 Thread Lee Jones 
On Tue, 08 Sep 2015, Enric Balletbo i Serra wrote:

> Add tps65217 battery charger subdevice.
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  drivers/mfd/tps65217.c | 4 
>  1 file changed, 4 insertions(+)

Applied, thanks.

> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 55add04..d32b5442 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -39,6 +39,10 @@ static const struct mfd_cell tps65217s[] = {
>   .name = "tps65217-bl",
>   .of_compatible = "ti,tps65217-bl",
>   },
> + {
> + .name = "tps65217-charger",
> + .of_compatible = "ti,tps65217-charger",
> + },
>  };
>  
>  /**

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] ASoC: simple-card: Update clocks binding for simple-card DAI subnodes

2015-09-19 Thread Mark Brown 
On Fri, Sep 11, 2015 at 04:18:02PM +0300, Jyri Sarha wrote:

> The updated binding provides a way to set clock-ID and direction
> parameters for DAI drivers set_sysclk() call back.

> I proposed something similar about a year ago, but Mark rejected that
> at the time. This RFC is to start that discussion again. This time
> before I do any code changes.

What's the use case again?  Can we address this by converting the
relevant drivers to the clock API (or improving their clock API
support)?


signature.asc
Description: Digital signature

Re: [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-19 Thread Mark Brown 
On Fri, Sep 18, 2015 at 02:06:40PM +0300, Jyri Sarha wrote:

> +#define SPDIF_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | 
> SNDRV_PCM_FMTBIT_S16_BE |\
> +  SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> +  SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
> +  SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE)
> +
> +#define I2S_FORMATS  (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\
> +  SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE |\
> +  SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> +  SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
> +  SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\
> +  SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)

I'm not sure how abstracted this I2S and S/PDIF DAI business is - it
doesn't feel like something that's going to be a property of all HDMI
devices, and the specific sets of formats above cause me to raise a bit
of an eyebrow.  Should this be an interface where the HDMI chip
registers multiple interfaces if it has them instead of automatically
getting this split as is?

We can probably skip more specific constraint stuff I guess on the basis
that things tend to support the full range of HDMI functionality, or at
least that can be added later?

Otherwise this looks mostly OK on a first pass, thanks for working on
it.


signature.asc
Description: Digital signature

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

2015-09-19 Thread Tony Lindgren 
* Grazvydas Ignotas  [150919 14:16]:
> On Fri, Sep 18, 2015 at 9:39 PM, Robert Nelson  
> wrote:
> > On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren  wrote:
> >> * Robert Nelson  [150918 09:45]:
> >>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren  wrote:
> >>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> >>> > device tree bindings for the TI WLAN SDIO on many omap variants.
> >>> >
> >>> > I recall wondering how come omap5-uevm did not have the WLAN
> >>> > added and this issue has been bugging me for a while now, and
> >>> > I finally tracked it down to a bad pinmux regression, and a missing
> >>> > deferred probe handling for the 32k clock from palmas that's
> >>> > requested by twl6040.
> >>> >
> >>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> >>> > added pin muxing for mcspi4 that conflicts with the onboard
> >>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
> >>> > this was probably only the case for initial prototypes. Both
> >>> > omap5-uevm boards I have have WLAN populated.
> >>>
> >>> Production boards from svtronics don't populate the wlan..
> >>>
> >>> http://www.svtronics.com/EVM/OMAP5432/5432
> >>>
> >>> quote: "WiFi not available on this model"
> >
> > Okay, got an email back from svtronics, there was a special omap5_uevm
> > + wlan order option for production units.
> 
> The boards we bought came without wlan, so that seems to be the
> "default" configuration.
> 
> I vote for using separate DT overlay for the wlan version to avoid
> unnecessary probing. OTOH the pins are not exposed on expansion
> connectors and should not conflict with custom peripherals, so no
> strong opinion here.

Good to hear those pins are not rerouted. But considering we
already have mmc3 defined in omap5-uevm.. And the SDIO bus
is meant to be probed.. And the boards have WLAN connectors but
unpopulated.. I'd say it's safe to have it mapped in the dts :)

BTW, I have a few patches coming for omap5-board-common.dtsi
and basic igepv5 support pending some more testing. That makes
it easy to add omap5-uevm related variants easily.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

2015-09-19 Thread Lee Jones 
On Fri, 18 Sep 2015, Tony Lindgren wrote:

> Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> added clock handling for the 32k clock from palmas-clk. However, that
> patch did not consider a typical situation where twl6040 is built-in,
> and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> 
> If palmas-clk is not loaded before twl6040 probes, we will get a
> "clk32k is not handled" warning during booting. This means that any
> drivers relying on this clock will mysteriously fail, including
> omap5-uevm WLAN and audio.
> 
> Note that for WLAN, we probably should also eventually get
> the clk32kgaudio for MMC3 directly as that's shared between
> audio and WLAN SDIO at least for omap5-uevm. It seems the
> WLAN chip cannot get it as otherwise MMC3 won't get properly
> probed.
> 
> Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> Cc: Benoit Cousson 
> Cc: Dr. H. Nikolaus Schaller 
> Cc: Grazvydas Ignotas 
> Cc: Lee Jones 
> Cc: Peter Ujfalusi 
> Cc: Samuel Ortiz 
> Cc: Sourav Poddar 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/mfd/twl6040.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks.

> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
>  
>   twl6040->clk32k = devm_clk_get(>dev, "clk32k");
>   if (IS_ERR(twl6040->clk32k)) {
> + if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
>   dev_info(>dev, "clk32k is not handled\n");
>   twl6040->clk32k = NULL;
>   }

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html