On Wed, 2009-05-27 at 23:42 -0500, Kumar Gala wrote:
Ben,
Any comments on this.. need a decision so we can have patches ready
for .31.
Clamping the DMA mask is even worse than the additional indirection
for us. We have valid scenarios in which we'd have 512M of outbound
PCI
On May 28, 2009, at 1:11 AM, Benjamin Herrenschmidt wrote:
On Wed, 2009-05-27 at 23:42 -0500, Kumar Gala wrote:
Ben,
Any comments on this.. need a decision so we can have patches ready
for .31.
Clamping the DMA mask is even worse than the additional indirection
for us. We have valid
On May 22, 2009, at 6:11 AM, Ian Campbell wrote:
BTW do you need swiotlb_bus_to_virt to be __weak or is the fact that
it
is implemented in terms of swiotlb_bus_to_phys sufficient?
The default one in swiotlb calls phys_to_virt on the result of
swiotlb_bus_to_phys, which only works on
On May 22, 2009, at 5:51 AM, FUJITA Tomonori wrote:
On Thu, 21 May 2009 13:18:54 -0700
Jeremy Fitzhardinge jer...@goop.org wrote:
Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert.
On May 26, 2009, at 7:51 AM, Ian Campbell wrote:
On Fri, 2009-05-22 at 19:55 -0400, Jeremy Fitzhardinge wrote:
Ian Campbell wrote:
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the
On Wed, 2009-05-27 at 15:05 -0400, Becky Bruce wrote:
On May 22, 2009, at 6:11 AM, Ian Campbell wrote:
BTW do you need swiotlb_bus_to_virt to be __weak or is the fact that
it
is implemented in terms of swiotlb_bus_to_phys sufficient?
The default one in swiotlb calls phys_to_virt on
On May 27, 2009, at 3:29 PM, Ian Campbell wrote:
On Wed, 2009-05-27 at 15:05 -0400, Becky Bruce wrote:
On May 22, 2009, at 6:11 AM, Ian Campbell wrote:
BTW do you need swiotlb_bus_to_virt to be __weak or is the fact that
it
is implemented in terms of swiotlb_bus_to_phys sufficient?
The
Ben,
Any comments on this.. need a decision so we can have patches ready
for .31.
- k
On May 19, 2009, at 8:04 AM, Kumar Gala wrote:
On May 18, 2009, at 4:49 PM, Benjamin Herrenschmidt wrote:
On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
Part of this is how the generic swiotlb
On Fri, 2009-05-22 at 19:55 -0400, Jeremy Fitzhardinge wrote:
Ian Campbell wrote:
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert.
Hello,
On Sat, May 23, 2009 at 1:55 AM, Jeremy Fitzhardinge jer...@goop.org wrote:
Ian Campbell wrote:
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have
On Thu, 21 May 2009 20:01:37 +0100
Ian Campbell ian.campb...@eu.citrix.com wrote:
It's not actually clear to me that we need that check, though. Can
someone explain what case that was designed to catch?
If map_single fails and returns NULL then we try to use
io_tlb_overflow_buffer, if
On Thu, 21 May 2009 13:18:54 -0700
Jeremy Fitzhardinge jer...@goop.org wrote:
Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert. In every case, this is a conversion I've
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert. In every case, this is a conversion I've already done and
that I need in the calling code
Ian Campbell wrote:
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert. In every case, this is a conversion I've already done and
that I need
Becky Bruce wrote:
If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
static inline int is_buffer_dma_capable(struct device *dev,
dma_addr_t addr, size_t size)
then we don't need two checking functions, address_needs_mapping and
range_needs_mapping.
It's never been clear
On May 21, 2009, at 12:43 PM, Jeremy Fitzhardinge wrote:
Becky Bruce wrote:
If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
static inline int is_buffer_dma_capable(struct device *dev,
dma_addr_t addr, size_t size)
then we don't need two checking functions,
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
We have both in every case but one,
which is in swiotlb_map_page where we call address_needs_mapping()
without calling range_needs_mapping.
The reason it calls address_needs_mapping without range_needs_mapping is
that in the
Becky Bruce wrote:
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert. In every case, this is a conversion I've already done and
that I need in the calling code as well. Can we pass in both the
On Thu, 2009-05-21 at 16:18 -0400, Jeremy Fitzhardinge wrote:
I guess the test is checking for a bad implementation of map_single().
More importantly the io_tlb_overflow_buffer is basically a second chance
if you exhaust the swiotlb pool. The check seems to be there to ensure
that the second
On May 18, 2009, at 4:49 PM, Benjamin Herrenschmidt wrote:
On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
Part of this is how the generic swiotlb code works and part of it
was
our desire not to bloat dev archdata by adding such info that as you
say is either bus specific or conveyed in
On May 17, 2009, at 11:49 PM, Benjamin Herrenschmidt wrote:
On Thu, 2009-05-14 at 17:42 -0500, Becky Bruce wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms. Probably the most interesting bit is the
On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
Part of this is how the generic swiotlb code works and part of it
was
our desire not to bloat dev archdata by adding such info that as you
say is either bus specific or conveyed in the dma addr mask.
Right but perf sucks :-)
Maybe an
CC'ed linux-kernel
On Thu, 14 May 2009 17:42:28 -0500
Becky Bruce bec...@kernel.crashing.org wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms. Probably the most interesting bit is the
addition of
On Thu, 2009-05-14 at 17:42 -0500, Becky Bruce wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms. Probably the most interesting bit is the
addition of addr_needs_map to dma_ops - we need this as
a
On May 14, 2009, at 5:42 PM, Becky Bruce wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms. Probably the most interesting bit is the
addition of addr_needs_map to dma_ops - we need this as
a dma_op
25 matches
Mail list logo
