linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Help request - ASoC recursion issue
@ 2012-07-23 14:05 Lee Jones
  2012-07-23 14:39 ` Mark Brown
  2012-07-23 14:50 ` Lee Jones
  0 siblings, 2 replies; 7+ messages in thread
From: Lee Jones @ 2012-07-23 14:05 UTC (permalink / raw)
  To: Mark Brown; +Cc: Liam Girdwood, alsa-devel, linux-kernel, linux-arm-kernel

Hi Mark,

I was wondering if I may bother you for some help. I've been having 
serious issues with testing the new mop500 sound system you have in your 
ASoC for-next branch. I've fixed a few issues and will be submitting 
patches shortly. The most serious issue I came across was with 
recursion. Let me show you:

So here we setup the power_check function pointer with 
'dapm_supply_check_power()'.

> static struct snd_soc_dapm_widget *
> snd_soc_dapm_new_control(struct snd_soc_dapm_context *dapm,
> 			 const struct snd_soc_dapm_widget *widget)
> {
<snip>
> 	case snd_soc_dapm_regulator_supply:
> 	case snd_soc_dapm_clock_supply:
> 		w->power_check = dapm_supply_check_power;
> 		break;
<snip>
> }

Later we call 'dapm_widget_power_check()' which calls into the function 
pointer we know to be 'dapm_supply_check_power()'.

 > static int dapm_widget_power_check(struct snd_soc_dapm_widget *w)
 > {
 > 	if (w->power_checked)
 > 		return w->new_power;
 >
 > 	if (w->force)
 > 		w->new_power = 1;
 > 	else
 > 		w->new_power = w->power_check(w);
 >
 > 	w->power_checked = true;
 >
 > 	return w->new_power;
 > }

The problem seems to be that 'dapm_supply_check_power()' then calls back 
into 'dapm_widget_power_check()'. Then round and round we go!

> /* Check to see if a power supply is needed */
> static int dapm_supply_check_power(struct snd_soc_dapm_widget *w)
> {
<snip>
> 	/* Check if one of our outputs is connected */
> 	list_for_each_entry(path, &w->sinks, list_source) {
> 		DAPM_UPDATE_STAT(w, neighbour_checks);
>
> 		if (path->weak)
> 			continue;
>
> 		if (path->connected &&
> 		    !path->connected(path->source, path->sink))
> 			continue;
>
> 		if (!path->sink)
> 			continue;
>
> 		if (dapm_widget_power_check(path->sink))     /* <-- Doh! */
> 			return 1;
> 	}
<snip>
> }

Can you shed some light on what the correct solution might be?

Any help would be gratefully received.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Help request - ASoC recursion issue
  2012-07-23 14:05 Help request - ASoC recursion issue Lee Jones
@ 2012-07-23 14:39 ` Mark Brown
  2012-07-23 14:50 ` Lee Jones
  1 sibling, 0 replies; 7+ messages in thread
From: Mark Brown @ 2012-07-23 14:39 UTC (permalink / raw)
  To: Lee Jones; +Cc: Liam Girdwood, alsa-devel, linux-kernel, linux-arm-kernel

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

On Mon, Jul 23, 2012 at 03:05:19PM +0100, Lee Jones wrote:

> I was wondering if I may bother you for some help. I've been having
> serious issues with testing the new mop500 sound system you have in

You might want to CC some of the people who wrote that code...

> The problem seems to be that 'dapm_supply_check_power()' then calls
> back into 'dapm_widget_power_check()'. Then round and round we go!

Please describe what the problem you think you're seeing is, you've just
cut'n'pasted the code into your mail without describing any actual
problem in the system...

The tree walk is recursive so the fact that we call the same function
more than once isn't terribly surprising.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Help request - ASoC recursion issue
  2012-07-23 14:05 Help request - ASoC recursion issue Lee Jones
  2012-07-23 14:39 ` Mark Brown
@ 2012-07-23 14:50 ` Lee Jones
  2012-07-23 14:56   ` Lee Jones
  1 sibling, 1 reply; 7+ messages in thread
From: Lee Jones @ 2012-07-23 14:50 UTC (permalink / raw)
  To: Mark Brown; +Cc: Liam Girdwood, alsa-devel, linux-kernel, linux-arm-kernel

> I was wondering if I may bother you for some help. I've been having
> serious issues with testing the new mop500 sound system you have in your
> ASoC for-next branch. I've fixed a few issues and will be submitting
> patches shortly. The most serious issue I came across was with
> recursion.

It appears you can ignore this. I just tried another piece of hardware 
and this problem doesn't arise, leading me to believe I have some kind 
of eMMC corruption error going on with one of my boards.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Help request - ASoC recursion issue
  2012-07-23 14:50 ` Lee Jones
@ 2012-07-23 14:56   ` Lee Jones
  2012-07-23 18:12     ` Will Deacon
  0 siblings, 1 reply; 7+ messages in thread
From: Lee Jones @ 2012-07-23 14:56 UTC (permalink / raw)
  To: Mark Brown; +Cc: Liam Girdwood, alsa-devel, linux-kernel, linux-arm-kernel

On 23/07/12 15:50, Lee Jones wrote:
>> I was wondering if I may bother you for some help. I've been having
>> serious issues with testing the new mop500 sound system you have in your
>> ASoC for-next branch. I've fixed a few issues and will be submitting
>> patches shortly. The most serious issue I came across was with
>> recursion.
>
> It appears you can ignore this. I just tried another piece of hardware
> and this problem doesn't arise, leading me to believe I have some kind
> of eMMC corruption error going on with one of my boards.

FYI, just so you don't think I'm mad: http://paste.ubuntu.com/1106535/

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Help request - ASoC recursion issue
  2012-07-23 14:56   ` Lee Jones
@ 2012-07-23 18:12     ` Will Deacon
  2012-07-24  7:26       ` Lee Jones
  0 siblings, 1 reply; 7+ messages in thread
From: Will Deacon @ 2012-07-23 18:12 UTC (permalink / raw)
  To: Lee Jones
  Cc: Mark Brown, alsa-devel, Liam Girdwood, linux-arm-kernel, linux-kernel

On Mon, Jul 23, 2012 at 03:56:02PM +0100, Lee Jones wrote:
> On 23/07/12 15:50, Lee Jones wrote:
> >> I was wondering if I may bother you for some help. I've been having
> >> serious issues with testing the new mop500 sound system you have in your
> >> ASoC for-next branch. I've fixed a few issues and will be submitting
> >> patches shortly. The most serious issue I came across was with
> >> recursion.
> >
> > It appears you can ignore this. I just tried another piece of hardware
> > and this problem doesn't arise, leading me to believe I have some kind
> > of eMMC corruption error going on with one of my boards.
> 
> FYI, just so you don't think I'm mad: http://paste.ubuntu.com/1106535/

I still maintain that you're getting memory corruption as a result of your
linear mapping getting screwed up:

  Truncating RAM at 18000000-3fffffff to -2c3fffff (vmalloc region overlap).

looks wrong to me. Your command line also has some non-standard mem= options
that I don't understand:

  vmalloc=300M mem=128M@0 mali.mali_mem=64M@128M hwmem=168M@192M mem=22M@360M mem_issw=1M@383M mem=640M@384M

I'd guess you need highmem to map that lot, but you don't appear to have that
enabled and you end up with a rather strange amount of reported memory to go
with your lowmem mapping:

  Memory: 474156k/474156k available, 11220k reserved, 0K highmem
  Virtual kernel memory layout:
      vector  : 0xffff0000 - 0xffff1000   (   4 kB)
      fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
      vmalloc : 0xec800000 - 0xff000000   ( 296 MB)
      lowmem  : 0xc0000000 - 0xec400000   ( 708 MB)

Now, I don't know a thing about Snowball, so maybe this is all normal for
that board but if you're seeing memory corruption I'd get to the bottom of
this before trying to debug instances of it cropping up in random driver
code :)

Will

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Help request - ASoC recursion issue
  2012-07-23 18:12     ` Will Deacon
@ 2012-07-24  7:26       ` Lee Jones
  2012-07-24 22:46         ` Mark Brown
  0 siblings, 1 reply; 7+ messages in thread
From: Lee Jones @ 2012-07-24  7:26 UTC (permalink / raw)
  To: Will Deacon
  Cc: Mark Brown, alsa-devel, Liam Girdwood, linux-arm-kernel, linux-kernel

On 23/07/12 19:12, Will Deacon wrote:
> On Mon, Jul 23, 2012 at 03:56:02PM +0100, Lee Jones wrote:
>> On 23/07/12 15:50, Lee Jones wrote:
>>>> I was wondering if I may bother you for some help. I've been having
>>>> serious issues with testing the new mop500 sound system you have in your
>>>> ASoC for-next branch. I've fixed a few issues and will be submitting
>>>> patches shortly. The most serious issue I came across was with
>>>> recursion.
>>>
>>> It appears you can ignore this. I just tried another piece of hardware
>>> and this problem doesn't arise, leading me to believe I have some kind
>>> of eMMC corruption error going on with one of my boards.
>>
>> FYI, just so you don't think I'm mad: http://paste.ubuntu.com/1106535/
>
> I still maintain that you're getting memory corruption as a result of your
> linear mapping getting screwed up:
>
>    Truncating RAM at 18000000-3fffffff to -2c3fffff (vmalloc region overlap).
>
> looks wrong to me. Your command line also has some non-standard mem= options
> that I don't understand:

Yes, I am inclined to agree with you. I just thought it was 
uncharacteristic of a memory corruption error, as can reliably reproduce 
the bootlog above. What's even more strange is that the issue only 
arises on one of my two _identical_ development boards.

>    vmalloc=300M mem=128M@0 mali.mali_mem=64M@128M hwmem=168M@192M mem=22M@360M mem_issw=1M@383M mem=640M@384M
>
> I'd guess you need highmem to map that lot, but you don't appear to have that
> enabled and you end up with a rather strange amount of reported memory to go
> with your lowmem mapping:
>
>    Memory: 474156k/474156k available, 11220k reserved, 0K highmem
>    Virtual kernel memory layout:
>        vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>        fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>        vmalloc : 0xec800000 - 0xff000000   ( 296 MB)
>        lowmem  : 0xc0000000 - 0xec400000   ( 708 MB)

Enabling HIGHMEM is actually on my TODO list. We have it enabled in our 
release kernel, it's just on in Mainline yet. I'll bring it forward and 
make it the next think I do.

> Now, I don't know a thing about Snowball, so maybe this is all normal for
> that board but if you're seeing memory corruption I'd get to the bottom of
> this before trying to debug instances of it cropping up in random driver
> code :)

I don't have any allocated time to debug issues which only arise on 
Snowball. I'm just waiting on another piece of hardware, then I can 
start testing on the u9540. This issue will be the first thing I test for.

Thanks for your time chaps.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Help request - ASoC recursion issue
  2012-07-24  7:26       ` Lee Jones
@ 2012-07-24 22:46         ` Mark Brown
  0 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2012-07-24 22:46 UTC (permalink / raw)
  To: Lee Jones
  Cc: Will Deacon, alsa-devel, Liam Girdwood, linux-arm-kernel, linux-kernel

On Tue, Jul 24, 2012 at 08:26:36AM +0100, Lee Jones wrote:

> Yes, I am inclined to agree with you. I just thought it was  
> uncharacteristic of a memory corruption error, as can reliably reproduce  
> the bootlog above. What's even more strange is that the issue only  
> arises on one of my two _identical_ development boards.

It's not that unusual depending on where the cause is - for example,
copying an initialised struct to the wrong place, and things like the
DAPM graph which are big and pointer driven are often affected.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-07-24 22:46 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-23 14:05 Help request - ASoC recursion issue Lee Jones
2012-07-23 14:39 ` Mark Brown
2012-07-23 14:50 ` Lee Jones
2012-07-23 14:56   ` Lee Jones
2012-07-23 18:12     ` Will Deacon
2012-07-24  7:26       ` Lee Jones
2012-07-24 22:46         ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).