Re: [PATCH 0/2] Generic HDMI codec: Add channel mapping control

From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>,
	alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org
Cc: kernel@stlinux.com, lgirdwood@gmail.com,
	Jyri Sarha <jsarha@ti.com>,
	broonie@kernel.org, Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 0/2] Generic HDMI codec: Add channel mapping control
Date: Fri, 9 Dec 2016 06:13:24 +0900	[thread overview]
Message-ID: <ca1cfca3-3f2a-3935-536d-5d92cc4d0a67@sakamocchi.jp> (raw)
In-Reply-To: <f4d0e685-51f0-5831-e087-67d2ba276422@sakamocchi.jp>

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 initiates here:
>> [RFC] ASOC: HDMI audio info frame speaker allocation
>> http://www.spinics.net/lists/alsa-devel/msg57363.html
>>
>> The code is fully inspired from HDA driver.
>> On hw_param, HDMI sink speaker capabilities are exported via TLV ops
>> and  a CEA allocation is choson, based on ELD information and the
>> number of
>> channels requested by user.
>>
>> Mains differences with HDA implementation are:
>>  - Control is read only
>>  - Channel swap is not supported. Consequence is that unused channel in
>>    the mid of CEA audio infoframe channel mapping are considered as
>>    active.
>>    example for channel allocation 0x02: FL, FR, 0, FC)
>>     This configuration is only available for a 4 channels stream.
>>   - Channel allocation table has been reordered and HDMI 2.0 is not
>>     supported.
>>
>> Arnaud Pouliquen (2):
>>   DRM: add help to get ELD speaker allocation
>>   ASoC: hdmi-codec: add channel mapping control
>>
>>  include/drm/drm_edid.h        |  13 ++
>>  sound/soc/codecs/hdmi-codec.c | 346
>> +++++++++++++++++++++++++++++++++++++++++-
>>  2 files changed, 358 insertions(+), 1 deletion(-)
>
> Please pay enough attention to development cycle for Linux kernel.
>
> We're 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.

Oops. I was stupid just after awakening...

Anyway, we're mostly on the end of development for 4.10 cycle, and the 
review process for new feature might be delay till 4.10-rc1 release, two 
weeks later. During the weeks. bug fixes are preferable to be applied.

Regards

Takashi Sakamoto
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel