[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH 02/15] [swiotlb] Add swiotlb_engine structure for tracking multiple software IO TLBs.
* Konrad Rzeszutek Wilk (konrad.wilk@xxxxxxxxxx) wrote: > The structure contains all of the existing variables used in > software IO TLB (swiotlb.c) collected within a structure. > > Additionally a name variable and a deconstructor (release) function > variable is defined for API usages. > > The other set of functions: is_swiotlb_buffer, dma_capable, phys_to_bus, > bus_to_phys, virt_to_bus, and bus_to_virt server as a method to abstract > them out of the SWIOTLB library. > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > --- > include/linux/swiotlb.h | 94 > +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 94 insertions(+), 0 deletions(-) > > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h > index febedcf..781c3aa 100644 > --- a/include/linux/swiotlb.h > +++ b/include/linux/swiotlb.h > @@ -24,6 +24,100 @@ extern int swiotlb_force; > > extern void swiotlb_init(int verbose); > You can move the comments to a kerneldoc section for proper documentation. /** * struct swiotlb_engine - short desc... * @name: Name of the engine... etc > +struct swiotlb_engine { > + > + /* > + * Name of the engine (ie: "Software IO TLB") > + */ > + const char *name; > + > + /* > + * Used to do a quick range check in unmap_single and > + * sync_single_*, to see if the memory was in fact allocated by this > + * API. > + */ > + char *start; > + char *end; Isn't this still global to swiotlb, not specific to the backend impl.? > + /* > + * The number of IO TLB blocks (in groups of 64) betweeen start and > + * end. This is command line adjustable via setup_io_tlb_npages. > + */ > + unsigned long nslabs; Same here. > + > + /* > + * When the IOMMU overflows we return a fallback buffer. > + * This sets the size. > + */ > + unsigned long overflow; > + > + void *overflow_buffer; And here. > + /* > + * This is a free list describing the number of free entries available > + * from each index > + */ > + unsigned int *list; > + > + /* > + * Current marker in the start through end location. Is incremented > + * on each map and wraps around. > + */ > + unsigned int index; > + > + /* > + * We need to save away the original address corresponding to a mapped > + * entry for the sync operations. > + */ > + phys_addr_t *orig_addr; > + > + /* > + * IOMMU private data. > + */ > + void *priv; > + /* > + * The API call to free a SWIOTLB engine if another wants to register > + * (or if want to turn SWIOTLB off altogether). > + * It is imperative that this function checks for existing DMA maps > + * and not release the IOTLB if there are out-standing maps. > + */ > + int (*release)(struct swiotlb_engine *); > + > + /* > + * Is the DMA (Bus) address within our bounce buffer (start and end). > + */ > + int (*is_swiotlb_buffer)(struct swiotlb_engine *, dma_addr_t dev_addr, > + phys_addr_t phys); > + Why is this implementation specific? > + /* > + * Is the DMA (Bus) address reachable by the PCI device?. > + */ > + bool (*dma_capable)(struct device *, dma_addr_t, phys_addr_t, size_t); This too... > + /* > + * Physical to bus (DMA) address translation. On > + * most platforms this is an equivalent function. > + */ > + dma_addr_t (*phys_to_bus)(struct device *hwdev, phys_addr_t paddr); > + > + /* > + * Bus (DMA) to physical address translation. On most > + * platforms this is an equivalant function. > + */ > + phys_addr_t (*bus_to_phys)(struct device *hwdev, dma_addr_t baddr); > + > + /* > + * Virtual to bus (DMA) address translation. On most platforms > + * this is a call to __pa(address). > + */ > + dma_addr_t (*virt_to_bus)(struct device *hwdev, void *address); > + > + /* > + * Bus (DMA) to virtual address translation. On most platforms > + * this is a call to __va(address). > + */ > + void* (*bus_to_virt)(struct device *hwdev, dma_addr_t address); > +}; > + > extern void > *swiotlb_alloc_coherent(struct device *hwdev, size_t size, > dma_addr_t *dma_handle, gfp_t flags); > -- > 1.6.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |