linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Arnaud Mouiche <arnaud.mouiche@invoxia.com>,
	broonie@kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, alsa-devel@alsa-project.org,
	tiwai@suse.com, perex@perex.cz, lgirdwood@gmail.com,
	fabio.estevam@nxp.com, timur@tabi.org, caleb@crome.org,
	max.krummenacher@toradex.com, mpa@pengutronix.de,
	mail@maciej.szmigiero.name
Subject: Re: [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number
Date: Sat, 25 Nov 2017 23:29:48 +0100	[thread overview]
Message-ID: <20171125232921.01994d72@jawa> (raw)
In-Reply-To: <20170913230147.GA21287@Asurada-Nvidia>

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

Hi Nicolin,

> On Wed, Sep 13, 2017 at 10:02:20AM +0200, Arnaud Mouiche wrote:
> 
> > >Could you please give me a few set of examples of how you set
> > >set_sysclk(), set_tdm_slot() with the current driver? The idea
> > >here is to figure out a way to calculate the bclk in hw_params
> > >without getting set_sysclk() involved any more.  
> 
> > Here is one, where a bclk = 4*16*fs is expected  
> 
> > In another setup, there are 8 x 16 bits slots, whatever the number
> > of active channels is.
> > In this case bclk = 128 * fs
> > The number of slots is completely arbitrary. Some slots can even be
> > reserved for communication between codecs that don't communicate
> > with linux.  
> 
> In summary, bclk = sample rate * slots * slot_width;
> 
> I will update my patch soon.
> 
> > >Unfortunately, it looks like a work around to me. I understand
> > >the idea of leaving set_sysclk() out there to override the bit
> > >clock is convenient, but it is not a standard ALSA design and
> > >may eventually introduce new problems like today.  
> > 
> > I agree. I'm not conservative at all concerning this question.
> > I don't see a way to remove set_sysclk without breaking current TDM
> > users anyway, at least for those who don't have their code
> > upstreamed.  
> 
> Which TDM case would be broken by this removal? The only impact
> that I can see is that the ASoC core returns an ENOTSUPP for a
> set_sysclk() call now, which is something that a dai-link driver
> should have taken care of anyway.
> 
> > All information provided through snd_soc_dai_set_tdm_slot( cpu_dai,
> > mask, mask, slots, width ) should be enough
> > In this case, for TDM users
> > 
> >    bclk = slots * width * fs   (where slots is != channels)  
> 
> > will manage 99 % of the cases.
> > And the remaining 1% will concern people who need to hack the kernel
> > so widely they don't care about the set_sysclk removal.  
> 
> A patch from those people will be always welcome.
> 
> > - fsl-asoc-card.c : *something will break since
> > snd_soc_dai_set_sysclk returned code is checked*  
> 
> I've already submitted a patch to ignore all ENOTSUPP.

Nicolin, do you know what happened with this patch? I couldn't find it
in current linux/master.

Has it been applied to any asoc tree for being upstreamed?

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2017-11-25 22:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-08  5:23 [PATCH] ASoC: fsl_ssi: Override bit clock rate based on slot number Nicolin Chen
2017-09-08  5:42 ` Nicolin Chen
2017-09-08  6:14   ` Arnaud Mouiche
2017-09-08  8:41   ` Łukasz Majewski
2017-09-12 14:35 ` Arnaud Mouiche
2017-09-12 21:32   ` Nicolin Chen
2017-09-13  8:02     ` Arnaud Mouiche
2017-09-13 23:01       ` Nicolin Chen
2017-11-25 22:29         ` Lukasz Majewski [this message]
2017-11-26  0:36           ` Nicolin Chen
2017-11-26 20:22             ` Lukasz Majewski

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=20171125232921.01994d72@jawa \
    --to=lukma@denx.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnaud.mouiche@invoxia.com \
    --cc=broonie@kernel.org \
    --cc=caleb@crome.org \
    --cc=fabio.estevam@nxp.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mail@maciej.szmigiero.name \
    --cc=max.krummenacher@toradex.com \
    --cc=mpa@pengutronix.de \
    --cc=nicoleotsuka@gmail.com \
    --cc=perex@perex.cz \
    --cc=timur@tabi.org \
    --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 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).