Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 12月, 2006 13 次提交
  3. 07 12月, 2006 1 次提交
  5. 05 12月, 2006 2 次提交
  7. 04 12月, 2006 3 次提交
  9. 03 12月, 2006 1 次提交
  11. 02 12月, 2006 8 次提交
  13. 30 11月, 2006 2 次提交
  15. 26 11月, 2006 1 次提交
  17. 23 11月, 2006 2 次提交
    • L
      [AGP] Allocate AGP pages with GFP_DMA32 by default · 66c669ba
      由 Linus Torvalds 提交于 
      Not all graphic page remappers support physical addresses over the 4GB
mark for remapping, so while some do (the AMD64 GART always did, and I
just fixed the i965 to do so properly), we're safest off just forcing
GFP_DMA32 allocations to make sure graphics pages get allocated in the
low 32-bit address space by default.

AGP sub-drivers that really care, and can do better, could just choose
to implement their own allocator (or we could add another "64-bit safe"
default allocator for their use), but quite frankly, you're not likely
to care in practice.

So for now, this trivial change means that we won't be allocating pages
that we can't map correctly by mistake on x86-64.

[ On traditional 32-bit x86, this could never happen, because GFP_KERNEL
  would never allocate any highmem memory anyway ]
Acked-by: NAndi Kleen <ak@suse.de>
Acked-by: NDave Jones <davej@redhat.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      66c669ba
    • L
      [AGP] Fix intel 965 AGP memory mapping function · 7d915a38
      由 Linus Torvalds 提交于 
      This introduces a i965-specific "mask_memory()" function that knows
about the extended physical addresses that the i965 supports.  This
allows us to correctly map in physical memory in the >4GB range into the
GTT.

Also simplify/clean-up the i965 case for the aperture sizing by just
returning the fixed 512kB size from "fetch_size()".  We don't really
care that not all of the aperture may be visible - the only thing that
cares about the aperture size is the Intel "stolen memory" calculation,
which depends on the fixed size.

Cc: Keith Packard <keithp@keithp.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7d915a38
  19. 22 11月, 2006 3 次提交
    • D
      WorkStruct: make allyesconfig · c4028958
      由 David Howells 提交于 
      Fix up for make allyesconfig.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      c4028958
    • D
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      由 David Howells 提交于 
      Pass the work_struct pointer to the work function rather than context data.
The work function can use container_of() to work out the data.

For the cases where the container of the work_struct may go away the moment the
pending bit is cleared, it is made possible to defer the release of the
structure by deferring the clearing of the pending bit.

To make this work, an extra flag is introduced into the management side of the
work_struct.  This governs auto-release of the structure upon execution.

Ordinarily, the work queue executor would release the work_struct for further
scheduling or deallocation by clearing the pending bit prior to jumping to the
work function.  This means that, unless the driver makes some guarantee itself
that the work_struct won't go away, the work function may not access anything
else in the work_struct or its container lest they be deallocated..  This is a
problem if the auxiliary data is taken away (as done by the last patch).

However, if the pending bit is *not* cleared before jumping to the work
function, then the work function *may* access the work_struct and its container
with no problems.  But then the work function must itself release the
work_struct by calling work_release().

In most cases, automatic release is fine, so this is the default.  Special
initiators exist for the non-auto-release case (ending in _NAR).
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      65f27f38
    • D
      WorkStruct: Separate delayable and non-delayable events. · 52bad64d
      由 David Howells 提交于 
      Separate delayable work items from non-delayable work items be splitting them
into a separate structure (delayed_work), which incorporates a work_struct and
the timer_list removed from work_struct.

The work_struct struct is huge, and this limits it's usefulness.  On a 64-bit
architecture it's nearly 100 bytes in size.  This reduces that by half for the
non-delayable type of event.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      52bad64d
  21. 21 11月, 2006 1 次提交
  23. 18 11月, 2006 3 次提交