buffer producer/consumer sync

buffer producer/consumer sync

[Gupta, Kshitij]

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


> hi ,
> 	While debugging my alsa driver , some observations...
> 
> The flow goes like this
> 
> - cat  test.raw > /dev/pcm
> - Middle layer fills up the buffer (size = period_size).   Why does middle
> layer only fills up period_size ??????
> - ...(open / init etc)
> - Trigger with PLAY command is called
> 	a) audio_dma_process routine is called
> 		This routine starts a dma transfer for a size of period_size
> 	
> 	b) We get a end of transfer interrupt and our callback is called.
> In the callback function we call snd_pcm_period_elapsed to notify that one
> period is finished.  This function causes Trigger to be called again with
> STOP and then START again.  And the reason which I found after much
> debugging is this  :
> 		
> --------------------------------------------------------------------------
> ------------------------------------------------
> 	 if (avail >= runtime->stop_threshold) {
>                 snd_pcm_stop(substream,
>                              runtime->status->state ==
> SNDRV_PCM_STATE_DRAINING ?
>                              SNDRV_PCM_STATE_SETUP :
> SNDRV_PCM_STATE_XRUN);
> 
> this code is a part of snd_pcm_update_hw_ptr_post function in
> sound/core/pcm_lib.c
> --------------------------------------------------------------------------
> ------------------------------------------------
> 
> avail value is coming equal to runtime->stop_threshold and that is why we
> are getting a stop.  A trace of these values is :
> 
> initially 
> 	hw_ptr = 0	appl_ptr = period_size		avail =
> runtime->buffersize    	stop_threshold = runtime->buffersize
> (this is set by default)
> 
> after one DMA transfer 
> 	hw_ptr = period_size	appl_ptr = period_size(still the same value
> ... middle layer should have filled in more data and updated this )
> 	
> 	avail = hw_ptr + runtime->buffersize  - appl_ptr
> 
> 	so again avail = runtime->buffersize  , since hw_ptr is equal to
> appl_ptr.  
> 
> What we analyzed here is that After the DMA transfer starts and before the
> finish of the DMA transfer the alsa middle layer should fill up data from
> application layer (cat command in this context).   So probably DMA
> transfer is happening at a much faster rate than the middle layer can fill
> up more application buffers. 
> 
> Can someone comment on this and guide a little bit to solve this problem.
> 
> warm regards
> -kshitij

[-- Attachment #2: Type: text/html, Size: 4882 bytes --]

Re: buffer producer/consumer sync

[Jaroslav Kysela]

On Tue, 9 Mar 2004, Gupta, Kshitij wrote:

> > Can someone comment on this and guide a little bit to solve this problem.

Yes, on ARM platform you might have problem with MMU / cache coherency, 
because appl_ptr and hw_ptr are mmaped to user space. I observed this 
behaviour on SA11xx platform, too.

Russell King already notified us about this problem. See the mail archive 
for the proper fix of the midlevel code.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote:
> On Tue, 9 Mar 2004, Gupta, Kshitij wrote:
> > > Can someone comment on this and guide a little bit to solve this problem.
> 
> Yes, on ARM platform you might have problem with MMU / cache coherency, 
> because appl_ptr and hw_ptr are mmaped to user space. I observed this 
> behaviour on SA11xx platform, too.
> 
> Russell King already notified us about this problem. See the mail archive 
> for the proper fix of the midlevel code.

There currently doesn't exist a public fix for this yet, so people using
ARM platforms will have to live without ALSA for the time being.
(Actually, you can still use ALSA but you must use OSS PCM emulation.)

As you say, appl_ptr and hw_ptr have cache coherency problems.  However,
a portable and acceptable solution does not exist today to solve this
problem which would be acceptable to ALSA.  The current preferred
solution is to call flush_dcache_page() on the page whenever the kernel
reads and writes such a page - obviously that is too expensive for ALSA.

Therefore, kernel architecture people need to trash this issue out, but
I'm only interested in doing that post-2.6.4, once we've managed to get
the DMA mapping stuff sorted properly.

Unfortunately I'm busy for the next three days with other stuff, so I
won't be able to look at any of this; I doubt 2.6.4 will be out before
Friday morning anyway.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Jaroslav Kysela]

On Tue, 9 Mar 2004, Russell King wrote:

> On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote:
> > On Tue, 9 Mar 2004, Gupta, Kshitij wrote:
> > > > Can someone comment on this and guide a little bit to solve this problem.
> > 
> > Yes, on ARM platform you might have problem with MMU / cache coherency, 
> > because appl_ptr and hw_ptr are mmaped to user space. I observed this 
> > behaviour on SA11xx platform, too.
> > 
> > Russell King already notified us about this problem. See the mail archive 
> > for the proper fix of the midlevel code.
> 
> There currently doesn't exist a public fix for this yet, so people using
> ARM platforms will have to live without ALSA for the time being.
> (Actually, you can still use ALSA but you must use OSS PCM emulation.)

Ok, I though that vma->vm_page_prot fix is sufficient for this purpose but 
appearently not.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

RE: buffer producer/consumer sync

[Gupta, Kshitij]

hi,
	Just for your information we are using OSS PCM emulation.  And let
me also first understand the problem :).  Which I am not able to figure out
yet :(. 
regards
-kshitij

-----Original Message-----
From: Russell King [mailto:rmk@arm.linux.org.uk]On Behalf Of Russell
King
Sent: Tuesday, March 09, 2004 3:48 PM
To: Jaroslav Kysela
Cc: Gupta, Kshitij; alsa-devel@lists.sourceforge.net
Subject: Re: [Alsa-devel] buffer producer/consumer sync


On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote:
> On Tue, 9 Mar 2004, Gupta, Kshitij wrote:
> > > Can someone comment on this and guide a little bit to solve this
problem.
> 
> Yes, on ARM platform you might have problem with MMU / cache coherency, 
> because appl_ptr and hw_ptr are mmaped to user space. I observed this 
> behaviour on SA11xx platform, too.
> 
> Russell King already notified us about this problem. See the mail archive 
> for the proper fix of the midlevel code.

There currently doesn't exist a public fix for this yet, so people using
ARM platforms will have to live without ALSA for the time being.
(Actually, you can still use ALSA but you must use OSS PCM emulation.)

As you say, appl_ptr and hw_ptr have cache coherency problems.  However,
a portable and acceptable solution does not exist today to solve this
problem which would be acceptable to ALSA.  The current preferred
solution is to call flush_dcache_page() on the page whenever the kernel
reads and writes such a page - obviously that is too expensive for ALSA.

Therefore, kernel architecture people need to trash this issue out, but
I'm only interested in doing that post-2.6.4, once we've managed to get
the DMA mapping stuff sorted properly.

Unfortunately I'm busy for the next three days with other stuff, so I
won't be able to look at any of this; I doubt 2.6.4 will be out before
Friday morning anyway.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Tue, Mar 09, 2004 at 11:23:45AM +0100, Jaroslav Kysela wrote:
> Ok, I though that vma->vm_page_prot fix is sufficient for this purpose but 
> appearently not.

Unfortunately not - as the code currently stands, not only are
userspace mappings cached, but also kernel mappings of the same pages.
Unfortunately changing userspace mappings to be uncached only solves
half the problem.  We also need to solve the kernel space problem as
well.  However, this needs to be done in an architecture specific way,
which in turn means sorting out something which architecture people
are happy with.

Then there's the issue about the abuse of virt_to_page() taking a
mapped virtual address (ie from pci_alloc_consistent or
dma_alloc_coherent) rather than a direct-mapped virtual address
(alloc_pages / kmalloc).

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

RE: buffer producer/consumer sync

[Gupta, Kshitij]

hi,
	I was referring to a ARM implementation in the ALSA tree for our
ALSA driver development on OMAP 1610 (ARM 926)
sound\arm\sa11xx-uda1341.c.  Just wanted to know if sa11xx-uda1341.c is also
affected by this problem.  
regards
-kshitij

-----Original Message-----
From: alsa-devel-admin@lists.sourceforge.net
[mailto:alsa-devel-admin@lists.sourceforge.net]On Behalf Of Gupta,
Kshitij
Sent: Tuesday, March 09, 2004 4:11 PM
To: 'Russell King'; Jaroslav Kysela
Cc: alsa-devel@lists.sourceforge.net
Subject: RE: [Alsa-devel] buffer producer/consumer sync


hi,
	Just for your information we are using OSS PCM emulation.  And let
me also first understand the problem :).  Which I am not able to figure out
yet :(. 
regards
-kshitij

-----Original Message-----
From: Russell King [mailto:rmk@arm.linux.org.uk]On Behalf Of Russell
King
Sent: Tuesday, March 09, 2004 3:48 PM
To: Jaroslav Kysela
Cc: Gupta, Kshitij; alsa-devel@lists.sourceforge.net
Subject: Re: [Alsa-devel] buffer producer/consumer sync


On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote:
> On Tue, 9 Mar 2004, Gupta, Kshitij wrote:
> > > Can someone comment on this and guide a little bit to solve this
problem.
> 
> Yes, on ARM platform you might have problem with MMU / cache coherency, 
> because appl_ptr and hw_ptr are mmaped to user space. I observed this 
> behaviour on SA11xx platform, too.
> 
> Russell King already notified us about this problem. See the mail archive 
> for the proper fix of the midlevel code.

There currently doesn't exist a public fix for this yet, so people using
ARM platforms will have to live without ALSA for the time being.
(Actually, you can still use ALSA but you must use OSS PCM emulation.)

As you say, appl_ptr and hw_ptr have cache coherency problems.  However,
a portable and acceptable solution does not exist today to solve this
problem which would be acceptable to ALSA.  The current preferred
solution is to call flush_dcache_page() on the page whenever the kernel
reads and writes such a page - obviously that is too expensive for ALSA.

Therefore, kernel architecture people need to trash this issue out, but
I'm only interested in doing that post-2.6.4, once we've managed to get
the DMA mapping stuff sorted properly.

Unfortunately I'm busy for the next three days with other stuff, so I
won't be able to look at any of this; I doubt 2.6.4 will be out before
Friday morning anyway.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Tue, Mar 09, 2004 at 05:03:37PM +0530, Gupta, Kshitij wrote:
> 	I was referring to a ARM implementation in the ALSA tree for our
> ALSA driver development on OMAP 1610 (ARM 926)
> sound\arm\sa11xx-uda1341.c.  Just wanted to know if sa11xx-uda1341.c is also
> affected by this problem.  

sa11xx-uda1341 isn't a good driver to look at - it's very specific to
the iPAQ as it stands.  I've been working on a properly modularised
driver which separates out the PCM DMA engine from the rest of the
code, which in turn makes it a lot easier to add support for different
platforms.  IOW, I've done the job properly.

However, just as the iPAQ people (didn't) work with the rest of the
ARM community when they created their supposed generic sa11xx-uda1341
implementation, the rest of the ARM community didn't work with them
when creating our driver.  And now various people are calling for
sa11xx-uda1341 to be deleted once my driver is merged.  It's good when
communities fragment, isn't it? 8(

However, the problem I've been describing is a problem with the core
ALSA implementation and affects all hardware drivers on ARM, whether
they be PCI, ISA or ARM specific.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

RE: buffer producer/consumer sync

[Gupta, Kshitij]

hi,
	I was just curious to know about by when will we be having a proper
reference driver for ARM .  We are ready to help out from here if there are
any issues.
warm regards
-kshitij

-----Original Message-----
From: Russell King [mailto:rmk@arm.linux.org.uk]On Behalf Of Russell
King
Sent: Tuesday, March 09, 2004 5:17 PM
To: Gupta, Kshitij
Cc: Jaroslav Kysela; alsa-devel@lists.sourceforge.net
Subject: Re: [Alsa-devel] buffer producer/consumer sync


On Tue, Mar 09, 2004 at 05:03:37PM +0530, Gupta, Kshitij wrote:
> 	I was referring to a ARM implementation in the ALSA tree for our
> ALSA driver development on OMAP 1610 (ARM 926)
> sound\arm\sa11xx-uda1341.c.  Just wanted to know if sa11xx-uda1341.c is
also
> affected by this problem.  

sa11xx-uda1341 isn't a good driver to look at - it's very specific to
the iPAQ as it stands.  I've been working on a properly modularised
driver which separates out the PCM DMA engine from the rest of the
code, which in turn makes it a lot easier to add support for different
platforms.  IOW, I've done the job properly.

However, just as the iPAQ people (didn't) work with the rest of the
ARM community when they created their supposed generic sa11xx-uda1341
implementation, the rest of the ARM community didn't work with them
when creating our driver.  And now various people are calling for
sa11xx-uda1341 to be deleted once my driver is merged.  It's good when
communities fragment, isn't it? 8(

However, the problem I've been describing is a problem with the core
ALSA implementation and affects all hardware drivers on ARM, whether
they be PCI, ISA or ARM specific.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Wed, Mar 31, 2004 at 10:32:07AM +0530, Gupta, Kshitij wrote:
> 	I was just curious to know about by when will we be having a proper
> reference driver for ARM .  We are ready to help out from here if there are
> any issues.

Given the kernel communities general negative reaction to trying to sort
out these problems, I've decided that its not worth me spending my time
fixing the core ALSA code any longer.

Therefore, expect ALSA to be non-functional on ARM for at least the 2.6
kernel series.

Sorry, but that's the way it is.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Jaroslav Kysela]

On Wed, 31 Mar 2004, Russell King wrote:

> On Wed, Mar 31, 2004 at 10:32:07AM +0530, Gupta, Kshitij wrote:
> > 	I was just curious to know about by when will we be having a proper
> > reference driver for ARM .  We are ready to help out from here if there are
> > any issues.
> 
> Given the kernel communities general negative reaction to trying to sort
> out these problems,

I think that the consensus was that using "->nopage" callback does not
make much sense for the DMA pages so remap_page_coherent_range() should be
used for this case when designed. Is not that true? We are ready to change
the ALSA core ourself, but we need this API on the kernel core side.

I also don't mind to include some hacks in our midlevel code to let the 
ARM platform working.

> I've decided that its not worth me spending my time fixing the core ALSA
> code any longer.

:-(

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Wed, Mar 31, 2004 at 09:44:45AM +0200, Jaroslav Kysela wrote:
> I think that the consensus was that using "->nopage" callback does not
> make much sense for the DMA pages so remap_page_coherent_range() should be
> used for this case when designed.

The consensus was that ->nopage is fine to use IFF you have RAM-backed
pages.  However, the choice of whether ->nopage is used or not is one
that the architecture must make, and not the device driver.

This requires a dma_mmap_coherent() API for all architectures to
implement.  However, I can not get anyone to even respond to agreeing
what the API requires.

It's no good one architecture implementing one version of the API and
others then deciding that they don't actually like it after all and
needing a different API.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Jaroslav Kysela]

On Wed, 31 Mar 2004, Russell King wrote:

> On Wed, Mar 31, 2004 at 09:44:45AM +0200, Jaroslav Kysela wrote:
> > I think that the consensus was that using "->nopage" callback does not
> > make much sense for the DMA pages so remap_page_coherent_range() should be
> > used for this case when designed.
> 
> The consensus was that ->nopage is fine to use IFF you have RAM-backed
> pages.  However, the choice of whether ->nopage is used or not is one
> that the architecture must make, and not the device driver.
> 
> This requires a dma_mmap_coherent() API for all architectures to
> implement.  However, I can not get anyone to even respond to agreeing
> what the API requires.
> 
> It's no good one architecture implementing one version of the API and
> others then deciding that they don't actually like it after all and
> needing a different API.

Yes, but if we have at least one API solving this problem, the successors 
should replace it completely. I think that it's much better solution than
having no way to support ARM or any other platforms with these problems in 
ALSA. If you come with a solution, then people not agreeing with you
have to propose/implement a better solution.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Wed, Mar 31, 2004 at 10:10:22AM +0200, Jaroslav Kysela wrote:
> Yes, but if we have at least one API solving this problem, the successors 
> should replace it completely. I think that it's much better solution than
> having no way to support ARM or any other platforms with these problems in 
> ALSA. If you come with a solution, then people not agreeing with you
> have to propose/implement a better solution.

Keeping the existing ->nopage will not work - there is no way to get to
a struct page on ARM given the information available to the ALSA code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Jaroslav Kysela]

On Wed, 31 Mar 2004, Russell King wrote:

> On Wed, Mar 31, 2004 at 10:10:22AM +0200, Jaroslav Kysela wrote:
> > Yes, but if we have at least one API solving this problem, the successors 
> > should replace it completely. I think that it's much better solution than
> > having no way to support ARM or any other platforms with these problems in 
> > ALSA. If you come with a solution, then people not agreeing with you
> > have to propose/implement a better solution.
> 
> Keeping the existing ->nopage will not work - there is no way to get to
> a struct page on ARM given the information available to the ALSA code.

Looking to arch/arm/mm/consistent.c - vm_region_find / pfn_to_page?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Wed, Mar 31, 2004 at 10:29:06AM +0200, Jaroslav Kysela wrote:
> On Wed, 31 Mar 2004, Russell King wrote:
> > Keeping the existing ->nopage will not work - there is no way to get to
> > a struct page on ARM given the information available to the ALSA code.
> 
> Looking to arch/arm/mm/consistent.c - vm_region_find / pfn_to_page?

No - we don't have a pfn to start with, and I'm not implementing an
interface which returns a struct page because, as was agreed on
linux-arch, such an interface is completely wrong.

The correct interface is dma_mmap_coherent().

I'm actually tempted to provide dma_mmap_coherent() and just let
everyone else whinge and moan that the API doesn't meet their
expectations.

BTW, ARM also needs the mark_pages and unmark_pages functions commented
out since they're also trying to use virt_to_page() on virtual addresses
that this function is not supposed to - except for the ISA DMA case
(and yes, we have ISA DMA-based sound cards as well.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Jaroslav Kysela]

On Wed, 31 Mar 2004, Russell King wrote:

> The correct interface is dma_mmap_coherent().
> 
> I'm actually tempted to provide dma_mmap_coherent() and just let
> everyone else whinge and moan that the API doesn't meet their
> expectations.

Thanks. Evolution is the best way.

> BTW, ARM also needs the mark_pages and unmark_pages functions commented
> out since they're also trying to use virt_to_page() on virtual addresses
> that this function is not supposed to - except for the ISA DMA case
> (and yes, we have ISA DMA-based sound cards as well.)

It's another inconsistency. We need to mark these pages for the x86 
architecture, because dma_alloc_coherent does not do this for us.

Do you see any reason to ommit this settings for some cases (including 
for ISA bus)? I think that dma_alloc_coherent should offer consistent
API - thus mark all allocated pages as reserved for all cases.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Wed, Mar 31, 2004 at 11:07:03AM +0200, Jaroslav Kysela wrote:
> Do you see any reason to ommit this settings for some cases (including 
> for ISA bus)? I think that dma_alloc_coherent should offer consistent
> API - thus mark all allocated pages as reserved for all cases.

That was another point I was trying to get resolved, but no one is
willing to provide an answer.

It's at times like this that you really start to wonder whether the
open source development model is really capable of working.

I suggest we add a load of preprocessor junk into the ALSA core and
comment exactly _why_ its needed, thereby laying the reason completely
at the door of these ill-defined APIs where questions have been asked
and responses not been received.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Jaroslav Kysela]

On Wed, 31 Mar 2004, Russell King wrote:

> I suggest we add a load of preprocessor junk into the ALSA core and
> comment exactly _why_ its needed, thereby laying the reason completely
> at the door of these ill-defined APIs where questions have been asked
> and responses not been received.

I'm thinking to prepare more or less complete patch for all 
architectures and send it to LKML for a discussion.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[Russell King]

On Wed, Mar 31, 2004 at 11:22:56AM +0200, Jaroslav Kysela wrote:
> On Wed, 31 Mar 2004, Russell King wrote:
> 
> > I suggest we add a load of preprocessor junk into the ALSA core and
> > comment exactly _why_ its needed, thereby laying the reason completely
> > at the door of these ill-defined APIs where questions have been asked
> > and responses not been received.
> 
> I'm thinking to prepare more or less complete patch for all 
> architectures and send it to LKML for a discussion.

The problem is that not all architecture maintainers are on lkml.

Besides, I've tried talking to the architecture maintainers - their
complete silence since two weeks ago indicates that they just don't
want to know about this issue.

As I said on the architecture alias - I've put enough non-rewarding
time into this issue.  I also have various commercial deadlines
coming up, so I couldn't work on it even if I wanted to.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: buffer producer/consumer sync

[James Courtier-Dutton]

Russell King wrote:
> On Wed, Mar 31, 2004 at 11:22:56AM +0200, Jaroslav Kysela wrote:
> 
>>On Wed, 31 Mar 2004, Russell King wrote:
>>
>>
>>>I suggest we add a load of preprocessor junk into the ALSA core and
>>>comment exactly _why_ its needed, thereby laying the reason completely
>>>at the door of these ill-defined APIs where questions have been asked
>>>and responses not been received.
>>
>>I'm thinking to prepare more or less complete patch for all 
>>architectures and send it to LKML for a discussion.
> 
> 
> The problem is that not all architecture maintainers are on lkml.
> 
> Besides, I've tried talking to the architecture maintainers - their
> complete silence since two weeks ago indicates that they just don't
> want to know about this issue.
> 
> As I said on the architecture alias - I've put enough non-rewarding
> time into this issue.  I also have various commercial deadlines
> coming up, so I couldn't work on it even if I wanted to.
> 

If something is broken in the linux kernel (in this case for arm), and 
you submit a patch, and no-one else rejects it without suggesting a 
better way to do it, I can't see why your patch could justifiably being 
rejected.
Of course if no-one else even cares about the problem and you don't have 
write access to the kernel tree, the problem will continue.
I think this might be one of the cases of don't bother discussing it, 
create a patch to do the fix how you think best, and then post it.

One can always use the approach of providing a patch for the linux 
kernel separately, so that any users wishing to use alsa have to first 
apply the patch. At least users can use alsa with arm!

As arm is used on a majority of embedded systems, and as more and more 
embedded systems are using linux, the demand for your patches will 
certainly rise.

As you obviously have support from Jaroslav Kysela, one could probably 
make it so that alsa-driver fails to compile on arm, unless your patch 
is applied to the kernel first. That would certainly provide a BIG 
incentive for your patch to get including into the kernel.

I don't have an ARM platform running linux, but I definetly support your 
efforts to bring alsa to more different platforms.

My 2 cents....

James


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click