[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231018082142.5b7d3ad5@aktux>
Date: Wed, 18 Oct 2023 08:21:42 +0200
From: Andreas Kemnade <andreas@...nade.info>
To: Tony Lindgren <tony@...mide.com>
Cc: Péter Ujfalusi <peter.ujfalusi@...il.com>,
bcousson@...libre.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
lgirdwood@...il.com, broonie@...nel.org, perex@...ex.cz,
tiwai@...e.com, jarkko.nikula@...mer.com,
dmitry.torokhov@...il.com, linux-omap@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
alsa-devel@...a-project.org
Subject: Re: [PATCH 1/3] ASoC: ti: omap-mcbsp: Ignore errors for getting
fck_src
On Wed, 18 Oct 2023 08:23:45 +0300
Tony Lindgren <tony@...mide.com> wrote:
> * Andreas Kemnade <andreas@...nade.info> [231015 21:48]:
> > On Sat, 7 Oct 2023 09:25:18 +0300
> > Tony Lindgren <tony@...mide.com> wrote:
> > > If so then the following might be a fix, not familiar with runtime PM
> > > done by ASoC though and not sure if some kind of locking would be
> > > needed here.
> > >
> > just checked: that one fixes the regression. runtime suspends again.
>
> OK good to hear. So is there some fixes tag for this one or where did this
> start happening? I'm not quite following how the dropping of platform data
> could have affected this, maybe it just hid the problem because of
> returning early?
>
yes I think so. From a perspective of OMAP[45] mith McBSP in master mode,
applying "clk: ti: Fix missing omap4 mcbsp functional clock and aliases"
on top of "ASoC: ti: omap-mcbsp: Ignore errors for getting fck_src"
is a regression. For everyone else not. So
"clk: ti: Fix missing omap4 mcbsp functional clock and aliases"
did uncover a hidden problem, but of course it is the right step
forward.
Regards
Andreas
Powered by blists - more mailing lists