Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 20 9月, 2009 4 次提交
  3. 16 9月, 2009 2 次提交
  5. 12 9月, 2009 1 次提交
    • R
      ARM: Fix pfn_valid() for sparse memory · b7cfda9f
      由 Russell King 提交于 
      On OMAP platforms, some people want to declare to segment up the memory
between the kernel and a separate application such that there is a hole
in the middle of the memory as far as Linux is concerned.  However,
they want to be able to mmap() the hole.

This currently causes problems, because update_mmu_cache() thinks that
there are valid struct pages for the "hole".  Fix this by making
pfn_valid() slightly more expensive, by checking whether the PFN is
contained within the meminfo array.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NKhasim Syed Mohammed <khasim@ti.com>
      b7cfda9f
  7. 05 9月, 2009 1 次提交
    • N
      ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem · 7929eb9c
      由 Nicolas Pitre 提交于 
      Let's suppose a highmem page is kmap'd with kmap().  A pkmap entry is
used, the page mapped to it, and the virtual cache is dirtied.  Then
kunmap() is used which does virtually nothing except for decrementing a
usage count.

Then, let's suppose the _same_ page gets mapped using kmap_atomic().
It is therefore mapped onto a fixmap entry instead, which has a
different virtual address unaware of the dirty cache data for that page
sitting in the pkmap mapping.

Fortunately it is easy to know if a pkmap mapping still exists for that
page and use it directly with kmap_atomic(), thanks to kmap_high_get().

And actual testing with a printk in the added code path shows that this
condition is actually met *extremely* frequently.  Seems that we've been
quite lucky that things have worked so well with highmem so far.

Cc: stable@kernel.org
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7929eb9c
  9. 02 9月, 2009 1 次提交
    • N
      ARM: 5687/1: fix an oops with highmem · 13f96d8f
      由 Nicolas Pitre 提交于 
      In xdr_partial_copy_from_skb() there is that sequence:

		kaddr = kmap_atomic(*ppage, KM_SKB_SUNRPC_DATA);
		[...]
		flush_dcache_page(*ppage);
		kunmap_atomic(kaddr, KM_SKB_SUNRPC_DATA);

Mixing flush_dcache_page() and kmap_atomic() is a bit odd,
especially since kunmap_atomic() must deal with cache issues
already.  OTOH the non-highmem case must use flush_dcache_page()
as kunmap_atomic() becomes a no op with no cache maintenance.

Problem is that with highmem the implementation of kmap_atomic()
doesn't set page->virtual, and page_address(page) returns 0 in
that case. Here flush_dcache_page() calls __flush_dcache_page()
which calls __cpuc_flush_dcache_page(page_address(page)) resulting
in a kernel oops.

None of the kmap_atomic() implementations uses set_page_address().
Hence we can assume page_address() is always expected to return 0 in
that case. Let's conditionally call __cpuc_flush_dcache_page() only
when the page address is non zero, and perform that test only when
highmem is configured.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      13f96d8f
  11. 18 8月, 2009 1 次提交
  13. 15 8月, 2009 1 次提交
    • R
      ARM: Fix broken highmem support · dde5828f
      由 Russell King 提交于 
      Currently, highmem is selectable, and you can request an increased
vmalloc area.  However, none of this has any effect on the memory
layout since a patch in the highmem series was accidentally dropped.
Moreover, even if you did want highmem, all memory would still be
registered as lowmem, possibly resulting in overflow of the available
virtual mapping space.

The highmem boundary is determined by the highest allowed beginning
of the vmalloc area, which depends on its configurable minimum size
(see commit 60296c71 for details on
this).

We should create mappings and initialize bootmem only for low memory,
while the zone allocator must still be told about highmem.

Currently, memory nodes which are completely located in high memory
are not supported.  This is not a huge limitation since systems
relying on highmem support are unlikely to have discontiguous memory
with large holes.

[ A similar patch was meant to be merged before commit 5f0fbf9e
  and be available  in Linux v2.6.30, however some git rebase screw-up
  of mine dropped the first commit of the series, and that goofage
  escaped testing somehow as well. -- Nico ]
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: NNicolas Pitre <nico@marvell.com>
      dde5828f
  15. 24 7月, 2009 7 次提交
  17. 11 7月, 2009 1 次提交
  19. 05 7月, 2009 1 次提交
  21. 03 7月, 2009 1 次提交
  23. 22 6月, 2009 1 次提交
  25. 19 6月, 2009 1 次提交
  27. 16 6月, 2009 1 次提交
  29. 03 6月, 2009 1 次提交
  31. 31 5月, 2009 1 次提交
  33. 30 5月, 2009 6 次提交
  35. 19 5月, 2009 1 次提交
    • H
      omap iommu: simple virtual address space management · 69d3a84a
      由 Hiroshi DOYU 提交于 
      This patch provides a device drivers, which has a omap iommu, with
address mapping APIs between device virtual address(iommu), physical
address and MPU virtual address.

There are 4 possible patterns for iommu virtual address(iova/da) mapping.

    |iova/			  mapping		iommu_		page
    | da	pa	va	(d)-(p)-(v)		function	type
  ---------------------------------------------------------------------------
  1 | c		c	c	 1 - 1 - 1	  _kmap() / _kunmap()	s
  2 | c		c,a	c	 1 - 1 - 1	_kmalloc()/ _kfree()	s
  3 | c		d	c	 1 - n - 1	  _vmap() / _vunmap()	s
  4 | c		d,a	c	 1 - n - 1	_vmalloc()/ _vfree()	n*

    'iova':	device iommu virtual address
    'da':	alias of 'iova'
    'pa':	physical address
    'va':	mpu virtual address

    'c':	contiguous memory area
    'd':	dicontiguous memory area
    'a':	anonymous memory allocation
    '()':	optional feature

    'n':	a normal page(4KB) size is used.
    's':	multiple iommu superpage(16MB, 1MB, 64KB, 4KB) size is used.

    '*':	not yet, but feasible.
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
      69d3a84a
  37. 01 5月, 2009 4 次提交
  39. 29 4月, 2009 1 次提交
  41. 28 4月, 2009 1 次提交
  43. 04 4月, 2009 1 次提交