Am 2021-03-15 18:10, schrieb Sameer Pujar:
Yes this is a problem, unfortunately I missed checking some of the
simple-card examples. I wonder we should be specifically looking for
"mclk"
clock here.
That would definitely help mitigate the problem but I really think
it's
cleaner and safer to ju
Yes this is a problem, unfortunately I missed checking some of the
simple-card examples. I wonder we should be specifically looking for "mclk"
clock here.
That would definitely help mitigate the problem but I really think it's
cleaner and safer to just push this down to set_sysclk().
Understand
On 3/15/2021 9:03 PM, Michael Walle wrote:
Am 2021-03-15 16:19, schrieb Sameer Pujar:
On 3/15/2021 5:35 PM, Michael Walle wrote:
Am 2021-03-12 14:46, schrieb Mark Brown:
On Fri, Mar 12, 2021 at 01:30:02PM +0100, Michael Walle wrote:
The card calls set_sysclk(), which eventually ends up in
On Mon, Mar 15, 2021 at 08:49:00PM +0530, Sameer Pujar wrote:
> On 3/15/2021 5:35 PM, Michael Walle wrote:
> > Am 2021-03-12 14:46, schrieb Mark Brown:
> > Sameer, it looks like the proper fix should be to add the clock
> > support to your codec.
> I agree that complicated clock relationships sho
Am 2021-03-15 16:19, schrieb Sameer Pujar:
On 3/15/2021 5:35 PM, Michael Walle wrote:
External email: Use caution opening links or attachments
Am 2021-03-12 14:46, schrieb Mark Brown:
On Fri, Mar 12, 2021 at 01:30:02PM +0100, Michael Walle wrote:
The card calls set_sysclk(), which eventuall
On 3/15/2021 5:35 PM, Michael Walle wrote:
External email: Use caution opening links or attachments
Am 2021-03-12 14:46, schrieb Mark Brown:
On Fri, Mar 12, 2021 at 01:30:02PM +0100, Michael Walle wrote:
The card calls set_sysclk(), which eventually ends up in the codec.
The codec therefo
Am 2021-03-12 14:46, schrieb Mark Brown:
On Fri, Mar 12, 2021 at 01:30:02PM +0100, Michael Walle wrote:
The card calls set_sysclk(), which eventually ends up in the codec.
The codec therefore, could figure out if it needs to configure the
clock or if it can use its internal FLL.
Is that what yo
On Fri, Mar 12, 2021 at 01:30:02PM +0100, Michael Walle wrote:
> The card calls set_sysclk(), which eventually ends up in the codec.
> The codec therefore, could figure out if it needs to configure the
> clock or if it can use its internal FLL.
> Is that what you mean?
Yes.
> But the set_sysclk(
Am 2021-03-12 13:04, schrieb Mark Brown:
On Fri, Mar 12, 2021 at 01:01:41PM +0100, Michael Walle wrote:
Am 2021-03-12 12:35, schrieb Mark Brown:
> If the card has a clock API clock as sysclk then set_sysclk(() should
> be configuring that clock.
What do you mean by "the card". The simple-a
On Fri, Mar 12, 2021 at 01:01:41PM +0100, Michael Walle wrote:
> Am 2021-03-12 12:35, schrieb Mark Brown:
> > If the card has a clock API clock as sysclk then set_sysclk(() should
> > be configuring that clock.
> What do you mean by "the card". The simple-audio-card itself?
> Take a look at:
> h
Am 2021-03-12 12:35, schrieb Mark Brown:
On Thu, Mar 11, 2021 at 11:11:15PM +0100, Michael Walle wrote:
Am 2021-03-11 17:15, schrieb Mark Brown:
> The trick is figuring out if it's best to vary the input clock
> or to use the FLL to adapt a fixed input clock,
For simple-audio-card you can
On Thu, Mar 11, 2021 at 11:11:15PM +0100, Michael Walle wrote:
> Am 2021-03-11 17:15, schrieb Mark Brown:
> > The trick is figuring out if it's best to vary the input clock
> > or to use the FLL to adapt a fixed input clock,
> For simple-audio-card you can set the "clock" property if you want
> t
Am 2021-03-11 17:15, schrieb Mark Brown:
On Wed, Mar 10, 2021 at 08:20:28PM +0530, Sameer Pujar wrote:
If I read this correctly below is the configuration you need,
SoC -> MCLK(fixed rate) -> PLL(wm8904) -> PLL output (256 * fs) ->
sysclk
For this device for integration with something like s
Am 2021-03-11 17:00, schrieb Mark Brown:
On Tue, Mar 09, 2021 at 03:41:56PM +0100, Michael Walle wrote:
Hi,
> If "clocks = <&xxx>" is specified from the CPU or Codec component
> device node, the clock is not getting enabled. Thus audio playback
> or capture fails.
This actually breaks sound
On Thu, Mar 11, 2021 at 04:43:20PM +0100, Michael Walle wrote:
> This could be a last resort, yes. But I'd rather see a flag which
> indicates whether the simple-audio-card should control the (first)
> clock of the codec or not. Because until now, this wasn't the case.
> And I don't know if this w
On Wed, Mar 10, 2021 at 08:20:28PM +0530, Sameer Pujar wrote:
> If I read this correctly below is the configuration you need,
> SoC -> MCLK(fixed rate) -> PLL(wm8904) -> PLL output (256 * fs) -> sysclk
For this device for integration with something like simple-audio-card
since there's limited fle
On Tue, Mar 09, 2021 at 03:41:56PM +0100, Michael Walle wrote:
> Hi,
>
> > If "clocks = <&xxx>" is specified from the CPU or Codec component
> > device node, the clock is not getting enabled. Thus audio playback
> > or capture fails.
> This actually breaks sound on my board
> (arch/arm64/boot/dts
Am 2021-03-11 15:29, schrieb Sameer Pujar:
On 3/11/2021 4:46 PM, Michael Walle wrote:
Am 2021-03-11 12:05, schrieb Sameer Pujar:
It would work and initially I had similar patch, see [0] and related
series. Suggestion is to always use "clocks" property with devices
only.
I see. But again, I d
On 3/11/2021 4:46 PM, Michael Walle wrote:
Am 2021-03-11 12:05, schrieb Sameer Pujar:
It would work and initially I had similar patch, see [0] and related
series. Suggestion is to always use "clocks" property with devices
only.
I see. But again, I don't think it is correct to change the cl
Am 2021-03-11 12:05, schrieb Sameer Pujar:
It would work and initially I had similar patch, see [0] and related
series. Suggestion is to always use "clocks" property with devices
only.
I see. But again, I don't think it is correct to change the clock of
the codec by default. What happens if th
On 3/11/2021 3:57 PM, Michael Walle wrote:
I've had a closer look at this and it seems you're messing around
with the clock of the codec's node (which is _not_ a subnode of
the simple-audio-card). I don't think this is correct.
I guess you should rather set the clock property in the codec
sub
Hi Sameer,
Am 2021-03-10 15:50, schrieb Sameer Pujar:
On 3/10/2021 4:00 AM, Michael Walle wrote:
Am 2021-03-09 17:27, schrieb Sameer Pujar:
On 3/9/2021 8:11 PM, Michael Walle wrote:
If "clocks = <&xxx>" is specified from the CPU or Codec component
device node, the clock is not getting enabled
On 3/10/2021 11:44 PM, Michael Walle wrote:
Btw I'm pretty sure, the MCLK was enabled and disabled depending on
whether there was an audio stream, the last time I've measured the
clock.
This may be true in your case because wm8904 driver does an explicit
clock enable/disable and does not r
Hi Sameer, Hi Mark,
Am 2021-03-10 15:50, schrieb Sameer Pujar:
On 3/10/2021 4:00 AM, Michael Walle wrote:
Am 2021-03-09 17:27, schrieb Sameer Pujar:
On 3/9/2021 8:11 PM, Michael Walle wrote:
If "clocks = <&xxx>" is specified from the CPU or Codec component
device node, the clock is not gettin
On 3/10/2021 4:00 AM, Michael Walle wrote:
Am 2021-03-09 17:27, schrieb Sameer Pujar:
On 3/9/2021 8:11 PM, Michael Walle wrote:
If "clocks = <&xxx>" is specified from the CPU or Codec component
device node, the clock is not getting enabled. Thus audio playback
or capture fails.
Fix this by
Hi Sameer,
Am 2021-03-09 17:27, schrieb Sameer Pujar:
On 3/9/2021 8:11 PM, Michael Walle wrote:
If "clocks = <&xxx>" is specified from the CPU or Codec component
device node, the clock is not getting enabled. Thus audio playback
or capture fails.
Fix this by populating "simple_dai->clk" field
Hi Michael,
On 3/9/2021 8:11 PM, Michael Walle wrote:
External email: Use caution opening links or attachments
Hi,
If "clocks = <&xxx>" is specified from the CPU or Codec component
device node, the clock is not getting enabled. Thus audio playback
or capture fails.
Fix this by populating "s
Hi,
> If "clocks = <&xxx>" is specified from the CPU or Codec component
> device node, the clock is not getting enabled. Thus audio playback
> or capture fails.
>
> Fix this by populating "simple_dai->clk" field when clocks property
> is specified from device node as well. Also tidy up by re-orga
Hi Sameer
> > /*
> > * Parse dai->sysclk come from "clocks = <&xxx>"
> > * (if system has common clock)
> > * or "system-clock-frequency = "
> > * or device's module clock.
> > */
>
> Yes, this can be rephrased now.
Thanks.
It is not
Hi Morimoto-san,
On 2/12/2021 5:14 AM, Kuninori Morimoto wrote:
diff --git a/sound/soc/generic/simple-card-utils.c
b/sound/soc/generic/simple-card-utils.c
index bc0b62e..0754d70 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -173,16 +173,15 @@
Hi Sameer
> diff --git a/sound/soc/generic/simple-card-utils.c
> b/sound/soc/generic/simple-card-utils.c
> index bc0b62e..0754d70 100644
> --- a/sound/soc/generic/simple-card-utils.c
> +++ b/sound/soc/generic/simple-card-utils.c
> @@ -173,16 +173,15 @@ int asoc_simple_parse_clk(struct device *d
If "clocks = <&xxx>" is specified from the CPU or Codec component
device node, the clock is not getting enabled. Thus audio playback
or capture fails.
Fix this by populating "simple_dai->clk" field when clocks property
is specified from device node as well. Also tidy up by re-organising
conditiona
32 matches
Mail list logo
