All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaroslav Kysela <perex@perex.cz>
To: Sven Van Asbroeck <thesven73@gmail.com>, Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware'
Date: Wed, 6 Mar 2019 16:53:47 +0100	[thread overview]
Message-ID: <02af2c16-b5c2-d717-4997-1dbeac6edc39@perex.cz> (raw)
In-Reply-To: <CAGngYiWDO6YTTMGOFwpzQCOkxEr+AOz3ScDt748w_0UuUk+JLw@mail.gmail.com>

Dne 05. 03. 19 v 15:23 Sven Van Asbroeck napsal(a):
> Hi Takashi,
> 
> On Mon, Mar 4, 2019 at 11:42 PM Takashi Sakamoto
> <o-takashi@sakamocchi.jp> wrote:
>>
>> Anyway, when posting to change UAPI of Linux sound subsystem, it's
>> better to describe the reason fot new stuffs; what they're designed for,
>> and the reason to require them. Wnen posting in a result of series of
>> discussion done previously, it's better to add any reference to it.
> 
> My apologies for not linking in previous discussions, I'll certainly make
> sure to link in the future.
> 
> The original problem was that the fsl_ssi did not appear to work with the
> tda998x hdmi codec. This codec seems to be 'unique' in the sense that it
> needs to know the number of clocks per frame on the wire, i.e. the bclk_ratio,
> which no-one in alsa is providing or using at the moment.
> 
> I first made the error of conflating the physical width and the bclk_ratio,
> and posted this patch - Russell King quickly pointed out my error:
> https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/145916.html
> 
> This then led to the following discussions:
> https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/thread.html#145985
> https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/thread.html#145947
> 
> Most of the discussion is about a mechanism to convey bclk_ratio from
> the frame master
> to the tda998x. We don't yet seem to have a consensus on how to do this best.
> 
> My rfc patch was only intended to provoke discussion, and to allow
> people to experiment
> with a flawed solution that would allow the alsa core to negotiate
> bclk_ratio between
> components. The uapi change is a serious flaw. bclk_ratio negotiation should be
> invisible to userspace. But I cannot see a way to accomplish this.

I think that this might be resolved using double constraint rules in the
affected driver:

    snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT,
                        bclk_format_constraint, substream,
                                  SNDRV_PCM_HW_PARAM_CHANNELS, -1);
    snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
                        bclk_channels_constraint, substream,
                                  SNDRV_PCM_HW_PARAM_FORMAT, -1);

And refine the format bitmask / channel interval according your bclk
constraint. The physical sample width can be obtained in both
bclk_format_constraint / bclk_channels_constraint function so all input
values are known. The final bclk value can be obtained like in your
proposed code:

    params_channels(params) * params_width(params)

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

  reply	other threads:[~2019-03-06 15:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-04 16:59 [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware' Sven Van Asbroeck
2019-03-04 16:59 ` [RFC PATCH 2/4] ASoC: hdmi-codec: add support for bclk_ratio Sven Van Asbroeck
2019-03-04 16:59 ` [RFC PATCH 3/4] drm/i2c: tda998x: calculate CTS_N directly from the bclk_ratio Sven Van Asbroeck
2019-03-04 16:59 ` [RFC PATCH 4/4] ASoC: fsl_ssi: constrain bclk_ratio in i2s master mode Sven Van Asbroeck
2019-03-05  4:42 ` [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware' Takashi Sakamoto
2019-03-05  9:35   ` Russell King - ARM Linux admin
2019-03-05 14:23   ` Sven Van Asbroeck
2019-03-06 15:53     ` Jaroslav Kysela [this message]
2019-03-08  4:10     ` Takashi Sakamoto
2019-03-08 12:59       ` Russell King - ARM Linux admin
2019-03-08 13:37         ` Russell King - ARM Linux admin
2019-03-08 14:29         ` Takashi Sakamoto
2019-03-08 14:55           ` Russell King - ARM Linux admin
2019-03-08 17:22         ` Mark Brown
2019-03-08 19:54           ` Jaroslav Kysela
2019-03-08 20:07             ` Sven Van Asbroeck
2019-03-08 20:49               ` Pierre-Louis Bossart
2019-03-08 21:13                 ` Mark Brown
2019-03-08 21:54                   ` Pierre-Louis Bossart
2019-03-11  8:15             ` Takashi Sakamoto
2019-03-11 15:43               ` Jaroslav Kysela
2019-03-12 15:03                 ` Mark Brown
2019-03-13  5:57                   ` Takashi Sakamoto

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02af2c16-b5c2-d717-4997-1dbeac6edc39@perex.cz \
    --to=perex@perex.cz \
    --cc=alsa-devel@alsa-project.org \
    --cc=thesven73@gmail.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.