All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian McMenamin <adrian@mcmen.demon.co.uk>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, Paul Mundt <lethal@linux-sh.org>,
	Lee Revell <rlrevell@joe-job.com>,
	linux-kernel@vger.kernel.org,
	linux-sh <linuxsh-dev@lists.sourceforge.net>
Subject: Re: [linuxsh-dev] [PATCH] Add support for Yamaha	AICA	sound on	SEGA Dreamcast
Date: Wed, 07 Jun 2006 00:10:48 +0100	[thread overview]
Message-ID: <1149635448.5154.7.camel@localhost.localdomain> (raw)
In-Reply-To: <s5hslmimvh5.wl%tiwai@suse.de>

On Tue, 2006-06-06 at 12:25 +0200, Takashi Iwai wrote:

> 
> As Paul already pointed, the platform_device things must be fixed.
> Also, better to clean up the code directly accessing hardcoded
> addresses.

Working on that, some new code in my personal CVS now - but I suspect it
will be the weekend before that gets fully fixed.


> 
> Another big concern is that spu_dma_work is initialized/rewritten
> dynamically in spu_begin_dma() and aica_period_elapsed() via
> INIT_WORK() and PREPARE_WOR().  This looks pretty strange and may be
> racy.

Actually, the two macros INIT_WORK and PREPARE_WORK use the same work
queue but ask it to schedule the execution of two different (if very
similar) functions start_spu_dma() - which does the initial transfer and
more_spu_dma - which tops up the dma transfers.

So I think I've got that right.

WARNING: multiple messages have this Message-ID (diff)
From: Adrian McMenamin <adrian@mcmen.demon.co.uk>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, Paul Mundt <lethal@linux-sh.org>,
	Lee Revell <rlrevell@joe-job.com>,
	linux-kernel@vger.kernel.org,
	linux-sh <linuxsh-dev@lists.sourceforge.net>
Subject: Re: [linuxsh-dev] [Alsa-devel] [PATCH] Add support for Yamaha AICA	sound on	SEGA Dreamcast
Date: Wed, 07 Jun 2006 00:10:48 +0100	[thread overview]
Message-ID: <1149635448.5154.7.camel@localhost.localdomain> (raw)
In-Reply-To: <s5hslmimvh5.wl%tiwai@suse.de>

On Tue, 2006-06-06 at 12:25 +0200, Takashi Iwai wrote:

> 
> As Paul already pointed, the platform_device things must be fixed.
> Also, better to clean up the code directly accessing hardcoded
> addresses.

Working on that, some new code in my personal CVS now - but I suspect it
will be the weekend before that gets fully fixed.


> 
> Another big concern is that spu_dma_work is initialized/rewritten
> dynamically in spu_begin_dma() and aica_period_elapsed() via
> INIT_WORK() and PREPARE_WOR().  This looks pretty strange and may be
> racy.

Actually, the two macros INIT_WORK and PREPARE_WORK use the same work
queue but ask it to schedule the execution of two different (if very
similar) functions start_spu_dma() - which does the initial transfer and
more_spu_dma - which tops up the dma transfers.

So I think I've got that right.


  reply	other threads:[~2006-06-06 23:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1149201071.9032.13.camel@localhost.localdomain>
2006-06-03 11:39 ` [linuxsh-dev] [PATCH] Add support for Yamaha AICA sound on SEGA Dreamcast Adrian McMenamin
2006-06-03 15:16   ` Lee Revell
2006-06-03 15:16     ` Lee Revell
2006-06-03 16:38     ` Adrian McMenamin
2006-06-03 16:38     ` Adrian McMenamin
2006-06-06 10:25   ` Takashi Iwai
2006-06-06 10:25   ` [Alsa-devel] " Takashi Iwai
2006-06-06 23:10     ` Adrian McMenamin [this message]
2006-06-06 23:10       ` [linuxsh-dev] [Alsa-devel] " Adrian McMenamin
2006-06-07  9:51       ` Takashi Iwai
2006-06-07 18:16         ` [linuxsh-dev] " Adrian McMenamin
2006-06-07 18:16         ` [Alsa-devel] " Adrian McMenamin
2006-06-08 10:35           ` Takashi Iwai
2006-06-08 10:35             ` [Alsa-devel] " Takashi Iwai
2006-06-08 18:16             ` Adrian McMenamin
2006-06-08 18:16               ` [linuxsh-dev] [Alsa-devel] " Adrian McMenamin
2006-06-07  9:51       ` [linuxsh-dev] " Takashi Iwai
2006-06-03 11:39 ` Adrian McMenamin
2006-06-05  9:53 ` Paul Mundt
2006-06-05  9:59   ` Adrian McMenamin
2006-06-05  9:59   ` Adrian McMenamin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1149635448.5154.7.camel@localhost.localdomain \
    --to=adrian@mcmen.demon.co.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxsh-dev@lists.sourceforge.net \
    --cc=rlrevell@joe-job.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.