RE: SRAM allocator(s!)

2009-05-26 Thread Tivy, Robert
@linux.davincidsp.com Subject: Re: SRAM allocator(s!) Troy Kisky wrote: Koen Kooi wrote: On 23-05-09 01:15, Ring, Chris wrote: New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) What's

Re: SRAM allocator(s!)

2009-05-24 Thread Koen Kooi
On 23-05-09 19:56, Troy Kisky wrote: Koen Kooi wrote: On 23-05-09 01:15, Ring, Chris wrote: New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) What's the plan for getting CMEM upstream?

Re: SRAM allocator(s!)

2009-05-24 Thread Vladimir Pantelic
Troy Kisky wrote: Koen Kooi wrote: On 23-05-09 01:15, Ring, Chris wrote: New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) What's the plan for getting CMEM upstream? I've been asking that

Re: SRAM allocator(s!)

2009-05-24 Thread Vladimir Pantelic
David Brownell wrote: If, on a DM355, the ASoC driver can't get SRAM, there's no point in continuing, since the dropout problems basically make audio unusable without it. Even on otherwise idle systems. (The same may be true on some dm6446 systems, although dropouts don't show up so readily

Re: SRAM allocator(s!)

2009-05-24 Thread Yusuf Caglar AKYUZ
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Pantelic wrote: David Brownell wrote: If, on a DM355, the ASoC driver can't get SRAM, there's no point in continuing, since the dropout problems basically make audio unusable without it. Even on otherwise idle systems. (The same may

Re: SRAM allocator(s!)

2009-05-24 Thread David Brownell
On Sunday 24 May 2009, Vladimir Pantelic wrote: David Brownell wrote: If, on a DM355, the ASoC driver can't get SRAM, there's no point in continuing, since the dropout problems basically make audio unusable without it. Even on otherwise idle systems. (The same may be true on some

Re: SRAM allocator(s!)

2009-05-23 Thread Troy Kisky
Koen Kooi wrote: On 23-05-09 01:15, Ring, Chris wrote: New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) What's the plan for getting CMEM upstream? I've been asking that question to TI

SRAM allocator(s!)

2009-05-22 Thread Ring, Chris
New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) when they're given this SRAM memory to manage to help catch collisions. CMEM added this recently too, so at least we'd get a nice error msg

Re: SRAM allocator(s!)

2009-05-22 Thread Troy Kisky
Ring, Chris wrote: New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) when they're given this SRAM memory to manage to help catch collisions. CMEM added this recently too, so at least

Re: SRAM allocator(s!)

2009-05-22 Thread David Brownell
On Friday 22 May 2009, Ring, Chris wrote: Assuming the SRAM allocator is pushed, can we talk through what happens when the audio driver (or any other driver!) requests this SRAM and either no SRAM is available, That's all driver-specific fault handling policy. If DaVinci gets power management

Re: SRAM allocator(s!)

2009-05-22 Thread Koen Kooi
On 23-05-09 01:15, Ring, Chris wrote: New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) What's the plan for getting CMEM upstream? I've been asking that question to TI engineers for a