From: Rene Herman <rene.herman@keyaccess.nl>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Takashi Iwai <tiwai@suse.de>, Andrew Morton <akpm@osdl.org>,
ALSA devel <alsa-devel@alsa-project.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] Re: 2.6.26-rc1 regression: ISA DMA broken (bisected)
Date: Sat, 31 May 2008 00:11:37 +0200 [thread overview]
Message-ID: <48407B99.4080209@keyaccess.nl> (raw)
In-Reply-To: <200805301543.42208.bjorn.helgaas@hp.com>
On 30-05-08 23:43, Bjorn Helgaas wrote:
> On Friday 30 May 2008 03:15:57 pm Rene Herman wrote:
>> It gets uglier. ALSA ISA drivers (for cards that exist both as legacy
>> and as ISAPnP at least) keep a merged legacy/isapnp model; PnP is used
>> mostly for initializing global variables that the same old legacy probe
>> routines then reference. This means that beyond that global resource
>> init step the specific struct device is no longer available. Without
>> restructuring too many things really only fixable through other hacks
>> again such as a global dma_dev[] array or some such.
>>
>> From the viewpoint of PnP itself setting the dma_mask for a pnp_card (a
>> pnp_dev collection) makes isolated sense so if no objections, I'll
>> submit the attached after all. From the ALSA side we'd then pass the
>> card dev (which we'd also do for isa_dev) and keep in mind that we might
>> want to get more specific if over time structure permits it.
>>
>> struct snd_pcm already has its own struct device * which would be the
>> right one here but it's setting that which gets ugly...
>
> Looks good to me. It does sound like a lot of work and possibly
> more risk than it's worth to fix up some of this stuff.
Fairly invasive at least. The good thing though is that with the recent
pnp_manual_config_dev() removal the PnP drivers have no actual need/use
for this global variable model anymore and now I have a great excuse for
rewriting them. That can happen one at a time though...
> I do still wonder whether any non-x86 architectures need similar
> fixes in dma_alloc_coherent(), i.e., check for dev==NULL and fall
> back to a 24-bit DMA mask.
Hrmmpf. Good question. In sound/isa, we've had a but of alpha spottyness
over time but nothing which would seem to be related.
> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Thanks. I'll assume Andrew picks it up from the CC...
Rene.
WARNING: multiple messages have this Message-ID (diff)
From: Rene Herman <rene.herman@keyaccess.nl>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Takashi Iwai <tiwai@suse.de>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel <linux-kernel@vger.kernel.org>,
ALSA devel <alsa-devel@alsa-project.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] Re: 2.6.26-rc1 regression: ISA DMA broken (bisected)
Date: Sat, 31 May 2008 00:11:37 +0200 [thread overview]
Message-ID: <48407B99.4080209@keyaccess.nl> (raw)
In-Reply-To: <200805301543.42208.bjorn.helgaas@hp.com>
On 30-05-08 23:43, Bjorn Helgaas wrote:
> On Friday 30 May 2008 03:15:57 pm Rene Herman wrote:
>> It gets uglier. ALSA ISA drivers (for cards that exist both as legacy
>> and as ISAPnP at least) keep a merged legacy/isapnp model; PnP is used
>> mostly for initializing global variables that the same old legacy probe
>> routines then reference. This means that beyond that global resource
>> init step the specific struct device is no longer available. Without
>> restructuring too many things really only fixable through other hacks
>> again such as a global dma_dev[] array or some such.
>>
>> From the viewpoint of PnP itself setting the dma_mask for a pnp_card (a
>> pnp_dev collection) makes isolated sense so if no objections, I'll
>> submit the attached after all. From the ALSA side we'd then pass the
>> card dev (which we'd also do for isa_dev) and keep in mind that we might
>> want to get more specific if over time structure permits it.
>>
>> struct snd_pcm already has its own struct device * which would be the
>> right one here but it's setting that which gets ugly...
>
> Looks good to me. It does sound like a lot of work and possibly
> more risk than it's worth to fix up some of this stuff.
Fairly invasive at least. The good thing though is that with the recent
pnp_manual_config_dev() removal the PnP drivers have no actual need/use
for this global variable model anymore and now I have a great excuse for
rewriting them. That can happen one at a time though...
> I do still wonder whether any non-x86 architectures need similar
> fixes in dma_alloc_coherent(), i.e., check for dev==NULL and fall
> back to a 24-bit DMA mask.
Hrmmpf. Good question. In sound/isa, we've had a but of alpha spottyness
over time but nothing which would seem to be related.
> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Thanks. I'll assume Andrew picks it up from the CC...
Rene.
next prev parent reply other threads:[~2008-05-30 22:08 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-09 1:37 2.6.26-rc1 regression: ISA DMA broken (bisected) Rene Herman
2008-05-09 1:37 ` Rene Herman
2008-05-09 6:06 ` Takashi Iwai
2008-05-09 6:06 ` Takashi Iwai
2008-05-09 8:55 ` Ingo Molnar
2008-05-09 8:55 ` Ingo Molnar
2008-05-09 8:58 ` Ingo Molnar
2008-05-09 17:20 ` Jesse Barnes
2008-05-09 12:03 ` Rene Herman
2008-05-09 12:03 ` Rene Herman
2008-05-09 12:28 ` Ingo Molnar
2008-05-09 12:28 ` Ingo Molnar
2008-05-09 23:00 ` Rene Herman
2008-05-09 23:00 ` Rene Herman
2008-05-13 14:36 ` Ingo Molnar
2008-05-13 14:36 ` Ingo Molnar
2008-05-13 15:26 ` Rene Herman
2008-05-09 12:29 ` Pete Clements
2008-05-09 12:29 ` Pete Clements
2008-05-09 12:48 ` Glauber Costa
2008-05-13 16:59 ` Bjorn Helgaas
2008-05-13 16:59 ` Bjorn Helgaas
2008-05-13 17:01 ` Alan Cox
2008-05-13 17:01 ` Alan Cox
2008-05-13 17:33 ` Rene Herman
2008-05-13 17:33 ` Rene Herman
2008-05-13 23:18 ` Bjorn Helgaas
2008-05-13 23:18 ` Bjorn Helgaas
2008-05-14 9:25 ` Takashi Iwai
2008-05-14 9:25 ` Takashi Iwai
2008-05-14 12:46 ` Rene Herman
2008-05-14 12:46 ` Rene Herman
2008-05-14 13:01 ` Takashi Iwai
2008-05-14 15:40 ` Rene Herman
2008-05-14 15:40 ` Rene Herman
2008-05-14 15:53 ` Takashi Iwai
2008-05-14 15:53 ` Takashi Iwai
2008-05-14 18:41 ` Rene Herman
2008-05-14 18:50 ` Bjorn Helgaas
2008-05-14 19:09 ` Rene Herman
2008-05-14 19:09 ` Rene Herman
2008-05-30 21:15 ` [PATCH] " Rene Herman
2008-05-30 21:15 ` Rene Herman
2008-05-30 21:28 ` [DEVICE MODEL] dev->dma_mask Rene Herman
2008-05-30 21:28 ` Rene Herman
2008-05-30 21:43 ` [PATCH] Re: 2.6.26-rc1 regression: ISA DMA broken (bisected) Bjorn Helgaas
2008-05-30 21:43 ` Bjorn Helgaas
2008-05-30 22:11 ` Rene Herman [this message]
2008-05-30 22:11 ` Rene Herman
2008-05-30 22:37 ` [PATCH] ISA: set 24-bit dma_mask for ISA devices Rene Herman
2008-05-30 22:37 ` Rene Herman
2008-05-30 22:55 ` Andrew Morton
2008-05-30 22:55 ` Andrew Morton
2008-05-30 23:50 ` Rene Herman
2008-05-30 23:50 ` Rene Herman
2008-05-30 23:54 ` [PATCH] PNP: set the pnp_card dma_mask for use by ISAPnP cards Rene Herman
2008-05-30 23:54 ` Rene Herman
2008-05-31 8:55 ` Takashi Iwai
2008-05-31 8:55 ` Takashi Iwai
2008-05-30 23:55 ` [PATCH] ISA: set 24-bit dma_mask for ISA devices Rene Herman
2008-05-30 23:55 ` Rene Herman
2008-05-31 8:56 ` Takashi Iwai
2008-05-31 8:56 ` Takashi Iwai
2008-05-14 15:26 ` 2.6.26-rc1 regression: ISA DMA broken (bisected) Bjorn Helgaas
2008-05-14 15:26 ` Bjorn Helgaas
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=48407B99.4080209@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=alsa-devel@alsa-project.org \
--cc=bjorn.helgaas@hp.com \
--cc=linux-kernel@vger.kernel.org \
--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.