rbolt/xdomain.c | 2 +-
> drivers/tty/serial/serial_core.c | 4 ++--
> drivers/usb/typec/class.c | 8
> include/linux/device.h | 4 ++--
> include/scsi/scsi_transport_iscsi.h| 4 ++--
> net/dsa/dsa.c | 2 +-
>
trol
>
> include/drm/drm_edid.h| 13 ++
> include/sound/pcm.h | 4 +-
> include/sound/soc-dai.h | 3 +
> sound/core/pcm_lib.c | 6 +-
> sound/soc/codecs/hdmi-codec.c | 313
> +++++++++-
> sound/soc/soc-core.c | 28
> 6 files changed, 361 insertions(+), 6 deletions(-)
I'm sorry but please drop me from CC list. I'd like not to be involved
into this kind of new integration within merge window of next Linux
kernel, as I said to you.
Regards
Takashi Sakamoto
Oops. This is not a patch for alsa-lib, but for Linux kernel.
I'm sorry to confuse you...
On Dec 16 2016 18:26, Takashi Sakamoto wrote:
> This is a fix for Linux 4.10-rc1.
>
> In C language specification, a bit-field is interpreted as a signed or
> unsigned integer type
Sarha
CC: Jie Qiu
CC: Arnaud Pouliquen
CC: Srinivas Kandagatla
CC: dri-devel at lists.freedesktop.org
CC: stable at vger.kernel.org
Fixes: 09184118a8ab ("ASoC: hdmi-codec: Add hdmi-codec for external
HDMI-encoders")
Signed-off-by: Takashi Sakamoto
---
include/sound/hdmi-codec.h
On 2016å¹´12æ13æ¥ 22:23, Takashi Sakamoto wrote:
> Hi Arnaud,
>>> This table is invariant in lifetime of the storage object, as well.
>>> Let's put into .rodata section, too.
>>>
>> This table is updated in hdmi_codec_cea_init_channel_alloc so can not
Hi Arnaud,
On Dec 12 2016 22:46, Arnaud Pouliquen wrote:
> On 12/12/2016 01:03 PM, Takashi Sakamoto wrote:
>> On 2016å¹´12æ12æ¥ 18:38, Arnaud Pouliquen wrote:
>>>>> + */
>>>>> +static struct hdmi_codec_cea_spk_alloc hdmi_codec_channel_alloc[] = {
>>
On Dec 12 2016 21:55, Takashi Iwai wrote:
> On Mon, 12 Dec 2016 13:12:16 +0100,
> Takashi Sakamoto wrote:
>>
>> On Dec 12 2016 18:54, Takashi Iwai wrote:
>>>>>> +enum hdmi_codec_cea_spk_placement {
>>>>>> +FL = (1 << 0),
1 << 10),/* Low Frequency Effect */
>>>> +};
>>>
>>> BIT() macro in "linux/bitops.h" is available.
>> will be corrected in a v2
>
> One slight caution: BIT() expands to an unsigned long type.
Mmm, indeed. This is my wrong indication, sorry.
Thanks for your correction.
Regards
Takashi Sakamoto
L_ELEM_ACCESS_TLV_READ |
>>> + SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK |
>>> + SNDRV_CTL_ELEM_ACCESS_VOLATILE,
>>> + .iface = SNDRV_CTL_ELEM_IFACE_PCM,
>>> + .name = "Playback Channel Map",
>>> + .info = hdmi_codec_chmap_ctl_info,
>>> + .get = hdmi_codec_chmap_ctl_get,
>>> + .tlv.c = hdmi_codec_chmap_ctl_tlv,
>>> + },
>>> };
>>
>> If you can keep the same interface for applications as
>> 'snd_pcm_add_chmap_ctls()' have, it's better to integrate the function
>> to have different tables/callbacks depending on drivers.
>>
> I had a look before define it. Unfortunately i cannot use
> snd_pcm_add_chmap_ctls. snd_pcm_add_chmap_ctls requests "snd_pcm"
> structure as input param. ASoC codec not aware of it.
> i could add an helper for ASoC, but hdmi-codec should be used for HDMI
> drivers and i'm not sure that there is another need in ASoC.
For example, splitting the function to two parts; one gets the parameter
for pcm instance, another deal with adding control element sets. Symbols
of both functions are going to be exported and your code can reuse the
latter.
My motivation for this idea is to use the same code for control element
sets with the same name of 'Playback Channel Map'. In this case, usage
of the same code brings us an merit. We can produce the consist way for
applications to handle the control element sets, even if long term
development brings much code changes. It has an advantage to reduce
maintaining effort.
This is merely my initial idea. If it's impossible, your idea is preferable.
Regards
Takashi Sakamoto
gt; + .tlv.c = hdmi_codec_chmap_ctl_tlv,
> + },
> };
If you can keep the same interface for applications as
'snd_pcm_add_chmap_ctls()' have, it's better to integrate the function
to have different tables/callbacks depending on drivers.
> static int hdmi_codec_new_stream(struct snd_pcm_substream *substream,
> @@ -164,7 +496,7 @@ static int hdmi_codec_hw_params(struct snd_pcm_substream
> *substream,
> .dig_subframe = { 0 },
> }
> };
> - int ret;
> + int ret, idx;
>
> dev_dbg(dai->dev, "%s() width %d rate %d channels %d\n", __func__,
> params_width(params), params_rate(params),
> @@ -191,6 +523,16 @@ static int hdmi_codec_hw_params(struct snd_pcm_substream
> *substream,
> hp.cea.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
> hp.cea.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
>
> + /* Select a channel allocation that matches with ELD and pcm channels */
> + idx = hdmi_codec_get_ch_alloc_table_idx(hcp, hp.cea.channels);
> + if (idx < 0) {
> + dev_err(dai->dev, "Not able to map channels to speakers (%d)\n",
> + ret);
> + return idx;
> + }
> + hp.cea.channel_allocation = hdmi_codec_channel_alloc[idx].ca_index;
> + hdmi_cea_alloc_to_tlv_chmap(&hdmi_codec_channel_alloc[idx], hcp->chmap);
> +
> hp.sample_width = params_width(params);
> hp.sample_rate = params_rate(params);
> hp.channels = params_channels(params);
> @@ -407,6 +749,8 @@ static int hdmi_codec_probe(struct platform_device *pdev)
> return ret;
> }
>
> + hdmi_codec_cea_init_channel_alloc();
> +
> dev_set_drvdata(dev, hcp);
> return 0;
> }
Regards
Takashi Sakamoto
gt; feature for the version N+1, is to propose patch from N-rc1 tag.
> (expecting that patch-set is enough mature to be integrated in N+1...)
It's a better way if you're aware of maintainers' work and your task
allows you to do things steadily.
Regards
Takashi Sakamoto
On Dec 9 2016 05:52, Takashi Sakamoto wrote:
> On Dec 9 2016 01:37, Arnaud Pouliquen wrote:
>> Aim of this patch is to add 'Playback Channel Map' control to export
>> audio capabilities in term of HDMI sink speakers allocation.
>> This patch follow discussion init
mostly on the end of development for 4.9 cycle, and review process
for new feature might be delay for next cycle, till 4.9 release, two
weeks later.
Regards
Takashi Sakamoto
13 matches
Mail list logo
