LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Arnaud Pouliquen <email@example.com>
To: Takashi Iwai <firstname.lastname@example.org>
Cc: Mark Brown <email@example.com>,
Olivier MOYSAN <firstname.lastname@example.org>,
Alexandre TORGUE <email@example.com>,
Benjamin GAIGNARD <firstname.lastname@example.org>,
Subject: Re: [alsa-devel] [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
Date: Wed, 6 Jun 2018 11:31:45 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
On 06/05/2018 08:29 PM, Takashi Iwai wrote:
> On Tue, 05 Jun 2018 17:50:57 +0200,
> Arnaud Pouliquen wrote:
>> Hi Takashi,
>> On 04/17/2018 01:17 PM, Mark Brown wrote:
>> > On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
>> >> I guess the blocking patch in this patchset is the patch "add IEC958
>> >> channel status control helper". This patch has been reviewed several
>> >> times, but did not get a ack so far.
>> >> If you think these helpers will not be merged, I will reintegrate the
>> >> corresponding code in stm driver.
>> >> Please let me know, if I need to prepare a v2 without helpers, or if we
>> >> can go further in the review of iec helpers patch ?
>> > I don't mind either way but you're right here, I'm waiting for Takashi
>> > to review the first patch. I'd probably be OK with it just integrated
>> > into the driver if we have to go that way though.
>> Gentlemen reminder for this patch set. We would appreciate to have your
>> feedback on iec helper.
>> From our point of view it could be useful to have a generic management
>> of the iec controls based on helpers instead of redefining them in DAIs.
>> Having the same behavior for these controls could be useful to ensure
>> coherence of the control management used by application (for instance
>> Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
> Oh sorry for the late reply, I've totally overlooked the thread.
> And, another sorry: the patchset doesn't look convincing enough to
> First off, the provided API definition appears somewhat
> unconventional, the mixture of the ops, the static data and the
> dynamic data.
Sorry i can't figure out your point. I suppose that you speak about the
what would be a more conventional API?
> Moreover, this is only for your driver, ATM.
It is also compatible with the sound/sti driver, even if we does not
propose patch yet. We also plan to propose an implementation, for the
HDMI_codec that would need to export a control to allow none-audio mode.
>If it were an API that
> does clean up the already existing usages, I'd happily apply it. There
> are lots of drivers creating and controlling the IEC958 ctls even
> Also, the patchset requires more fine-tuning, in anyways. The changes
> in create_iec958_consumre() are basically irrelevant, should be split
> off as an individual fix. it is linked to the control, as not possible in existing implementation
(rate and width are get from hwparam or runtime). But no problem we can
split it in a separate patch.
Also, the new function doesn't create the
> "XXX Mask" controls. And the byte comparison should be replaced with
> memcmp(), etc, etc.
Yes mask are missing, can be added. For the rest could you comment
directly in code? i suppose that you want to replace the for loops by
> So, please proceed rather with the open codes for now. If you can
> provide a patch that cleans up the *multiple* driver codes, again,
> I'll happily take it. But it can be done anytime later, too.
Not simple to clean up the other drivers as this control is a PCM
control, that is mainly implemented as a mixer or card control.
This means that it should be registered on the pcm_new in CPU DAI or in
the DAI codec, to be able to bind it to the PCM device.
Inpact is not straigthforward as this could generate regression on driver.
For now We can add the clean up on the sti driver based on this helper,
and we are working on the HDMI_codec, we could also use this helper to
export the control....
So if you estimate that it is interesting to purchase on this helper we
can try to come back with a patch set that implements the helper for
the 3 drivers.
The other option, is that we drop the helpers, and implement the control
directly in our drivers.
Please just tell us if we should continue to propose the helpers or not.
next prev parent reply other threads:[~2018-06-06 9:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 16:27 Olivier Moysan
2018-03-13 16:27 ` [PATCH 1/3] ALSA: pcm: add IEC958 channel status control helper Olivier Moysan
2018-03-13 16:27 ` [PATCH 2/3] ASoC: stm32: sai: add iec958 controls support Olivier Moysan
2018-06-05 15:52 ` Arnaud Pouliquen
2018-03-13 16:27 ` [PATCH 3/3] ASoC: dmaengine_pcm: document process callback Olivier Moysan
2018-03-13 16:47 ` Applied "ASoC: dmaengine_pcm: document process callback" to the asoc tree Mark Brown
2018-04-17 8:29 ` [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls Olivier MOYSAN
2018-04-17 11:17 ` Mark Brown
2018-05-17 13:03 ` Olivier MOYSAN
2018-06-05 15:50 ` [alsa-devel] " Arnaud Pouliquen
2018-06-05 18:29 ` Takashi Iwai
2018-06-06 9:31 ` Arnaud Pouliquen [this message]
2018-06-06 9:47 ` Takashi Iwai
2018-06-07 16:02 ` Arnaud Pouliquen
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [alsa-devel] [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).