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 scena
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
> >
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 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 de
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 phy
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 p
On May 22, 2009, at 5:51 AM, FUJITA Tomonori wrote:
On Thu, 21 May 2009 13:18:54 -0700
Jeremy Fitzhardinge 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,
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 low
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
>
Hello,
On Sat, May 23, 2009 at 1:55 AM, 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 t
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
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 co
On Thu, 21 May 2009 13:18:54 -0700
Jeremy Fitzhardinge 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 already done an
On Thu, 21 May 2009 20:01:37 +0100
Ian Campbell 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 that is somehow not D
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 cha
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
phys_ad
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 swiotlb_f
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, address_ne
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 19, 2009, at 12:27 AM, FUJITA Tomonori wrote:
CC'ed linux-kernel
On Thu, 14 May 2009 17:42:28 -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 inter
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 code works and part of it
was
our desire not to bloat dev archdata by adding such info that
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
CC'ed linux-kernel
On Thu, 14 May 2009 17:42:28 -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_op
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 :-)
Mayb
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
a
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
>
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 bec
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 because the decision of whether or not an addr
can be m
28 matches
Mail list logo