I am using the YMFPCI driver on a Toshiba Tecra 8100.
The sound_alloc_dmap() function in dmabuf.c must be changed from using
__get_free_pages() and virt_to_bus() -> pci_alloc_consistent().
This looked like an easy thing to do, but the only parameter to
sound_alloc_dmap() is of type struct dma_buffparms -- whose definition I
couldn't even find -- and pci_alloc_consistent() expects a struct
pci_dev as a parameter. I read the driver-model.txt file in the
Documentation in the hopes of finding some magic __get_pci_dev_by_id(int
dev) function, but things are never that easy :).
I tried asking about this in kernelnewbies, but got no response. Anyone
here want to give me a nudge in the right direction?
> I am using the YMFPCI driver on a Toshiba Tecra 8100.
>
> The sound_alloc_dmap() function in dmabuf.c must be changed from using
> __get_free_pages() and virt_to_bus() -> pci_alloc_consistent().
What the hell are you talking about, I changed it long ago.
Linus uses ymfpci on his Crusoe Picturebook with no problems.
What is your kernel version?
-- Pete
> > The sound_alloc_dmap() function in dmabuf.c must be changed from using
> > __get_free_pages() and virt_to_bus() -> pci_alloc_consistent().
>
> What the hell are you talking about, I changed it long ago.
> Linus uses ymfpci on his Crusoe Picturebook with no problems.
> What is your kernel version?
In the ymfpci case its not the sound_alloc_dmap (at least not in 2.4 but
2.5 might be out of date except in -dj). Its the use of virt_to_bus still
rather than the handles returned from the pci api
Alan Cox wrote:
>>>The sound_alloc_dmap() function in dmabuf.c must be changed from using
>>>__get_free_pages() and virt_to_bus() -> pci_alloc_consistent().
>>>
>>What the hell are you talking about, I changed it long ago.
>>Linus uses ymfpci on his Crusoe Picturebook with no problems.
>>What is your kernel version?
>>
>
> In the ymfpci case its not the sound_alloc_dmap (at least not in 2.4 but
> 2.5 might be out of date except in -dj). Its the use of virt_to_bus still
> rather than the handles returned from the pci api
>
>
I am looking at both 2.5.4 and 2.4.18-pre9.
In my copy of sound_alloc_dmap(), I see a direct call to
__get_free_pages to allocate the buffer and a call to virt_to_bus. I
just thought that this could be cleared up by using pci_alloc_consistent
(since this function will call __get_free_pages anyway and eliminates
the need to use virt_to_bus).
Anyway, I'm not sure I understand this. I know using the virt_to_bus is
wrong, but why would we use __get_free_pages() here? (This is not a
rhetorical question, I honestly want to learn).
> Date: Mon, 11 Feb 2002 13:13:22 -0500
> From: John Weber <[email protected]>
> I am looking at both 2.5.4 and 2.4.18-pre9.
OK. Marcelo is not removing virt_to_bus any time soon, so ymfpci
in 2.4.18 is not going to have it removed. There were some other
interesting fixes, so I want 2.4.18 to be testing those. Sure,
for 2.4.19 I can add pci_alloc_XXX. The patch to do it is in my
tree and I am using it on my laptop. It is not a priority though.
Linus tree is different. I feel pretty safe dumping all fixes
that I receive into it as soon as they get tested on my laptop.
If his sound stops working, he'll let me know pretty quick.
Thus, the ymfpci in 2.5.4 uses pci_alloc_consistent.
> In my copy of sound_alloc_dmap(), I see a direct call to
> __get_free_pages to allocate the buffer and a call to virt_to_bus.
This is wonderful, but how is this related to ymfpci?
Config.in makes you to build sound.o if you select
CONFIG_SOUND_YMFPCI, but that's pretty irrelevant.
The ymfpci should load fine without sound.o, it only needs
soundcore.o.
OTOH, if you just want to fix dmabuf.c, by all means be my guest.
-- Pete
P.S. I changed i810_audio to use pci_alloc_consistent too, it is
somewhere in dledford's queue.
> This is wonderful, but how is this related to ymfpci?
I don't know. All I know is that _I_ did not enable persistent dma
buffers in my kernel config, so I blamed this dmap stuff on ymfpci
(which is the only sound option that I enabled).
I do see that CONFIG_SOUND_GAMEPORT is enabled automatically
(perhaps by the OSS option). Do you think this is what is requiring
sound_alloc_dmap() ?
Thanks for all your help!
> Date: Mon, 11 Feb 2002 14:09:32 -0500
> From: John Weber <[email protected]>
> I enable ymfpci, and I have to compile and link dmabuf.c which leads to
> the problem (the only other sound options enabled are
> CONFIG_SOUND_GAMEPORT and CONFIG_SOUND_OSS).
> By the way, I don't use modules so this problem results in a link error.
> I guess I could use modules if this would rectify the problem.
Try to do this. Open drivers/sound/Config.in, and find YMFPCI
tristate, then delete $CONFIG_SOUND_OSS from that line.
Edit .config, and remove CONFIG_SOUND_OSS. Rerun make oldconfig,
when prompted for CONFIG_SOUND_OSS, say N. This should work.
I use monolithic kernels on 2.4, but on 2.5 it is officially
discouraged, so I gave up on it.
I do not see ANYTHING in 2.5.4 Makefiles that depended on
CONFIG_SOUND_GAMEPORT. This option only works to restric
some configurations choices, but it does not control any
compilations. Seems like a deadwood to me. Just kill it too.
-- Pete
> Try to do this. Open drivers/sound/Config.in, and find YMFPCI
> tristate, then delete $CONFIG_SOUND_OSS from that line.
> Edit .config, and remove CONFIG_SOUND_OSS. Rerun make oldconfig,
> when prompted for CONFIG_SOUND_OSS, say N. This should work.
if [ "$CONFIG_SOUND_OSS" = "y" -o "$CONFIG_SOUND_OSS" = "m" ]; then
bool ' Verbose initialisation' CONFIG_SOUND_TRACEINIT
bool ' Persistent DMA buffers' CONFIG_SOUND_DMAP
The YMFPCI option was in the body of the above if statement, so I had
to move it out of there to be able to enable it without enabling
CONFIG_SOUND_OSS. I hope this is what you meant.
>
> I use monolithic kernels on 2.4, but on 2.5 it is officially
> discouraged, so I gave up on it.
To what granularity? I use the hardware as a rule of thumb: if the
the hardware supported is fixed, then I put it in the kernel.
Should I compile everything as modules?
However, I did hear something about everything being a module in 2.6
because the kernel will eventually use initramfs or something...
Anyway, this is a different thread. But I would like to hear your rule
of thumb for when you compile things as a module...
> I do not see ANYTHING in 2.5.4 Makefiles that depended on
> CONFIG_SOUND_GAMEPORT. This option only works to restric
> some configurations choices, but it does not control any
> compilations. Seems like a deadwood to me. Just kill it too.
I kill it but make oldconfig enables it right back :).
I'll look through Config.in in a bit.
John Weber wrote:
>> Try to do this. Open drivers/sound/Config.in, and find YMFPCI
>> tristate, then delete $CONFIG_SOUND_OSS from that line.
>> Edit .config, and remove CONFIG_SOUND_OSS. Rerun make oldconfig,
>> when prompted for CONFIG_SOUND_OSS, say N. This should work.
>
>
> if [ "$CONFIG_SOUND_OSS" = "y" -o "$CONFIG_SOUND_OSS" = "m" ]; then
> bool ' Verbose initialisation' CONFIG_SOUND_TRACEINIT
> bool ' Persistent DMA buffers' CONFIG_SOUND_DMAP
>
> The YMFPCI option was in the body of the above if statement, so I had
> to move it out of there to be able to enable it without enabling
> CONFIG_SOUND_OSS. I hope this is what you meant.
>
This works, by the way.