Not sure if this was the same message I received. but here
is the patch I used to get around my sound problem in
2.5.4.
Linus, please apply to 2.5.5 pre1
Later,
Albert
--- linux/drivers/sound/dmabuf.c.orig Tue Feb 12 10:12:59 2002
+++ linux/drivers/sound/dmabuf.c Tue Feb 12 10:15:06 2002
@@ -113,7 +113,7 @@
}
}
dmap->raw_buf = start_addr;
- dmap->raw_buf_phys = virt_to_bus(start_addr);
+ dmap->raw_buf_phys = isa_virt_to_bus(start_addr);
for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
mem_map_reserve(page);
--
Albert Cranford Deerfield Beach FL USA
[email protected]
From: Albert Cranford <[email protected]>
Date: Tue, 12 Feb 2002 22:51:35 -0500
Not sure if this was the same message I received. but here
is the patch I used to get around my sound problem in
2.5.4.
Linus, please apply to 2.5.5 pre1
Umm, I don't it is safe to assume that only ISA sound drivers end up
making use of this code. I would like you to prove that before
submitting this change.
On Tuesday 12 February 2002 19:51, Albert Cranford wrote:
> Not sure if this was the same message I received. but here
> is the patch I used to get around my sound problem in
> 2.5.4.
Are you sure this is correct? include/asm/io.h seems to indicate that i/o
addresses for PCI may not map correctly. The sound card I am using is PCI,
not ISA.
Documentation/DMA-mapping.txt says that virt_to_bus is completly depreciated
and nothing should be using it. Well, grepping the kernel source shows that
quite a bit still uses it.
What it looks like, on first glance, is that virt_to_bus was changed for pci
devices to give this error message. (Since that symbol goes nowhere.) That
effects a number of things, not just sound. (A whole bunch of cardbus drivers
I would guess...)
When was this change made? It appears as if they missed a few bits.
Comment: 2.5.4 has been more than a bit rough. Rarely do i see more than one
patch needed just to get it to compile. Not trying to be bitchy about it.
Just a wee bit frustrated...
> Linus, please apply to 2.5.5 pre1
> Later,
> Albert
> --- linux/drivers/sound/dmabuf.c.orig Tue Feb 12 10:12:59 2002
> +++ linux/drivers/sound/dmabuf.c Tue Feb 12 10:15:06 2002
> @@ -113,7 +113,7 @@
> }
> }
> dmap->raw_buf = start_addr;
> - dmap->raw_buf_phys = virt_to_bus(start_addr);
> + dmap->raw_buf_phys = isa_virt_to_bus(start_addr);
>
> for (page = virt_to_page(start_addr); page <=
> virt_to_page(end_addr); page++) mem_map_reserve(page);
Alan wrote:
> On Tuesday 12 February 2002 19:51, Albert Cranford wrote:
>
>>Not sure if this was the same message I received. but here
>>is the patch I used to get around my sound problem in
>>2.5.4.
>>
>
> Are you sure this is correct? include/asm/io.h seems to indicate that i/o
> addresses for PCI may not map correctly. The sound card I am using is PCI,
> not ISA.
You should not use isa_virt_to_bus. IIRC someone on this list worried
about this exact thing happening.
> Documentation/DMA-mapping.txt says that virt_to_bus is completly depreciated
> and nothing should be using it. Well, grepping the kernel source shows that
> quite a bit still uses it.
This is on the kernel janitor TODO, and we (janitors) will be tackling
this shortly. But your instinct is right, virt_to_bus shouldn't be
everywhere.
> What it looks like, on first glance, is that virt_to_bus was changed for pci
> devices to give this error message. (Since that symbol goes nowhere.) That
> effects a number of things, not just sound. (A whole bunch of cardbus drivers
> I would guess...)
This is correct. It has been a policy to use pci_alloc_consistent
instead of kmalloc/getfreepages and virt_to_bus, 2.5 is enforcing it now.
It is boring work to change this in many drivers, but I don't know any
better so I think it quite fun to go in and help :). I'll start sending
patches to the relevant maintainers shortly.
By the way, anyone know who the maintainer is for the persistent DMA
buffer code?
--
(o- j o h n e w e b e r
//\ http://www.linuxhq.com/people/weber/
v_/_ [email protected]
On Tuesday 12 February 2002 21:03, John Weber wrote:
> Alan wrote:
> > On Tuesday 12 February 2002 19:51, Albert Cranford wrote:
> >>Not sure if this was the same message I received. but here
> >>is the patch I used to get around my sound problem in
> >>2.5.4.
> >
> > Are you sure this is correct? include/asm/io.h seems to indicate that
> > i/o addresses for PCI may not map correctly. The sound card I am using
> > is PCI, not ISA.
>
> You should not use isa_virt_to_bus. IIRC someone on this list worried
> about this exact thing happening.
Glad I checked before adding the patch... ]:>
> > Documentation/DMA-mapping.txt says that virt_to_bus is completly
> > depreciated and nothing should be using it. Well, grepping the kernel
> > source shows that quite a bit still uses it.
>
> This is on the kernel janitor TODO, and we (janitors) will be tackling
> this shortly. But your instinct is right, virt_to_bus shouldn't be
> everywhere.
IMHO 2.5.4 is pretty broken until that gets fixed. the list is pretty long
as well.
> > What it looks like, on first glance, is that virt_to_bus was changed for
> > pci devices to give this error message. (Since that symbol goes
> > nowhere.) That effects a number of things, not just sound. (A whole
> > bunch of cardbus drivers I would guess...)
>
> This is correct. It has been a policy to use pci_alloc_consistent
> instead of kmalloc/getfreepages and virt_to_bus, 2.5 is enforcing it now.
By breaking sound (in dmabuf and sound modules), cardbus (lots of places),
and who knows what else.
"grep -r virt_to_bus | less" shows jut how bad it is going to be...
> It is boring work to change this in many drivers, but I don't know any
> better so I think it quite fun to go in and help :). I'll start sending
> patches to the relevant maintainers shortly.
Thanks.
It just makes me wonder if anyone actually compiled this and ran it before it
was released.
Back to 2.4.x land for a while i guess... (At least on this machine.)
On Tue, 2002-02-12 at 21:18, Alan wrote:
> On Tuesday 12 February 2002 21:03, John Weber wrote:
<snip>
> > This is correct. It has been a policy to use pci_alloc_consistent
> > instead of kmalloc/getfreepages and virt_to_bus, 2.5 is enforcing it now.
>
> By breaking sound (in dmabuf and sound modules), cardbus (lots of places),
> and who knows what else.
>
> "grep -r virt_to_bus | less" shows jut how bad it is going to be...
I checked, there are 1069 occurrences.
Miles
> > This is correct. It has been a policy to use pci_alloc_consistent
> > instead of kmalloc/getfreepages and virt_to_bus, 2.5 is enforcing it now.
>
> By breaking sound (in dmabuf and sound modules), cardbus (lots of places),
> and who knows what else.
It needed breaking. In order to get the drivers portable they need to be
using the DMA API. It shouldn't take too long for the common drivers to
get converted. For much of the sound layer it doesnt matter since the
ALSA code will replace a lot of the older sound stuff.
Alan
> Umm, I don't it is safe to assume that only ISA sound drivers end up
> making use of this code. I would like you to prove that before
> submitting this change.
There are PCI drivers using the old sound code. Whether it matters is a
more complicated question as these devices use ISA DMA emulation or their
own pseudo DMA functionality.
Alan
From: Alan Cox <[email protected]>
Date: Wed, 13 Feb 2002 09:26:32 +0000 (GMT)
There are PCI drivers using the old sound code. Whether it matters is a
more complicated question as these devices use ISA DMA emulation or their
own pseudo DMA functionality.
The sound layer PCI DMA stuff like a nice project for some kernel
janitors :-))
> There are PCI drivers using the old sound code. Whether it matters is a
> more complicated question as these devices use ISA DMA emulation or their
> own pseudo DMA functionality.
>
> The sound layer PCI DMA stuff like a nice project for some kernel
> janitors :-))
Waste of effort. ALSA will replace the OSS code anyway
> There are PCI drivers using the old sound code. Whether it matters is a
> more complicated question as these devices use ISA DMA emulation or their
> own pseudo DMA functionality.
>
> Alan
Sometimes it's only a configuration mistake. Not that it mattered,
since "The ALSA is coming! The ALSA is coming!" can be heard from
our forrestals.
--- linux-2.5.4/drivers/sound/Config.in Sun Feb 10 17:50:10 2002
+++ linux-2.5.4-p3/drivers/sound/Config.in Mon Feb 11 10:12:51 2002
@@ -164,7 +164,7 @@
dep_tristate ' Yamaha FM synthesizer (YM3812/OPL-3) support' CONFIG_SOUND_YM3812 $CONFIG_SOUND_OSS
dep_tristate ' Yamaha OPL3-SA1 audio controller' CONFIG_SOUND_OPL3SA1 $CONFIG_SOUND_OSS
dep_tristate ' Yamaha OPL3-SA2 and SA3 based PnP cards' CONFIG_SOUND_OPL3SA2 $CONFIG_SOUND_OSS
- dep_tristate ' Yamaha YMF7xx PCI audio (native mode)' CONFIG_SOUND_YMFPCI $CONFIG_SOUND_OSS $CONFIG_PCI
+ dep_tristate ' Yamaha YMF7xx PCI audio (native mode)' CONFIG_SOUND_YMFPCI $CONFIG_PCI
dep_mbool ' Yamaha PCI legacy ports support' CONFIG_SOUND_YMFPCI_LEGACY $CONFIG_SOUND_YMFPCI
dep_tristate ' 6850 UART support' CONFIG_SOUND_UART6850 $CONFIG_SOUND_OSS
On Wed, 13 Feb 2002, David S. Miller wrote:
> From: Alan Cox <[email protected]>
> Date: Wed, 13 Feb 2002 09:26:32 +0000 (GMT)
>
> There are PCI drivers using the old sound code. Whether it matters is a
> more complicated question as these devices use ISA DMA emulation or their
> own pseudo DMA functionality.
>
> The sound layer PCI DMA stuff like a nice project for some kernel
> janitors :-))
Not worth, IMO.
Machines that give us fun support the legacy virt_to_bus() semantic.
Those that require the PCI DMA abstraction are so boring than adding sound
will probably not improve user pleasure significantly.
:-)) (this smiley is just to prevent from too much flaming ;-)
G?rard.
On Wed, 13 Feb 2002, Alan Cox wrote:
>
> Waste of effort. ALSA will replace the OSS code anyway
In fact, in my tree it right now has replaced it. I'll make a pre-patch
and try to get the BK tree pushed out.
Linus
On Wednesday 13 February 2002 02:24, Alan Cox wrote:
> > There are PCI drivers using the old sound code. Whether it matters is
> > a more complicated question as these devices use ISA DMA emulation or
> > their own pseudo DMA functionality.
> >
> > The sound layer PCI DMA stuff like a nice project for some kernel
> > janitors :-))
>
> Waste of effort. ALSA will replace the OSS code anyway
When I looked at the code, it looked like a lot more than just the sound code
needed to be fixed. I will look at the next patch and see what is left.