> How about this (with documentation fixes by David-B):
Actually I'd be just as happy to call the ARM pci_free_consistent()
behavior (BUG in_interrupt) the problem. Particularly if that ARM
patch works OK! I've gotten success reports with pci_pool from
folk using about half the architectures
How about this (with documentation fixes by David-B):
Actually I'd be just as happy to call the ARM pci_free_consistent()
behavior (BUG in_interrupt) the problem. Particularly if that ARM
patch works OK! I've gotten success reports with pci_pool from
folk using about half the architectures in
How about this (with documentation fixes by David-B):
diff -ur -X dontdiff linux-2.4.4/Documentation/DMA-mapping.txt
linux-2.4.4-niph/Documentation/DMA-mapping.txt
--- linux-2.4.4/Documentation/DMA-mapping.txt Thu Apr 19 08:38:48 2001
+++ linux-2.4.4-niph/Documentation/DMA-mapping.txt
How about this (with documentation fixes by David-B):
diff -ur -X dontdiff linux-2.4.4/Documentation/DMA-mapping.txt
linux-2.4.4-niph/Documentation/DMA-mapping.txt
--- linux-2.4.4/Documentation/DMA-mapping.txt Thu Apr 19 08:38:48 2001
+++ linux-2.4.4-niph/Documentation/DMA-mapping.txt
Pete Zaitcev writes:
> A fix in pci remove does not fix regular processing.
I see. Here is where I was confused.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
> From: "David S. Miller" <[EMAIL PROTECTED]>
> Date: Tue, 8 May 2001 17:52:45 -0700 (PDT)
> Ummm... What Alan's saying is:
>
> 1) Whatever driver is trying to shut down from IRQ context
>is broken must be fixed. pci_pool is fine.
>
> 2) The Documentation/ files which suggest that such
From: David S. Miller [EMAIL PROTECTED]
Date: Tue, 8 May 2001 17:52:45 -0700 (PDT)
Ummm... What Alan's saying is:
1) Whatever driver is trying to shut down from IRQ context
is broken must be fixed. pci_pool is fine.
2) The Documentation/ files which suggest that such device
Pete Zaitcev writes:
A fix in pci remove does not fix regular processing.
I see. Here is where I was confused.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
David Brownell writes:
> Pete's patch to pci_pool_free() is fine with me, and I'd be glad
> to see that bit of pci interface cleaned up. Any changes needed
> other than the pci.txt doc update?
Ummm... What Alan's saying is:
1) Whatever driver is trying to shut down from IRQ context
is
Alan Cox writes:
> I suspect we should fix the documentation (and if need be the code) to reflect
> the fact that you have to be completely out of your tree to handle device
> removal in the irq handler
Agreed.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
> This sure makes life difficult. Device removal events can be called
> from interrupt context according to Documentation/pci.txt. This is
> certainly a place where one might want to call pci_consistent_free.
None of our device code supports interrupt based device removal. In fact
many drivers
Pete Zaitcev writes:
> Russel King complained that you might be calling pci_consistent_free
> from an interrupt, which is unsafe on ARM.
This sure makes life difficult. Device removal events can be called
from interrupt context according to Documentation/pci.txt. This is
certainly a place where
David,
Russel King complained that you might be calling pci_consistent_free
from an interrupt, which is unsafe on ARM. Why don't you remove this
part from pci_pool_free():
+ else if (!is_page_busy (pool->blocks_per_page, page->bitmap))
+ pool_free_page (pool, page);
In that
David Brownell writes:
Pete's patch to pci_pool_free() is fine with me, and I'd be glad
to see that bit of pci interface cleaned up. Any changes needed
other than the pci.txt doc update?
Ummm... What Alan's saying is:
1) Whatever driver is trying to shut down from IRQ context
is
Pete Zaitcev writes:
Russel King complained that you might be calling pci_consistent_free
from an interrupt, which is unsafe on ARM.
This sure makes life difficult. Device removal events can be called
from interrupt context according to Documentation/pci.txt. This is
certainly a place where
David,
Russel King complained that you might be calling pci_consistent_free
from an interrupt, which is unsafe on ARM. Why don't you remove this
part from pci_pool_free():
+ else if (!is_page_busy (pool-blocks_per_page, page-bitmap))
+ pool_free_page (pool, page);
In that
This sure makes life difficult. Device removal events can be called
from interrupt context according to Documentation/pci.txt. This is
certainly a place where one might want to call pci_consistent_free.
None of our device code supports interrupt based device removal. In fact
many drivers use
Alan Cox writes:
I suspect we should fix the documentation (and if need be the code) to reflect
the fact that you have to be completely out of your tree to handle device
removal in the irq handler
Agreed.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the
18 matches
Mail list logo
