The version offered by the core is ridiculously optimized and
does the same thing. So use it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
It fiddles the sarea out of the maps which are also handled in
drm_bufs.c
With this drm_drv.c is a notch more legacy free.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.
Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to keep it
around. This simplifies code paths in drivers, too.
Last but not least, fix gma500 to call drm_gem_object_release() before
freeing objects that were allocated via drm_gem_private_object_init().
That isn't actually necessary for now, but might be in the future.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Only ever re-cleared in drm_setup, otherwise completely unused.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
There's no other caller from driver code, so we can fold this in.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Really, this is all old-style stuff and just copy-pasta from the
ums driver.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The former doesn't do anything without DRIVER_HAVE_DMA (which is
force-disabled for kms drivers anyway). The latter isn't used by the
(kms) nouveau ddx.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
No need to create a dummy ioctl function to return -EINVAL, since
that's what the core already does in the absence of the dma_ioctl
callback. So we can safely remove this.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Only ever assigned in the context code for real, with no readers
anywhere. Remove it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
No one ever waits on this waitqueue, so the wake_up call is wasted.
Remove it all.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
In
commit 325b9d0488
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 19 11:24:33 2013 +0200
drm/i915: fixup 12bpc hdmi dotclock handling
I've errornously claimed that we don't yet support the hdmi 1.4
dotclocks > 225 MHz on Haswell. But a bug report and a closer look at
the wrpll table showed that we've supported port clocks up to 300MHz.
With the new code to dynamically compute wrpll limits we should have
no issues going up to the full 340 MHz range of hdmi 1.4, so let's
just use that to fix this regression. That'll allow 4k over hdmi for
free!
v2: Drop the random hunk that somehow slipped in.
v3: Cantiga has the original HDMI dotclock limit of 165MHz. And also
patch up the mode filtering. To do so extract the dotclock limits into
a little helper function.
v4: Use 300MHz (from Bspec) instead of 340MHz (upper limit for hdmi
1.3), apparently hw is not required to be able to drive the highest
dotclocks. Suggested by Damien.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67048
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
Tested-by: Andreas Reis <andreas.reis@gmail.com> (v2)
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Change to using max P-state instead of max turbo P-state. This
change resolves two issues.
On a quiet system intel_pstate can fail to respond to a load change.
On CPU SKUs that have a limited number of P-states and no turbo range
intel_pstate fails to select the highest available P-state.
This change is suitable for stable v3.9+
References: https://bugzilla.kernel.org/show_bug.cgi?id=59481
Reported-and-tested-by: Arjan van de Ven <arjan@linux.intel.com>
Reported-and-tested-by: dsmythies@telus.net
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull thermal management fixes from Zhang Rui:
"These are fixes collected over the last week, they fixes several
problems caused by the x86_pkg_temp_thermal introduced in 3.11-rc1.
Specifics:
- the x86_pkg_temp_thermal driver causes crash on systems with no
package MSR support as there is a bug in the logic to check
presence of DTHERM and PTS feature together. Added a change so
that when there is no PTS support, module doesn't get loaded.
- fix krealloc() misuse in pkg_temp_thermal_device_add().
If krealloc() returns NULL, it doesn't free the original. Thus if
we want to exit because of the krealloc() failure, we must make
sure the original one is freed.
- The error code path of the x86 package temperature thermal driver's
initialization routine makes an unbalanced call to
get_online_cpus(), which causes subsequent CPU offline operations,
and consequently system suspend, to permanently block in
cpu_hotplug_begin() on systems where get_core_online() returns an
error code.
Remove the extra get_online_cpus() to fix the problem"
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
Thermal: Fix lockup of cpu_down()
Thermal: x86_pkg_temp: Limit number of pkg temp zones
Thermal: x86_pkg_temp: fix krealloc() misuse in in pkg_temp_thermal_device_add()
Thermal: x86 package temp thermal crash
- OMAP device tree boot fix
- Handle an error condition in the MSM driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJR7cUHAAoJEEEQszewGV1zor0P/3cBk+OpJxbEtC0xf4RZJLka
VQ9Yv/W7aaIbdYCvNwoXOCBFFW2eWniN6XwHRzWmxRZNnP7GrNLRU41KchCuRrjz
mZMKKwwjHriIZ9Kz1WmB2Pbc2mKAOoEc0vjRQCiNajR+/dyQnrjYqwo9mEQO1g6Z
Yn4n8tx85CJVF+63Its5UnYy3yHNDuzt160SyGb660qYiinBlWmf0N+pzZ9MKlvZ
9HUsRElfgjRqwvIan0SzhkdP3PBWdycEo8sRXv4Wgb1+Jb5YkbNhFjbRIJUyUVOx
+gyfXhsvYWFEOANpzywbRdfUpfjYVkER/rNkDeTZzwvjneyCVokzawVfvkpMikmH
pJ4gxxipRcELsTLa5h+EaA80MfiKlH/LesGiEQimr17vVkTu6ZPGHmb0PKISQp39
JZmTdwqodWCzV/Eldtz8ykKx8fZzDg7Y9cTr7SGPgTTFgpaOdzU0wIQTVy2fBjPV
+SOWJ/998eV9tatI+v4v+xyPD8zeyGuC14IDGZa/kwsJf9S8/87gfVXNyMnUOz/F
edyLuX7kFt7segkpBoWD5wa+LAIsnzSNVhlLvV6UX2rz4j9V9zv7fe8pi5JFvjbh
dG3T0/y2OpC5aEzbI8DeTU+FBO6+ss47vqhEaalmUawKlk5RgjgVlVhp4phfP0IQ
2A32KgcjBKV4/QMh3evq
=Ld25
-----END PGP SIGNATURE-----
Merge tag 'gpio-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull gpio fixes from Linus Walleij:
"A first round of GPIO fixes for the v3.11 series:
- OMAP device tree boot fix
- Handle an error condition in the MSM driver
The OMAP patches have been around since around the merge window, but
since they first caused more breakage I let them boil in -next for a
while. These should be fine now"
* tag 'gpio-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
drivers: gpio: msm: Fix the error condition for reading ngpio
gpio/omap: fix build error when OF_GPIO is not defined.
gpio/omap: auto request GPIO as input if used as IRQ via DT
gpio/omap: don't create an IRQ mapping for every GPIO on DT
Pull block IO driver bits from Jens Axboe:
"As I mentioned in the core block pull request, due to real life
circumstances the driver pull request would be late. Now it looks
like -rc2 late... On the plus side, apart form the rsxx update, these
are all things that I could argue could go in later in the cycle as
they are fixes and not features. So even though things are late, it's
not ALL bad.
The pull request contains:
- Updates to bcache, all bug fixes, from Kent.
- A pile of drbd bug fixes (no big features this time!).
- xen blk front/back fixes.
- rsxx driver updates, some of them deferred form 3.10. So should be
well cooked by now"
* 'for-3.11/drivers' of git://git.kernel.dk/linux-block: (63 commits)
bcache: Allocation kthread fixes
bcache: Fix GC_SECTORS_USED() calculation
bcache: Journal replay fix
bcache: Shutdown fix
bcache: Fix a sysfs splat on shutdown
bcache: Advertise that flushes are supported
bcache: check for allocation failures
bcache: Fix a dumb race
bcache: Use standard utility code
bcache: Update email address
bcache: Delete fuzz tester
bcache: Document shrinker reserve better
bcache: FUA fixes
drbd: Allow online change of al-stripes and al-stripe-size
drbd: Constants should be UPPERCASE
drbd: Ignore the exit code of a fence-peer handler if it returns too late
drbd: Fix rcu_read_lock balance on error path
drbd: fix error return code in drbd_init()
drbd: Do not sleep inside rcu
bcache: Refresh usage docs
...
sata_inic162x never reached a state where it's reliable enough for
production use and data corruption is a relatively common occurrence.
Make the driver generate warning about the issues and mark the Kconfig
option as experimental.
If the situation doesn't improve, we'd be better off making it depend
on CONFIG_BROKEN. Let's wait for several cycles and see if the kernel
message draws any attention.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Martin Braure de Calignon <braurede@free.fr>
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Reported-by: risc4all@yahoo.com
This warning has been introduced by the commit
0f9bc4bcdf pinctrl: single: adopt pinctrl sleep mode management
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The usage of strict_strtol() is not preferred, because
strict_strtol() is obsolete. Thus, kstrtol() should be
used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Noticed that my old Radeon 7500 hung after printing
drm: GPU not posted. posting now...
when it wasn't selected as the primary card the BIOS. Some digging
revealed that it was hanging in combios_parse_mmio_table() while
parsing the ASIC INIT 3 table. Looking at the BIOS ROM for the card,
it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
The code is just processing random garbage. No surprise it hangs!
Why do I say that there is no ASIC INIT 3 table is the BIOS? This
table is found through the MISC INFO table. The MISC INFO table can
be found at offset 0x5e in the COMBIOS header. But the header is
smaller than that. The COMBIOS header starts at offset 0x126. The
standard PCI Data Structure (the bit that starts with 'PCIR') lives at
offset 0x180. That means that the COMBIOS header can not be larger
than 0x5a bytes and therefore cannot contain a MISC INFO table.
I looked at a dozen or so BIOS images, some my own, some downloaded from:
<http://www.techpowerup.com/vgabios/index.php?manufacturer=ATI&page=1>
It is fairly obvious that the size of the COMBIOS header can be found
at offset 0x6 of the header. Not sure if it is a 16-bit number or
just an 8-bit number, but that doesn't really matter since the tables
seems to be always smaller than 256 bytes.
So I think combios_get_table_offset() should check if the requested
table is present. This can be done by checking the offset against the
size of the header. See the diff below. The diff is against the WIP
OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
point. But I don't think this bit of the code changed much since
then.
For what it is worth:
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Hopefully avoid more quirks in the future due to bogus
vbios dac data.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Hello,
got another card with "too bright" problem:
Sapphire Radeon VE 7000 DDR (VGA+S-Video)
lspci -vnn:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28]
The patch below fixes the problem for this card.
But I don't like the blacklist, couldn't some heuristic be used instead?
The interesting thing is that the manufacturer is the same as the other card
needing the same quirk. I wonder how many different types are broken this way.
The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.
====================
drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR
Values from BIOS are wrong, causing too bright colors.
Use default values instead.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The atom interpreter expects data in LE format, so
swap the message buffer as apprioriate.
v2: properly handle non-dw aligned byte counts.
v3: properly handle remainder
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Dong He <hedonghust@gmail.com>
Cc: stable@vger.kernel.org
Make sure the 3D engine is idle before using CP DMA for
bo copies.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Marek Olšák <maraeo@gmail.com>
The PFC pinctrl driver on sh73a0 is also regiatering a VccQ regulator for
SDHI0. However, its consumers list only included the platform-data based
SDHI device name. When booted with DT SDHI0 couldn't enable VccQ and
therefore was unusable. Fix this by adding a consumer with DT-based name.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It almost does not matter because most users use only the ->start member
of the struct. However if this struct is passed to a platform device
which is then added via platform_device_add() then the ->parent member is
also used.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
list_first_entry() expects the list is not empty, we need to check if list is
empty before calling list_first_entry(). Thus use list_first_entry_or_null()
instead of list_first_entry().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Set the ehci->resuming flag for the port we receive a remote
wakeup on so that resume signalling can be completed.
Without this, the root hub timer will not fire again to check
if the resume was completed and there will be a never-ending wait on
on the port.
This effect is only observed if the HUB IRQ IN does not come after we
have initiated the port resume.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Added support for MMB Networks and Planet Innovation Ingeni ZigBee USB
devices using customized Silicon Labs' CP210x.c USB to UART bridge
drivers with PIDs: 88A4, 88A5.
Signed-off-by: Sami Rahman <sami.rahman@mmbresearch.com>
Tested-by: Sami Rahman <sami.rahman@mmbresearch.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds support for the Schweitzer Engineering Laboratories
C662 USB cable based off the CP210x driver.
Signed-off-by: Barry Grussling <barry@grussling.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch was tested on 3.10.1 kernel.
Same models of Petatel NP10T modems have different device IDs.
Unfortunately they have no additional revision information on a board
which may treat them as different devices. Currently I've seen only
two NP10T devices with various IDs. Possibly Petatel NP10T list will
be appended upon devices with new IDs will appear.
Signed-off-by: Daniil Bolsun <dan.bolsun@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The device report an error capacity when read_capacity_16().
Using read_capacity_10() can get the correct capacity.
Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds NetGear Managed Switch M4100 series, M5300 series, M7100 series
USB ID (0846:0110) to the cp210x driver. Without this, the serial
adapter is not recognized in Linux. Description was obtained from
an Netgear Eng.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- fixup panel fitter readout for gen2/3 (just quitens dmesg noise)
- fix pft computations for non-autoscaled resolutions (i.e. letter/pillar
boxing on gen2/3)
- preserve the DDI A/E lane sharing bit (Stéphane Marchesin)
- fix the "rc6 fails to work after resume" regression, big thanks to
Konstantin Khlebnikov for the patch and debug insight about what
actually might be going on here
- fix Oops in is_crtc_connector_off (Chris)
- sanitize shared dpll state - our new paranoid state checker tripped up
over dirt left behind by the BIOS
- correctly restore fences, fixes the "my screen is all messed up after
resume" regression introduced in the final 3.10 pull request
- quirk backlights harder, this time for Dell XPS13 machines to fix a
regression (patch from Kamal Mostafa)
- 90% fix for some haswell hangs when accessing registers concurrently,
the 100% solution is simply too invasive for -fixes and what we have
here seems to be good enough (Chris)
* tag 'drm-intel-fixes-2013-07-22' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: fix up gt init sequence fallout
drm/i915: Serialize almost all register access
drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight
drm/i915: correctly restore fences with objects attached
drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off()
drm/i915: Sanitize shared dpll state
drm/i915: fix long-standing SNB regression in power consumption after resume v2
drm/i915: Preserve the DDI_A_4_LANES bit from the bios
drm/i915: fix pfit regression for non-autoscaled resolutions
drm/i915: fix up readout of the lvds dither bit on gen2/3
Commit f1a18a105 "Thermal: CPU Package temperature thermal" had code
that did a get_online_cpus(), run a loop and then do a
put_online_cpus(). The problem is that the loop had an error exit that
would skip the put_online_cpus() part.
In the error exit part of the function, it also did a get_online_cpus(),
run a loop and then put_online_cpus(). The only way to get to the error
exit part is with get_online_cpus() already performed. If this error
condition is hit, the system will be prevented from taking CPUs offline.
The process taking the CPU offline will lock up hard.
Removing the get_online_cpus() removes the lockup as the hotplug CPU
refcount is back to zero.
This was bisected with ktest.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Fixes for some locking issues, and fence timeouts.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: do not allow negative sizes for now
drm/nouveau: add falcon interrupt handler
drm/nouveau: use dedicated channel for async moves on GT/GF chipsets.
drm/nouveau: bump fence timeout to 15 seconds
drm/nouveau: do not unpin in nouveau_gem_object_del
drm/nv50/kms: fix pin refcnt leaks
drm/nouveau: fix some error-path leaks in fbcon handling code
drm/nouveau: fix locking issues in page flipping paths
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b684
Author: Imre Deak <imre.deak@intel.com>
Date: Fri May 3 19:44:07 2013 +0200
drm/i915: force full modeset if the connector is in DPMS OFF mode
which according to Greg KH seems to aim for a new record in most
Bugzilla: links in a commit message.
The history of this dpms forcing is pretty interesting. This patch
here is an almost-revert of
commit 811aaa55ba
Author: Keith Packard <keithp@keithp.com>
Date: Thu Feb 3 16:57:28 2011 -0800
drm: Only set DPMS ON when actually configuring a mode
which fixed the bug of trying to dpms on disabled outputs, but
introduced the new discrepancy between an fb update only and full
modesets. The actual introduction of this goes back to
commit bf9dc102e2
Author: Keith Packard <keithp@keithp.com>
Date: Fri Nov 26 10:45:58 2010 -0800
drm: Set connector DPMS status to ON in drm_crtc_helper_set_config
And if you'd dig around in the i915 driver code there's even more fun
around forcing dpms on and losing our heads and temper of the
resulting inconsistencies. Especially the DP re-training code had tons
of funny stuff in it.
v2: So v1 totally blew up on resume on my radeon system here. After
much head-scraching I've figured out that the radeon resume functions
resumes the console system _before_ it actually restores all the
modeset state. And resuming the console systems means that fbdev doeas
an immediate ->set_par call.
Now up to this patch that ->set_par did absolutely nothing: All the
old sw state from pre-suspend was still around (since the modeset
reset wasn't done yet), which means that the set_config calls done as
a result of the ->set_par where all treated as no-ops (despite that
the real hw state was obviously something completely different).
Since v1 of this patch just added a bunch of ->dpms calls if the crtc
was enabled, those set_config calls suddenly stopped being no-ops. But
because the hw state wasn't restored the ->dpms callbacks resulted in
decent amounts of hilarity and eventual full hangs.
Since I can't review all kms drivers for such tricky ordering
constraints v2 opts for a different approach and forces a full modeset
if the connector dpms state isnt' DPMS_ON. Since the ->dpms callbacks
implemented by the modeset helpers update the connector->dpms property
we have the same effect of ensuring that the pipe is ultimately turned
on, even if we just end up updating the fb. This is the same approac
we ended up using in the intel driver.
Note that besides i915.ko only all other drivers eventually call
drm_helper_connector_dpms with the exception of vmwgfx, which does not
support dmps at all.
v3: Dave Airlie merged the broken first version of this patch, so
squash in the revert of
commit 372835a852
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jun 15 00:13:13 2013 +0200
drm/crtc-helper: explicit DPMS on after modeset
Also fix up the spelling fail a bit in the commit message while at it.
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67043
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this patch adds the lost pin group which supports to let USP0 to simulate
a UART without hardware flow control.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
we missed a pin and related mux bit for usp pin group, this
patch fixes it.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Change from Aaron Lu makes ACPICA export a variable which can be
used by driver code to determine whether or not the BIOS believes
that we are compatible with Windows 8.
- Change from Matthew Garrett makes the ACPI video driver initialize
the ACPI backlight even if it is not going to be used afterward
(that is needed for backlight control to work on Thinkpads).
- Fix from Rafael J Wysocki implements Windows 8 backlight support
workaround making i915 take over bakclight control if the firmware
thinks it's dealing with Windows 8. Based on the work of multiple
developers including Matthew Garrett, Chun-Yi Lee, Seth Forshee,
and Aaron Lu.
- Fix from Aaron Lu makes the kernel follow Windows 8 by informing
the firmware through the _DOS method that it should not carry out
automatic brightness changes, so that brightness can be controlled
by GUI.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJR6yY7AAoJEKhOf7ml8uNsbGUQAIVXwX8HF+9AOnqEIQYEaBiF
HqfLDtHS5qobraK06auF/YmVaA17RdUnHssTuGiEbtIxpiUbuLPJaecZ9BeAf0Pz
V4Y2IxF27aF9TDZrzkZXHcnYflzQ/kxj36eR9AmM2vSXmKZKxhfqLMeihVh2GgMv
IlOs9PltK2GNX6C/CzjUQuUj4TYw8yxXsG93Gta0Z8scmxR7mpq9a9d0cPU/TjN/
iatIhZLFU8ujp8xFiG9MDeG948AtperLu3g0v1D4mPnkmDJTuyMuE3FiioKL2zMY
7jh6mDPkWUYdjdZkJcmyzgKZh5lAlZIJTZnJV6TrW5fjIpUz5F8XeD4ArMVU/u+A
smro6XFcpgToRZTtmaEuraxzJHCS44FTjlXyH01FSIiN/Ll6YKyxDYsAzz4Z2sf6
X5BJofAAiRelZh/o1MaMQzs3QeTUo44TaboGr2zka0cQ37KK9+8YRGYqcWo/BvGs
sicgFKMeA6SANxHnCVNTslQzMYFrPp4yyMEu4gD7EE+U7cG6FSVhVHQjjTO9CmBd
ZnX2EDX0Uy+oHTQ9BkyjWAD7rXF6StnOm37FPWHNZ+HnplHEoQQAn+vXsSfl9tbO
7CPefZ/LQQEo1PZwLLkxruZ67NgxOd8/9I/aVjLUKgd8CDjez0UJVJ65gIXl1J4V
kvaDy6faYTnUF8h/AYJf
=vlwF
-----END PGP SIGNATURE-----
Merge tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI video support fixes from Rafael Wysocki:
"I'm sending a separate pull request for this as it may be somewhat
controversial. The breakage addressed here is not really new and the
fixes may not satisfy all users of the affected systems, but we've had
so much back and forth dance in this area over the last several weeks
that I think it's time to actually make some progress.
The source of the problem is that about a year ago we started to tell
BIOSes that we're compatible with Windows 8, which we really need to
do, because some systems shipping with Windows 8 are tested with it
and nothing else, so if we tell their BIOSes that we aren't compatible
with Windows 8, we expose our users to untested BIOS/AML code paths.
However, as it turns out, some Windows 8-specific AML code paths are
not tested either, because Windows 8 actually doesn't use the ACPI
methods containing them, so if we declare Windows 8 compatibility and
attempt to use those ACPI methods, things break. That occurs mostly
in the backlight support area where in particular the _BCM and _BQC
methods are plain unusable on some systems if the OS declares Windows
8 compatibility.
[ The additional twist is that they actually become usable if the OS
says it is not compatible with Windows 8, but that may cause
problems to show up elsewhere ]
Investigation carried out by Matthew Garrett indicates that what
Windows 8 does about backlight is to leave backlight control up to
individual graphics drivers. At least there's evidence that it does
that if the Intel graphics driver is used, so we've decided to follow
Windows 8 in that respect and allow i915 to control backlight (Daniel
likes that part).
The first commit from Aaron Lu makes ACPICA export the variable from
which we can infer whether or not the BIOS believes that we are
compatible with Windows 8.
The second commit from Matthew Garrett prepares the ACPI video driver
by making it initialize the ACPI backlight even if it is not going to
be used afterward (that is needed for backlight control to work on
Thinkpads).
The third commit implements the actual workaround making i915 take
over backlight control if the firmware thinks it's dealing with
Windows 8 and is based on the work of multiple developers, including
Matthew Garrett, Chun-Yi Lee, Seth Forshee, and Aaron Lu.
The final commit from Aaron Lu makes us follow Windows 8 by informing
the firmware through the _DOS method that it should not carry out
automatic brightness changes, so that brightness can be controlled by
GUI.
Hopefully, this approach will allow us to avoid using blacklists of
systems that should not declare Windows 8 compatibility just to avoid
backlight control problems in the future.
- Change from Aaron Lu makes ACPICA export a variable which can be
used by driver code to determine whether or not the BIOS believes
that we are compatible with Windows 8.
- Change from Matthew Garrett makes the ACPI video driver initialize
the ACPI backlight even if it is not going to be used afterward
(that is needed for backlight control to work on Thinkpads).
- Fix from Rafael J Wysocki implements Windows 8 backlight support
workaround making i915 take over bakclight control if the firmware
thinks it's dealing with Windows 8. Based on the work of multiple
developers including Matthew Garrett, Chun-Yi Lee, Seth Forshee,
and Aaron Lu.
- Fix from Aaron Lu makes the kernel follow Windows 8 by informing
the firmware through the _DOS method that it should not carry out
automatic brightness changes, so that brightness can be controlled
by GUI"
* tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / video: no automatic brightness changes by win8-compatible firmware
ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
ACPI / video: Always call acpi_video_init_brightness() on init
ACPICA: expose OSI version
The regression fix for gen6+ rps fallout
commit 7dcd2677ea
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Wed Jul 17 10:22:58 2013 +0400
drm/i915: fix long-standing SNB regression in power consumption after resume
unintentionally also changed the init sequence ordering between
gt_init and gt_reset - we need to reset BIOS damage like leftover
forcewake references before we run our own code. Otherwise we can get
nasty dmesg noise like
[drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
again. Since _reset suggests that we first need to have stuff
initialized (which isn't the case here) call it sanitze instead.
While at it also block out the rps disable introduced by the above
commit on ilk: We don't have any knowledge of ilk rps being broken in
similar ways. And the disable functions uses the default hw state
which is only read out when we're enabling rps. So essentially we've
been writing random grabage into that register.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Here are a few iio driver fixes for 3.11-rc2. They are still spread
across drivers/iio and drivers/staging/iio so they are coming in through
this tree.
I've also removed the drivers/staging/csr/ driver as the developers who
originally sent it to me have moved on to other companies, and CSR still
will not send us the specs for the device, making the driver pretty much
obsolete and impossible to fix up. Deleting it now prevents people from
sending in lots of tiny codingsyle fixes that will never go anywhere.
It also helps to offset the large lustre filesystem merge that happened
in 3.11-rc1 in the overall 3.11.0 diffstat. :)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iEYEABECAAYFAlHq64AACgkQMUfUDdst+ynysQCgwUM8pbZ7iJGDJAW2TahKwVie
f5MAnRR8DokyE7iWwXDEx5UYVPerMrpq
=9ORA
-----END PGP SIGNATURE-----
Merge tag 'staging-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging tree fixes from Greg KH:
"Here are a few iio driver fixes for 3.11-rc2. They are still spread
across drivers/iio and drivers/staging/iio so they are coming in
through this tree.
I've also removed the drivers/staging/csr/ driver as the developers
who originally sent it to me have moved on to other companies, and CSR
still will not send us the specs for the device, making the driver
pretty much obsolete and impossible to fix up. Deleting it now
prevents people from sending in lots of tiny codingsyle fixes that
will never go anywhere.
It also helps to offset the large lustre filesystem merge that
happened in 3.11-rc1 in the overall 3.11.0 diffstat. :)"
* tag 'staging-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: csr: remove driver
iio: lps331ap: Fix wrong in_pressure_scale output value
iio staging: fix lis3l02dq, read error handling
staging:iio:ad7291: add missing .driver_module to struct iio_info
iio: ti_am335x_adc: add missing .driver_module to struct iio_info
iio: mxs-lradc: Remove useless check in read_raw
iio: mxs-lradc: Fix misuse of iio->trig
iio: inkern: fix iio_convert_raw_to_processed_unlocked
iio: Fix iio_channel_has_info
iio:trigger: device_unregister->device_del to avoid double free
iio: dac: ad7303: fix error return code in ad7303_probe()
of_property_read_u32 return 0 on success. The check was using a ! to
return error. Fix the if condition.
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Pankaj Jangra <jangra.pankaj9@gmail.com>
Cc: "Bird, Tim" <Tim.Bird@sonymobile.com>
Signed-off-by: David Brown <davidb@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The OMAP GPIO driver check if the chip has an associated
Device Tree node using the struct gpio_chip of_node member.
But this is only build if CONFIG_OF_GPIO is defined which
leads to the following error when using omap1_defconfig:
linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_chip_init':
linux/drivers/gpio/gpio-omap.c:1080:17: error: 'struct gpio_chip' has no member named 'of_node'
linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_map':
linux/drivers/gpio/gpio-omap.c:1116:16: error: 'struct gpio_chip' has no member named 'of_node'
Reported-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drives should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just request the IRQ and this has to
be handled by the irq_chip driver.
With the current OMAP GPIO DT binding, if we define:
gpio6: gpio@49058000 {
compatible = "ti,omap3-gpio";
reg = <0x49058000 0x200>;
interrupts = <34>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
interrupt-parent = <&gpio6>;
interrupts = <16 8>;
The GPIO is correctly mapped as an IRQ but a call to gpio_request()
is never made. Since a call to the custom IRQ domain .map function
handler is made for each GPIO used as an IRQ, the GPIO can be setup
and configured as input there automatically.
Changes since v3:
- Use bank->chip.of_node instead of_have_populated_dt() to check
DT or legacy boot as suggested by Jean-Christophe PLAGNIOL-VILLARD
- Add a comment that this is just a temporary solution until and
that it has to be removed once is handled by the IRQ core.
Changes since v2:
- Only make the call to gpio_request_one() conditional in the DT
case as suggested by Grant Likely.
Changes since v1:
- Split the irq domain mapping function handler and the GPIO
request in two different patches.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When a GPIO is defined as an interrupt line using Device
Tree, a call to irq_create_of_mapping() is made that calls
irq_create_mapping(). So, is not necessary to do the mapping
for all OMAP GPIO lines and explicitly call irq_create_mapping()
on the driver probe() when booting with Device Tree.
Add a custom IRQ domain .map function handler that will be
called by irq_create_mapping() to map the GPIO lines used as IRQ.
This also allows to execute needed setup code such as configuring
a GPIO as input and enabling the GPIO bank.
Changes since v3:
- Use bank->chip.of_node instead of_have_populated_dt() to check
DT or legacy boot as suggested by Jean-Christophe PLAGNIOL-VILLARD
Changes since v2:
- Unconditionally do the IRQ setup in the .map() function and
only call irq_create_mapping() in the gpio chip init to avoid
code duplication as suggested by Grant Likely.
Changes since v1:
- Split the addition of the .map function handler and the
automatic gpio request in two different patches.
- Add GPIO IRQ setup logic to the irq domain mapping function.
- Only call irq_create_mapping for every GPIO on legacy boot.
- Only setup a GPIO IRQ on the .map function for DeviceTree boot.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In theory, the different register blocks were meant to be only ever
touched when holding either the struct_mutex, mode_config.lock or even a
specific localised lock. This does not seem to be the case, and the
hardware reacts extremely badly if we attempt to concurrently access two
registers within the same cacheline.
The HSD suggests that we only need to do this workaround for display
range registers. However, upon review we need to serialize the multiple
stages in our register write functions - if only for preemption
protection.
Irrespective of the hardware requirements, the current io functions are
a little too loose with respect to the combination of pre- and
post-condition testing that we do in conjunction with the actual io. As
a result, we may be pre-empted and generate both false-postive and
false-negative errors.
Note well that this is a "90%" solution, there remains a few direct
users of ioread/iowrite which will be fixed up in the next few patches.
Since they are more invasive and that this simple change will prevent
almost all lockups on Haswell, we kept this patch simple to facilitate
backporting to stable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63914
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
BugLink: https://bugs.launchpad.net/bugs/1163720
BugLink: https://bugs.launchpad.net/bugs/1162026
Some machines suffer from non-functional backlight controls if
BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so.
Apply this quirk to Dell XPS 13 models.
Tested-by: Eric Griffith <EGriffith92@gmail.com>
Tested-by: Kent Baxley <kent.baxley@canonical.com>
Cc: <stable@vger.kernel.org> # v3.8+
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull s390 fixes from Martin Schwidefsky:
"An update for the BFP jit to the latest and greatest, two patches to
get kdump working again, the random-abort ptrace extention for
transactional execution, the z90crypt module alias for ap and a tiny
cleanup"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/zcrypt: Alias for new zcrypt device driver base module
s390/kdump: Allow copy_oldmem_page() copy to virtual memory
s390/kdump: Disable mmap for s390
s390/bpf,jit: add pkt_type support
s390/bpf,jit: address randomize and write protect jit code
s390/bpf,jit: use generic jit dumper
s390/bpf,jit: call module_free() from any context
s390/qdio: remove unused variable
s390/ptrace: PTRACE_TE_ABORT_RAND
- Two cpufreq commits from the 3.10 cycle introduced regressions.
The first of them was buggy (it did way much more than it needed
to do) and the second one attempted to fix an issue introduced by
the first one. Fixes from Srivatsa S Bhat revert both.
- If autosleep triggers during system shutdown and the shutdown
callbacks of some device drivers have been called already, it may
crash the system. Fix from Liu Shuo prevents that from happening
by making try_to_suspend() check system_state.
- The ACPI memory hotplug driver doesn't clear its driver_data on
errors which may cause a NULL poiter dereference to happen later.
Fix from Toshi Kani.
- The ACPI namespace scanning code should not try to attach scan
handlers to device objects that have them already, which may confuse
things quite a bit, and it should rescan the whole namespace branch
starting at the given node after receiving a bus check notify event
even if the device at that particular node has been discovered
already. Fixes from Rafael J Wysocki.
- New ACPI video blacklist entry for a system whose initial backlight
setting from the BIOS doesn't make sense. From Lan Tianyu.
- Garbage string output avoindance for ACPI PNP from Liu Shuo.
- Two Kconfig fixes for issues introduced recently in the s3c24xx
cpufreq driver (when moving the driver to drivers/cpufreq) from
Paul Bolle.
- Trivial comment fix in pm_wakeup.h from Chanwoo Choi.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJR6Sq+AAoJEKhOf7ml8uNsrGQP/0HRDW+QmTGM8znDTHXngbn9
X3pqlpjEOiCtcmJaSJlD7GwLHMscwWcHKEezteaZ7KUI4mcnysJX6EY5YVbNriDC
xlLcDQn9c6Xx1maCSfp+WMygvqItxZwuc8veRjrT3XtOfCNWS/FlX40Voh63BCAe
GbfQ/HesmUg5CKplyD8/XypLWh5OFXmHzCe8IhrKGfhsZukXdSgSBjwQZMRrEMsQ
kJjDCF8zUu0JisiWqL+xE6IFSKme9i6LBlHpzU0Y1g4RqAqkIbuS0Z3vezOYzoTD
oZjBNa9XAgCS3x0l5g3G0ChgDAU+Mpji/imXA7JysrwbirGFbtPHtQYh2HzpAtnw
Hkah/0ocBM7/w7VTsUQiRsFPdIJTCBLlm6J38x8yh7n84h4nJgOpK69dBLrMwCUZ
f3kid6KIPVLBvnC3QSULrCAKUcUcVVWYtNho+sfXBMjP+cPwTmc3DvATnpru6twa
0KjR5o585UOcciq7EWAoMrCFCfZYF5C4XGaZAxHI/SWooxeCQH84S8vfNLL2epVC
ixmLYo4X2ANDsnfbUV+ewhB0/L2905Et6NhPUgPD/1rm15MEZbowbB2K0pzr0QL9
/1hTL61InXx3jLxducJJFKN+HZ0zfDQdTkyafKrR9jb+GsdmnzYJ/vnfDG8MfPjp
GZ281YBqVmUeYJh5CPU+
=IUmn
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki:
"These are fixes collected over the last week, most importnatly two
cpufreq reverts fixing regressions introduced in 3.10, an autoseelp
fix preventing systems using it from crashing during shutdown and two
ACPI scan fixes related to hotplug.
Specifics:
- Two cpufreq commits from the 3.10 cycle introduced regressions.
The first of them was buggy (it did way much more than it needed to
do) and the second one attempted to fix an issue introduced by the
first one. Fixes from Srivatsa S Bhat revert both.
- If autosleep triggers during system shutdown and the shutdown
callbacks of some device drivers have been called already, it may
crash the system. Fix from Liu Shuo prevents that from happening
by making try_to_suspend() check system_state.
- The ACPI memory hotplug driver doesn't clear its driver_data on
errors which may cause a NULL poiter dereference to happen later.
Fix from Toshi Kani.
- The ACPI namespace scanning code should not try to attach scan
handlers to device objects that have them already, which may
confuse things quite a bit, and it should rescan the whole
namespace branch starting at the given node after receiving a bus
check notify event even if the device at that particular node has
been discovered already. Fixes from Rafael J Wysocki.
- New ACPI video blacklist entry for a system whose initial backlight
setting from the BIOS doesn't make sense. From Lan Tianyu.
- Garbage string output avoindance for ACPI PNP from Liu Shuo.
- Two Kconfig fixes for issues introduced recently in the s3c24xx
cpufreq driver (when moving the driver to drivers/cpufreq) from
Paul Bolle.
- Trivial comment fix in pm_wakeup.h from Chanwoo Choi"
* tag 'pm+acpi-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / video: ignore BIOS initial backlight value for Fujitsu E753
PNP / ACPI: avoid garbage in resource name
cpufreq: Revert commit 2f7021a8 to fix CPU hotplug regression
cpufreq: s3c24xx: fix "depends on ARM_S3C24XX" in Kconfig
cpufreq: s3c24xx: rename CONFIG_CPU_FREQ_S3C24XX_DEBUGFS
PM / Sleep: Fix comment typo in pm_wakeup.h
PM / Sleep: avoid 'autosleep' in shutdown progress
cpufreq: Revert commit a66b2e to fix suspend/resume regression
ACPI / memhotplug: Fix a stale pointer in error path
ACPI / scan: Always call acpi_bus_scan() for bus check notifications
ACPI / scan: Do not try to attach scan handlers to devices having them
Make the uevent strings part of the user API for people who wish to
write their own listeners.
v2: Make a space in the string concatenation. (Chad)
Use the "UEVENT" suffix intead of "EVENT" (Chad)
Make kernel-doc parseable Docbook comments (Daniel)
v3: Undid reset change introduced in last submission (Daniel)
Fixed up comments to address removal changes.
Thanks to Daniel Vetter for a majority of the parity error comments.
CC: Chad Versace <chad.versace@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It was very similar to ironlake_irq_postinstall, so IMHO merging both
functions results in a code that is easier to maintain.
With this change, all the irq handler vfuncs between ironlake and
ivybridge are now unified.
v2: Add "(" and ")" to make at least one vim user much happier (Chris)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The IVB funtions are exactly the same as the ILK ones, with the
exception of the bit register. So add IVB/HSW support to
ironlake_enable_vblank and ironlake_disable_vblank, then kill the
ivybridge functions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And then rename it to ironlake_irq_handler. Also move
ilk_gt_irq_handler up to avoid forward declarations.
In the previous patches I did small modifications to both
ironlake_irq_handler an ivybridge_irq_handler so they became very
similar functions. Now it should be very easy to verify that all we
need to add ILK/SNB support is to call ilk_gt_irq_handler, call
ilk_display_irq_handler and avoid reading pm_iir on gen 5.
v2: - Rebase due to changes on the previous patches
- Move pm_iir to a tighter scope (Chris)
- Change some Gen checks for readability
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have this POSTING_READ inside ironlake_irq_handler. I suppose we
also want it on IVB because we want to stop the IRQ handler as soon as
possible at this point.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ironlake_irq_handler and ivybridge_irq_handler functions do
basically the same thing, but they have different implementation
styles. With this patch we reorganize ironlake_irq_handler in a way
that makes it look very similar to ivybridge_irq_handler.
One of the advantages of this new function style is that we don't
write 0 to the IIR registers anymore.
v2: - Rebase due to changes on previous patches
- Move pm_iir to a tighter scope (Chris)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The register doesn't exist on Gen 5.
v2: Simplify checks since pm_iir is always 0 on Gen 5 (Chris)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like we did with ilk_display_irq_handler.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's the code that deals with de_iir.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After Daniel's latest changes it's now equal to
ironlake_irq_preinstall.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
prefault is stll enabled by default which prevent most of pwrite/pread/reloc
from running slow path, in order to verify these slow pathes, prefault need
to be disabled.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
[danvet: Make checkpatch happy and bikeshed the module option help
text a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915_gem_vma_destroy() frees its argument so we have to move the
drm_mm_remove_node() call up a few lines.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915_gem_vma_create() returns and ERR_PTR() or a valid pointer, it never
returns NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The next step is to modify lpt_enable_clkout_dp to enable support for
"Sequence to enable CLKOUT_DP" and "Sequence to enable CLKOUT_DP
without spread".
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because lpt_init_pch_refclk implements the "Sequence to enable
CLKOUT_DP for FDI usage and configure PCH FDI I/O", which is very
similar to "Sequence to enable CLKOUT_DP" and "Sequence to enable
CLKOUT_DP without spread". With the extracted functions we can more
easily implement the two missing sequences.
v2: Rebase (WaMPhyProgramming:hsw comment).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The machines that fall in the "is_sdv" case are some very early
pre-production steppings. This patch may break VGA output after
suspend/resume on these machines.
Even the documentation for the is_sdv cases was removed from BSpec.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The zcrypt device driver has been split into base/bus module, api-module,
card modules and message type modules. The base module has been renamed
from z90crypt to ap.
A module alias (with the well-known z90crypt identifier) will be introduced
that enable users to use their existing way to load the zcrypt device driver.
Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Pull networking fixes from David Miller:
"A couple interesting SKB fragment handling fixes, plus the usual small
bits here and there:
1) Fix 64-bit divide build failure on 32-bit platforms in mlx5, from
Tim Gardner.
2) Get rid of a stupid reimplementation on "%*phC" in our sysfs MAC
address printing helper.
3) Fix NETIF_F_SG capability advertisement in hyperv driver, if the
device can't do checksumming offloads then it shouldn't say it can
do SG either. From Haiyang Zhang.
4) bgmac needs to depend on PHYLIB, from Hauke Mehrtens.
5) Don't leak DMA mappings on mapping failures, from Neil Horman.
6) We need to reset the transport header of SKBs in ipv4 before we
attempt to perform early socket demux, just like ipv6 does. From
Eric Dumazet.
7) Add missing locking on vxlan device removal, from Stephen
Hemminger.
8) xen-netfront has to make two passes over an SKB to prepare it for
transfer. One pass calculates the number of slots needed, the
second massages the SKB and fills the slots. Unfortunately, the
first pass doesn't calculate the number of slots properly so we
can end up trying to build a MAX_SKB_FRAGS + 1 SKB which doesn't
work out so well. Fix from Jan Beulich with help and discussion
with several others.
9) Fix a similar problem in tun and macvtap, which have to split up
scatter-gather elements at PAGE_SIZE boundaries. Don't do
zerocopy if it would result in a > MAX_SKB_FRAGS skb. Fixes from
Jason Wang.
10) On receive, once we've decoded the VLAN state completely, clear
skb->vlan_tci. Otherwise demuxed tunnels underneath can trigger
the VLAN code again, corrupting the packet. Fix from Eric
Dumazet"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
vlan: fix a race in egress prio management
vlan: mask vlan prio bits
macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS
tuntap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS
pkt_sched: sch_qfq: remove a source of high packet delay/jitter
xen-netfront: pull on receive skb may need to happen earlier
vxlan: add necessary locking on device removal
hyperv: Fix the NETIF_F_SG flag setting in netvsc
net: Fix sysfs_format_mac() code duplication.
be2net: Fix to avoid hardware workaround when not needed
macvtap: do not assume 802.1Q when send vlan packets
macvtap: fix the missing ret value of TUNSETQUEUE
ipv4: set transport header earlier
mlx5 core: Fix __udivdi3 when compiling for 32 bit arches
bgmac: add dependency to phylib
net/irda: fixed style issues in irlan_eth
ethtool: fixed trailing statements in ethtool
ndisc: bool initializations should use true and false
atl1e: unmap partially mapped skb on dma error and free skb
Highlights:
- follow-up refactoring after the shared dpll rework that landed in 3.11
- oddball prep cleanups from Ben for ppgtt
- encoder->get_config state tracking infrastructure from Jesse
- used by the experimental fastboot support from Jesse (disabled by
default)
- make the error state file official and add it to our sysfs interface
(Mika)
- drm_mm prep changes from Ben, prepares to embedd the drm_mm_node (which
will be used by the vma rework later on)
- interrupt handling rework, follow up cleanups to the VECS enabling, hpd
storm handling and fifo underrun reporting.
- Big pile of smaller cleanups, code improvements and related stuff.
* tag 'drm-intel-next-2013-07-12' of git://people.freedesktop.org/~danvet/drm-intel: (72 commits)
drm/i915: clear DPLL reg when disabling i9xx dplls
drm/i915: Fix up cpt pixel multiplier enable sequence
drm/i915: clean up vlv ->pre_pll_enable and pll enable sequence
drm/i915: move error state to own compilation unit
drm/i915: Don't attempt to read an unitialized stack value
drm/i915: Use for_each_pipe() when possible
drm/i915: don't enable PM_VEBOX_CS_ERROR_INTERRUPT
drm/i915: unify ring irq refcounts (again)
drm/i915: kill dev_priv->rps.lock
drm/i915: queue work outside spinlock in hsw_pm_irq_handler
drm/i915: streamline hsw_pm_irq_handler
drm/i915: irq handlers don't need interrupt-safe spinlocks
drm/i915: kill lpt pch transcoder->crtc mapping code for fifo underruns
drm/i915: improve GEN7_ERR_INT clearing for fifo underrun reporting
drm/i915: improve SERR_INT clearing for fifo underrun reporting
drm/i915: extract ibx_display_interrupt_update
drm/i915: remove unused members from drm_i915_private
drm/i915: don't frob mm.suspended when not using ums
drm/i915: Fix VLV DP RBR/HDMI/DAC PLL LPF coefficients
drm/i915: WARN if the bios reserved range is bigger than stolen size
...
Conflicts:
drivers/gpu/drm/i915/i915_gem.c
Pull x86 fixes from Peter Anvin:
"Trying again to get the fixes queue, including the fixed IDT alignment
patch.
The UEFI patch is by far the biggest issue at hand: it is currently
causing quite a few machines to boot. Which is sad, because the only
reason they would is because their BIOSes touch memory that has
already been freed. The other major issue is that we finally have
tracked down the root cause of a significant number of machines
failing to suspend/resume"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Make sure IDT is page aligned
x86, suspend: Handle CPUs which fail to #GP on RDMSR
x86/platform/ce4100: Add header file for reboot type
Revert "UEFI: Don't pass boot services regions to SetVirtualAddressMap()"
efivars: check for EFI_RUNTIME_SERVICES
3.10 wasn't a good release for md. The bio changes left a couple of
bugs, and an md "fix" created another one.
These three patches appear to fix the issues and have been tagged for
-stable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIVAwUAUedstTnsnt1WYoG5AQJmlBAAvQq9PryhyhPl1xC7K6ufoFfoRFO9yQPd
lbe1bpAgyDuStF2t0H+pOBJeI45P9p8oGDsGlvzNI0/1YPxJpv20d/EkQI3eJ4vm
B2iLt2NyZLs3zTc1V0oWBCCp2BT5vgdjHfCfyt7H2MQg0Lxtz9DjVnV0uF58EIWe
mEo5fipXtRlgHAsTay4hiDqoUNy1Lc4I9nPRGtxH8/qj4oB5YudMyNvAq9FFGwr0
31L/ok+mjZdsZJZ+T4jS6hcjy0Wv/TU9lO2Ou1Jua2hLwVk6jvJ5DWzwuqakauaP
MJqiiT4Wuv9V5LKvNknhT2fHfevfBJfhA1hTdVNQuVEHFVW5eb3nW8n8bYZUOhxD
arqWHTIPqK6x8VBfocmjgePnc7CqCS4psPN5DAmp+Kiu6aF0e+eNF4SH8PIV+PQB
xFW2CR3I6Y3evnUab7K+t2gw41vB5iJmlejvlCY3wd4OhRSt0rDQJc7b51tu7lbB
FR8yYSoZ2fvjAqcG4ScSGKol5lkWJALgaLBPMSUdc984pNpEORv+Euqgy2nhYtgo
fvF+loq0l9MVs9qxiuGzIMltt50nqdRrJMzWCAVbH3n9eYfzBj10A/eUUYqoH/zL
+A9spAj8Brk9stdaOT/ZXlDSnwT4S3Q5WEuDl/rYM7VjPj6yUrGiXozHGjdxkL/T
Q7+kYSLrXrA=
=mQEH
-----END PGP SIGNATURE-----
Merge tag 'md-3.11-fixes' of git://neil.brown.name/md
Pull md bug fixes from NeilBrown:
"Sorry boss, back at work now boss. Here's them nice shiny patches ya
wanted. All nicely tagged and justified for -stable and everyfing:
Three bug fixes for md in 3.10
3.10 wasn't a good release for md. The bio changes left a couple of
bugs, and an md "fix" created another one.
These three patches appear to fix the issues and have been tagged for
-stable"
* tag 'md-3.11-fixes' of git://neil.brown.name/md:
md/raid1: fix bio handling problems in process_checks()
md: Remove recent change which allows devices to skip recovery.
md/raid10: fix two problems with RAID10 resync.
To avoid stalls we delay tiling changes and especially hold of
committing the new fence state for as long as possible.
Synchronization points are in the execbuf code and in our gtt fault
handler.
Unfortunately we've missed that tricky detail when adding proper fence
restore code in
commit 19b2dbde57
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 12 10:15:12 2013 +0100
drm/i915: Restore fences after resume and GPU resets
The result was that we've restored fences for objects with no tiling,
since the object<->fence link still existed after resume. Now that
wouldn't have been too bad since any subsequent access would have
fixed things up, but if we've changed from tiled to untiled real havoc
happened:
The tiling stride is stored -1 in the fence register, so a stride of 0
resulted in all 1s in the top 32bits, and so a completely bogus fence
spanning everything from the start of the object to the top of the
GTT. The tell-tale in the register dumps looks like:
FENCE START 2: 0x0214d001
FENCE END 2: 0xfffff3ff
Bit 11 isn't set since the hw doesn't store it, even when writing all
1s (at least on my snb here).
To prevent such a gaffle in the future add a sanity check for fences
with an untiled object attached in i915_gem_write_fence.
v2: Fix the WARN, spotted by Chris.
v3: Trying to reuse get_fences looked ugly and obfuscated the code.
Instead reuse update_fence and to make it really dtrt also move the
fence dirty state clearing into update_fence.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530
Cc: stable@vger.kernel.org (for 3.10 only)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Matthew Garrett <matthew.garrett@nebula.com>
Tested-by: Björn Bidar <theodorstormgrade@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull drm fixes from Dave Airlie:
"You'll be terribly disappointed in this, I'm not trying to sneak any
features in or anything, its mostly radeon and intel fixes, a couple
of ARM driver fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (34 commits)
drm/radeon/dpm: add debugfs support for RS780/RS880 (v3)
drm/radeon/dpm/atom: fix broken gcc harder
drm/radeon/dpm/atom: restructure logic to work around a compiler bug
drm/radeon/dpm: fix atom vram table parsing
drm/radeon: fix an endian bug in atom table parsing
drm/radeon: add a module parameter to disable aspm
drm/rcar-du: Use the GEM PRIME helpers
drm/shmobile: Use the GEM PRIME helpers
uvesafb: Really allow mtrr being 0, as documented and warn()ed
radeon kms: do not flush uninitialized hotplug work
drm/radeon/dpm/sumo: handle boost states properly when forcing a perf level
drm/radeon: align VM PTBs (Page Table Blocks) to 32K
drm/radeon: allow selection of alignment in the sub-allocator
drm/radeon: never unpin UVD bo v3
drm/radeon: fix UVD fence emit
drm/radeon: add fault decode function for CIK
drm/radeon: add fault decode function for SI (v2)
drm/radeon: add fault decode function for cayman/TN (v2)
drm/radeon: use radeon device for request firmware
drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate
...
We try to linearize part of the skb when the number of iov is greater than
MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
network.
Solve this problem by calculate the pages needed for iov before trying to do
zerocopy and switch to use copy instead of zerocopy if it needs more than
MAX_SKB_FRAGS.
This is done through introducing a new helper to count the pages for iov, and
call uarg->callback() manually when switching from zerocopy to copy to notify
vhost.
We can do further optimization on top.
This bug were introduced from b92946e291
(macvtap: zerocopy: validate vectors before building skb).
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We try to linearize part of the skb when the number of iov is greater than
MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
network.
Solve this problem by calculate the pages needed for iov before trying to do
zerocopy and switch to use copy instead of zerocopy if it needs more than
MAX_SKB_FRAGS.
This is done through introducing a new helper to count the pages for iov, and
call uarg->callback() manually when switching from zerocopy to copy to notify
vhost.
We can do further optimization on top.
The bug were introduced from commit 0690899b4d
(tun: experimental zero copy tx support)
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here are some driver core patches for 3.11-rc2. They aren't really
bugfixes, but a bunch of new helper macros for drivers to properly
create attribute groups, which drivers and subsystems need to fix up a
ton of race issues with incorrectly creating sysfs files (binary and
normal) after userspace has been told that the device is present.
Also here is the ability to create binary files as attribute groups, to
solve that race condition, which was impossible to do before this, so
that's my fault the drivers were broken.
The majority of the .c changes is indenting and moving code around a
bit. It affects no existing code, but allows the large backlog of 70+
patches that I already have created to start flowing into the different
subtrees, instead of having to live in my driver-core tree, causing
merge nightmares in linux-next for the next few months.
These were finalized too late for the -rc1 merge window, which is why
they were didn't make that pull request, testing and review from others
didn't happen until a few weeks ago, and then there's the whole
distraction of the past few days, which prevented these from getting to
you sooner, sorry about that.
Oh, and there's a bugfix for the documentation build warning in here as
well. All of these have been in linux-next this week, with no reported
problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iEYEABECAAYFAlHoRUUACgkQMUfUDdst+ymkNACdHAjEXZZmXohDuCb2SqyMeQsz
AZcAn3qqJa/NoPEgTCgOkDlAQZM6BnC5
=+Gqk
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core patches from Greg KH:
"Here are some driver core patches for 3.11-rc2. They aren't really
bugfixes, but a bunch of new helper macros for drivers to properly
create attribute groups, which drivers and subsystems need to fix up a
ton of race issues with incorrectly creating sysfs files (binary and
normal) after userspace has been told that the device is present.
Also here is the ability to create binary files as attribute groups,
to solve that race condition, which was impossible to do before this,
so that's my fault the drivers were broken.
The majority of the .c changes is indenting and moving code around a
bit. It affects no existing code, but allows the large backlog of 70+
patches that I already have created to start flowing into the
different subtrees, instead of having to live in my driver-core tree,
causing merge nightmares in linux-next for the next few months.
These were finalized too late for the -rc1 merge window, which is why
they were didn't make that pull request, testing and review from
others didn't happen until a few weeks ago, and then there's the whole
distraction of the past few days, which prevented these from getting
to you sooner, sorry about that.
Oh, and there's a bugfix for the documentation build warning in here
as well. All of these have been in linux-next this week, with no
reported problems"
* tag 'driver-core-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
driver-core: fix new kernel-doc warning in base/platform.c
sysfs: use file mode defines from stat.h
sysfs: add more helper macro's for (bin_)attribute(_groups)
driver core: add default groups to struct class
driver core: Introduce device_create_groups
sysfs: prevent warning when only using binary attributes
sysfs: add support for binary attributes in groups
driver core: device.h: add RW and RO attribute macros
sysfs.h: add BIN_ATTR macro
sysfs.h: add ATTRIBUTE_GROUPS() macro
sysfs.h: add __ATTR_RW() macro
The BIOS of FUjitsu E753 reports an incorrect initial backlight value
for WIN8 compatible OS, causing backlight to be dark during startup.
This change causes the incorrect initial value from BIOS to be ignored.
References: https://bugzilla.kernel.org/show_bug.cgi?id=60161
Reported-and-tested-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 3.7+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull phase two of __cpuinit removal from Paul Gortmaker:
"With the __cpuinit infrastructure removed earlier, this group of
commits only removes the function/data tagging that was done with the
various (now no-op) __cpuinit related prefixes.
Now that the dust has settled with yesterday's v3.11-rc1, there
hopefully shouldn't be any new users leaking back in tree, but I think
we can leave the harmless no-op stubs there for a release as a
courtesy to those who still have out of tree stuff and weren't paying
attention.
Although the commits are against the recent tag to allow for minor
context refreshes for things like yesterday's v3.11-rc1~ slab content,
the patches have been largely unchanged for weeks, aside from such
trivial updates.
For detail junkies, the largely boring and mostly irrelevant history
of the patches can be viewed at:
http://git.kernel.org/cgit/linux/kernel/git/paulg/cpuinit-delete.git
If nothing else, I guess it does at least demonstrate the level of
involvement required to shepherd such a treewide change to completion.
This is the same repository of patches that has been applied to the
end of the daily linux-next branches for the past several weeks"
* 'cpuinit_phase2' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (28 commits)
block: delete __cpuinit usage from all block files
drivers: delete __cpuinit usage from all remaining drivers files
kernel: delete __cpuinit usage from all core kernel files
rcu: delete __cpuinit usage from all rcu files
net: delete __cpuinit usage from all net files
acpi: delete __cpuinit usage from all acpi files
hwmon: delete __cpuinit usage from all hwmon files
cpufreq: delete __cpuinit usage from all cpufreq files
clocksource+irqchip: delete __cpuinit usage from all related files
x86: delete __cpuinit usage from all x86 files
score: delete __cpuinit usage from all score files
xtensa: delete __cpuinit usage from all xtensa files
openrisc: delete __cpuinit usage from all openrisc files
m32r: delete __cpuinit usage from all m32r files
hexagon: delete __cpuinit usage from all hexagon files
frv: delete __cpuinit usage from all frv files
cris: delete __cpuinit usage from all cris files
metag: delete __cpuinit usage from all metag files
tile: delete __cpuinit usage from all tile files
sh: delete __cpuinit usage from all sh files
...
Except for a slightly big OMAP changes, all rest are small, mostly
boring changes; all either 3.11 regression fixes or stable materials.
- ASoC OMAP fixes due to non-DT OMAP4 removals
- Other ASoC driver changes (sglt5000, wm8978, wm8948, samsung)
- Fix missing locking for snd_pcm_stop() calls in many drivers
- Fix the blocking request_module() in OSS sequencer
- Fix old OSS vwsnd driver builds
- Add a new HD-audio HDMI codec ID
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJR5/PFAAoJEGwxgFQ9KSmkqb0QAJ9pio0iRL2T+N8m4deTAn/E
71suhNyMmqEwSt86UtOO6N/QKGCsUhQA1tXCWKgLE9Dqo4f3S7fWD0cGKDdk53QZ
D3qwjTPvFP05gMSmAkKxPr8C48HTrngSUxdrV5BSU0goRXYa/qqP7H1+jRbIhNv+
1WBXQJ8I0ALqLqs2MCw22snCVp6SOnYzvBn543jcJOf+weDqZ/tWlfgzhZAlIvKJ
OSkL8t+hiEyadjW/jSKm8Xe2Onb7tqZFG/x9ZggLq5HWQm7q261f3785X6EBtAKR
nm8yZZW88JGrVvCRwuE1hJNSptnIhFFYTc+DeQiicYMKT5ixgSG3N99sMYQcsi5J
jSUhLHeg3KeT44s//B+Vd/++lrwz5wcvnCLrcl0LqFaVrdIaZo6UUTMUHFPnl74f
mIqpGgQBH7dcbYUWF4X26Y2qpvbZmNaHmd++0ywVNz7ponue1DKtaGfeiYEFyzDw
BTnLI+sqg/1Y85ydE/04izeNtcS3y+iUw6A8slB+eS6MGl3B05oVZSewJOJhMccy
+pn0Y/BvPNf/IxcHgRQ65GZmbGTW3sWv1syPqYvXRHeiYYv9Ekf55Nr+LKPpFJdj
M9G4BBo56Y+xC8UpHYgcGfzmW8P+rzpc+yuGZC/z6kFO0Y9LL9ABUMOHhk4mPD7d
5/GebLUeG8gowWV8zgVP
=xUZh
-----END PGP SIGNATURE-----
Merge tag 'sound-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Except for a slightly big OMAP changes, all rest are small, mostly
boring changes; all either 3.11 regression fixes or stable materials.
- ASoC OMAP fixes due to non-DT OMAP4 removals
- Other ASoC driver changes (sglt5000, wm8978, wm8948, samsung)
- Fix missing locking for snd_pcm_stop() calls in many drivers
- Fix the blocking request_module() in OSS sequencer
- Fix old OSS vwsnd driver builds
- Add a new HD-audio HDMI codec ID"
* tag 'sound-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (23 commits)
ALSA: seq-oss: Initialize MIDI clients asynchronously
ALSA: hda - Add new GPU codec ID to snd-hda
staging: line6: Fix unlocked snd_pcm_stop() call
[media] saa7134: Fix unlocked snd_pcm_stop() call
ASoC: s6000: Fix unlocked snd_pcm_stop() call
ASoC: atmel: Fix unlocked snd_pcm_stop() call
ALSA: pxa2xx: Fix unlocked snd_pcm_stop() call
ALSA: usx2y: Fix unlocked snd_pcm_stop() call
ALSA: ua101: Fix unlocked snd_pcm_stop() call
ALSA: 6fire: Fix unlocked snd_pcm_stop() call
ALSA: atiixp: Fix unlocked snd_pcm_stop() call
ALSA: asihpi: Fix unlocked snd_pcm_stop() call
sound: oss/vwsnd: Always define vwsnd_mutex
sound: oss/vwsnd: Add missing inclusion of linux/delay.h
ASoC: wm8978: enable symmetric rates
ASoC: omap-mcbsp: Use different method for DMA request when booted with DT
ASoC: omap-dmic: Do not use platform_get_resource_byname() for DMA
ASoC: omap-mcpdm: Do not use platform_get_resource_byname() for DMA
ASoC: omap-pcm: Request the DMA channel differently when DT is involved
ASoC: Samsung: Set RFS and BFS in slave mode
...
Restore debug message lost in merge commit e1b73cba13. Also clarify it
that we are only clamping bpp not overwriting it.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
clk_prepare/unprepare (and indirectly clk_prepare_enable/disable_unprepare)
may sleep and thus cannot be called in critical section.
This patch fix a bug introduced by commit
6f0d94790e where clk_disable_unprepare was
called with user_lock hold.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJR0K2gAAoJEHm+PkMAQRiGWsEH+gMZSN1qRm34hZ82q1Tx7HvL
Eb/Gsl3Qw/7G2TlTqgjBUs36IdqV9O2cui/aa3/TfXvdvrx+0GlhRkEwQPc+ygcO
Mvoyoke4tT4+4jVFdCg1J8avREsa28/6oaHs0ZZxuVmJBBLTJH7aXaNsGn6eU1q9
9+p798MQis6naIiPC63somlZcCIiBhsuWCPWpEfLMn8G1HWAFTM3xXIbNBqe/brS
bmIOfhomlIZ5dcdaXGvjtP3+KJhkNDwhkPC4tVYu8JqqgSlrE+a+EGyEuuGqKk10
U+swiqyuD31uBI9ga54u/2FzSqDiAu6YOcMXevjo/m3g9XLdYbYLvN+nvN8alCQ=
=Ob6Z
-----END PGP SIGNATURE-----
Merge tag 'v3.10' into drm-intel-fixes
Backmerge Linux 3.10 to get at
commit 19b2dbde57
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 12 10:15:12 2013 +0100
drm/i915: Restore fences after resume and GPU resets
That commit is not in my current -fixes pile since that's based on my
-next queue for 3.11. And the above mentioned fix was merged really
late into 3.10 (and blew up, bad me) so was on a diverging branch.
Option B would have been to rebase my current pile of fixes onto
Dave's drm-fixes branch. But since some of the patches here are a bit
tricky I've decided not to void all the testing by moving over the
entire merge window.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PSR must be enabled after transcoder and port are running.
And it is only available for HSW.
v2: move enable/disable to intel_ddi
v3: The spec suggests PSR should be disabled even before backlight (by pzanoni)
v4: also disabling and enabling whenever panel is disabled/enabled.
v5: make it last patch to avoid breaking whenever bisecting. So calling for
update and force exit came to this patch along with enable/disable calls.
v6: Remove unused and unecessary psr_enable/disable calls, as notice by Paulo.
CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Drop the psr exit code in the busy ioctl since I didn't merge
that part of the infrastructure yet - it needs more thought.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Required function to disable PSR when going to console mode.
But also can be used whenever PSR mode entry conditions changed.
v2: Add it before PSR Hook. Update function not really been called yet.
v3: Fix coding style detected by checkpatch by Paulo Zanoni.
v4: do_enable must be static as Paulo noticed.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: prefer seq_puts to seq_printf detected by Paulo Zanoni.
v3: PSR is disabled by default. Without userspace ready it
will cause regression for kde and xdm users
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Prefer seq_puts to seq_printf by Paulo Zanoni.
v3: small changes like avoiding calling dp_to_dig_port twice as noticed by
Paulo Zanoni.
v4: Avoiding reading non-existent registers - noticed by Paulo
on first psr debugfs patch.
v5: Accepting more suggestions from Paulo:
* check sw interlace flag instead of i915_read
* introduce PSR_S3D_ENABLED to avoid forgeting it whenever added.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
[danvet: Fix up debugfs output (spotted by Paulo) and rip out the
power well check since we really can't do that in a race-free manner,
so it's bogus.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adding support for PSR Status, PSR entry counter and performance counters.
Heavily based on initial work from Shobhit.
v2: Fix PSR Status Link bits by Paulo Zanoni.
v3: Prefer seq_puts to seq_printf by Paulo Zanoni.
v4: Fix identation by Paulo Zanoni.
v5: Return earlier if it isn't Haswell in order to avoid reading non-existing
registers - by Paulo Zanoni.
CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Credits-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adding Enable and Disable PSR functionalities. This includes setting the
PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
enabling PSR in the sink via DPCD register and finally enabling PSR on
the host.
This patch is based on initial PSR code by Sateesh Kavuri and Kumar Shobhit
but in a different implementation.
v2: * moved functions around and changed its names.
* removed VSC DIP unset from disable.
* remove FBC wa.
* don't mask LSPS anymore.
* incorporate new crtc usage after a rebase.
v3: Make a clear separation between Sink (Panel) and Source (HW) enabling.
v4: Fix identation and other style issues raised by checkpatch (by Paulo).
v5: Changes according to Paulo's review:
static on write_vsc;
avoid using dp_to_dev when already calling dp_to_dig_port;
remove unecessary TP default time setting;
remove unecessary interrupts disabling;
remove unecessary wait_for_vblank when disabling psr;
v6: remove unecessary wait_for_vblank when writing vsc;
v7: adding setup once function to avoid unnecessarily write to vsc
and set debug_ctl every time we enable or disable psr.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Credits-by: Sateesh Kavuri <sateesh.kavuri@intel.com>
Credits-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
[danvet: Apply Paulo's suggestion for unconditionally clearing the
control register when writing the DIP.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: reuse of just created is_edp_psr and put it at right place.
v3: move is_edp_psr above intel_edp_disable
v4: remove parentheses. Noticed by Paulo.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Formerly: "drm/i915: Create VMAs (part 1)"
In a previous patch, the notion of a VM was introduced. A VMA describes
an area of part of the VM address space. A VMA is similar to the concept
in the linux mm. However, instead of representing regular memory, a VMA
is backed by a GEM BO. There may be many VMAs for a given object, one
for each VM the object is to be used in. This may occur through flink,
dma-buf, or a number of other transient states.
Currently the code depends on only 1 VMA per object, for the global GTT
(and aliasing PPGTT). The following patches will address this and make
the rest of the infrastructure more suited
v2: s/i915_obj/i915_gem_obj (Chris)
v3: Only move an object to the now global unbound list if there are no
more VMAs for the object which are bound into a VM (ie. the list is
empty).
v4: killed obj->gtt_space
some reworks due to rebase
v5: Free vma on error path (Imre)
v6: Another missed vma free in i915_gem_object_bind_to_gtt error path
(Imre)
Fixed vma freeing in stolen preallocation (Imre)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Squash in fixup from Ben to not deref a non-existing vma in
set_cache_level, reported by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Recent change to use bio_copy_data() in raid1 when repairing
an array is faulty.
The underlying may have changed the bio in various ways using
bio_advance and these need to be undone not just for the 'sbio' which
is being copied to, but also the 'pbio' (primary) which is being
copied from.
So perform the reset on all bios that were read from and do it early.
This also ensure that the sbio->bi_io_vec[j].bv_len passed to
memcmp is correct.
This fixes a crash during a 'check' of a RAID1 array. The crash was
introduced in 3.10 so this is suitable for 3.10-stable.
Cc: stable@vger.kernel.org (3.10)
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
commit 7ceb17e87b
md: Allow devices to be re-added to a read-only array.
allowed a bit more than just that. It also allows devices to be added
to a read-write array and to end up skipping recovery.
This patch removes the offending piece of code pending a rewrite for a
subsequent release.
More specifically:
If the array has a bitmap, then the device will still need a bitmap
based resync ('saved_raid_disk' is set under different conditions
is a bitmap is present).
If the array doesn't have a bitmap, then this is correct as long as
nothing has been written to the array since the metadata was checked
by ->validate_super. However there is no locking to ensure that there
was no write.
Bug was introduced in 3.10 and causes data corruption so
patch is suitable for 3.10-stable.
Cc: stable@vger.kernel.org (3.10)
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
1/ When an different between blocks is found, data is copied from
one bio to the other. However bv_len is used as the length to
copy and this could be zero. So use r10_bio->sectors to calculate
length instead.
Using bv_len was probably always a bit dubious, but the introduction
of bio_advance made it much more likely to be a problem.
2/ When preparing some blocks for sync, we don't set BIO_UPTODATE
except on bios that we schedule for a read. This ensures that
missing/failed devices don't confuse the loop at the top of
sync_request write.
Commit 8be185f2c9 "raid10: Use bio_reset()"
removed a loop which set BIO_UPTDATE on all appropriate bios.
So we need to re-add that flag.
These bugs were introduced in 3.10, so this patch is suitable for
3.10-stable, and can remove a potential for data corruption.
Cc: stable@vger.kernel.org (3.10)
Reported-by: Brassow Jonathan <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
more DPM fixes for radeon.
* 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/dpm: add debugfs support for RS780/RS880 (v3)
drm/radeon/dpm/atom: fix broken gcc harder
drm/radeon/dpm/atom: restructure logic to work around a compiler bug
drm/radeon/dpm: fix atom vram table parsing
drm/radeon: fix an endian bug in atom table parsing
drm/radeon: add a module parameter to disable aspm
Starting from win8, MS backlight control driver will set bit 2 of the
parameter of control method _DOS, to inform firmware it should not
perform any automatic brightness changes. This mostly affects hotkey
notification deliver - if we do not set this bit, on hotkey press,
firmware may choose to adjust brightness level instead of sending out
notification and doing nothing.
So this patch sets bit 2 when calling _DOS so that GUIs can show the
notification window on hotkey press. This behavior change is only
necessary for win8 systems.
The MS document on win8 backlight control is here:
http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305
References: https://bugzilla.kernel.org/show_bug.cgi?id=52951
References: https://bugzilla.kernel.org/show_bug.cgi?id=56711
Reported-by: Micael Dias <kam1kaz3@gmail.com>
Reported-by: Dan Garton <dan.garton@gmail.com>
Reported-by: Bob Ziuchkovski <bob.ziuchkovski@gmail.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8. The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems".
There's a problem with that approach, however, because simply
avoiding to register the ACPI backlight interface if the firmware
calls _OSI for Windows 8 may not work in the following situations:
(1) The ACPI backlight interface actually works on the given system
and the i915 driver is not loaded (e.g. another graphics driver
is used).
(2) The ACPI backlight interface doesn't work on the given system,
but there is a vendor platform driver that will register its
own, equally broken, backlight interface if not prevented from
doing so by the ACPI subsystem.
Therefore we need to allow the ACPI backlight interface to be
registered until the i915 driver is loaded which then will unregister
it if the firmware has called _OSI for Windows 8 (or will register
the ACPI video driver without backlight support if not already
present).
For this reason, introduce an alternative function for registering
ACPI video, acpi_video_register_with_quirks(), that will check
whether or not the ACPI video driver has already been registered
and whether or not the backlight Windows 8 quirk has to be applied.
If the quirk has to be applied, it will block the ACPI backlight
support and either unregister the backlight interface if the ACPI
video driver has already been registered, or register the ACPI
video driver without the backlight interface otherwise. Make
the i915 driver use acpi_video_register_with_quirks() instead of
acpi_video_register() in i915_driver_load().
This change is based on earlier patches from Matthew Garrett,
Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's.
References: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Tested-by: Aaron Lu <aaron.lu@intel.com>
Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Tested-by: Yves-Alexis Perez <corsac@debian.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
Set temporary variable as 0 to avoid garbage string output from
/proc/iomem after register resources and reset to PNP dev name
later.
Signed-off-by: Liu ShuoX <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We have to call acpi_video_init_brightness() even if we're not going
to initialise the backlight - Thinkpads seem to use this as the
trigger for enabling ACPI notifications rather than handling it in
firmware.
[rjw: Drop the brightness object created by
acpi_video_init_brightness() if we are not going to use it.]
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Expose acpi_gbl_osi_data so that code outside of ACPICA can check
the value of the last successfull _OSI call. The definitions for
OSI versions are moved to actypes.h so that other components can
access them too.
Based on a patch from Matthew Garrett which in turn was based on
an earlier patch from Seth Forshee.
[rjw: Changelog]
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This allows you to look at the current DPM state via
debugfs.
Due to the way the hardware works on these asics, there's
no way to look up exactly what power state we are in, so
we make the best guess we can based on the current sclk.
v2: Anthoine's version
v3: fix ref div
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The odds of this happening are *extremely* unlikely.
Reported-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Shamelessly manipulated out of Daniel :-)
"When moving the lists around explain that the active/inactive stuff is
used by eviction when we run out of address space, so needs to be
per-vma and per-address space. Bound/unbound otoh is used by the
shrinker which only cares about the amount of memory used and not one
bit about in which address space this memory is all used in. Of course
to actual kick out an object we need to unbind it from every address
space, but for that we have the per-object list of vmas."
v2: Leave the bound list as a global one. (Chris, indirectly)
v3: Rebased with no i915_gtt_vm. In most places I added a new *vm local,
since it will eventually be replaces by a vm argument.
Put comment back inline, since it no longer makes sense to do otherwise.
v4: Rebased on hangcheck/error state movement
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After we plumb our code to support multiple address spaces (VMs), there
are a few situations where we want to be able to traverse the list of
all address spaces in the system. Cases like eviction, or error state
collection are obvious example.
v2: Delete the global link instead of the list head. While this in and
of itself shouldn't be really be a problem, doing this allows us to WARN
on an non-empty list, which is a problem. (Daniel)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Every address space should support object allocation. It therefore makes
sense to have the allocator be part of the "superclass" which GGTT and
PPGTT will derive.
Since our maximum address space size is only 2GB we're not yet able to
avoid doing allocation/eviction; but we'd hope one day this becomes
almost irrelvant.
v2: Rebased
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The GTT and PPGTT can be thought of more generally as GPU address
spaces. Many of their actions (insert entries), state (LRU lists), and
many of their characteristics (size) can be shared. Do that.
The change itself doesn't actually impact most of the VMA/VM rework
coming up, it just fits in with the grand scheme of abstracting the GPU
VM operations. GGTT will usually be a special case where we either know
an object must be in the GGTT (dislay engine, workarounds, etc.).
The scratch page is left as part of the VM (even though it's currently
shared with the ppgtt code) because in the future when we have Full
PPGTT, I intend to create a separate scratch page for each.
v2: Drop usage of i915_gtt_vm (Daniel)
Make cleanup also part of the parent class (Ben)
Modified commit msg
Rebased
v3: Properly share scratch page (Imre)
Finish commit message (Daniel, Imre)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure
linear area is big enough on RX") xennet_fill_frags() may end up
filling MAX_SKB_FRAGS + 1 fragments in a receive skb, and only reduce
the fragment count subsequently via __pskb_pull_tail(). That's a
result of xennet_get_responses() allowing a maximum of one more slot to
be consumed (and intermediately transformed into a fragment) if the
head slot has a size less than or equal to RX_COPY_THRESHOLD.
Hence we need to adjust xennet_fill_frags() to pull earlier if we
reached the maximum fragment count - due to the described behavior of
xennet_get_responses() this guarantees that at least the first fragment
will get completely consumed, and hence the fragment count reduced.
In order to not needlessly call __pskb_pull_tail() twice, make the
original call conditional upon the pull target not having been reached
yet, and defer the newly added one as much as possible (an alternative
would have been to always call the function right before the call to
xennet_fill_frags(), but that would imply more frequent cases of
needing to call it twice).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: stable@vger.kernel.org (3.6 onwards)
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The socket management is now done in workqueue (outside of RTNL)
and protected by vn->sock_lock. There were two possible bugs, first
the vxlan device was removed from the VNI hash table per socket without
holding lock. And there was a race when device is created and the workqueue
could run after deletion.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The GEM CMA PRIME import/export helpers have been removed in favor of
generic GEM PRIME helpers with GEM CMA low-level operations. Fix the
driver accordingly.
Reported-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Mark Brown <broonie@linaro.org>
The GEM CMA PRIME import/export helpers have been removed in favor of
generic GEM PRIME helpers with GEM CMA low-level operations. Fix the
driver accordingly.
Reported-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Mark Brown <broonie@linaro.org>
In commit e3de42b684
Author: Imre Deak <imre.deak@intel.com>
Date: Fri May 3 19:44:07 2013 +0200
drm/i915: force full modeset if the connector is in DPMS OFF mode
a new function was added that walked over the set of connectors to see
if any of the currently associated CRTC was switched off. This function
walked an array of connectors, rather than the array of pointers to
connectors contained in the drm_mode_set - i.e. it was dereferencing far
past the end of the first connector. This only becomes an issue if we
attempt to use a clone mode (i.e. more than one connector per CRTC) such
that set->num_connectors > 1.
Reported-by: Timo Aaltonen <tjaalton@ubuntu.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There seems to be no limit to the amount of gunk the firmware can
leave behind. Some platforms leave pch dplls on which are not in
active use at all. The example in the bug report is a Apple Macbook
Pro.
Note that this escape scrunity of the hw state checker until we've
tried to use this enabled, but unused pll since we did only check for
the inverse case of a in-used, but disabled pll.
v2: Add a WARN in the pll state checker which would have caught this
case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66952
Reported-and-tested-by: shui yangwei <yangweix.shui@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fixes regression in power consumtion of sandy bridge gpu, which
exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
it's extremely busy. After that it never reaches rc6 state.
Bug exists since kernel v3.6:
commit b4ae3f22d2
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Jun 14 11:04:48 2012 -0700
drm/i915: load boot context at driver init time
For some reason RC6 is already enabled at the beginning of resuming process.
Following initliaztion breaks some internal state and confuses RPS engine.
This patch disables RC6 at the beginnig of resume and initialization.
I've rearranged initialization sequence, because intel_disable_gt_powersave()
needs initialized force_wake_get/put and some locks from the dev_priv.
Note: The culprit in the initialization sequence seems to be the write
to MBCTL added in the above mentioned commit. The first version of
this patch just held a forcewake reference across the clock gating
init functions, which seems to have been enought to gather quite a few
positive test reports. But since that smelled a bit like ad-hoc
duct-tape v2 now just disables rps/rc6 across the entire hw setup.
References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
References: https://patchwork.kernel.org/patch/2827634/ (patch v1)
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add note about v1 vs. v2 of this patch and use standard
layout for the commit citation. Also add the tested-bys from v1 and a
cc: stable.]
Cc: stable@vger.kernel.org (Note: tiny conflict due to the addition of
the backlight lock in 3.11)
Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1)
Tested-by: rocko <rockorequin@hotmail.com> (v1)
Tested-by: JohnMB <johnmbryant@sky.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we are posting pressure status, we may get interrupted and handle
the un-balloon operation. In this case just don't post the status as we
know the pressure status is stale.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As we hot-add 128 MB chunks of memory, we wait to ensure that the memory
is onlined before attempting to hot-add the next chunk. If the udev rule for
memory hot-add is not executed within the allowed time, we would rollback the
state and abort further hot-add. Since the hot-add has succeeded and the only
failure is that the memory is not onlined within the allowed time, we should not
be rolling back the state. Fix this bug.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: Stable <stable@vger.kernel.org>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Whenever a device is unregistered in vmbus_device_unregister (drivers/hv/vmbus_drv.c), the device name in the log message may contain garbage as the memory has already been freed by the time pr_info is called. Log example:
[ 3149.170475] hv_vmbus: child device àõsèè0_5 unregistered
By logging the message just before calling device_unregister, the correct device name is printed:
[ 3145.034652] hv_vmbus: child device vmbus_0_5 unregistered
Also changing register & unregister messages to debug to avoid unnecessarily cluttering the kernel log.
Signed-off-by: Fernando M Soto <fsoto@bluecatnetworks.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SG mode is not currently supported by netvsc, so remove this flag for now.
Otherwise, it will be unconditionally enabled by commit ec5f061564
"Kill link between CSUM and SG features"
Previously, the SG feature is disabled because CSUM is not set here.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix new kernel-doc warning in drivers/base/platform.c:
Warning(drivers/base/platform.c:528): No description found for parameter 'owner'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This set is larger than I would like, partly due to my lack of review
time in the weeks before the merge window and partly because a
couple of large drivers and the subsystem as a whole seem to be
getting a lot more exposure and testing recently.
1) A long term bug in trigger handling gave a double free of the device.
2) Wrong return value handling means offsets are ignored in
iio_convert_raw_to_processed_unlocked.
3) The iio_channel_has_info utility function was incorrectly updated
during the recent info_mask split, this is now fixed.
4) mxs-lradc has a couple of little fixes.
5) A couple of missing .driver_module entries meant that drivers
could be removed from underneath their users.
6) Error path fixes for ad7303 and lis3l02dq.
7) The scale value for presure in the lps331ap driver was out by
a factor of 100.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQIcBAABAgAGBQJR5QAJAAoJEFSFNJnE9BaIG2oP/1kV33gxoFwoKMblG7J1paHU
h8XdffT93XJTHnCMykCgI9KjohKtr0UmtDLXLXuZD9mkq6T9e6qh6xwpap68Nmwn
bCPdaYfqU8cmJ794JV3uK2MUqQphTvV5WhjH4U7qJU8jDesSinPYxEH04DXVnCLC
600PHw8bbl4DGCYLgpDKeq0zZ/4joKFhItVNaRPCpJJB/MYbLkOXE8CLhSoGslKo
IfpcBvuN7oYS4CbLqvnkMOmrSaI4a4eI3L6vG42zNuOQLPyL2dNZK3/ViJCJFbqX
FbYbYvgApn04liyVkSDQAgW3fkQivF0Lh9R2kkHQ/meTqDMr+r6uvyQ6KDYgw6Px
Xh79hwHn/mjT3xRWqtMeMJ85v/9I2dGpKeX2EUm4a8o3+5/gq/oyHR2eF2OZfvBn
b3X1PYk29TkGN2K42JKwMJUqHFnVc4w91A9/TWTqz/cqFvBWvdJb8IJmijSug4NG
/MN9U07QJgsH5sgRjhkorRe68dXvvBNAhka5ZX3TzrxUO74AdmJ/FscoFulevPgs
MTpP8/OxRs4ez94SMNiudK6o6ycNCJYsyKEaF9utDhsJf3W04bXMIP2HvEmZRz14
DCh6v33/vqVjSnrHt95XVa37ahoGUClzAyqvJ+AbnlCXH9yvLjtvP6zLL2p014Zu
UcK4x2wZrEhCH6RHPK1y
=ratf
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.11a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
The first round of IIO fixes for the 3.11 cycle.
This set is larger than I would like, partly due to my lack of review
time in the weeks before the merge window and partly because a
couple of large drivers and the subsystem as a whole seem to be
getting a lot more exposure and testing recently.
1) A long term bug in trigger handling gave a double free of the device.
2) Wrong return value handling means offsets are ignored in
iio_convert_raw_to_processed_unlocked.
3) The iio_channel_has_info utility function was incorrectly updated
during the recent info_mask split, this is now fixed.
4) mxs-lradc has a couple of little fixes.
5) A couple of missing .driver_module entries meant that drivers
could be removed from underneath their users.
6) Error path fixes for ad7303 and lis3l02dq.
7) The scale value for presure in the lps331ap driver was out by
a factor of 100.
This driver is not being updated as the specifications are not able to
be gotten from CSR or anyone else. Without those, getting this driver
into proper mergable shape is going to be impossible. So remove the
driver from the tree.
If the specifications ever become available, this patch can be reverted
and the driver fixed up properly.
Reported-by: Lidza Louina <lidza.louina@gmail.com>
Cc: Veli-Pekka Peltola <veli-pekka.peltola@bluegiga.com>
Cc: Mikko Virkkilä <mikko.virkkila@bluegiga.com>
Cc: Lauri Hintsala <Lauri.Hintsala@bluegiga.com>
Cc: Riku Mettälä <riku.mettala@bluegiga.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kent writes:
Hey Jens - I've been busy torture testing and chasing bugs, here's the
fruits of my labors. These are all fairly small fixes, some of them
quite important.
One feature latecomer, I've forgotten to merge the patch to reeanble the
Haswell power well feature now that the audio interaction is fixed up.
Since that was the only unfixed issue with it I've figured I could throw
it in a bit late, and it's trivial to revert in case I'm wrong.
Otherwise all bug/regression fixes:
- Fix status page reinit after gpu hangs, spotted by more paranoid igt
checks.
- Fix object list walking fumble regression in the shrinker (only the
counting part, the actual shrinking code was correct so no Oops
potential), from Xiong Zhang.
- Fix DP 1.2 bw limits (Imre).
- Restore legacy forcewake on ivb, too many broken biosen out there. We
dump a warn though that recent userspace might fall over with that
config (Guenter Roeck).
- Patch up the gen2 cs tlb w/a.
- Improve the fence coherency w/a now that we have a better understanding
what's going on. The removed wbinvd+ipi should make -rt folks happy. Big
thanks to Jon Bloomfield for figuring this out, patches from Chris.
- Fix write-read race when switching ring (Chris). Spotted with code
inspection, but now we also have an igt for it.
There's an ugly regression we're still working on introduced between
3.10-rc7 and 3.10.0. Unfortunately we can't just revert the offender since
that one fixes another regression :( I've asked Steven to include my
-fixes branch into linux-next to prevent such fallout in the future,
hopefully.
* tag 'drm-intel-fixes-2013-07-11' of git://people.freedesktop.org/~danvet/drm-intel:
Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs"
drm/i915: Fix incoherence with fence updates on Sandybridge+
drm/i915: Fix write-read race with multiple rings
Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"
drm/i915: fix lane bandwidth capping for DP 1.2 sinks
drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a
drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list
drm/i915: switch disable_power_well default value to 1
drm/i915: reinit status page registers after gpu reset
The hub driver was recently changed to use "global" suspend for system
suspend transitions on non-SuperSpeed buses. This means that we don't
suspend devices individually by setting the suspend feature on the
upstream hub port; instead devices all go into suspend automatically
when the root hub stops transmitting packets. The idea was to save
time and to avoid certain kinds of wakeup races.
Now it turns out that many hubs are buggy; they don't relay wakeup
requests from a downstream port to their upstream port if the
downstream port's suspend feature is not set (depending on the speed
of the downstream port, whether or not the hub is enabled for remote
wakeup, and possibly other factors).
We can't have hubs dropping wakeup requests. Therefore this patch
goes partway back to the old policy: It sets the suspend feature for a
port if the device attached to that port or any of its descendants is
enabled for wakeup. People will still be able to benefit from the
time savings if they don't care about wakeup and leave it disabled on
all their devices.
In order to accomplish this, the patch adds a new field to the usb_hub
structure: wakeup_enabled_descendants is a count of how many devices
below a suspended hub are enabled for remote wakeup. A corresponding
new subroutine determines the number of wakeup-enabled devices at or
below an arbitrary suspended USB device.
This should be applied to the 3.10 stable kernel.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2f7021a8 "cpufreq: protect 'policy->cpus' from offlining
during __gov_queue_work()" caused a regression in CPU hotplug,
because it lead to a deadlock between cpufreq governor worker thread
and the CPU hotplug writer task.
Lockdep splat corresponding to this deadlock is shown below:
[ 60.277396] ======================================================
[ 60.277400] [ INFO: possible circular locking dependency detected ]
[ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted
[ 60.277411] -------------------------------------------------------
[ 60.277417] bash/2225 is trying to acquire lock:
[ 60.277422] ((&(&j_cdbs->work)->work)){+.+...}, at: [<ffffffff810621b5>] flush_work+0x5/0x280
[ 60.277444] but task is already holding lock:
[ 60.277449] (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81042d8b>] cpu_hotplug_begin+0x2b/0x60
[ 60.277465] which lock already depends on the new lock.
[ 60.277472] the existing dependency chain (in reverse order) is:
[ 60.277477] -> #2 (cpu_hotplug.lock){+.+.+.}:
[ 60.277490] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200
[ 60.277503] [<ffffffff815b6157>] mutex_lock_nested+0x67/0x410
[ 60.277514] [<ffffffff81042cbc>] get_online_cpus+0x3c/0x60
[ 60.277522] [<ffffffff814b842a>] gov_queue_work+0x2a/0xb0
[ 60.277532] [<ffffffff814b7891>] cs_dbs_timer+0xc1/0xe0
[ 60.277543] [<ffffffff8106302d>] process_one_work+0x1cd/0x6a0
[ 60.277552] [<ffffffff81063d31>] worker_thread+0x121/0x3a0
[ 60.277560] [<ffffffff8106ae2b>] kthread+0xdb/0xe0
[ 60.277569] [<ffffffff815bb96c>] ret_from_fork+0x7c/0xb0
[ 60.277580] -> #1 (&j_cdbs->timer_mutex){+.+...}:
[ 60.277592] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200
[ 60.277600] [<ffffffff815b6157>] mutex_lock_nested+0x67/0x410
[ 60.277608] [<ffffffff814b785d>] cs_dbs_timer+0x8d/0xe0
[ 60.277616] [<ffffffff8106302d>] process_one_work+0x1cd/0x6a0
[ 60.277624] [<ffffffff81063d31>] worker_thread+0x121/0x3a0
[ 60.277633] [<ffffffff8106ae2b>] kthread+0xdb/0xe0
[ 60.277640] [<ffffffff815bb96c>] ret_from_fork+0x7c/0xb0
[ 60.277649] -> #0 ((&(&j_cdbs->work)->work)){+.+...}:
[ 60.277661] [<ffffffff810ab826>] __lock_acquire+0x1766/0x1d30
[ 60.277669] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200
[ 60.277677] [<ffffffff810621ed>] flush_work+0x3d/0x280
[ 60.277685] [<ffffffff81062d8a>] __cancel_work_timer+0x8a/0x120
[ 60.277693] [<ffffffff81062e53>] cancel_delayed_work_sync+0x13/0x20
[ 60.277701] [<ffffffff814b89d9>] cpufreq_governor_dbs+0x529/0x6f0
[ 60.277709] [<ffffffff814b76a7>] cs_cpufreq_governor_dbs+0x17/0x20
[ 60.277719] [<ffffffff814b5df8>] __cpufreq_governor+0x48/0x100
[ 60.277728] [<ffffffff814b6b80>] __cpufreq_remove_dev.isra.14+0x80/0x3c0
[ 60.277737] [<ffffffff815adc0d>] cpufreq_cpu_callback+0x38/0x4c
[ 60.277747] [<ffffffff81071a4d>] notifier_call_chain+0x5d/0x110
[ 60.277759] [<ffffffff81071b0e>] __raw_notifier_call_chain+0xe/0x10
[ 60.277768] [<ffffffff815a0a68>] _cpu_down+0x88/0x330
[ 60.277779] [<ffffffff815a0d46>] cpu_down+0x36/0x50
[ 60.277788] [<ffffffff815a2748>] store_online+0x98/0xd0
[ 60.277796] [<ffffffff81452a28>] dev_attr_store+0x18/0x30
[ 60.277806] [<ffffffff811d9edb>] sysfs_write_file+0xdb/0x150
[ 60.277818] [<ffffffff8116806d>] vfs_write+0xbd/0x1f0
[ 60.277826] [<ffffffff811686fc>] SyS_write+0x4c/0xa0
[ 60.277834] [<ffffffff815bbbbe>] tracesys+0xd0/0xd5
[ 60.277842] other info that might help us debug this:
[ 60.277848] Chain exists of:
(&(&j_cdbs->work)->work) --> &j_cdbs->timer_mutex --> cpu_hotplug.lock
[ 60.277864] Possible unsafe locking scenario:
[ 60.277869] CPU0 CPU1
[ 60.277873] ---- ----
[ 60.277877] lock(cpu_hotplug.lock);
[ 60.277885] lock(&j_cdbs->timer_mutex);
[ 60.277892] lock(cpu_hotplug.lock);
[ 60.277900] lock((&(&j_cdbs->work)->work));
[ 60.277907] *** DEADLOCK ***
[ 60.277915] 6 locks held by bash/2225:
[ 60.277919] #0: (sb_writers#6){.+.+.+}, at: [<ffffffff81168173>] vfs_write+0x1c3/0x1f0
[ 60.277937] #1: (&buffer->mutex){+.+.+.}, at: [<ffffffff811d9e3c>] sysfs_write_file+0x3c/0x150
[ 60.277954] #2: (s_active#61){.+.+.+}, at: [<ffffffff811d9ec3>] sysfs_write_file+0xc3/0x150
[ 60.277972] #3: (x86_cpu_hotplug_driver_mutex){+.+...}, at: [<ffffffff81024cf7>] cpu_hotplug_driver_lock+0x17/0x20
[ 60.277990] #4: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff815a0d32>] cpu_down+0x22/0x50
[ 60.278007] #5: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81042d8b>] cpu_hotplug_begin+0x2b/0x60
[ 60.278023] stack backtrace:
[ 60.278031] CPU: 3 PID: 2225 Comm: bash Not tainted 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744
[ 60.278037] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011
[ 60.278042] ffffffff8204e110 ffff88014df6b9f8 ffffffff815b3d90 ffff88014df6ba38
[ 60.278055] ffffffff815b0a8d ffff880150ed3f60 ffff880150ed4770 3871c4002c8980b2
[ 60.278068] ffff880150ed4748 ffff880150ed4770 ffff880150ed3f60 ffff88014df6bb00
[ 60.278081] Call Trace:
[ 60.278091] [<ffffffff815b3d90>] dump_stack+0x19/0x1b
[ 60.278101] [<ffffffff815b0a8d>] print_circular_bug+0x2b6/0x2c5
[ 60.278111] [<ffffffff810ab826>] __lock_acquire+0x1766/0x1d30
[ 60.278123] [<ffffffff81067e08>] ? __kernel_text_address+0x58/0x80
[ 60.278134] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200
[ 60.278142] [<ffffffff810621b5>] ? flush_work+0x5/0x280
[ 60.278151] [<ffffffff810621ed>] flush_work+0x3d/0x280
[ 60.278159] [<ffffffff810621b5>] ? flush_work+0x5/0x280
[ 60.278169] [<ffffffff810a9b14>] ? mark_held_locks+0x94/0x140
[ 60.278178] [<ffffffff81062d77>] ? __cancel_work_timer+0x77/0x120
[ 60.278188] [<ffffffff810a9cbd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 60.278196] [<ffffffff81062d8a>] __cancel_work_timer+0x8a/0x120
[ 60.278206] [<ffffffff81062e53>] cancel_delayed_work_sync+0x13/0x20
[ 60.278214] [<ffffffff814b89d9>] cpufreq_governor_dbs+0x529/0x6f0
[ 60.278225] [<ffffffff814b76a7>] cs_cpufreq_governor_dbs+0x17/0x20
[ 60.278234] [<ffffffff814b5df8>] __cpufreq_governor+0x48/0x100
[ 60.278244] [<ffffffff814b6b80>] __cpufreq_remove_dev.isra.14+0x80/0x3c0
[ 60.278255] [<ffffffff815adc0d>] cpufreq_cpu_callback+0x38/0x4c
[ 60.278265] [<ffffffff81071a4d>] notifier_call_chain+0x5d/0x110
[ 60.278275] [<ffffffff81071b0e>] __raw_notifier_call_chain+0xe/0x10
[ 60.278284] [<ffffffff815a0a68>] _cpu_down+0x88/0x330
[ 60.278292] [<ffffffff81024cf7>] ? cpu_hotplug_driver_lock+0x17/0x20
[ 60.278302] [<ffffffff815a0d46>] cpu_down+0x36/0x50
[ 60.278311] [<ffffffff815a2748>] store_online+0x98/0xd0
[ 60.278320] [<ffffffff81452a28>] dev_attr_store+0x18/0x30
[ 60.278329] [<ffffffff811d9edb>] sysfs_write_file+0xdb/0x150
[ 60.278337] [<ffffffff8116806d>] vfs_write+0xbd/0x1f0
[ 60.278347] [<ffffffff81185950>] ? fget_light+0x320/0x4b0
[ 60.278355] [<ffffffff811686fc>] SyS_write+0x4c/0xa0
[ 60.278364] [<ffffffff815bbbbe>] tracesys+0xd0/0xd5
[ 60.280582] smpboot: CPU 1 is now offline
The intention of that commit was to avoid warnings during CPU
hotplug, which indicated that offline CPUs were getting IPIs from the
cpufreq governor's work items. But the real root-cause of that
problem was commit a66b2e5 (cpufreq: Preserve sysfs files across
suspend/resume) because it totally skipped all the cpufreq callbacks
during CPU hotplug in the suspend/resume path, and hence it never
actually shut down the cpufreq governor's worker threads during CPU
offline in the suspend/resume path.
Reflecting back, the reason why we never suspected that commit as the
root-cause earlier, was that the original issue was reported with
just the halt command and nobody had brought in suspend/resume to the
equation.
The reason for _that_ in turn, as it turns out, is that earlier
halt/shutdown was being done by disabling non-boot CPUs while tasks
were frozen, just like suspend/resume.... but commit cf7df378a
(reboot: migrate shutdown/reboot to boot cpu) which came somewhere
along that very same time changed that logic: shutdown/halt no longer
takes CPUs offline. Thus, the test-cases for reproducing the bug
were vastly different and thus we went totally off the trail.
Overall, it was one hell of a confusion with so many commits
affecting each other and also affecting the symptoms of the problems
in subtle ways. Finally, now since the original problematic commit
(a66b2e5) has been completely reverted, revert this intermediate fix
too (2f7021a8), to fix the CPU hotplug deadlock. Phew!
Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Cc: 3.10+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Hardware workaround requesting hardware to skip vlan insertion is necessary
only when umc or qnq is enabled. Enabling this workaround in other scenarios
could cause controller to stall.
Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The hard-coded 8021.q proto will break 802.1ad traffic. So switch to use
vlan->proto.
Cc: Basil Gor <basil.gor@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 441ac0fcaa
(macvtap: Convert to using rtnl lock) forget to return what
macvtap_ioctl_set_queue() returns to its caller. This may break multiqueue API
by always falling through to TUNGETFEATURES.
Cc: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Eli Cohen <eli@mellanox.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
bgmac is using functions from phylib, add the dependency.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Hutchings pointed out that my recent update to atl1e
in commit 352900b583
("atl1e: fix dma mapping warnings") was missing a bit of code.
Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation. This patch fixes that up. It also remembers to free the
skb in the event that an error occurs, so we don't leak. Untested, as
I don't have hardware. I think its pretty straightforward, but please
review closely.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: Jay Cliburn <jcliburn@gmail.com>
CC: Chris Snook <chris.snook@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
We should be using groups, not attribute lists, for classes to allow
subdirectories, and soon, binary files. Groups are just more flexible
overall, so add them.
The dev_attrs list will go away after all in-kernel users are converted
to use dev_groups.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
device_create_groups lets callers create devices as well as associated
sysfs attributes with a single call. This avoids race conditions seen
if sysfs attributes on new devices are created later.
[fixed up comment block placement and add checks for printk buffer
formats - gregkh]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a patch b55f84e2d5 "ata_piix: Fix DVD
not dectected at some Haswell platforms" to fix an issue of DVD not
recognized on Haswell Desktop platform with Lynx Point.
Recently, it is also found the same issue at some platformas with Wellsburg PCH.
So deliver a similar patch to fix it by disables 32bit PIO in IDE mode.
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
To run hangcheck in near future.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix a "set but not used" warning found via make W=1.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The intent of the check is made more clear if we use the proper name for
0 here.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The default context is always supported (as it contains the global
hangcheck stats) and the contexts for hangcheck are not limited
to any ring.
References: https://bugs.freedesktop.org/show_bug.cgi?id=65845
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_enable_rc6() is used to check if we can compute the RC6 residency
in the sysfs code. Disable this for platforms older than Ironlake.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Put the comment a bit closer to the actual write (Paulo Zanoni)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Fix space before tab.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We also wait for that blank on other platforms but the w/a doesn't
apply there. Not an issue at all.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fixes improper in_pressure_scale output that is
returned by the lps331ap barometer sensor driver. According
to the documentation the pressure after applying the scale has to
be expressed in kilopascal units. With erroneous implementation
the scale value larger by two orders of magnitude is returned -
2441410 instead of 24414.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
At the moment we have the following interrupt enabling sequence:
1. irq preinstall hook
2. enabling the interrupt handler and calling irq postinstall hook
3. enable rps interrupts from the async work
And the folliwing disable sequence:
1. disabling the interrupt handler and calling the uninstall hook
2. disabling the rps interrupt
Since the postinstall hook now always sets up PMIIR, PMIER and PMIMR
to known-good states there no way for an interrupt to sneak in in the
enable sequence, so we can reinstate the WARN lost in
commit eda63ffb90
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Tue May 28 19:22:26 2013 -0700
drm/i915: Add PM regs to pre/post install
Note that there's some room for future cleanups since most of the
interrupt register clearing in the disable function is rather
redundant. But that's better done in follow-up patches, if at all.
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The VECS enabling required some changes to how rps interrupts are
enabled/disabled since VECS interrupts are handling with the PM
interrupt registers.
But now that the pre/postinstall sequences is identical for all
platforms with rps support (snb, ivb, hsw, vlv) we can also use the
exact same sequence to actually enable the rps interrupts. Strictly
speaking using spinlocks is overkill on snb/ivb & vlv since they have
no VECS ring, but imo that's more than made up by the common code.
Hence this just unifies the vlv code with the snb-hsw code which
matched exactly before the VECS enabling. See
commit eda63ffb90
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Tue May 28 19:22:26 2013 -0700
drm/i915: Add PM regs to pre/post install
and
commit 4848405cce
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Tue May 28 19:22:27 2013 -0700
drm/i915: make PM interrupt writes non-destructive
for why the gen6 code (shared between snb, ivb and hsw) needed to be
changed originally.
v3: Improve the commit message to more clearly spell out why we want
to unify the code and what exactly changes.
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again extract a common helper. For the postinstall hook things are a
bit more complicated since we have more cases on ilk-hsw/vlv here.
But since vlv was clearly broken by failing to initialize
dev_priv->gt_irq_mask correctly the shared code is clearly justified.
Also kill the PMIER setting in the async rps enable work. I should
have been save, but also clearly looked rather fragile. PMIER setup is
now all down in the irq pre/postinstall hooks.
With this we now have the usual interrupt register sequence for GT/PM
irq registers:
- IER is setup once with all the interrupts we ever need in the
postinstall hook and never touched again. Exceptions are SDEIER,
which is touched in the preinstall hook (when the irq handler isn't
enabled) and then only from the irq handler. And DEIER/VLV_IER with
is used in the irq handler but also written to once in the
postinstall hook. But since that write is essentially what enables
the interrupt and we should always have MSI interrupts we should be
save. In case we ever have non-MSI interrupts we'd be screwed.
- IIR is cleared in the postinstall hook before we enable/unmask the
respective interrupt sources. Hence we can't steal an interrupt
event an accidentally trigger the spurious interrupt logic in the
core kernel. Note that after some discussion with Ben Widawsky we
think that we actually should clear the IIR registers in the
preinstall hook. But doing that is a much larger patch series.
- IMR regs are (usually) all masked off. Those are the only regs
changed at runtime, which is all protected by dev_priv->irq_lock.
This unification also kills the cargo-culted read-modify-write PM
register setup for VECS. Interrupt setup is done without userspace
being able to interfere, so we better know what values we want to put
into those registers. RMW cycles otoh are really good at papering over
races, until stuff magically blows up and no one has a clue why.
v2: Touch the gen6+ PM interrupt registers only on gen6+.
v3: Improve the commit message to more clearly spell out why we want
to unify the code and what exactly changes.
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add a comment to explain why the l3 parity interrupt is
special.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the addition of VECS we have a slightly different enable
sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
will end up in hard to track down surprises.
Hence unifiy things and since we have copies of this code in 3 places
now, extract it into its own little helper.
Note that this changes the irq preinstall sequence a bit for snb and
vlv: We now also clear the PM registers in the preinstall hook, in
addition to the PM register clearing/setup already done when actually
enabling rps. So this doesn't fix a bug but simply unifies the code
across all platforms. After the postinstall hook is similarly unified
we can rip out the then redundant PM interrupt setup from the rps
code.
v3: Rebase on top of the retained double-GTIIR clearing. Also
resurrect the masking/disabling of the gen6+ PM interrupts as spotted
by Ben Widaswky.
v4: Move the DE interrupt reset code out of gen5_gt_irq_preinstall
back to ironlake_irq_preinstall where it really belongs. Spotted by
Paulo.
v3: Improve the commit message to more clearly spell out why we want
to unify the code and what exactly changes.
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: s/GT/PM/ to fix up a comment which Ben spotted while
reviewing.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To make users life a little easier figuring out what they have on their
system.
Ideally, I'd really like to report LLC size, but it turned out to be a
bit of a pain. Maybe I'll revisit it in the future.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRI clients really should be using MOCS to get fine grained streaming
cache controls. With that note, I *hope* that this patch doesn't improve
performance overwhelmingly, because if it does - it means there is a
problem elsewhere.
In any case, the kernel, and old userspace should get some benefit from
this, so let's do it. eLLC is always a good default, and really not
using it is the special case for MOCS.
References: http://www.intel.com/newsroom/kits/restricted/ha$well!/pdfs/4th_Gen_Intel_Core_PressBriefing_5-29.pdf (page 57)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The eLLC cannot be determined by PCIID because as far as we know, even
machines supporting eLLC may not have it enabled, or fused off or
whatever. It's possible this isn't actually true, and at that point we
can switch to a DEV_INFO flag instead.
I've defined everything where the docs are clear, and left the rest as
magic.
But we need it before we set the pte_encode function pointers, which
happens really early, in gtt_init.
The problem with just doing the normal sequence earlier is we don't have
the ability to use forcewake until after the pte functions have been set
up.
Since all solutions are somewhat ugly (barring rewriting all the init
ordering), I've opted to do the detection really early, and the enabling
later - since the register to detect doesn't require forcewake.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Move dev_priv->ellc_size away from the dri1 dungeon to a nice
place right next to the l3 parity stuff. Also squash in the follow-up
commit to read out the eLLC size a bit earlier.]
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The EDRAM present register isn't really defined in the docs. It just
says check to see if it's set to 1. So I haven't defined the 1 value not
knowing what it actually means.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The cacheability controls have changed, and the bits have been
rearranged in general.
Note that age 0 is the oldest (most likely to get evicted) and age 3
is the youngest (most likely to stick around for a bit). We've picked
0 for no reason, but atm it shouldn't matter anyway (since we don't
yet try to differentiate between different objects).
v2: Remove comments for snb/ivb cache leves, that's a separate change.
v3: Resolve conflicts due to patch series reordering.
v4: Rebased on top of Kenneth Graunke's ->pte_encode refactoring.
v5: Removed eLLC bits for separate patch.
In the internal repository this was:
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Add comment about cache ages as requested by Ben provoked due
to a question from Damien.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Although it is unlikley that physical package id is set to some
arbitary number, it is better to prevent in anycase. Since package
temp zones use this in thermal zone type and for allocation, added
a limit.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
More DPM fixes, r6xx DMA fix for bo moving, UVD fixes,
one major regression fix on bootup on some machine (ttm backoff missing)
* 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux:
radeon kms: do not flush uninitialized hotplug work
drm/radeon/dpm/sumo: handle boost states properly when forcing a perf level
drm/radeon: align VM PTBs (Page Table Blocks) to 32K
drm/radeon: allow selection of alignment in the sub-allocator
drm/radeon: never unpin UVD bo v3
drm/radeon: fix UVD fence emit
drm/radeon: add fault decode function for CIK
drm/radeon: add fault decode function for SI (v2)
drm/radeon: add fault decode function for cayman/TN (v2)
drm/radeon: use radeon device for request firmware
drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate
drm/radeon: use CP DMA on r6xx for bo moves
drm/radeon: implement bo copy callback using CP DMA (v2)
drm/radeon: Disable dma rings for bo moves on r6xx
drm/radeon/dpm: disable gfx PG on PALM
drm/radeon/hdmi: make sure we have an afmt block assigned
This fixes a crash if something tries to do an asynchronous operation on
busless maps which was introduced during the merge window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJR48ywAAoJELSic+t+oim9qWsP/1/t39jYvgHvkKyTKs9OHiDv
tnhJdtbfGty10/wykRfkg5cKC+gCQaLjbBiynpOMUc0lURoCLZSIXaX/Y+mc7A8y
HvnojQ2mUOxhYmeZsFgwnOFZmBLjTC4ZpqRmsuQ/t+qV41BbhXUVyN9nSbpjL35Z
Fgq7za+vdLBxcHjKk6Xigi1XA2orgcIWoU9F8hcSLgw9XRjr1DhCS4KZliqZbVgR
8ulANUro+tvzXM7PbTZmSDX6tXTy40IZBkVu74Tfh7y+stAr/nlpPcXMBW49hw+W
9Z3NKYBTEnstBRjhWGqiPUtPGThme5fPu/nvASH8uMDIQDdCzm2oYhYaRtEoir0n
SIu3vbaWCOtZNM6z1XWpoPPlb3e4HBbgm/kGur3DzCsb8LY23JzYxmGzN0JJ5om6
2f1GwaIK2MYc4lT0iBkaw5MaNjFk3KJSw+MIjJ0bNUub3A8HwvCyN+BzRc87lnar
RGpJ12wOBCtw+K5kqOuLPuPW0fyGOGIrxFJQy4ji+FSwasvA8bcJczhGroQayzrk
kS6t38Iy0ZNSZ4IZYyYs5vwEqOumRYWNND/KI0lqPKhaysxGJ+YVTd42SiCF/1YN
3NRAqEKgquUYvhacCealMQuDcQBRplHCwfbDco1gjcWfBugDq6P8ST9K2ZJ/8R+C
O3HMMG6VlXKJ0K9GbnS7
=c5Gp
-----END PGP SIGNATURE-----
Merge tag 'regmap-v3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fix from Mark Brown:
"Fix regmap crash for async operation on busless maps
This fixes a crash if something tries to do an asynchronous operation
on busless maps which was introduced during the merge window"
* tag 'regmap-v3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: cache: bail in regmap_async_complete() for bus-less maps
Need to properly enable/disable boost states when forcing a performance
level.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Covers requirements of all current asics.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Correction of the omap_usb3_dpll_params array when the sys_clk_rate is
20MHz.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The error message is common to both clk_get functions. Update it
accordingly.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
When CONFIG_HAS_DMA isn't enabled, the UDC core gets build errors:
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
drivers/built-in.o: In function `usb_gadget_unmap_request':
drivers/usb/gadget/udc-core.c:91: undefined reference to `dma_unmap_sg'
drivers/usb/gadget/udc-core.c:96: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `usb_gadget_map_request':
drivers/usb/gadget/udc-core.c:62: undefined reference to `dma_map_sg'
drivers/usb/gadget/udc-core.c:71: undefined reference to `dma_map_single'
drivers/usb/gadget/udc-core.c:74: undefined reference to `dma_mapping_error'
Prevent this by protecting the DMA API routines with preprocessor tests.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If NO_DMA=y:
drivers/built-in.o: In function `mv_u3d_done':
drivers/usb/gadget/mv_u3d_core.c:206: undefined reference to `dma_pool_free'
drivers/usb/gadget/mv_u3d_core.c:209: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `mv_u3d_build_trb_one':
drivers/usb/gadget/mv_u3d_core.c:311: undefined reference to `dma_pool_alloc'
drivers/built-in.o: In function `mv_u3d_req_to_trb':
drivers/usb/gadget/mv_u3d_core.c:480: undefined reference to `dma_map_single'
drivers/built-in.o: In function `mv_u3d_remove':
drivers/usb/gadget/mv_u3d_core.c:1770: undefined reference to `dma_pool_destroy'
drivers/usb/gadget/mv_u3d_core.c:1773: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `mv_u3d_probe':
drivers/usb/gadget/mv_u3d_core.c:1880: undefined reference to `dma_alloc_coherent'
drivers/usb/gadget/mv_u3d_core.c:1890: undefined reference to `dma_pool_create'
drivers/usb/gadget/mv_u3d_core.c:1984: undefined reference to `dma_pool_destroy'
drivers/usb/gadget/mv_u3d_core.c:1986: undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If NO_DMA=y:
drivers/built-in.o: In function `fotg210_start_dma':
drivers/usb/gadget/fotg210-udc.c:354: undefined reference to `dma_map_single'
drivers/usb/gadget/fotg210-udc.c:357: undefined reference to `dma_mapping_error'
drivers/usb/gadget/fotg210-udc.c:362: undefined reference to `dma_sync_single_for_cpu'
drivers/usb/gadget/fotg210-udc.c:376: undefined reference to `dma_unmap_single'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If NO_DMA=y:
drivers/built-in.o: In function `done':
drivers/usb/gadget/mv_udc_core.c:239: undefined reference to `dma_pool_free'
drivers/built-in.o: In function `build_dtd':
drivers/usb/gadget/mv_udc_core.c:371: undefined reference to `dma_pool_alloc'
drivers/built-in.o: In function `udc_prime_status':
drivers/usb/gadget/mv_udc_core.c:1465: undefined reference to `dma_map_single'
drivers/built-in.o: In function `mv_udc_remove':
drivers/usb/gadget/mv_udc_core.c:2087: undefined reference to `dma_pool_destroy'
drivers/usb/gadget/mv_udc_core.c:2090: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `mv_udc_probe':
drivers/usb/gadget/mv_udc_core.c:2190: undefined reference to `dma_alloc_coherent'
drivers/usb/gadget/mv_udc_core.c:2201: undefined reference to `dma_pool_create'
drivers/usb/gadget/mv_udc_core.c:2315: undefined reference to `dma_pool_destroy'
drivers/usb/gadget/mv_udc_core.c:2317: undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If NO_DMA=y:
drivers/built-in.o: In function `dwc3_free_one_event_buffer':
drivers/usb/dwc3/core.c:132: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `dwc3_alloc_one_event_buffer':
drivers/usb/dwc3/core.c:154: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
drivers/built-in.o: In function `dwc3_free_trb_pool':
drivers/usb/dwc3/gadget.c:407: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `dwc3_gadget_exit':
drivers/usb/dwc3/gadget.c:2693: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `dwc3_alloc_trb_pool':
drivers/usb/dwc3/gadget.c:391: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `dwc3_gadget_init':
drivers/usb/dwc3/gadget.c:2598: undefined reference to `dma_alloc_coherent'
drivers/usb/dwc3/gadget.c:2667: undefined reference to `dma_free_coherent'
drivers/usb/dwc3/gadget.c:2674: undefined reference to `dma_free_coherent'
drivers/usb/dwc3/gadget.c:2678: undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
USB_CONFIGFS_RNDIS depends on USB_U_RNDIS. Select it.
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb_gadget_ops :: udc_stop might be called with driver = NULL since
511f3c5326
(usb: gadget: udc-core: fix a regression during gadget driver unbinding)
Because of that, 2nd times insmod goes fail.
This patch fixes it up.
Reported-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
free_irq() expects the same device identity that was passed to
corresponding request_irq(), otherwise the IRQ is not freed.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
When there is an error with the usb3_phy probe or absence, the error returned
is erroneously for usb2_phy.
Cc: <stable@vger.kernel.org>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the
Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the
bit is 1, the event is represented Device-Specific Event, then use
[7:1] bits as Device Specific Event to marked the type. It has 7 bits,
and we can see the reserved8_31 variable name which means from 8 to 31
bits marked reserved, actually there are 24 bits not 25 bits between
that. And 1 + 7 + 24 = 32, the event size is 4 byes.
So in dwc3_event_type, the bit mask should be:
is_devspec [0] 1 bit
type [7:1] 7 bits
reserved8_31 [31:8] 24 bits
This patch should be backported to kernels as old as 3.2, that contain
the commit 72246da40f "usb: Introduce
DesignWare USB3 DRD Driver".
Cc: <stable@vger.kernel.org>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Remove __init and __exit from probe() and remove() and
would also fix the section mismatch issue.
Signed-off-by: Yuan-Hsin Chen <yhchen@faraday-tech.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This avoids a build error in at91sam9261_9g10_defconfig:
drivers/usb/gadget/at91_udc.c: In function 'at91udc_probe':
drivers/usb/gadget/at91_udc.c:1685:34: warning: 'flags' may be used uninitialized in this
function [-Wmaybe-uninitialized]
board->vbus_active_low = (flags & OF_GPIO_ACTIVE_LOW) ? 1 : 0;
^
drivers/usb/gadget/at91_udc.c:1678:21: note: 'flags' was declared here
enum of_gpio_flags flags;
^
Making the call to at91udc_of_init conditinal also reduces
the object code size without sacrificing build coverage.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In case we fail our ->udc_start() callback, we
should be ready to accept another modprobe following
the failed one.
We had forgotten to clear dwc->gadget_driver back
to NULL and, because of that, we were preventing
gadget driver modprobe from being retried.
Cc: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If krealloc() returns NULL, it doesn't free the original. So any code
of the form 'foo = krealloc(foo, ...);' is almost certainly a bug.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
On systems with no package MSR support this caused crash as there
is a bug in the logic to check presence of DTHERM and PTS feature
together. Added a change so that when there is no PTS support, module
doesn't get loaded. Even if some CPU comes online with the PTS
feature disabled, and other CPUs has this support, this patch
will still prevent such MSR accesses.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reported-by: Daniel Walker <dwalker@fifo99.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
This removes all the remaining one-off uses of the __cpuinit macros
from all C files in the drivers/* directory.
[1] https://lkml.org/lkml/2013/5/20/589
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
This removes all the drivers/acpi uses of the __cpuinit macros
from all C files.
[1] https://lkml.org/lkml/2013/5/20/589
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
This removes all the drivers/hwmon uses of the __cpuinit macros
from all C files.
[1] https://lkml.org/lkml/2013/5/20/589
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: lm-sensors@lm-sensors.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Daniel Vetter