If SMAP support is not compiled into the kernel, don't enable SMAP in
CR4 -- in fact, we should clear it, because the kernel doesn't contain
the proper STAC/CLAC instructions for SMAP support.
Found by Fengguang Wu's test system.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.7+
Retrying indefinitely places too much trust on the aux implementation of
the sink devices.
Reported-by: Daniel Martin <consume.noise@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Tested-by: Theodore Ts'o <tytso@mit.edu>
Tested-by: Sree Harsha Totakura <freedesktop@h.totakura.in>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Give more slack to sink devices before retrying on native aux
defer. AFAICT the 100 us timeout was not based on the DP spec.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org (on Jani's request)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix incorrect sscanf() string in function acpi_battery_alarm_store().
Signed-off-by: Luis G.F <luisgf@luisgf.es>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI thermal driver defines acpi_thermal_resume() when
CONFIG_PM_SLEEP is defined. This results in the following compile
error when CONFIG_PM_SLEEP is undefined.
CC drivers/acpi/thermal.o
drivers/acpi/thermal.c:107:8: error: ‘acpi_thermal_resume’ undeclared here (not in a function)
make[2]: *** [drivers/acpi/thermal.o] Error 1
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI SBS driver defines acpi_sbs_resume() when CONFIG_PM_SLEEP is
defined. This results in the following compile error when CONFIG_PM_SLEEP
is undefined:
CC [M] drivers/acpi/sbs.o
drivers/acpi/sbs.c:674:8: error: ‘acpi_sbs_resume’ undeclared here (not in a function)
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI fan driver defines acpi_fan_suspend() and acpi_fan_resume()
when CONFIG_PM_SLEEP is defined. This results in the following compile
errors when CONFIG_PM_SLEEP is undefined:
drivers/acpi/fan.c:60:8: error: ‘acpi_fan_suspend’ undeclared here (not in a function)
drivers/acpi/fan.c:60:8: error: ‘acpi_fan_resume’ undeclared here (not in a function)
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI button driver defines acpi_button_resume() when
CONFIG_PM_SLEEP is defined. This results in the following
compile error when CONFIG_PM_SLEEP is undefined:
drivers/acpi/button.c:85:8: error: ‘acpi_button_resume’ undeclared here (not in a function)
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI battery driver defines acpi_battery_resume() when
CONFIG_PM_SLEEP is defined. This results in the following compile
error when CONFIG_PM_SLEEP is undefined:
drivers/acpi/battery.c:847:8: error: ‘acpi_battery_resume’ undeclared here (not in a function)
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI AC driver defines acpi_ac_resume() when CONFIG_PM_SLEEP is
defined. This results in the following compile error when
CONFIG_PM_SLEEP is undefined:
drivers/acpi/ac.c:248:8: error: ‘acpi_ac_resume’ undeclared here (not in a function)
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
NICs supported by iwldvm don't handle well TX AMPDU.
Disable it by default, still leave the possibility to
the user to force enable it with a debug parameter.
NICs supported by iwlmvm don't suffer from the same issue,
leave TX AMPDU enabled by default for these.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
I started noticing problems with KVM guest destruction on Linux
3.12+, where guest memory wasn't being cleaned up. I bisected it
down to the commit introducing the new 'asm goto'-based atomics,
and found this quirk was later applied to those.
Unfortunately, even with GCC 4.8.2 (which ostensibly fixed the
known 'asm goto' bug) I am still getting some kind of
miscompilation. If I enable the asm_volatile_goto quirk for my
compiler, KVM guests are destroyed correctly and the memory is
cleaned up.
So make the quirk unconditional for now, until bug is found
and fixed.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1392274867-15236-1-git-send-email-steven@uplinklabs.net
Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Signed-off-by: Ingo Molnar <mingo@kernel.org>
It can be corrected later and may be what was actually desired, but
generally isn't, so if we find nothing is enabled, let the core DRM fb
helper figure something out.
v2: free the array too (Jesse)
Note that this also undoes any changes in case we bail out due to hw
cloning.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will make the code more readable, and extensible which is needed
for upcoming feature work. Eventually, we'll do the same for init.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have a couple of switch cases to compute the port value for the
VIDEO_DIP_CTL register. Replace them with a simple macro.
We do lose a few BUG() calls, but many people may consider that
an improvement.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Russell King observed 'wierd' looking output from debugfs, and also suggested
better ways of getting device names (use KBUILD_MODNAME, dev_name())
This patch addresses these issues to make the debugfs output correct and better
looking.
While at it, replace seq_printf with seq_puts to remove the checkpatch.pl
warnings.
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Interestingly, the raid5 code can actually prevent double initialization and
hence can use the following simplified form of callback registration:
register_cpu_notifier(&foobar_cpu_notifier);
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
put_online_cpus();
A hotplug operation that occurs between registering the notifier and calling
get_online_cpus(), won't disrupt anything, because the code takes care to
perform the memory allocations only once.
So reorganize the code in raid5 this way to fix the deadlock with callback
registration.
Cc: linux-raid@vger.kernel.org
Cc: stable@vger.kernel.org (v2.6.32+)
Fixes: 36d1c6476b
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
[Srivatsa: Fixed the unregister_cpu_notifier() deadlock, added the
free_scratch_buffer() helper to condense code further and wrote the changelog.]
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Though my old email address continues to work as alias, updating
to the new address as it's shorter, easier and more appropriate.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove the reporting of energy since it does not provide any useful
information about the state of the driver and will be a maintainance
headache going forward since the RAPL energy units register is not
architectural and subject to change between micro-architectures
References: https://bugzilla.kernel.org/show_bug.cgi?id=69831
Fixes: b69880f9cc (intel_pstate: Add trace point to report internal state.)
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Enabling some of the mvebu platforms in the multiplatform config for ARM
enabled these drivers, which also triggered a bunch of warnings when LPAE
is enabled (thus making phys_addr_t 64-bit).
Most changes are switching printk formats, but also a bit of changes to what
used to be array-based pointer arithmetic that could just be done with the
address types instead.
The warnings were:
drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
Acked-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Olof Johansson <olof@lixom.net>
This reverts commit ab3f5faa62.
Explanation from Hugh:
It's because more thorough testing, by others here, found that it
wasn't always solving the problem: so I asked Tejun privately to
hold off from sending it in, until we'd worked out why not.
Most of our testing being on a v3,11-based kernel, it was perfectly
possible that the problem was merely our own e.g. missing Tejun's
8a2b753844 ("workqueue: fix ordered workqueues in NUMA setups").
But that turned out not to be enough to fix it either. Then Filipe
pointed out how percpu_ref_kill_and_confirm() uses call_rcu_sched()
before we ever get to put the offline on to the workqueue: by the
time we get to the workqueue, the ordering has already been lost.
So, thanks for the Acks, but I'm afraid that this ordered workqueue
solution is just not good enough: we should simply forget that patch
and provide a different answer."
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Need to take into account that protection sg_list
(copy-buffer) may consist of multiple entries.
Changes from v0:
- Changed commit description
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The CMD_T_FAILED flag is set used in one place to record the result of a
trivial test, and it is only tested once, few lines later. We might as
well make the code simpler and easier to read by directly doing the test
of "success" where we want to use it.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch fixes Status SNACK handling of BegRun=0 to allow
for all unacknowledged respones to be resent, instead of
always assuming that BegRun would be an explicit value less
than the current ExpStatSN.
Reported-by: santosh kulkarni <santosh.kulkarni@calsoftinc.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Commit fbfe858fea ("target_core_spc: Include target device
descriptor in VPD page 83") added a new length variable, but (due to a
cut and paste mistake?) just checks scsi_name_len against 256 twice.
Fix this to check scsi_target_len for overflow too.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The only place this struct member is touched is in one INIT_LIST_HEAD.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch changes core_alua_state_lba_dependent() to use do_div()
instead sector_div() to avoid the following link error on 32-bit
with CONFIG_LBDAF=n as reported by Jim:
buildlog-1391099072.txt-drivers/built-in.o: In function `target_alua_state_check':
buildlog-1391099072.txt-(.text+0x928d93): undefined reference to `__umoddi3'
buildlog-1391099072.txt:make: *** [vmlinux] Error 1 --
buildlog-1391101753.txt- CC init/version.o
buildlog-1391101753.txt- LD init/built-in.o
buildlog-1391101753.txt-drivers/built-in.o: In function `core_alua_state_lba_dependent':
buildlog-1391101753.txt-/home/jim/linux/drivers/target/target_core_alua.c:503: undefined reference to `__umoddi3'
buildlog-1391101753.txt:make: *** [vmlinux] Error 1
Reported-by: Jim Davis <jim.epost@gmail.com>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch addresses a >= v3.11 free-after-use regression
in core_scsi3_emulate_pro_register() that was introduced
in the following commit:
commit bc118fe4c4
Author: Andy Grover <agrover@redhat.com>
Date: Thu May 16 10:41:04 2013 -0700
target: Further refactoring of core_scsi3_emulate_pro_register()
To avoid the free-after-use, save an type value before hand, and
only call core_scsi3_put_pr_reg() with a valid *pr_reg.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Andy Grover <agrover@redhat.com>
Cc: <stable@vger.kernel.org> #3.11+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
... past the check for DRIVER_MODESET. Avoids races with userspace
opening a master and our sarea setup.
Cc: Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We assign the sarea_priv pointer only in the dma ioctl, which is
disallowed when kernel modesetting is enabled. So this is dead code.
Cc: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BIOS or boot loader will generally create an initial display
configuration for us that includes some set of active pipes and
displays. This routine tries to figure out which pipes and connectors
are active and stuffs them into the crtcs and modes array given to us by
the drm_fb_helper code.
The overall sequence is:
intel_fbdev_init - from driver load
intel_fbdev_init_bios - initialize the intel_fbdev using BIOS data
drm_fb_helper_init - build fb helper structs
drm_fb_helper_single_add_all_connectors - more fb helper structs
intel_fbdev_initial_config - apply the config
drm_fb_helper_initial_config - call ->probe then register_framebuffer()
drm_setup_crtcs - build crtc config for fbdev
intel_fb_initial_config - find active connectors etc
drm_fb_helper_single_fb_probe - set up fbdev
intelfb_create - re-use or alloc fb, build out fbdev structs
v2: use BIOS connector config unconditionally if possible (Daniel)
check for crtc cloning and reject (Daniel)
fix up comments (Daniel)
v3: use command line args and preferred modes first (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Re-add the WARN_ON for a missing encoder crtc - the state
sanitizer should take care of this. And spell-ocd the comments.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows drivers to use them in custom initial_config functions.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just a bit of polish which I hope will help me with massaging some
internal patches to use Imre's reworked pipestat handling:
- Don't check for underrun reporting or enable pipestat interrupts
twice.
- Frob the comments a bit.
- Do the iir PIPE_EVENT to pipe mapping explicitly with a switch. We
only have one place which does this, so better to make it explicit.
v2: Ville noticed that I've broken the logic a bit with trying to
avoid checking whether we're interested in a given pipe twice. push
the PIPESTAT read down after we've computed the mask of interesting
bits first to avoid that duplication properly.
v3: Squash in fixups from Imre on irc.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Marvell SoCs place the SoC number into the PCIe endpoint device ID. The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.
The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.
When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality. Debian would
like to use this in order to aid installing the correct DTB file.
Fixes: 45361a4fe4 ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org # v3.11+
- Fix ARM and Xen FIFO not working.
- Remove more Xen ia64 vestigates.
- Fix UAPI missing Xen files.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJS+j6MAAoJEFjIrFwIi8fJnwsH/2KAR3OU6Xye10bXzHVf/SLD
C7q7OR0tYPSWAesJ+W2B0pzrWbs4sZF+rr0ctLPH0neE6dqxiv2fypT5WHCQDS4E
WLmFtzwxVOXr4wy7vCH5VWP9Xc8ACLnyFHrQXycT7kV4+jlcHC2DkeiJ02bKtUR9
1MgUXem8OrdLvtvKMG7Zlw8c5xgJ5QQskCMMja1DjkRtUYnpgxQk/gqNhf+c20zj
NeRBSvwi2zxYwyH7l26zGusk08cvNEBKDnZaxXsraHXIFMDaLdkmWBEp8Y5Bjn+D
xWHofrRpARPKSODL9wN0ozUdKEVFmlMwfiHB0OqY/rHip3+3ceYJDTZ7brjV3gE=
=i0aW
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.14-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull Xen bugfixes from Konrad Rzeszutek Wilk:
"This has an healthy amount of code being removed - which we do not use
anymore (the only user of it was ia64 Xen which had been removed
already). The other bug-fixes are to make Xen ARM be able to use the
new event channel mechanism and proper export of header files to
user-space.
Summary:
- Fix ARM and Xen FIFO not working.
- Remove more Xen ia64 vestigates.
- Fix UAPI missing Xen files"
* tag 'stable/for-linus-3.14-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
ia64/xen: Remove Xen support for ia64 even more
xen: install xen/gntdev.h and xen/gntalloc.h
xen/events: bind all new interdomain events to VCPU0
Sync regcache when entering STANDBY from OFF. ON isn't entered with
OFF as the current state, so the registers were not being re-synced
after suspend/resume.
The 98088 and 98095 already call regcache_sync from STANDBY.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
Set the return variable to an error code as done elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Set the return variable to an error code as done elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Make sure all guest-backed object commands are properly packed.
Have the command verifier treat uninitialized command entries as invalid
rather than dereferencing NULL pointers.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
We want to reuse this in the fbdev initial config code independently
from any fastboot hacks. So allow a bit more flexibility.
v2: Forgot to git add ...
v3: make non-static (Jesse)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to do this early on before we try to fetch the plane config,
which depends on some of the pipe config state.
Note that the important part is that we do this before we initialize
gem, since otherwise we can't properly pre-reserve the stolen memory
for framebuffers inherited from the bios.
v2: split back out from get_plane_config change (Daniel)
update for recent locking & reset changes (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Explain a bit more why we need to move this.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far during driver unload we called drm_framebuffer_cleanup() for the
fbdev fb, which only removes the fb from the drm fb list regardless of
its reference count, but leaves the fb bound on an active crtc. Since
the fb's backing storage was freed this could mean we scan some random
memory content out afterwards. It's not a big issue since the fb is
allocated from stolen memory and afaik there is no other user for that
than i915. It's still cleaner to properly unbind the fb and disable the
crtc, which is what drm_framebuffer_remove() does.
Note that after
commit 88891eb1e9eca0ba619518bed31580f91e9cf84d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Feb 10 18:00:38 2014 +0100
we call drm_framebuffer_cleanup() only after dropping the last reference
on the fb, but that won't happen since we don't unbind the fb. This
results in a drm core warn about a leaked fb.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Everything can be overridden by module parameters, so don't confuse the
users that are using them.
We have RC6 turned on for all platforms which support it, but Ironlake,
so the need to explain the situation is no longer pressing.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It wasn't ever used by the caller anyway with the exception of what we
show in sysfs.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Apply Deepak's suggestion.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
