Do to the move active/inactive lists, it no longer makes sense to use
them for shrinking, since shrinking isn't VM specific (such a need may
also exist, but doesn't yet).
What we can do instead is use the global bound list to find all objects
which aren't active.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Earlier in the conversion sequence we attempted to quickly wedge in the
transitional interface as static inlines.
Now that we're sure these interfaces are sane, for easier debug and to
decrease code size (since many of these functions may be called quite a
bit), make them real functions
While at it, kill off the set_color interface. We'll always have the
VMA, or easily get to it.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With an upcoming change to bind, to make checkpatch happy and keep the
code clean, we need to rework this code a bit.
This should have no functional impact.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add the newline Chris requested.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move all the similar address space (VM) initialization code to one
function. Until we have multiple VMs, there should only ever be 1 VM.
The aliasing ppgtt is a special case without it's own VM (since it
doesn't need it's own address space management).
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The default LLC age was changed:
commit 0d8ff15e9a
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Thu Jul 4 11:02:03 2013 -0700
drm/i915/hsw: Set correct Haswell PTE encodings.
On the surface it would seem setting a default age wouldn't matter
because all GEM BOs are aged similarly, so the order in which objects
are evicted would not be subject to aging. The current working theory as
to why this caused a regression though is that LLC is a bit special in
that it is shared with the CPU. Presumably (not verified) the CPU
fetches cachelines with age 3, and therefore recently cached GPU objects
would be evicted before similar CPU object first when the LLC is full.
It stands to reason therefore that this would negatively impact CPU
bound benchmarks - but those seem to be low on the priority list.
eLLC OTOH does not have this same property as LLC. It should be used
entirely for the GPU, and so the age really shouldn't matter.
Furthermore, we have no evidence to suggest one is better than another
on eLLC. Since we've never properly supported eLLC before no, there
should be no regression. If the GPU client really wants "younger"
objects, they should use MOCS.
v2: Drop the extra #define (Chad)
v3: Actually git add
v4: Pimped commit message
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67062
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since commit 29a241c (ACPICA: Add argument typechecking for all
predefined ACPI names), _DSM parameters are validated which trigger the
following warning:
ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
As the Intel _DSM method seems to ignore this parameter, let's comply to
the ACPI spec and use a Package instead.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32602
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Userspace can pass a mode with an unspecified vsync/hsync polarity
setting. All encoders in the Intel driver take this to mean a negative
polarity setting. The HW readout/state checker code on the other hand
needs these flags to be explicitly set, otherwise the state checker will
WARN about the mismatch.
Get rid of the WARN by making the polarity setting explicit in the
adjusted mode flags based on the requested mode flags. This will keep
the existing behavior otherwise.
Note that we could guess from the other timing parameters whether the
user wanted a VESA or other standard mode and set the polarity
accordingly. This is what the NV driver does
(drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very
exact and would change the existing behavior of the Intel driver.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: cancan,feng <cancan.feng@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV wants encoder enabling before the pipe is up. With the previously
rearranged VLV DP and HDMI ->pre_enable and ->enable callbacks in place,
this no longer depends on the early ->enable hook call. Move the
->enable call at the end of the sequence, similar to the crtc enable on
other platforms. This will be needed e.g. for moving the eDP backlight
enabling to the right place in the sequence, currently done too early on
VLV.
There should be no functional changes.
v2: Rebase.
v3: Explain why this is needed in the commit message (Chris).
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV wants encoder enabling before the pipe is up. This is currently
achieved through calling the ->enable callback early, right after the
->pre_enable callback, in valleyview_crtc_enable(). This loses both the
distinction between ->pre_enable and ->enable on VLV and the possibility
to use a hook at the end of the modeset sequence.
Rearrange the HDMI callbacks to make it possible to move ->enable call
later. Basically do everything in ->pre_enable on VLV, and make ->enable
a NOP.
There should be no functional changes.
v2: Rebase.
v3: Explain why this is needed in the commit message (Chris).
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV wants encoder enabling before the pipe is up. This is currently
achieved through calling the ->enable callback early, right after the
->pre_enable callback, in valleyview_crtc_enable(). This loses both the
distinction between ->pre_enable and ->enable on VLV and the possibility
to use a hook at the end of the modeset sequence.
Rearrange the DP callbacks to make it possible to move ->enable call
later. Basically do everything in ->pre_enable on VLV, and make ->enable
a NOP.
There should be no functional changes.
v2: Rebase.
v3: Explain why this is needed in the commit message (Chris).
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise we get flooded by the kernel warning us that we are doing
long sequences of IO without serialisation. For example,
WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef()
Modules linked in:
CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G W 3.11.0-rc2+ #4
Call Trace:
[<c2028564>] ? warn_slowpath_common+0x63/0x78
[<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef
[<c20285dd>] ? warn_slowpath_null+0xf/0x13
[<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef
[<c227b060>] ? vlv_dpio_write+0x1c/0x21
[<c2262b3b>] ? intel_dp_set_signal_levels+0x24a/0x385
[<c2264909>] ? intel_dp_complete_link_train+0x25/0x1d1
[<c2264c55>] ? intel_dp_check_link_status+0xf7/0x106
[<c2238ced>] ? i915_hotplug_work_func+0x17b/0x221
[<c203a204>] ? process_one_work+0x12e/0x210
[<c203a5e4>] ? worker_thread+0x116/0x1ad
[<c203a4ce>] ? rescuer_thread+0x1cb/0x1cb
[<c203d8f5>] ? kthread+0x67/0x6c
[<c2457ebb>] ? ret_from_kernel_thread+0x1b/0x30
[<c203d88e>] ? init_completion+0x18/0x18
v2: Retire the locking in vlv_crtc_enable() and do it close to the meat.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Squash in a s/mutex_lock/mutex_unlock/ fixup spotted by the 0
day kernel build/coccinelle and reported by Dan Carpenter.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Art confirms that this should work fine. Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SNB and IVB have slightly a different way to read out the
watermark latency values.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The LP1+ watermark latency values need to be multiplied by 5 to
make them suitable for watermark calculations. However on pre-HSW
platforms we're going to need the raw value later when we have to
write it to the WM_LPn registers' latency field. So delay the
multiplication until it's needed.
Note: Paulo complains that the units of wm (now in 100ns) aren't
really clear and I agree. But that can be fixed later on ...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add a comment about the unit obfuscation.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move parsing of MCH_SSKPD to a separate function, we'll add other
platforms there later.
Note: Chris spotted an empty struct initializer and wondered whether
that is hiding a compilier warning. Ville explained that it should
have been part of the patch that extends this function to snb/ivb,
which don't have all levels hsw has. I've figured it's ok to keep it
here with a small note.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add note about the ominous struct initializer.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The latency values fit in uint16_t, so let's save a few bytes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The FBC watermark doesn't depend on the latency value, so no point in
passing it in.
Note: It actually depends upon the latency, but only through priv_val
...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add review comment from Paulo to the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions are appropriate for everything since ILK.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
hsw_wm_get_pixel_rate() isn't specific to HSW. In fact it should be made
to handle all gens, but for now it depends on the PCH panel fitter
state, so give it an ilk_ prefix.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using the destination width in the sprite WM calculations isn't correct.
We should be using the source width.
Note: This doesn't affect hsw since it does not support sprite
scaling.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add review note from Paulo to the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't subtract one from the sprite width before watermark calculations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For calculating watermarks we want to know whether sprites are
scaled. Pass that information to update_sprite_watermarks() so that
eventually we may do some watermark pre-computing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some of our macros we trying to convert from an drm_device to a
drm_i915_private and then use the pointer inline. This is not only
cumbersome but prone to error. Replacing it with a typesafe function
should help catch those errors in future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Squash in fixup to correctly order static vs. inline
qualifiers, static comes first. Also fix up another offender.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The PTE layouts are the same for both ppgtt and gtt, so we can simplify
the setup for ppgtt by copying the encoding function pointer from gtt.
This prevents bugs where we update one function pointer, but forget the
other.
For instance,
commit 4d15c145a6
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Thu Jul 4 11:02:06 2013 -0700
drm/i915: Use eLLC/LLC by default when available
only extends the gtt to use eLLC/LLC cacheing and forgets to also update
the ppgtt function pointer.
v2: Actually mention the bug being fixed (Kenneth)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Almost invariably the reason why FBC cannot be turned on is the same
every time (disabled via parameter, too many pipes, pipe too large etc)
as modesetting and framebuffer configuration changes less frequently
than trying to enable FBC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the old days of the crtc helpers we've only had the encoder and
crtc ->mode_fixup callbacks. So when the lvds connector wanted to
adjust the crtc timings it had to set a driver-private mode flag to
tell the crtc mode fixup code to not overwrite them with the generic
ones.
When converting things to the new infrastructure I've kept the entire
logic and only moved the flag to pipe_config->timings_set. But this
logic is pretty tricky and already caused regressions:
commit 21d8a4756a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 12 08:07:30 2013 +0200
drm/i915: fix pfit regression for non-autoscaled resolutions
So take advantage of the flexibility our own modeset infrastructure
affords us and prefill default crtc timings. This allows us to rip out
->timings_set. Note that we overwrite things again when retrying the
pipe config computation due to bandwidth constraints to avoid bogus
crtc timings if the encoder only does relative adjustments (which is
how the pfit code works). Only a theoretical concern though since
platforms where we retry (pch-split platforms) do not need
adjustements (since only the old gmch pfit needs that). But let's
better be safe than sorry.
Since we now initialize the crtc timings before calling the
encoder->compute_config functions the crtc initialization in the gmch
pfit code is now redudant and so can be removed.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add a paragraph to the commit message to explain why we can
ditch the crtc timings initialization call from the gmch pfit code, to
answer a question from Rodrigo's review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The encoder->mode_set callback from the crtc helpers is now completely
unused in our driver. Good riddance!
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Does nothing, so trivial conversion. But update the outdated comment
while at it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Usual drill applies. Again I've not switched the upcast helpers to use
intel_encoder instead of drm_encoder since that's much more invasive
and will change also the hdmi and ddi encoders.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again drop the intel_ prefix from the intel_crtc local variable to
save a bit of space. But here I didn't switch the upcast macros to
intel_encoder since all our infoframe interfaces still use
drm_encoder. That needs to be changed first.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also drop the intel_ prefix from the local intel_crtc variable and
reorder the upcast macros a bit for more reuse.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also switch to intel_encoder for the upcast helper while at it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's what all callers (except for the destroy callback which is called
from drm core) actually want.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Everyone is now using our own ->compute_config callback, which means
we can now also make that callback mandatory.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the last encoder ->mode_fixup callback we have left, so
convert it.
Note that we want to only rip out the encoder->mode_fixup callback.
But we still have the dvo_slave->mode_fixup callback. dvo is gen2
only, so we won't ever touch this again. Hence why I didn't go through
all 6-7 dvo slave drivers and give them the same treatment. I'll add a
note to the commit message about this when merging, presuming there's
nothing else in the patch that needs to be fixed up.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add note about why we keep the dvo->mode_fixup callback to
answer a question from Rodrigo's review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need BUG_ON(), spinlock_t and standard kernel data-types so include the
right headers.
Subject: [drm-intel:drm-intel-nightly 154/166] include/drm/drm_mm.h:67:2:
error: unknown type name 'spinlock_t'
Message-ID: <51f14693.g5HGdcuw2v3m8FOd%fengguang.wu@intel.com>
In case it didn't link to it correctly. Somehow this bug doesn't occur
here on my machine, hmm. But I think fixing drm_mm.h is better than
changing the include-order in drm_vma_manager.h, so this is what I
did.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Driver fixes for AM33xx, SIRF and PFC pin controllers.
- Fix a compile warning from the pinctrl single-register
driver.
- Fix a little nasty memory leak.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJR9YhoAAoJEEEQszewGV1zfl8P/jk2VjlRE0P4LRLSRn3Rt7yj
Wz7IyZTol+mFnaY0yKQS9rToK+GqtJQHA1zuNP8iQnJbQh+UromAZwBd58dP7cnu
mYSi2QS4osYT5RjvVtB2yYy9sRrc4iTb+qJFekanA4IcHt0zKDZysyN8moU5JxmN
TVr+cauFm7qimkjps2Dns94UhVGpgB7A6Y8yC3SYtPv1GPdWQgSaDabWqMYq0bn1
ARUaz3XcbjMAGbPi8kDEFsP/SkM2OcMXpjX23G6ifgO9pyEKeum5+FWtllVeeAzb
LmymMJYVcTPLFw0yj+9lkRBew2K9JKmPp8rAUBvbDn53vbguMkDJTczM3IUZ279h
lRvR+w9F2M1rqIfwSa0/ZqTYKXbsF/IASYMXL/awNywnss+caPUxiN4EWRuKDssS
Wh6veS9l4roMupaez6GU7gQ8UgNnFTQg2BYzeFYbAg1jJ1b/U+E0MK/9yUzewXQw
phlcFFibYce+1qhJhQ3lIYb6O512vw+2Xk+G6JBZVuwzMVvUUJwJqfGRKCoobxZz
DRBIQJ9U4DRMethjfp5mP0H6nH7/fwKqvftKlsnOb9SXZregpcLV+ymrkkmW/Ey2
XuEHQqUbmD0zoPHvFgoUmAYlzmhxtmHK5uJDSH1aZ4b9IOzr2mV1RSt0xwo3BpTS
gwtDvmutV/JQ8RZMLLvw
=URtB
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
- Driver fixes for AM33xx, SIRF and PFC pin controllers
- Fix a compile warning from the pinctrl single-register driver
- Fix a little nasty memory leak
* tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: fix a memleak when freeing maps
pinctrl: pinctrl-single: fix compile warning when no CONFIG_PM
pinctrl: sh-pfc: fix SDHI0 VccQ regulator on sh73a0 with DT
arm/dts: sirf: fix the pingroup name mismatch between drivers and dts
pinctrl: sirf: add usp0_uart_nostreamctrl pin group for usp-uart without flowctrl
pinctrl: sirf: fix the pin number and mux bit for usp0
pinctrl: am33xx dt binding: correct include path
and deleting that event at the same time (both must be done as root).
I also found a bug while testing Oleg's patches which has to do with
a race with kprobes using the function tracer.
There's also a deadlock fix that was introduced with the previous fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABAgAGBQJR8nMiAAoJEOdOSU1xswtMXMMH/jNuG1vDcTjo7WXu3kYHJNWc
u1Z3YPXunFozz4DofzXPCuSkSgRqSR4cVeGOAv3oEfwQv07jJdTAor8/FuVTNXW9
yiGMUvth0nLVZQEmsh3VvVztqFy8FxhpnQHhIa6pillPUdROKgE/A7/q4wT37lxT
qniM1QJTK9fIf2t6suMwSsBD7fepiDkdHwVbs5NvN7qj62/QSPN+pHLAOBl90AGp
r5eUSj8cDHxmzlV+GAJxeqI7KH+P2PGts9USI+s5EX8mODci620jz1HkKab6XRpz
ggYdNzJ21z1fO9vfnpGCF0d03sKdnbJoIQjkyD4AJHlojmLe3s6l/nxS6jg3wH8=
=VrR4
-----END PGP SIGNATURE-----
Merge tag 'trace-fixes-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"Oleg is working on fixing a very tight race between opening a event
file and deleting that event at the same time (both must be done as
root).
I also found a bug while testing Oleg's patches which has to do with a
race with kprobes using the function tracer.
There's also a deadlock fix that was introduced with the previous
fixes"
* tag 'trace-fixes-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus()
ftrace: Add check for NULL regs if ops has SAVE_REGS set
tracing: Kill trace_cpu struct/members
tracing: Change tracing_fops/snapshot_fops to rely on tracing_get_cpu()
tracing: Change tracing_entries_fops to rely on tracing_get_cpu()
tracing: Change tracing_stats_fops to rely on tracing_get_cpu()
tracing: Change tracing_buffers_fops to rely on tracing_get_cpu()
tracing: Change tracing_pipe_fops() to rely on tracing_get_cpu()
tracing: Introduce trace_create_cpu_file() and tracing_get_cpu()
This is five bug fixes, two of which fix long standing problems causing
crashes (sd and mvsas). The remaining three are hung (isci race) or lost
(qla2xxx, isci) devices.
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJR8+WtAAoJEDeqqVYsXL0MDIUIAKkm+XVgNPAUhDnPH5IUcHVB
jr0NnKnsmlWVNV/Jc8xYKAjPeyBGr4foMR4W+Qqy2g8tTXI55AkXq4A8lyJfYVj9
1j8HTdbJFcOIwQO3e4gp6yJ9j2AdMoM9eHMYqts9u/G+2ckQm8GyMksgttUatVPu
gShyvU2Er546Di6D+JKNMjLufMucnuyPBHmzAKFc9l0L8A31vE0zkbO1qGozDTEB
tDotPSRuaaHaNQDvP/V0uwEIA1/KTq50ZJQerFp/mhc+gAvC/bQlmiOpWEJ8BxW7
3L0TEBsU+Bq1f+1uIWCHk3NWZEjj7nFLfk2lkhh32UtfXMB8Io46PbQAC9/Nk6U=
=/0W8
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is five bug fixes, two of which fix long standing problems
causing crashes (sd and mvsas). The remaining three are hung (isci
race) or lost (qla2xxx, isci) devices"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] isci: fix breakage caused by >16byte CDB patch
[SCSI] mvsas: Fix kernel panic on tile due to unaligned data access
[SCSI] sd: fix crash when UA received on DIF enabled device
[SCSI] qla2xxx: Properly set the tagging for commands.
[SCSI] isci: Fix a race condition in the SSP task management path
Pull drm fixes from Dave Airlie:
"This is just a regular fixes pull apart from the qxl one, it has
radeon and intel bits in it,
The intel fixes are for a regression with the RC6 fix and a 3.10 hdmi
regression, whereas radeon is more DPM fixes, a few lockup fixes and
some rn50/r100 DAC fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon/dpm: fix r600_enable_sclk_control()
drm/radeon/dpm: implement force performance levels for rv6xx
drm/radeon/dpm: fix displaygap programming on rv6xx
drm/radeon/dpm: fix a typo in the rv6xx mclk setup
drm/i915: initialize gt_lock early with other spin locks
drm/i915: fix hdmi portclock limits
drm/radeon: fix combios tables on older cards
drm/radeon: improve dac adjust heuristics for legacy pdac
drm/radeon: Another card with wrong primary dac adj
drm/radeon: fix endian issues with DP handling (v3)
drm/radeon/vm: only align the pt base to 32k
drm/radeon: wait for 3D idle before using CP DMA
Pull qxl drm fixes from Dave Airlie:
"Okay as I warned, the qxl driver was running a bit free and loose with
its ttm object reservations and the new lockdep enabled reservation
tracking shone a bright light into it, it also with the new
reservations mutexes hits a possible deadlock during boot.
The first patch is a real fix to render the console correctly as the
driver used to just drop irq renderering as too hard, this also fixes
a sleeping while atomic warning.
The other two patches are the big ugly ones that redo how the driver
allocates objects and reserves them and makes things all work
properly, I've tested this in a VM, and compared to the current code
which hits a lockdep warning and the sleep while atomic warning before
failing.
So sorry this is coming in late, I should have tested qxl before
merging the mutex code, but I'd rather just fix qxl with this than
revert the reservations code at this point"
* 'qxl-fixes' of git://people.freedesktop.org/~airlied/linux:
qxl: convert qxl driver to proper use for reservations
qxl: allow creation of pre-pinned objects and use for releases.
drm/qxl: add delayed fb operations
- Revert of the ACPI video commit that I hoped would help fix
backlight problems related to Windows 8 compatibility on some
systems. Unfortunately, it turned out to cause problems to happen
too.
- Fix for two problems in intel_pstate, a possible failure to respond
to a load change on a quiet system and a possible failure to select
the highest available P-state on some systems. From Dirk Brandewie.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJR8ub/AAoJEKhOf7ml8uNsgeQP+QFcSyDmkVCPTiLg5UYwFAIj
nptNB108tFH3ac9eZKNNdkYUeO3aeQooACMG3OqDEMzM88EUlQY33/yWJf9LXaq9
CYh6wNhGIFLWbIm2NcdP7akbXfz9dnoty2ELvD6kfVkRfVUgdo5LJlTn+sBcKwcu
kKUWODj4776dbFvg1Qv5Q6SrFNFWvpWZpsedpAQZWZE88sLy0pwpfq2H88naH551
9PxHqJ3trihq8i2cPSgKAipcIotqubPSHKm0HGYOKo8+C+V64TcJxWIaFwYawnvB
LrnsdjC3l+0DyQIy7OztEzWr/gTi6fdeiWuTU6+6IVbJ7P1waTdVy+B/wy/25PLL
zCJ+DXfqVTiaeSh4nriQVny30XTdZL/jpeFHRdL707FbuK1LLoFSlhH+uDx9EQUc
yIabX+roV6WX2ohNc+cu+pRPuG45vs7/gPUPa167UvqR0rxNc2Qf/kWWwVH7fwFz
g5FMMWqdNRxa7XKo0VbazG9mTk023CB37CVNEHWNe9g1a3XHe6zcgq2Ea8+i4QRi
WALLCSzV8+1eA/upS1wQs8M2o3Mh+Okdu7WEN89OANQHMgyTVjHGHWIyV820XXWc
MrhvB2DeqjyREl1ks2qiuUhrGO5nipCIlgKLvI2qD0jumasLob+9e3ozMSpSrtvi
J8qR46N4/fB9eLNdPCZt
=mGfr
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"These are just two fixes, a revert of the would-be backlight fix that
didn't work and an intel_pstate fix for two problems related to
maximum P-state selection.
Specifics:
- Revert of the ACPI video commit that I hoped would help fix
backlight problems related to Windows 8 compatibility on some
systems. Unfortunately, it turned out to cause problems to happen
too.
- Fix for two problems in intel_pstate, a possible failure to respond
to a load change on a quiet system and a possible failure to select
the highest available P-state on some systems. From Dirk
Brandewie"
* tag 'pm+acpi-3.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8"
cpufreq / intel_pstate: Change to scale off of max P-state
This is a largeish batch of fixes, mostly because I missed -rc2 due to
travel/vacation. So in number these are a bit more than ideal unless
you amortize them over two -rcs.
Quick breakdown:
- Defconfig updates
- Making multi_v7_defconfig useful on more hardware to encourage
single-image usage
- Davinci and nomadik updates due to new code merged this merge window
- Fixes for UART on Samsung platforms, both PM and clock-related
- A handful of warning fixes from defconfig builds, including for
max8925 backlight and pxamci (both with appropriate acks)
- Exynos5440 fixes for LPAE configuration, PM
- ...plus a bunch of other smaller changes all over the place
I expect to switch to regressions-or-severe-bugs-only fixes from here
on out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJR8cSDAAoJEIwa5zzehBx3dgsQAIRYV0xKDWYUgzvLGx1Gn/eC
tUw5JeT13eSyEzPL8vAHyMFkI/N7yUzExMjzULPsDXiKHCkRDosLqwxNRFCSVBEv
vp6ipoa75t+l7sys4lOoTVZGY+Pt0SJDIs1jpkTzWPt+BtFanKpaOFJN0hCMZh1j
x0ls+TX4UUsl7MhxtTSEHSMIjt+8bz4rxE6shQOSRePGHkQKrsS1VrFAIC+u1x5b
bkAU3KdLCu5i4qNSU5Niqg2VgRWzxrkR1lQiY8e0BtGqmret9itYFsRWwdZ0qrLQ
Q6aYnR6O/uWH1i2g+Fcl+R4FJo96hy7KqbI0wJmgKlpG5nRQWhCXyYWo86xjw97G
JOA4EHyV+wcmQIo7ZwjYRae7fJYQeRBdUT6/rVnlW++Hi7ZeHI2DLyNLkwG7iXat
iD3OPgzsQ2beK5QTB6fL8iTv+q4o4hXHFDmFukjPYdR3NPHNaJ+uuaI78rUAblmc
RoQ38UzSL82kiseaFP8b7sU9P1JF2hopPDLA7rdSyKBCLczEhzXvgXG1XJVwOdmA
FTBf1g9taawLAxzaJOC82wYrTCLWX2dzv3DeCbaEpzYq1nblJrqYLerQ6Rb0c5xy
V7a+h4aQhLsZvA2Qu7NGBD0wv47d7r5UAPUS1i4Em1Yi+syrBNY4XCiJhBH0fZc5
k4PXz5wVMhpyVLrX6bVd
=XOG3
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"This is a largeish batch of fixes, mostly because I missed -rc2 due to
travel/vacation. So in number these are a bit more than ideal unless
you amortize them over two -rcs.
Quick breakdown:
- Defconfig updates
- Making multi_v7_defconfig useful on more hardware to encourage
single-image usage
- Davinci and nomadik updates due to new code merged this merge
window
- Fixes for UART on Samsung platforms, both PM and clock-related
- A handful of warning fixes from defconfig builds, including for
max8925 backlight and pxamci (both with appropriate acks)
- Exynos5440 fixes for LPAE configuration, PM
- ...plus a bunch of other smaller changes all over the place
I expect to switch to regressions-or-severe-bugs-only fixes from here
on out"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (37 commits)
mfd: max8925: fix dt code for backlight
ARM: omap5: Only select errata 798181 if SMP
ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
ARM: EXYNOS: Fix low level debug support
ARM: SAMSUNG: Save/restore only selected uart's registers
ARM: SAMSUNG: Add SAMSUNG_PM config option to select pm
ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART
ARM: multi_v7_defconfig: Select USB chipidea driver
ARM: pxa: propagate errors from regulator_enable() to pxamci
ARM: zynq: fix compilation warning
ARM: keystone: fix compilation warning
ARM: highbank: Only touch common coherency control register fields
ARM: footbridge: fix overlapping PCI mappings
dmaengine: shdma: fix a build failure on platforms with no DMA support
ARM: STi: Set correct ARM ERRATAs.
ARM: dts: STi: Fix pinconf setup for STiH416 serial2
ARM: nomadik: configure for NO_HZ and HRTIMERS
ARM: nomadik: update defconfig base
ARM: nomadik: Update MMC defconfigs
ARM: davinci: defconfig: enable EDMA driver
...
