All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Sune Brian <briansune@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sound/soc/codecs/wm8978: add missing BCLK divider setup
Date: Tue, 7 Oct 2025 14:15:19 +0100	[thread overview]
Message-ID: <aOUSZ2pnxRfxEPi4@opensource.cirrus.com> (raw)
In-Reply-To: <CAN7C2SBsFQJ2qNe0HLfpG+6cuONtpChBnq6fuFkd_CGkLt2c5g@mail.gmail.com>

On Tue, Oct 07, 2025 at 08:48:40PM +0800, Sune Brian wrote:
> Charles Keepax <ckeepax@opensource.cirrus.com> 於 2025年10月7日 週二 下午8:11寫道:
> > On Tue, Oct 07, 2025 at 07:22:10PM +0800, Sune Brian wrote:
> > > Charles Keepax <ckeepax@opensource.cirrus.com> 於 2025年10月7日 週二 下午6:30寫道:
> > > > On Fri, Oct 03, 2025 at 05:13:04PM +0800, Brian Sune wrote:
> > > > > The original WM8978 codec driver did not set the BCLK (bit clock)
> > Its not missing its right there. That said your way is probably
> > slightly more standard these days, but we should take care of the
> > interaction between the two.
> 
> What my missing meant is if run with DEBUG flag on that case had never
> behave as expected.
> MCLK and LRCLK both is correctly outputted. While the current
> unpatched version will generate
> wrong BCLK complete break the codec. As such I proposed the BCLK patch.
> I had not investigate deep why it never calls but the "int div" is
> loaded and computed by where is a bit puzzling.
> And the loaded it simply with div on actual mclk/2/bit_per_channel is
> also incorrect.
> As mentioned in previous explanations, the clock register is a fix
> table on dividing # that is a LUT with restricted # allowed.

Yeah the existing code expects the machine driver to call
snd_soc_dai_set_clkdiv. I am guessing you are using something
like simple card that doesn't do this.

To be clear the bulk of your patch is good, updating this in
hw_params is probably more normal these days. But we need to
make sure the two paths don't interfere with each other. Think
of a system that is already calling snd_soc_dai_set_clkdiv() to
set BCLKDIV, after your patch BCLKDIV will be set twice
potentially to two different values and would generate no error
messages.

I think you have two options:

1) Remove WM8978_BCLKDIV from wm8978_set_dai_clkdiv. There are no
   upstream users that I can see, so this should be fine. This
   would mean an out of tree user of snd_soc_dai_set_clkdiv would
   now get an error so they know they need to fix something.
2) Only run your dynamic BCLK code if wm8978_set_dai_clkdiv
   hasn't been called. This would mean any out of tree users of
   snd_soc_dai_set_clkdiv would have no problems everything would
   keep working as before, but at the cost of a little complexity
   in the code.

I am happy with either approach so which ever you prefer is fine
with me.

Thanks,
Charles

  reply	other threads:[~2025-10-07 13:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-03  9:13 [PATCH] sound/soc/codecs/wm8978: add missing BCLK divider setup Brian Sune
2025-10-07 10:30 ` Charles Keepax
2025-10-07 11:22   ` Sune Brian
2025-10-07 12:11     ` Charles Keepax
2025-10-07 12:18       ` Mark Brown
2025-10-07 12:26         ` Charles Keepax
2025-10-07 12:30           ` Mark Brown
2025-10-07 12:37             ` Sune Brian
2025-10-07 12:48       ` Sune Brian
2025-10-07 13:15         ` Charles Keepax [this message]
2025-10-07 13:39           ` Sune Brian
2025-10-07 13:48             ` Mark Brown
2025-10-07 13:54               ` Sune Brian
2025-10-07 11:33 ` [PATCH v2] ASoC: wm8978: " Brian Sune
2025-10-07 11:44   ` Mark Brown
2025-10-07 11:48     ` Sune Brian
2025-10-07 11:52       ` Mark Brown
2025-10-07 11:56         ` Sune Brian
2025-10-07 12:10           ` Mark Brown
2025-10-07 13:03             ` Sune Brian
2025-10-07 13:15               ` Mark Brown
2025-10-07 13:48                 ` Sune Brian

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=aOUSZ2pnxRfxEPi4@opensource.cirrus.com \
    --to=ckeepax@opensource.cirrus.com \
    --cc=briansune@gmail.com \
    --cc=broonie@kernel.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    /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.