Re: linux-next: build failure after merge of the sound-asoc tree

Re: linux-next: build failure after merge of the sound-asoc tree

[Michael Ellerman]

Mark Brown <broonie@kernel.org> writes:
> On Tue, Mar 26, 2019 at 01:33:49PM +1100, Stephen Rothwell wrote:
>
>> After merging the sound-asoc tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>
>> sound/soc/codecs/tlv320aic32x4-clk.c: In function 'clk_aic32x4_pll_prepare':
>> include/linux/kernel.h:979:32: error: dereferencing pointer to incomplete type 'struct clk_hw'
>>   BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
>>                                 ^~~~~~
>
> 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?

cheers

Re: linux-next: build failure after merge of the sound-asoc tree

[Mark Brown]

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

On Wed, Mar 27, 2019 at 03:29:55PM +1100, Michael Ellerman wrote:
> Mark Brown <broonie@kernel.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.

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

Re: linux-next: build failure after merge of the sound-asoc tree

[Michael Ellerman]

Mark Brown <broonie@kernel.org> writes:
> On Wed, Mar 27, 2019 at 03:29:55PM +1100, Michael Ellerman wrote:
>> Mark Brown <broonie@kernel.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

Re: linux-next: build failure after merge of the sound-asoc tree

[Mark Brown]

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

On Mon, Apr 01, 2019 at 10:11:44PM +1100, Michael Ellerman wrote:

> 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.

It's probably fine for now for this one driver but it's going to cause
issues going forwards since we're trying to make the framework's clock
handling more standard.  

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