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-define
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
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 th
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
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
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
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
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
> A
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
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
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 kern
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 t
: Tuesday, March 09, 2004 5:17 PM
To: Gupta, Kshitij
Cc: Jaroslav Kysela; [EMAIL PROTECTED]
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
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.
sa1
]
[mailto:[EMAIL PROTECTED] Behalf Of Gupta,
Kshitij
Sent: Tuesday, March 09, 2004 4:11 PM
To: 'Russell King'; Jaroslav Kysela
Cc: [EMAIL PROTECTED]
Subject: RE: [Alsa-devel] buffer producer/consumer sync
hi,
Just for your information we are using OSS PCM emulation. And let
me
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.
Un
09, 2004 3:48 PM
To: Jaroslav Kysela
Cc: Gupta, Kshitij; [EMAIL PROTECTED]
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
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 /
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 ar
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
Title: buffer producer/consumer sync
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 e
21 matches
Mail list logo
