18 Apr, 2013
1 commit
-
Chao said that kdump does does work well on his system on 3.8
without extra parameter, even iommu does not work with kdump.
And now have to append crashkernel_low=Y in first kernel to make
kdump work.We have now modified crashkernel=X to allocate memory beyong 4G (if
available) and do not allocate low range for crashkernel if the user
does not specify that with crashkernel_low=Y. This causes regression
if iommu is not enabled. Without iommu, swiotlb needs to be setup in
first 4G and there is no low memory available to second kernel.Set crashkernel_low automatically if the user does not specify that.
For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.-v3: add swiotlb_size() according to Konrad.
-v4: add comments what 8M is for according to hpa.
also update more crashkernel_low= in kernel-parameters.txt
-v5: update changelog according to Vivek.
-v6: Change description about swiotlb referring according to HATAYAMA.Reported-by: WANG Chao
Tested-by: WANG Chao
Signed-off-by: Yinghai Lu
Link: http://lkml.kernel.org/r/1366089828-19692-2-git-send-email-yinghai@kernel.org
Acked-by: Vivek Goyal
Signed-off-by: H. Peter Anvin
30 Jan, 2013
1 commit
-
Normal boot path on system with iommu support:
swiotlb buffer will be allocated early at first and then try to initialize
iommu, if iommu for intel or AMD could setup properly, swiotlb buffer
will be freed.The early allocating is with bootmem, and could panic when we try to use
kdump with buffer above 4G only, or with memmap to limit mem under 4G.
for example: memmap=4095M$1M to remove memory under 4G.According to Eric, add _nopanic version and no_iotlb_memory to fail
map single later if swiotlb is still needed.-v2: don't pass nopanic, and use -ENOMEM return value according to Eric.
panic early instead of using swiotlb_full to panic...according to Eric/Konrad.
-v3: make swiotlb_init to be notpanic, but will affect:
arm64, ia64, powerpc, tile, unicore32, x86.
-v4: cleanup swiotlb_init by removing swiotlb_init_with_default_size.Suggested-by: Eric W. Biederman
Signed-off-by: Yinghai Lu
Link: http://lkml.kernel.org/r/1359058816-7615-36-git-send-email-yinghai@kernel.org
Reviewed-and-tested-by: Konrad Rzeszutek Wilk
Cc: Joerg Roedel
Cc: Ralf Baechle
Cc: Jeremy Fitzhardinge
Cc: Kyungmin Park
Cc: Marek Szyprowski
Cc: Arnd Bergmann
Cc: Andrzej Pietrasiewicz
Cc: linux-mips@linux-mips.org
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: Shuah Khan
Signed-off-by: H. Peter Anvin
30 Oct, 2012
7 commits
-
Currently swiotlb is the only consumer for swiotlb_bounce. Since that is the
case it doesn't make much sense to be exporting it so make it a static
function only.In addition we can save a few more lines of code by making it so that it
accepts the DMA address as a physical address instead of a virtual one. This
is the last piece in essentially pushing all of the DMA address values to use
physical addresses in swiotlb.In order to clarify things since we now have 2 physical addresses in use
inside of swiotlb_bounce I am renaming phys to orig_addr, and dma_addr to
tlb_addr. This way is should be clear that orig_addr is contained within
io_orig_addr and tlb_addr is an address within the io_tlb_addr buffer.Signed-off-by: Alexander Duyck
Signed-off-by: Konrad Rzeszutek Wilk -
This change makes it so that the sync functionality also uses physical
addresses. This helps to further reduce the use of virt_to_phys and
phys_to_virt functions.In order to clarify things since we now have 2 physical addresses in use
inside of swiotlb_tbl_sync_single I am renaming phys to orig_addr, and
dma_addr to tlb_addr. This way is should be clear that orig_addr is
contained within io_orig_addr and tlb_addr is an address within the
io_tlb_addr buffer.Signed-off-by: Alexander Duyck
Signed-off-by: Konrad Rzeszutek Wilk -
This change makes it so that the unmap functionality also uses physical
addresses. This helps to further reduce the use of virt_to_phys and
phys_to_virt functions.In order to clarify things since we now have 2 physical addresses in use
inside of swiotlb_tbl_unmap_single I am renaming phys to orig_addr, and
dma_addr to tlb_addr. This way is should be clear that orig_addr is
contained within io_orig_addr and tlb_addr is an address within the
io_tlb_addr buffer.Signed-off-by: Alexander Duyck
Signed-off-by: Konrad Rzeszutek Wilk -
This change makes it so that swiotlb_tbl_map_single will return a physical
address instead of a virtual address when called. The advantage to this once
again is that we are avoiding a number of virt_to_phys and phys_to_virt
translations by working with everything as a physical address.One change I had to make in order to support using physical addresses is that
I could no longer trust 0 to be a invalid physical address on all platforms.
So instead I made it so that ~0 is returned on error. This should never be a
valid return value as it implies that only one byte would be available for
use.In order to clarify things since we now have 2 physical addresses in use
inside of swiotlb_tbl_map_single I am renaming phys to orig_addr, and
dma_addr to tlb_addr. This way is should be clear that orig_addr is
contained within io_orig_addr and tlb_addr is an address within the
io_tlb_addr buffer.Signed-off-by: Alexander Duyck
Signed-off-by: Konrad Rzeszutek Wilk -
This change makes it so that we can avoid virt_to_phys overhead when using the
io_tlb_overflow_buffer. My original plan was to completely remove the value
and replace it with a constant but I had seen that there were recent patches
that stated this couldn't be done until all device drivers that depended on
that functionality be updated.Signed-off-by: Alexander Duyck
Signed-off-by: Konrad Rzeszutek Wilk -
This change replaces all references to the virtual address for io_tlb_start
with references to the physical address io_tlb_end. The main advantage of
replacing the virtual address with a physical address is that we can avoid
having to do multiple translations from the virtual address to the physical
one needed for testing an existing DMA address.Signed-off-by: Alexander Duyck
Signed-off-by: Konrad Rzeszutek Wilk -
This change replaces all references to the virtual address for io_tlb_end
with references to the physical address io_tlb_end. The main advantage of
replacing the virtual address with a physical address is that we can avoid
having to do multiple translations from the virtual address to the physical
one needed for testing an existing DMA address.Signed-off-by: Alexander Duyck
Signed-off-by: Konrad Rzeszutek Wilk
22 Aug, 2012
1 commit
-
This enables the caller to initialize swiotlb with its own iotlb
memory late in the bootup.See git commit eb605a5754d050a25a9f00d718fb173f24c486ef
"swiotlb: add swiotlb_tbl_map_single library function" which will
explain the full details of what it can be used for.CC: FUJITA Tomonori
[v1: Fold in smatch warning]
Signed-off-by: Konrad Rzeszutek Wilk
30 May, 2012
1 commit
-
Print swiotlb info in a style consistent with the %pR style used elsewhere
in the kernel. For example:-Placing 64MB software IO TLB between ffff88007a662000 - ffff88007e662000
-software IO TLB at phys 0x7a662000 - 0x7e662000
+software IO TLB [mem 0x7a662000-0x7e661fff] (64MB) mapped at [ffff88007a662000-ffff88007e661fff]Signed-off-by: Bjorn Helgaas
Cc: Yinghai Lu
Cc: Konrad Rzeszutek Wilk
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Mar, 2012
1 commit
-
Pull cleanup of fs/ and lib/ users of module.h from Paul Gortmaker:
"Fix up files in fs/ and lib/ dirs to only use module.h if they really
need it.These are trivial in scope vs the work done previously. We now have
things where any few remaining cleanups can be farmed out to arch or
subsystem maintainers, and I have done so when possible. What is
remaining here represents the bits that don't clearly lie within a
single arch/subsystem boundary, like the fs dir and the lib dir.Some duplicate includes arising from overlapping fixes from
independent subsystem maintainer submissions are also quashed."Fix up trivial conflicts due to clashes with other include file cleanups
(including some due to the previous bug.h cleanup pull).* tag 'module-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
lib: reduce the use of module.h wherever possible
fs: reduce the use of module.h wherever possible
includecheck: delete any duplicate instances of module.h
20 Mar, 2012
1 commit
-
Signed-off-by: Cong Wang
08 Mar, 2012
1 commit
-
For files only using THIS_MODULE and/or EXPORT_SYMBOL, map
them onto including export.h -- or if the file isn't even
using those, then just delete the include. Fix up any implicit
include dependencies that were being masked by module.h along
the way.Signed-off-by: Paul Gortmaker
06 Dec, 2011
1 commit
-
As a mechanism to detect whether SWIOTLB is enabled or not.
We also fix the spelling - it was swioltb instead of
swiotlb.CC: FUJITA Tomonori
[v1: Ripped out swiotlb_enabled]
Signed-off-by: Konrad Rzeszutek Wilk
07 Jun, 2011
1 commit
-
By default the io_tlb_nslabs is set to zero, and gets set to
whatever value is passed in via swiotlb_init_with_tbl function.
The default value passed in is 64MB. However, if the user provides
the 'swiotlb=' the default value is ignored and
the value provided by the user is used... Except when the SWIOTLB
is used under Xen - there the default value of 64MB is used and
the Xen-SWIOTLB has no mechanism to get the 'io_tlb_nslabs' filled
out by setup_io_tlb_npages functions. This patch provides a function
for the Xen-SWIOTLB to call to see if the io_tlb_nslabs is set
and if so use that value.Signed-off-by: FUJITA Tomonori
Signed-off-by: Konrad Rzeszutek Wilk
26 Feb, 2011
1 commit
-
swiotlb's map_page wrongly calls panic() when it can't find a buffer fit
for device's dma mask. It should return an error instead.Devices with an odd dma mask (i.e. under 4G) like b44 network card hit
this bug (the system crashes):http://marc.info/?l=linux-kernel&m=129648943830106&w=2
If swiotlb returns an error, b44 driver can use the own bouncing
mechanism.Reported-by: Chuck Ebbert
Signed-off-by: FUJITA Tomonori
Tested-by: Arkadiusz Miskiewicz
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
02 Nov, 2010
1 commit
-
"gadget", "through", "command", "maintain", "maintain", "controller", "address",
"between", "initiali[zs]e", "instead", "function", "select", "already",
"equal", "access", "management", "hierarchy", "registration", "interest",
"relative", "memory", "offset", "already",Signed-off-by: Uwe Kleine-König
Signed-off-by: Jiri Kosina
12 Oct, 2010
2 commits
-
We could call free_bootmem_late() if swiotlb is not used, and
it will shrink to page alignment.So alloc them with page alignment at first, to avoid lose two pages
before patch:
[ 0.000000] memblock_x86_reserve_range: [00d3600000, 00d7600000] swiotlb buffer
[ 0.000000] memblock_x86_reserve_range: [00d7e7ef40, 00d7e9ef40] swiotlb list
[ 0.000000] memblock_x86_reserve_range: [00d7e3ef40, 00d7e7ef40] swiotlb orig_ad
[ 0.000000] memblock_x86_reserve_range: [000008a000, 0000092000] swiotlb overfloafter patch will get
[ 0.000000] memblock_x86_reserve_range: [00d3600000, 00d7600000] swiotlb buffer
[ 0.000000] memblock_x86_reserve_range: [00d7e7e000, 00d7e9e000] swiotlb list
[ 0.000000] memblock_x86_reserve_range: [00d7e3e000, 00d7e7e000] swiotlb orig_ad
[ 0.000000] memblock_x86_reserve_range: [000008a000, 0000092000] swiotlb overfloSigned-off-by: Yinghai Lu
Acked-by: FUJITA Tomonori
Cc: Becky Bruce
Signed-off-by: Konrad Rzeszutek Wilk -
We don't need to export io_tlb_overflow_buffer. I'll remove
io_tlb_overflow_buffer completely in the long term though.Signed-off-by: FUJITA Tomonori
Signed-off-by: Konrad Rzeszutek Wilk
07 Jun, 2010
5 commits
-
We put the functions dealing with the operations on
the SWIOTLB buffer in the header and make those functions non-static.
And also make the functions exported via EXPORT_SYMBOL_GPL.See "swiotlb: swiotlb: add swiotlb_tbl_map_single library function" for
full description of patchset.[v2: swiotlb_sync_single_range_for_* no more. Remove usage.]
Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: FUJITA Tomonori
Tested-by: Albert Herranz -
.. to catch anybody doing something funky.
See "swiotlb: swiotlb: add swiotlb_tbl_map_single library function" for
full description of patchset.[v2: swiotlb_sync_single_range_* no more - removed usage]
[v3: enum dma_data_direction direction -> enum dma_data_direction dir]Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: FUJITA Tomonori
Tested-by: Albert Herranz -
The functions that operate on io_tlb_list/io_tlb_start/io_tlb_orig_addr
have the prefix 'swiotlb_tbl' now.See "swiotlb: swiotlb: add swiotlb_tbl_map_single library function" for
full description of patchset.Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: FUJITA Tomonori
Tested-by: Albert Herranz -
This enables the caller to initialize swiotlb with its own iotlb
memory.See "swiotlb: swiotlb: add swiotlb_tbl_map_single library function" for
full description of patchset.[v2: changed ..with_tlb to ..with_tbl]
Signed-off-by: FUJITA Tomonori
Reviewed-by: Konrad Rzeszutek Wilk
Tested-by: Albert Herranz -
swiotlb_tbl_map_single() takes the dma address of iotlb instead of
using swiotlb_virt_to_bus().[v2: changed swiotlb_tlb to swiotlb_tbl]
[v3: changed u64 to dma_addr_t]This patch:
This is a set of patches that separate the address translation
(virt_to_phys, virt_to_bus, etc) and allocation of the SWIOTLB buffer
from the SWIOTLB library.The idea behind this set of patches is to make it possible to have separate
mechanisms for translating virtual to physical or virtual to DMA addresses
on platforms which need an SWIOTLB, and where physical != PCI bus address
and also to allocate the core IOTLB memory outside SWIOTLB.One customers of this is the pv-ops project, which can switch between
different modes of operation depending on the environment it is running in:
bare-metal or virtualized (Xen for now). Another is the Wii DMA - used to
implement the MEM2 DMA facility needed by its EHCI controller (for details:
http://lkml.org/lkml/2010/5/18/303)On bare-metal SWIOTLB is used when there are no hardware IOMMU. In virtualized
environment it used when PCI pass-through is enabled for the guest. The problems
with PCI pass-through is that the guest's idea of PFN's is not the real thing.
To fix that, there is translation layer for PFN->machine frame number and vice-versa.
To bubble that up to the SWIOTLB layer there are two possible solutions.One solution has been to wholesale copy the SWIOTLB, stick it in
arch/x86/xen/swiotlb.c and modify the virt_to_phys, phys_to_virt and others
to use the Xen address translation functions. Unfortunately, since the kernel can
run on bare-metal, there would be big code overlap with the real SWIOTLB.
(git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git xen/dom0/swiotlb-new)Another approach, which this set of patches explores, is to abstract the
address translation and address determination functions away from the
SWIOTLB book-keeping functions. This way the core SWIOTLB library functions
are present in one place, while the address related functions are in
a separate library that can be loaded when running under non-bare-metal platform.Changelog:
Since the last posting [v8.2] Konrad has done:
- Added this changelog in the patch and referenced in the other patches
this description.
- 'enum dma_data_direction direction' to 'enum dma.. dir' so to be
unified.
[v8-v8.2 changes:]
- Rolled-up the last two patches in one.
- Rebased against linus latest. That meant dealing with swiotlb_sync_single_range_* changes.
- added Acked-by: Fujita Tomonori and Tested-by: Albert Herranz
[v7-v8 changes:]
- Minimized the list of exported functions.
- Integrated Fujita's patches and changed "swiotlb_tlb" to "swiotlb_tbl" in them.
[v6-v7 changes:]
- Minimized the amount of exported functions/variable with a prefix of: "swiotbl_tbl".
- Made the usage of 'int dir' to be 'enum dma_data_direction'.
[v5-v6 changes:]
- Made the exported functions/variables have the 'swiotlb_bk' prefix.
- dropped the checkpatches/other reworksSigned-off-by: FUJITA Tomonori
Reviewed-by: Konrad Rzeszutek Wilk
Tested-by: Albert Herranz
28 May, 2010
1 commit
-
swiotlb_sync_single_range_for_cpu and swiotlb_sync_single_range_for_device
are unnecessary because swiotlb_sync_single_for_cpu and
swiotlb_sync_single_for_device can be used instead.Signed-off-by: FUJITA Tomonori
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
16 Dec, 2009
1 commit
-
dma_mask is, when interpreted as address, the last valid byte, and hence
comparison msut also be done using the last valid of the buffer in
question.Also fix the open-coded instances in lib/swiotlb.c.
Signed-off-by: Jan Beulich
Cc: FUJITA Tomonori
Cc: Becky Bruce
Cc: "Luck, Tony"
Cc: Benjamin Herrenschmidt
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Dec, 2009
1 commit
-
Conflicts:
kernel/irq/chip.c
04 Dec, 2009
1 commit
-
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.Signed-off-by: André Goddard Rosa
Signed-off-by: Jiri Kosina
11 Nov, 2009
1 commit
-
POWERPC doesn't expect it to be used.
This fixes the linux-next build failure reported by
Stephen Rothwell:lib/swiotlb.c: In function 'setup_io_tlb_npages':
lib/swiotlb.c:114: error: 'swiotlb' undeclared (first use in this function)Reported-by: Stephen Rothwell
Signed-off-by: FUJITA Tomonori
Cc: peterz@infradead.org
LKML-Reference:
Signed-off-by: Ingo Molnar
10 Nov, 2009
3 commits
-
If HW IOMMU initialization fails (Intel VT-d often does this,
typically due to BIOS bugs), we fall back to nommu. It doesn't
work for the majority since nowadays we have more than 4GB
memory so we must use swiotlb instead of nommu.The problem is that it's too late to initialize swiotlb when HW
IOMMU initialization fails. We need to allocate swiotlb memory
earlier from bootmem allocator. Chris explained the issue in
detail:http://marc.info/?l=linux-kernel&m=125657444317079&w=2
The current x86 IOMMU initialization sequence is too complicated
and handling the above issue makes it more hacky.This patch changes x86 IOMMU initialization sequence to handle
the above issue cleanly.The new x86 IOMMU initialization sequence are:
1. we initialize the swiotlb (and setting swiotlb to 1) in the case
of (max_pfn > MAX_DMA32_PFN && !no_iommu). dma_ops is set to
swiotlb_dma_ops or nommu_dma_ops. if swiotlb usage is forced by
the boot option, we finish here.2. we call the detection functions of all the IOMMUs
3. the detection function sets x86_init.iommu.iommu_init to the
IOMMU initialization function (so we can avoid calling the
initialization functions of all the IOMMUs needlessly).4. if the IOMMU initialization function doesn't need to swiotlb
then sets swiotlb to zero (e.g. the initialization is
sucessful).5. if we find that swiotlb is set to zero, we free swiotlb
resource.Signed-off-by: FUJITA Tomonori
Cc: chrisw@sous-sol.org
Cc: dwmw2@infradead.org
Cc: joerg.roedel@amd.com
Cc: muli@il.ibm.com
LKML-Reference:
Signed-off-by: Ingo Molnar -
This enables us to avoid printing swiotlb memory info when we
initialize swiotlb. After swiotlb initialization, we could find
that we don't need swiotlb.This patch removes the code to print swiotlb memory info in
swiotlb_init() and exports the function to do that.Signed-off-by: FUJITA Tomonori
Cc: chrisw@sous-sol.org
Cc: dwmw2@infradead.org
Cc: joerg.roedel@amd.com
Cc: muli@il.ibm.com
Cc: tony.luck@intel.com
Cc: benh@kernel.crashing.org
LKML-Reference:
[ -v2: merge up conflict ]
Signed-off-by: Ingo Molnar -
swiotlb_free() function frees all allocated memory for swiotlb.
We need to initialize swiotlb before IOMMU initialization (x86
and powerpc needs to allocate memory from bootmem allocator). If
IOMMU initialization is successful, we need to free swiotlb
resource (don't want to waste 64MB).Signed-off-by: FUJITA Tomonori
Cc: chrisw@sous-sol.org
Cc: dwmw2@infradead.org
Cc: joerg.roedel@amd.com
Cc: muli@il.ibm.com
LKML-Reference:
[ -v2: build fix for the !CONFIG_SWIOTLB case ]
Signed-off-by: Ingo Molnar
21 Aug, 2009
1 commit
-
swiotlb_full() in lib/swiotlb.c throws one of two panic messages
based on whether the direction of transfer is from the device
or to the device. The logic around this is somewhat weird in
the case of bidirectional transfers. It appears to want to
throw both in succession, but since its a panic only the first
makes it.This patch adds a third, separate error for DMA_BIDIRECTIONAL
to make things a bit clearer.Signed-off-by: Casey Dahlin
Cc: FUJITA Tomonori
Cc: Becky Bruce
[ further fixed the error message ]
Signed-off-by: Andrew Morton
LKML-Reference:
Signed-off-by: Ingo Molnar
28 Jul, 2009
5 commits
-
This converts swiotlb to use phys_to_dma and dma_to_phys instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().swiotlb_phys_to_bus() and swiotlb_bus_to_phys() are not necessary so
this patch also removes them.Signed-off-by: FUJITA Tomonori
Acked-by: Becky Bruce -
This converts swiotlb to use dma_capable() instead of
swiotlb_arch_address_needs_mapping() and is_buffer_dma_capable().Signed-off-by: FUJITA Tomonori
Acked-by: Becky Bruce -
swiotlb_bus_to_virt is unncessary; we can use swiotlb_bus_to_phys and
phys_to_virt instead.Signed-off-by: FUJITA Tomonori
Acked-by: Becky Bruce -
Nobody uses swiotlb_arch_range_needs_mapping().
Signed-off-by: FUJITA Tomonori
Acked-by: Becky Bruce -
Nobody uses swiotlb_alloc().
Signed-off-by: FUJITA Tomonori
Acked-by: Becky Bruce