linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: galak@kernel.crashing.org, hch@infradead.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	ian.campbell@citrix.com, beckyb@kernel.crashing.org
Subject: Re: [PATCH 4/7] swiotlb: Allow arch override of address_needs_mapping
Date: Wed, 08 Apr 2009 14:55:55 -0700	[thread overview]
Message-ID: <49DD1D6B.6030001@goop.org> (raw)
In-Reply-To: <20090409061444G.fujita.tomonori@lab.ntt.co.jp>

FUJITA Tomonori wrote:
> On Wed, 8 Apr 2009 15:56:32 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>   
>> On Apr 8, 2009, at 3:38 PM, Christoph Hellwig wrote:
>>
>>     
>>> On Wed, Apr 08, 2009 at 09:09:18AM -0500, Kumar Gala wrote:
>>>       
>>>> From: Becky Bruce <beckyb@kernel.crashing.org>
>>>>
>>>> Some architectures require additional checking to determine
>>>> if a device can dma to an address and need to provide their
>>>> own address_needs_mapping..
>>>>         
>>> Shouldn't we just move it completely to the arch?  I think that ia64  
>>> and
>>> x86 currently use the same one is more of an accident.
>>>       
>> It seems like the swiotlb code uses __weak for a number of things:
>>
>> lib/swiotlb.c:void * __weak __init swiotlb_alloc_boot(size_t size,  
>> unsigned long nslabs)
>> lib/swiotlb.c:void * __weak swiotlb_alloc(unsigned order, unsigned  
>> long nslabs)
>> lib/swiotlb.c:dma_addr_t __weak swiotlb_phys_to_bus(struct device  
>> *hwdev, phys_addr_t paddr)
>> lib/swiotlb.c:phys_addr_t __weak swiotlb_bus_to_phys(struct device  
>> *hwdev, dma_addr_t baddr)
>> lib/swiotlb.c:void * __weak swiotlb_bus_to_virt(struct device *hwdev,  
>> dma_addr_t address)
>> lib/swiotlb.c:int __weak swiotlb_arch_address_needs_mapping(struct  
>> device *hwdev,
>> lib/swiotlb.c:int __weak swiotlb_arch_range_needs_mapping(phys_addr_t  
>> paddr, size_t size)
>>
>> instead of #ifndef HAVE_ARCH_<FOO>.  Not sure if there is a historical  
>> reason for that.
>>     
>
> ia64 and x86_64 use swiotlb but neither need this function. And
> neither need any above __weak. They were added for dom0 support.
> Yeah, swiotlb is much cleaner and better if we don't add dom0 support.
>   

Some architectures need non-trivial bus<->phys conversion routines, etc, 
so either we can require it that all architectures wishing to use 
swiotlb define these functions, or have weak default functions that can 
be overridden by architectures where necessary.

This isn't a specific Xen dom0 requirement, except that enabling it in 
the config will override these functions (but now in a Xen-only file, 
rather than affecting the normal x86 pci-swiotlb.c).

    J

  reply	other threads:[~2009-04-08 21:56 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-08 14:09 [PATCH V3 0/7] swiotlb: changes for powerpc/highmem Kumar Gala
2009-04-08 14:09 ` [PATCH 1/7] swiotlb: comment corrections (no code changes) Kumar Gala
2009-04-08 14:09   ` [PATCH 2/7] swiotlb: fix compile warning Kumar Gala
2009-04-08 14:09     ` [PATCH 3/7] swiotlb: map_page fix for highmem systems Kumar Gala
2009-04-08 14:09       ` [PATCH 4/7] swiotlb: Allow arch override of address_needs_mapping Kumar Gala
2009-04-08 14:09         ` [PATCH 5/7] swiotlb: Rename unmap_single to do_unmap_single Kumar Gala
2009-04-08 14:09           ` [PATCH 6/7] swiotlb: Use swiotlb_sync_single instead of duplicating code Kumar Gala
2009-04-08 14:09             ` [PATCH 7/7] swiotlb: Change swiotlb_bus_to[phys,virt] prototypes Kumar Gala
2009-04-08 15:25               ` [tip:core/iommu] swiotlb: change " Becky Bruce
2009-04-08 15:25             ` [tip:core/iommu] swiotlb: use swiotlb_sync_single instead of duplicating code Becky Bruce
2009-04-08 15:25           ` [tip:core/iommu] swiotlb: rename unmap_single to do_unmap_single Becky Bruce
2009-04-08 15:25         ` [tip:core/iommu] swiotlb: allow arch override of address_needs_mapping Becky Bruce
2009-04-08 20:38         ` [PATCH 4/7] swiotlb: Allow " Christoph Hellwig
2009-04-08 20:56           ` Kumar Gala
2009-04-08 21:15             ` FUJITA Tomonori
2009-04-08 21:55               ` Jeremy Fitzhardinge [this message]
2009-04-08 22:10                 ` FUJITA Tomonori
2009-04-08 22:36                   ` Jeremy Fitzhardinge
2009-04-08 23:01                     ` FUJITA Tomonori
2009-04-08 23:16                       ` Jeremy Fitzhardinge
2009-04-08 23:37                         ` FUJITA Tomonori
2009-04-09  0:09                           ` Jeremy Fitzhardinge
2009-04-09  4:43                             ` Kumar Gala
2009-04-09 18:34                             ` FUJITA Tomonori
2009-04-09 19:19                               ` Jeremy Fitzhardinge
2009-04-09 19:43                                 ` FUJITA Tomonori
2009-04-09 19:50                                 ` FUJITA Tomonori
2009-04-09 19:54                                   ` Jeremy Fitzhardinge
2009-04-09  4:59                       ` Kumar Gala
2009-04-09 18:50                         ` FUJITA Tomonori
2009-04-09 20:10                           ` Kumar Gala
2009-04-09 20:25                             ` Kumar Gala
2009-04-08 22:24               ` Christoph Hellwig
2009-04-08 15:24       ` [tip:core/iommu] swiotlb: map_page fix for highmem systems Becky Bruce
2009-04-08 15:24     ` [tip:core/iommu] swiotlb: fix compile warning Becky Bruce
2009-04-08 15:24   ` [tip:core/iommu] swiotlb: comment corrections Becky Bruce
2009-04-08 14:21 ` [PATCH V3 0/7] swiotlb: changes for powerpc/highmem Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2009-04-04  1:56 [PATCH V2 " Becky Bruce
2009-04-04  1:56 ` [PATCH 1/7] swiotlb: comment corrections (no code changes) Becky Bruce
2009-04-04  1:56   ` [PATCH 2/7] swiotlb: fix compile warning Becky Bruce
2009-04-04  1:56     ` [PATCH 3/7] swiotlb: map_page fix for highmem systems Becky Bruce
2009-04-04  1:56       ` [PATCH 4/7] swiotlb: Allow arch override of address_needs_mapping Becky Bruce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49DD1D6B.6030001@goop.org \
    --to=jeremy@goop.org \
    --cc=beckyb@kernel.crashing.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=galak@kernel.crashing.org \
    --cc=hch@infradead.org \
    --cc=ian.campbell@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).