Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 05 1月, 2012 2 次提交
  3. 20 12月, 2011 3 次提交
  5. 17 12月, 2011 1 次提交
    • E
      iommu: Export intel_iommu_enabled to signal when iommu is in use · 8bc1f85c
      由 Eugeni Dodonov 提交于 
      In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. The new 'intel_iommu_enabled' variable signals when the
iommu code is in operation.

Cc: Ted Phelps <phelps@gnusto.com>
Cc: Peter <pab1612@gmail.com>
Cc: Lukas Hejtmanek <xhejtman@fi.muni.cz>
Cc: Andrew Lutomirski <luto@mit.edu>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      8bc1f85c
  7. 14 12月, 2011 1 次提交
  9. 13 12月, 2011 1 次提交
    • L
      linux/log2.h: Fix rounddown_pow_of_two(1) · 13c07b02
      由 Linus Torvalds 提交于 
      Exactly like roundup_pow_of_two(1), the rounddown version was buggy for
the case of a compile-time constant '1' argument.  Probably because it
originated from the same code, sharing history with the roundup version
from before the bugfix (for that one, see commit 1a06a52e: "Fix
roundup_pow_of_two(1)").

However, unlike the roundup version, the fix for rounddown is to just
remove the broken special case entirely.  It's simply not needed - the
generic code

    1UL << ilog2(n)

does the right thing for the constant '1' argment too.  The only reason
roundup needed that special case was because rounding up does so by
subtracting one from the argument (and then adding one to the result)
causing the obvious problems with "ilog2(0)".

But rounddown doesn't do any of that, since ilog2() naturally truncates
(ie "rounds down") to the right rounded down value.  And without the
ilog2(0) case, there's no reason for the special case that had the wrong
value.

tl;dr: rounddown_pow_of_two(1) should be 1, not 0.
Acked-by: NDmitry Torokhov <dtor@vmware.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      13c07b02
  11. 11 12月, 2011 1 次提交
  13. 09 12月, 2011 1 次提交
  15. 07 12月, 2011 1 次提交
    • A
      fix apparmor dereferencing potentially freed dentry, sanitize __d_path() API · 02125a82
      由 Al Viro 提交于 
      __d_path() API is asking for trouble and in case of apparmor d_namespace_path()
getting just that.  The root cause is that when __d_path() misses the root
it had been told to look for, it stores the location of the most remote ancestor
in *root.  Without grabbing references.  Sure, at the moment of call it had
been pinned down by what we have in *path.  And if we raced with umount -l, we
could have very well stopped at vfsmount/dentry that got freed as soon as
prepend_path() dropped vfsmount_lock.

It is safe to compare these pointers with pre-existing (and known to be still
alive) vfsmount and dentry, as long as all we are asking is "is it the same
address?".  Dereferencing is not safe and apparmor ended up stepping into
that.  d_namespace_path() really wants to examine the place where we stopped,
even if it's not connected to our namespace.  As the result, it looked
at ->d_sb->s_magic of a dentry that might've been already freed by that point.
All other callers had been careful enough to avoid that, but it's really
a bad interface - it invites that kind of trouble.

The fix is fairly straightforward, even though it's bigger than I'd like:
	* prepend_path() root argument becomes const.
	* __d_path() is never called with NULL/NULL root.  It was a kludge
to start with.  Instead, we have an explicit function - d_absolute_root().
Same as __d_path(), except that it doesn't get root passed and stops where
it stops.  apparmor and tomoyo are using it.
	* __d_path() returns NULL on path outside of root.  The main
caller is show_mountinfo() and that's precisely what we pass root for - to
skip those outside chroot jail.  Those who don't want that can (and do)
use d_path().
	* __d_path() root argument becomes const.  Everyone agrees, I hope.
	* apparmor does *NOT* try to use __d_path() or any of its variants
when it sees that path->mnt is an internal vfsmount.  In that case it's
definitely not mounted anywhere and dentry_path() is exactly what we want
there.  Handling of sysctl()-triggered weirdness is moved to that place.
	* if apparmor is asked to do pathname relative to chroot jail
and __d_path() tells it we it's not in that jail, the sucker just calls
d_absolute_path() instead.  That's the other remaining caller of __d_path(),
BTW.
        * seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway -
the normal seq_file logics will take care of growing the buffer and redoing
the call of ->show() just fine).  However, if it gets path not reachable
from root, it returns SEQ_SKIP.  The only caller adjusted (i.e. stopped
ignoring the return value as it used to do).
Reviewed-by: NJohn Johansen <john.johansen@canonical.com>
ACKed-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
      02125a82
  17. 06 12月, 2011 11 次提交
  19. 05 12月, 2011 1 次提交
    • P
      perf: Fix loss of notification with multi-event · 10c6db11
      由 Peter Zijlstra 提交于 
      When you do:
        $ perf record -e cycles,cycles,cycles noploop 10

You expect about 10,000 samples for each event, i.e., 10s at
1000samples/sec. However, this is not what's happening. You
get much fewer samples, maybe 3700 samples/event:

$ perf report -D | tail -15
Aggregated stats:
           TOTAL events:      10998
            MMAP events:         66
            COMM events:          2
          SAMPLE events:      10930
cycles stats:
           TOTAL events:       3644
          SAMPLE events:       3644
cycles stats:
           TOTAL events:       3642
          SAMPLE events:       3642
cycles stats:
           TOTAL events:       3644
          SAMPLE events:       3644

On a Intel Nehalem or even AMD64, there are 4 counters capable
of measuring cycles, so there is plenty of space to measure those
events without multiplexing (even with the NMI watchdog active).
And even with multiplexing, we'd expect roughly the same number
of samples per event.

The root of the problem was that when the event that caused the buffer
to become full was not the first event passed on the cmdline, the user
notification would get lost. The notification was sent to the file
descriptor of the overflowed event but the perf tool was not polling
on it.  The perf tool aggregates all samples into a single buffer,
i.e., the buffer of the first event. Consequently, it assumes
notifications for any event will come via that descriptor.

The seemingly straight forward solution of moving the waitq into the
ringbuffer object doesn't work because of life-time issues. One could
perf_event_set_output() on a fd that you're also blocking on and cause
the old rb object to be freed while its waitq would still be
referenced by the blocked thread -> FAIL.

Therefore link all events to the ringbuffer and broadcast the wakeup
from the ringbuffer object to all possible events that could be waited
upon. This is rather ugly, and we're open to better solutions but it
works for now.
Reported-by: NStephane Eranian <eranian@google.com>
Finished-by: NStephane Eranian <eranian@google.com>
Reviewed-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20111126014731.GA7030@quadSigned-off-by: NIngo Molnar <mingo@elte.hu>
      10c6db11
  21. 04 12月, 2011 1 次提交
  23. 02 12月, 2011 14 次提交
    • T
      OMAPDSS: Add comments about blocking of ovl/mgr functions · 9d11c321
      由 Tomi Valkeinen 提交于 
      Add comments specifying what ovl/mgr functions may block.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9d11c321
    • T
      OMAPDSS: APPLY: remove device_changed field · ff4733dc
      由 Tomi Valkeinen 提交于 
      omap_overlay_manager contains device_changed field, which no longer has
any use. So remove the field and the few places where it is touched.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ff4733dc
    • T
      OMAPDSS: APPLY: move channel-field to extra_info set · 5d5a97a6
      由 Tomi Valkeinen 提交于 
      Setting overlay's output channel is currently handled at the same time
as other overlay attributes. This is not right, as the normal attributes
should only affect one overlay and manager, but changing the channel
affects two managers.

This patch moves the channel field into the "extra_info" set, handled
together with enabled-status.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5d5a97a6
    • T
      OMAPDSS: APPLY: move ovl->info to apply.c · c1a9febf
      由 Tomi Valkeinen 提交于 
      struct omap_overlayr contains info and info_dirty fields, both of which
should be internal to apply.c.

This patch moves those fields into ovl_priv data, and names them
user_info and user_info_dirty.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c1a9febf
    • T
      OMAPDSS: APPLY: move mgr->info to apply.c · 388c4c6c
      由 Tomi Valkeinen 提交于 
      struct omap_overlay_manager contains info and info_dirty fields, both of
which should be internal to apply.c.

This patch moves those fields into mgr_priv data, and names them
user_info and user_info_dirty.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      388c4c6c
    • T
      OMAPDSS: APPLY: rewrite overlay enable/disable · aaa874a9
      由 Tomi Valkeinen 提交于 
      Overlays are currently enabled and disabled with a boolean in the struct
omap_overlay_info. The overlay info is set with ovl->set_overlay_info(),
and made into use with mgr->apply().

This doesn't work properly, as the enable/disable status may affect also
other overlays, for example when using fifo-merge. Thus the enabling and
disabling of the overlay needs to be done outside the normal overlay
configuration.

This patch achieves that by doing the following things:

1) Add function pointers to struct omap_overlay: enable(), disable() and
is_enabled(). These are used to do the obvious. The functions may block.

2) Move the "enabled" field from struct omap_overlay to ovl_priv_data.

3) Add a new route for settings to be applied to the HW, called
"extra_info". The status of the normal info and extra_info are tracked
separately.

The point here is to allow the normal info to be changed and
applied in non-blocking matter, whereas the extra_info can only be
changed when holding the mutex. This makes it possible to, for example,
set the overlay enable flag, apply it, and wait until the HW has taken
the flag into use.

This is not possible if the enable flag would be in the normal info, as
a new value for the flag could be set at any time from the users of
omapdss.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      aaa874a9
    • T
      OMAPDSS: APPLY: move mgr->enabled to mgr_priv_data · bf213523
      由 Tomi Valkeinen 提交于 
      struct omap_overlay_manager contains "enabled"-field, used to track if
the manager is enabled or not. This field should be internal to apply.c.

This patch moves the field to mgr_priv_data, and applies the necessary
locking when accessing the field.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bf213523
    • T
      OMAPDSS: DSI: call mgr_enable/disable for cmd mode displays · 9a147a65
      由 Tomi Valkeinen 提交于 
      The current code uses dsi_video_mode_enable/disable functions to
enable/disable DISPC output for video mode displays. For command mode
displays we have no notion in the DISPC side of whether the panel is
enabled, except when a dss_mgr_start_update() call is made.

However, to properly maintain the DISPC state in apply.c, we need to
know if a manager used for a manual update display is currently in use.

This patch achieves that by changing dsi_video_mode_enable/disable to
dsi_enable/disable_video_output, which is called by both video and
command mode displays. For video mode displays it starts the actual
pixel stream, as it did before. For command mode displays it doesn't do
anything else than mark that the manager is currently in use.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9a147a65
    • T
      OMAPDSS: store overlays in a list for each manager · 07e327c9
      由 Tomi Valkeinen 提交于 
      Current way of handling overlay-manager links is a bit strange: each
manager has a static array, containing pointers to all the overlays
(even those used by other managers). The overlays contain a pointer to
the manager being used.

This patch makes the system a bit saner: each manager has a linked list
of overlays, and only the overlays linked to that manager are in the
list.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      07e327c9
    • T
      OMAPDSS: store managers in an array · 5617ad09
      由 Tomi Valkeinen 提交于 
      Overlay managers are stored in a linked list. There's no need for this
list, as an array would do just as fine.

This patch changes the code to use an array for overlay managers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5617ad09
    • T
      OMAPDSS: APPLY: track whether a manager is enabled · be729178
      由 Tomi Valkeinen 提交于 
      Add "enabled" field to struct omap_overlay_manager, which tells if the
output is enabled or not. This will be used in apply.c in the following
patches.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      be729178
    • T
      OMAPDSS: hide manager's enable/disable() · 7797c6da
      由 Tomi Valkeinen 提交于 
      omap_overlay_manager struct contains enable() and disable() functions.
However, these are only meant to be used from inside omapdss, and thus
it's bad to expose the functions.

This patch adds dss_mgr_enable() and dss_mgr_disable() functions to
apply.c, which handle enabling and disabling the output.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7797c6da
    • T
      OMAPDSS: remove partial update from DSI · 5476e74a
      由 Tomi Valkeinen 提交于 
      Partial update for manual update displays has never worked quite well:
* The HW has limitations on the update area, and the x and width need to
  be even.
* Showing a part of a scaled overlay causes artifacts.
* Makes the management of dispc very complex

Considering the above points and the fact that partial update is not
used anywhere, this and the following patches remove the partial update
support. This will greatly simplify the following re-write of the apply
mechanism to get proper locking and additional features like fifo-merge.

This patch removes the partial update from the dsi.c.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5476e74a
    • A
      drm/radeon/kms: add some new pci ids · 2ed4d9d6
      由 Alex Deucher 提交于 
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>
      2ed4d9d6
  25. 01 12月, 2011 1 次提交
  27. 29 11月, 2011 1 次提交