Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "clk_disable" [sound/soc/dwc/designware_i2s.ko] undefined!
ERROR: "clk_get" [sound/soc/dwc/designware_i2s.ko] undefined!
ERROR: "clk_enable" [sound/soc/dwc/designware_i2s.ko] undefined!
ERROR: "clk_put" [sound/soc/dwc/designware_i2s.ko] undefined!
Caused by commit 3a9cf8efd7b6 ("ASoC: Add support for synopsys i2s
controller as per ASoC framework"). According to the Kconfig in the
patch, this driver depends on nothing ...
I have used the sound-asoc tree from next-20120622 for today.
--
Cheers,
Stephen Rothwell [email protected]
Hi Stephen,
On 6/25/2012 9:41 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "clk_disable" [sound/soc/dwc/designware_i2s.ko] undefined!
> ERROR: "clk_get" [sound/soc/dwc/designware_i2s.ko] undefined!
> ERROR: "clk_enable" [sound/soc/dwc/designware_i2s.ko] undefined!
> ERROR: "clk_put" [sound/soc/dwc/designware_i2s.ko] undefined!
I have checked this on ARM platform where these definitions are
available (clk_get/clk_put* variants are usually used by ARM platforms).
To ensure compilation does not fail on x86_64 we can do either of three
things:
1. Protecting clk_get/clk_put* calls under macro 'CONFIG_HAVE_CLK' in
the driver.
2. Adding a check in Kconfig for HAVE_CLK.
(But that will limit the compilation of this driver for only platforms
which are ARM based/or similar).
3. We can pick the patches circulated by Viresh Kumar where we don't
have HAVE_CLK defined for x86_64, then the inline routines like
following should come into play:
static inline unsigned long clk_get_rate(struct clk *clk)
{
return 0;
}
See the patches for the same here:
http://lkml.org/lkml/2012/4/24/154
Please let me know your opinion.
Best Regards
Rajeev
On 25/06/12 07:09, Rajeev kumar wrote:
> 1. Protecting clk_get/clk_put* calls under macro 'CONFIG_HAVE_CLK' in
> the driver.
Not at all now.
> 2. Adding a check in Kconfig for HAVE_CLK.
> (But that will limit the compilation of this driver for only platforms
> which are ARM based/or similar).
Not actually required
> 3. We can pick the patches circulated by Viresh Kumar where we don't
> have HAVE_CLK defined for x86_64, then the inline routines like
> following should come into play:
That's the best. But probably Mark need to pull in AKPM's tree first into
sound-asoc tree. Mark?
--
Viresh
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Mon, Jun 25, 2012 at 11:39:30AM +0530, Rajeev kumar wrote:
> 3. We can pick the patches circulated by Viresh Kumar where we don't
> have HAVE_CLK defined for x86_64, then the inline routines like
> following should come into play:
This is what *should* be happening, in conjunction with architectures
doing the trivial work required to turn the clock API on now that there
is a generic clock API, but both of these things seem to be going
nowhere. I've applied a bodge until someone decides it's worth applying
the stubs.