linux-toradex.git/arch/powerpc/kernel/iommu.c, branch v3.4.2

fadump: Register for firmware assisted dump.

2012-02-22T23:50:01+00:00

On 2012-02-20 11:02:51 Mon, Paul Mackerras wrote:
> On Thu, Feb 16, 2012 at 04:44:30PM +0530, Mahesh J Salgaonkar wrote:
>
> If I have read the code correctly, we are going to get this printk on
> non-pSeries machines or on older pSeries machines, even if the user
> has not put the fadump=on option on the kernel command line.  The
> printk will be annoying since there is no actual error condition.  It
> seems to me that the condition for the printk should include
> fw_dump.fadump_enabled.  In other words you should probably add
>
> 	if (!fw_dump.fadump_enabled)
> 		return 0;
>
> at the beginning of the function.

Hi Paul,

Thanks for pointing it out. Please find the updated patch below.

The existing patches above this (4/10 through 10/10) cleanly applies
on this update.

Thanks,
-Mahesh.

Signed-off-by: Benjamin Herrenschmidt

powerpc: Reserve iommu page 0

2011-09-23T00:27:03+00:00

Some devices have a dma-window that starts at the address 0. This allows
DMA addresses to be mapped to this address and returned to drivers as a
valid DMA address. Some drivers may not behave well in this case, since
the address 0 is considered an error or not allocated.

The solution to avoid this kind of error from happening is reserve the
page addressed as 0 so it cannot be allocated for a DMA mapping.

Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Benjamin Herrenschmidt

powerpc: iommu: Add device name to iommu error printks

2010-12-09T04:35:32+00:00

Right now its difficult to see which device is running out of iommu space:

iommu_alloc failed, tbl c00000076e096660 vaddr c000000768806600 npages 1

Use dev_info() so we get the device name and location:

ipr 0000:00:01.0: iommu_alloc failed, tbl c00000076e096660 vaddr c000000768806600 npages 1

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Remove unused 'protect4gb' boot parameter

2010-05-21T07:31:13+00:00

'protect4gb' boot parameter was introduced to avoid allocating dma
space acrossing 4GB boundary in 2007 (the commit
569975591c5530fdc9c7a3c45122e5e46f075a74).

In 2008, the IOMMU was fixed to use the boundary_mask parameter per
device properly. So 'protect4gb' workaround was removed (the
383af9525bb27f927511874f6306247ec13f1c28). But somehow I messed the
'protect4gb' boot parameter that was used to enable the
workaround.

Signed-off-by: FUJITA Tomonori 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Remove IOMMU_VMERGE config option

2010-03-19T05:38:16+00:00

The description says:

 Cause IO segments sent to a device for DMA to be merged virtually
 by the IOMMU when they happen to have been allocated contiguously.
 This doesn't add pressure to the IOMMU allocator. However, some
 drivers don't support getting large merged segments coming back
 from *_map_sg().

 Most drivers don't have this problem; it is safe to say Y here.

It's out of date. Long ago, drivers didn't have a way to tell IOMMUs
about their segment length limit (that is, the maximum segment length
that they can handle). So IOMMUs merged as many segments as possible
and gave too large segments to drivers.

dma_get_max_seg_size() was introduced to solve the above
problem. Device drives can use the API to tell IOMMU about the maximum
segment length that they can handle. In addition, the default limit
(64K) should be safe for everyone.

So this config option seems to be unnecessary.

Note that this config option just enables users to disable the virtual
merging by default. Users can still disable the virtual merging by the
boot parameter.

Signed-off-by: FUJITA Tomonori 
Signed-off-by: Benjamin Herrenschmidt

iommu-helper: use bitmap library

2009-12-16T15:20:18+00:00

Use bitmap library and kill some unused iommu helper functions.

1. s/iommu_area_free/bitmap_clear/

2. s/iommu_area_reserve/bitmap_set/

3. Use bitmap_find_next_zero_area instead of find_next_zero_area

  This cannot be simple substitution because find_next_zero_area
  doesn't check the last bit of the limit in bitmap

4. Remove iommu_area_free, iommu_area_reserve, and find_next_zero_area

Signed-off-by: Akinobu Mita 
Cc: "David S. Miller" 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: FUJITA Tomonori 
Cc: Joerg Roedel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

powerpc: Change u64/s64 to a long long integer type

2009-01-13T03:47:59+00:00

Convert arch/powerpc/ over to long long based u64:

 -#ifdef __powerpc64__
 -# include 
 -#else
 -# include 
 -#endif
 +#include 

This will avoid reoccuring spurious warnings in core kernel code that
comes when people test on their own hardware. (i.e. x86 in ~98% of the
cases) This is what x86 uses and it generally helps keep 64-bit code
32-bit clean too.

[Adjusted to not impact user mode (from paulus) - sfr]

Signed-off-by: Ingo Molnar 
Signed-off-by: Stephen Rothwell 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Update remaining dma_mapping_ops to use map/unmap_page

2008-10-31T05:13:48+00:00

After the merge of the 32 and 64bit DMA code, dma_direct_ops lost
their map/unmap_single() functions but gained map/unmap_page().  This
caused a problem for Cell because Cell's dma_iommu_fixed_ops called
the dma_direct_ops if the fixed linear mapping was to be used or the
iommu ops if the dynamic window was to be used.  So in order to fix
this problem we need to update the 64bit DMA code to use
map/unmap_page.

First, we update the generic IOMMU code so that iommu_map_single()
becomes iommu_map_page() and iommu_unmap_single() becomes
iommu_unmap_page().  Then we propagate these changes up through all
the callers of these two functions and in the process update all the
dma_mapping_ops so that they have map/unmap_page rahter than
map/unmap_single.  We can do this because on 64bit there is no HIGHMEM
memory so map/unmap_page ends up performing exactly the same function
as map/unmap_single, just taking different arguments.

This has no affect on drivers because the dma_map_single_attrs() just
ends up calling the map_page() function of the appropriate
dma_mapping_ops and similarly the dma_unmap_single_attrs() calls
unmap_page().

This fixes an oops on Cell blades, which oops on boot without this
because they call dma_direct_ops.map_single, which is NULL.

Signed-off-by: Mark Nelson 
Signed-off-by: Paul Mackerras

powerpc: Use is_kdump_kernel()

2008-10-31T05:11:47+00:00

linux/crash_dump.h defines is_kdump_kernel() to be used by code that
needs to know if the previous kernel crashed instead of a (clean) boot
or reboot.

This updates the just added powerpc code to use it.  This is needed
for the next commit, which will remove __kdump_flag.

Signed-off-by: Milton Miller 
Signed-off-by: Paul Mackerras

powerpc: Support for relocatable kdump kernel

2008-10-22T04:01:22+00:00

This adds relocatable kernel support for kdump. With this one can
use the same regular kernel to capture the kdump. A signature (0xfeed1234)
is passed in r6 from panic code to the next kernel through kexec_sequence
and purgatory code. The signature is used to differentiate between
kdump kernel and non-kdump kernels.

The purgatory code compares the signature and sets the __kdump_flag in
head_64.S.  During the boot up, kernel code checks __kdump_flag and if it
is set, the kernel will behave as relocatable kdump kernel. This kernel
will boot at the address where it was loaded by kexec-tools ie. at the
address reserved through crashkernel boot parameter.

CONFIG_CRASH_DUMP depends on CONFIG_RELOCATABLE option to build kdump
kernel as relocatable. So the same kernel can be used as production and
kdump kernel.

This patch incorporates the changes suggested by Paul Mackerras to avoid
GOT use and to avoid two copies of the code.

Signed-off-by: Paul Mackerras 
Signed-off-by: Mohan Kumar M 
Signed-off-by: Michael Ellerman 
Signed-off-by: Benjamin Herrenschmidt