[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tvfiou8f.fsf@concordia.ellerman.id.au>
Date: Mon, 01 Apr 2019 22:11:44 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Mark Brown <broonie@...nel.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Liam Girdwood <lgirdwood@...il.com>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Annaliese McDermond <nh6z@...z.net>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>, linuxppc-dev@...abs.org
Subject: Re: linux-next: build failure after merge of the sound-asoc tree
Mark Brown <broonie@...nel.org> writes:
> On Wed, Mar 27, 2019 at 03:29:55PM +1100, Michael Ellerman wrote:
>> Mark Brown <broonie@...nel.org> writes:
>
>> > Hrm, seems PowerPC is still not using the common clock API - is there
>> > any plan for that? There are some ASoC PowerPC uses so it's going to be
>> > a bit of an issue as we expand our use of the clock API.
>
>> I don't know anything about the common clock API. What would it involve
>> for powerpc to use it?
>
> It's what's in drivers/clk - you'd have to provide clock drivers for all
> the clocks that are current supported by arch-specific code, make sure
> that those drivers can be instantiated and then remove the custom
> implementation of the clock API in arch/powerpc in favour of those.
OK. I realise we do have some support for the common clock API, but only
on certain sub-platforms (PPC_MPC512x, PPC_MPC52xx, PPC_E500MC).
On other platforms we have nothing at all AFAICS.
Seems Ben posted an RFC to support it in 2009, but nothing since:
http://patchwork.ozlabs.org/patch/31551/
Anyway I think what you've done in next, make the code depend on
COMMON_CLOCK, is the best option. If anyone cares about that driver on
powerpc platforms that don't support COMMON_CLOCK they should speak up.
cheers
Powered by blists - more mailing lists