As we need to manipulate our device structure and allocate queue a task,
it is no longer a simple atomic operation and cannot be performed along
the atomic modeset paths. Instead make sure that we disable FBC (which
must be therefore kept as a set of simple register writes) when
performing the atomic modeset and leave the heavy-weight
intel_update_fbc() for the normal modeset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This originally started as a patch from Bernard as a way of simply
setting the VS scheduler. After submitting the RFC patch, we decided to
also modify the DS scheduler. To be most explicit, I've made the patch
explicitly set all scheduler modes, and included the defines for other
modes (in case someone feels frisky later).
The rest of the story gets a bit weird. The first version of the patch
showed an almost unbelievable performance improvement. Since rebasing my
branch it appears the performance improvement has gone, unfortunately.
But setting these bits seem to be the right thing to do given that the
docs describe corruption that can occur with the default settings.
In summary, I am seeing no more perf improvements (or regressions) in my
limited testing, but we believe this should be set to prevent rendering
corruption, therefore cc stable.
v1: Clear bit 4 also (Ken + Eugeni)
Do a full clear + set of the bits we want (Me).
Cc: Bernard Kilarski <bernard.r.kilarski@intel.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by (RFC): Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The (2<<6) virtual memory space selector harks back to gen3 and is
mandatory given our use of GTT space for batchbuffers. On gen4+, use of
the GTT became mandatory and bit6 marked reserved. However the code must
now explicitly set (1<<7), which conveniently is also (2<<6).
To clarify the meaning for future readers, replace the open coded (2<<6)
with MI_BATCH_GTT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we defer updating the fence register from set-tiling to the point of
use, we need to declare every access through the GTT as either fenced or
unfenced.
This patches fixes an old bug in the execbuffer relocation processing
which could conceivably be hit by a pathological userspace.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Sparse doesn't like:
"error: bad constant expression"
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
[danvet: apply s/drm_malloc_ab/kcalloc bikeshed. If it's small enough
for the stack, it's small enough for kmalloc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should contain all the changes which require no thought to make
sparse happy.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the PCH split occurred, hw dropped support for separate hsync and
vsync disable in the VGA DAC. So add a PCH specific DPMS function that
just uses the port enable bit for controlling DPMS states.
Before this fix, when anything other than a full DPMS off occurred,
the VGA port would be left enabled and scanning out while all the other
heads would turn off as expected.
v2: duplicate encoder helper vtable into pch and gmch versions (Daniel)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48491
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: s/intel_crt_dpms/gmch_crt_dpms as suggested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The purpose of this patch is to avoid zeroing the lower 12 reserved bits
of surface base address registers (framebuffer & sprite). There are bits
in that range that may occasionally be set by BIOS or by other components.
Signed-off-by: Armin Reese <armin.c.reese@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This needs proper enablement to avoid machine hangs, so let's just avoid
it for now.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They work differently, but the count is the same.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those are used to program the WRPLL dividers correctly for each gives
frequency.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our workaround list kindly lists that this new default value needs to
be updated in Bspec. Naturally, this did not happen.
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to Bsepc, this should be set by default, but isn't. See vo1c.4
"Render Engine Command Streamer", Section 1.1.14.3 "3D_CHICKEN3"
Bspec also says that we always need to set all mask bits.
v2: Add comment about the mask bits wtf.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For some reason snb has 2 fields to set ppgtt cacheability. This one
here does not exist on gen7.
This might explain why ppgtt wasn't a win on snb like on ivb - not
enough pte caching.
v2: Fixup rebase fail.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bspec says that we need to set this: vol1c.3 "Blitter Command
Streamer", Section 1.1.2.1 "GAB_CTL_REG - GAB Unit Control Register".
We don't really rely on pagefaults, but who knows what this all
affects.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Contrary to the other clock gating w/a in GEN6_UCGCTL1, this one is
actually documented in Bspec, vol1g "GT Interface Registers [SNB]",
Section 1.5.1 "UCGCTL1 - Unit Level Clock Gating Control 1".
Supposedly this can prevent hangs on the media ring.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEbBAABAgAGBQJPi3XOAAoJEHm+PkMAQRiGnsUH9RjHwH4YFVyuP/DKtKa6zs74
wqkpT15yITQ5WWMog4JaJFFg5rJCUd8QZr7AS/HSn0ijDyZX5VU7Rcs9cMudDzNR
H/5K/AscS4fjb0HwWVqoltTWHRb9QGSwVN3+E3VCDLt9P89YJ0o3QztkkuEX5dkZ
jc7reVXTfRnCcILEa9jleOzrn+OLM3j/jAjQ2hGunl8EDLzD4b17HHPoli4jEZ/5
5ibpSVsPD+AqzN+glbXvYjVItl12D0IQos/JdOwfuZriCVWLxysSSwHZTbPCyvBZ
LHH4HR5T+XLSXbjJeNkUFHLzqU+d5gVRadIoWtJCxqxFjKbOs2YtzJ5Ai0nDiw==
=kTkC
-----END PGP SIGNATURE-----
Merge tag 'v3.4-rc3' into drm-intel-next-queued
Backmerge Linux 3.4-rc3 into drm-intel-next to resolve a few things
that conflict/depend upon patches in -rc3:
- Second part of the Sandybridge workaround series - it changes some
of the same registers.
- Preparation for Chris Wilson's fencing cleanup - we need the fix
from -rc3 merged before we can move around all that code.
- Resolve the gmbus conflict - gmbus has been disabled in 3.4 again,
but should be enabled on all generations in 3.5.
Conflicts:
drivers/gpu/drm/i915/intel_i2c.c
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we may kick off a delayed workqueue task to switch of the VDD lines, we
need to complete that task prior to turning off the panel (which itself
depends upon VDD being off).
v2: Don't cancel the outstanding work as this may trigger a deadlock
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As I do not see the output update without the scaler enabled on my
i3-330m, always enable it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than export every single architecture specific update_wm, just
export the wrapper around the display vtable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull ARM fixes from Russell King:
"Nothing too disasterous, the biggest thing being the removal of the
regulator support for vcore in the AMBA driver; only one SoC was using
this and it got broken during the last merge window, which then
started causing problems for other people. Mutual agreement was
reached for it to be removed."
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7386/1: jump_label: fixup for rename to static_key
ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE
ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU
ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus
ARM: 7383/1: nommu: populate vectors page from paging_init
ARM: 7381/1: nommu: fix typo in mm/Kconfig
ARM: 7380/1: DT: do not add a zero-sized memory property
ARM: 7379/1: DT: fix atags_to_fdt() second call site
ARM: 7366/3: amba: Remove AMBA level regulator support
ARM: 7377/1: vic: re-read status register before dispatching each IRQ handler
ARM: 7368/1: fault.c: correct how the tsk->[maj|min]_flt gets incremented
The 'max' range needs to be unsigned, since the size of the user address
space is bigger than 2GB.
We know that 'count' is positive in 'long' (that is checked in the
caller), so we will truncate 'max' down to something that fits in a
signed long, but before we actually do that, that comparison needs to be
done in unsigned.
Bug introduced in commit 92ae03f2ef ("x86: merge 32/64-bit versions of
'strncpy_from_user()' and speed it up"). On x86-64 you can't trigger
this, since the user address space is much smaller than 63 bits, and on
x86-32 it works in practice, since you would seldom hit the strncpy
limits anyway.
I had actually tested the corner-cases, I had only tested them on
x86-64. Besides, I had only worried about the case of a pointer *close*
to the end of the address space, rather than really far away from it ;)
This also changes the "we hit the user-specified maximum" to return
'res', for the trivial reason that gcc seems to generate better code
that way. 'res' and 'count' are the same in that case, so it really
doesn't matter which one we return.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
c5905afb0 ("static keys: Introduce 'struct static_key'...") renamed
struct jump_label_key to struct static_key. Fixup ARM for this to
eliminate these build warnings:
include/linux/jump_label.h:113:2:
warning: passing argument 1 of 'arch_static_branch' from incompatible pointer type
include/asm/jump_label.h:17:82:
note: expected 'struct jump_label_key *' but argument is of type 'struct static_key *'
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE
register states are not saved/restored at context switch. The default state
of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the
ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour
when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing
covert communication - eg between userspace tasks running inside chroot
jails.
This patch sets up TEECR in order to prevent user-space access to TEEHBR
when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to
access TEEHBR.
Cc: stable@vger.kernel.org
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
kernel then we will hang early during boot since the memory bank will
have wrapped around to zero.
This patch truncates memory banks for !LPAE configurations when the end
address is not representable in 32 bits.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
During booting of cpu1, there is a short window where cpu1
is online, but not active where cpu1 is occupied by waiting
to become active. If cpu0 then decides to schedule something
on cpu1 and wait for it to complete, before cpu0 has set
cpu1 active, we have a deadlock.
Typically it's this CPU frequency transition that happens at
this time, so let's just not wait for it to happen, it will
happen whenever the CPU eventually comes online instead.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@kernel.org
Signed-off-by: Jonas Aaberg <jonas.aberg@stericsson.com>
Reviewed-by: Rickard Andersson <rickard.andersson@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 26f41062f2 ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* A handful of warning and build fixes for Qualcomm MSM
* Build/warning and bug fixes for Samsung Exynos
* A fix from Rob Herring that removes misplaced interrupt-parent
properties from a few device trees
* A fix to OMAP dealing with cpufreq build errors, removing some of the
offending code since it was redundant anyway
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPiwhZAAoJEIwa5zzehBx30A0P/RkEOmm7eSWj9sDMW0zTvdoO
MDPIxp/D3gyUtp0IJlrikyGm+si8NlBFgz4O35np9NWmE/eek6ZDjF359Oj0SI2n
/G21xjZT26TQevJtOXprWf3VhdUnCN3VQMiqJpB+doUuJdp7sHyOXdo6c3h76q9V
cqOxtxb0gZFF6MxQpqOG1i1VaL8G1h697NeiUKJWKpgu3HIdzaA02T8X5YSRDTwU
MMmAIa2004oaYMvJJJWWfWa2m7gkCUqwnCTupn9vJGKwA7dv/GPK2BakXYy9ChgE
Rm2K/ddIQck7OwctP8MBj2Y7Pu2D3z762xqq1V43WpVgVknNsHZLEKeMrUcRTuVW
N6bkvAQ30eAQ6Q/BoE22ihtm3K1lY+mkyvc+8UUA0Ph3qN5FTNrrjCCZgSp2KHUM
6Y7vmAAS89kC0ocjS+3VwRktP2FUyAQDuMiDuaNSwga3vdnf0WsDlCP0Cwn2mK6t
pugBlX9ZShXzuVd68LvAkRSlFvqnexjyQlgkl/vuyfg2YAEgjDx9J2ngBrAwxUDa
glwNv8njO2q4B7RWUd+jhXxPH2KI+7xaPHZ4PbyKpE0xK5qgstMmROQFQKloGnaI
UtOt9i9clv2N8sCv6f6lwNw0P1f4Qt4KjBphquolMBTtTNwS4RDOywitDk7d8rc7
6nngNhd+UTCqfyQ4rCHn
=OWRk
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull "ARM: a few more SoC fixes for 3.4-rc" from Olof Johansson:
- A handful of warning and build fixes for Qualcomm MSM
- Build/warning and bug fixes for Samsung Exynos
- A fix from Rob Herring that removes misplaced interrupt-parent
properties from a few device trees
- A fix to OMAP dealing with cpufreq build errors, removing some of the
offending code since it was redundant anyway
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: OMAP: clock: cleanup CPUfreq leftovers, fix build errors
ARM: dts: remove blank interrupt-parent properties
ARM: EXYNOS: Fix Kconfig dependencies for device tree enabled machine files
ARM: EXYNOS: Remove broken config values for touchscren for NURI board
ARM: EXYNOS: set fix xusbxti clock for NURI and Universal210 boards
ARM: EXYNOS: fix regulator name for NURI board
ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL
ARM: msm: Fix section mismatches in proc_comm.c
video: msm: Fix section mismatches in mddi.c
arm: msm: trout: fix compile failure
arm: msm: halibut: remove unneeded fixup
ARM: EXYNOS: Add PDMA and MDMA physical base address defines
ARM: S5PV210: Fix compiler warning in dma.c file
ARM: EXYNOS: Fix compile error in exynos5250-cpufreq.c
ARM: EXYNOS: Add missing definition for IRQ_I2S0
ARM: S5PV210: fix unused LDO supply field from wm8994_pdata
A few regression fixes for Realtek HD-audio codecs, mainly specific to
some laptop models.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAABAgAGBQJPis5JAAoJEGwxgFQ9KSmkhGsQAIIbBE05eB3BHi44eP5/olay
Cv+/k9l+LEPBdZuPCJhC80s8gVZ3Ef9BCsmDBsH2mqKCv8nqWQhc9fjf9WHzdwOV
M/IGyvyYaFbI9XDOrCXFhXByjWj5Q2Itxi79VkK00ZE5SC8TPy6x/mXxcGyWfu/E
NNnYB+IJcTOKEhQG/G4uqeu6lAKiDgQWXCFDQdZpLv4Bod40E4c/Zviw2+iModwW
CCGyNJJFzSQIXun/d0bgLO7ZLo+c1aWMBKCfF/rd6g6AI6fgrnRx/8vXdxhY3gH+
FuQbQMuI8hv7KePritZZad/StSBdrOed1k1O0m9NdjAwjlygWYo0rGJ8gy2DiGWx
kyLOGWCIUaRIA3121Veq/rooJEdjP4+2di38ero+P/ondYleaQkG6iNescp6aSX7
GTs6fcbP81oUFhlRzHCEFQkxh/F4kN77kpXnI9HQCMkbX9K8TWDsy/s6dS3wKA7l
8FGM+lForE9X2TmYTcMJW1Gn4HyVl5opgcSgaE/GaZIrT6URJR2Eoi9CFKnuvx/j
xpNzSCt5DOB/TikwDSdeypja1NvbWk6QbhGmXEnSgIlrEy9ZVPJuMVRtmHf84YUj
sQz3+i4MHr7EyrwuRdpTliGJ4vZ2GJlfz3f1WFtD26ImhDKyZAYytuS/uVwsDwDh
vqYlU8+8DLh4BGHUr+4o
=8He+
-----END PGP SIGNATURE-----
Merge tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull another round of sound fixes from Takashi Iwai:
"A few regression fixes for Realtek HD-audio codecs, mainly specific to
some laptop models."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda/realtek - Fix mem leak (and rid us of trailing whitespace).
ALSA: hda/realtek - Add quirk for Mac Pro 5,1 machines
ALSA: hda/realtek - Add a fixup entry for Acer Aspire 8940G
ALSA: hda/realtek - Fix GPIO1 setup for Acer Aspire 4930 & co
ALSA: hda/realtek - Add a few ALC882 model strings back
Commit 18a4d0a22e ("[SCSI] Handle disk devices which can not process
medium access commands") introduced a bug in which we would attempt to
dereference the scsi driver even when the device had no ULD attached.
Ensure that a driver is registered and make the driver accessor function
more resilient to errors during device discovery.
Reported-by: Elric Fu <elricfu1@gmail.com>
Reported-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This function, along with the registers and deferred work hander, are
all shared with SandyBridge, IvyBridge and their variants. So remove the
duplicate code into a single function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... we will botch up the bit17 swizzling. Furthermore tiled pwrite is
a (now) unused slowpath, so no one really cares.
This fixes the last swizzling issues I have with i-g-t on my bit17
swizzling i915G. No regression, it's been broken since the dawn of
gem, but it's nice for regression tracking when really _all_ i-g-t
tests work.
Actually this is not true, Chris Wilson noticed while reviewing this
patch that the commit
commit d9e86c0ee6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Nov 10 16:40:20 2010 +0000
drm/i915: Pipelined fencing [infrastructure]
contained a functional change that broke things.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On the first instance we just wish to kick the waiters and see if that
terminates the wait conditions. If it does not, then we do not want to
keep retrying without ever making any forward progress and becoming
stuck in a hangcheck loop.
Reported-and-tested-by: Lukas Hejtmanek <xhejtman@fi.muni.cz>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48209
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Removing this code also eliminates build errors when CPU_FREQ_TABLE
support is not enabled.
Thanks to Russell King for pointing out the parts I missed under
plat-omap in the original version and also pointing out the build
errors when CPUFREQ_TABLE support was not enabled.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
These were incorrectly introduced and can cause problems for of_irq_init.
The correct way to define a root controller is no interrupt-parent set at
all or the interrupt-parent is set to the root controller itself when
inherited from a parent node.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Tested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
From David Brown:
"Here are some fixes for msm that fix problems caused by the latest
ARM code. The ones from Daniel remove unneeded fixups that now
cause compilation failures. Mine fix section mismatches, that were
incompletely fixed earlier."
* 'msm-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm:
ARM: msm: Fix section mismatches in proc_comm.c
video: msm: Fix section mismatches in mddi.c
arm: msm: trout: fix compile failure
arm: msm: halibut: remove unneeded fixup
Add config dependency for Exynos4 and Exynos5 device tree enabled machine
files on config options ARCH_EXYNOS4 and ARCH_EXYNOS5 respectively.
Enabling machine support without proper ARCH support enabled is incorrect.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
GCC's NULL is actually __null, which allows detecting some questionable
NULL usage and warn about it. Moreover each platform/compiler should
have its own stddef.h anyway (which is different from linux/stddef.h).
So there's no good reason to leak kernel's NULL to userspace and
override what the compiler provides.
Signed-off-by: Luboš Luňák <l.lunak@suse.cz>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The atmel_mxt_ts driver has been extended to support more 'configuration
objects' in commit 81c88a711 ("Input: atmel_mxt_ts - update object list"),
what broke the configuration values for NURI board. These values are
optional anyway, so remove them to get the driver working correctly.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
On some versions of NURI and UniversalC210 boards, camera clocks are
routed directly to xusbxti clock source. This patch sets the correct
value for this clock to let usb and camera sensors to work correctly and
avoid division by zero on driver's probe.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Regulator names should not contain slash to avoid issues with debugfs.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
When selecting SAMSUNG_PM_DEBUG, it complains about a missing printascii()
function if you do not select DEBUG_LL, so make the former select the latter.
Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Pull system.h fixups for less common arch's from Paul Gortmaker:
"Here is what is hopefully the last of the system.h related fixups.
The fixes for Alpha and ia64 are code relocations consistent with what
was done for the more mainstream architectures. Note that the
diffstat lines removed vs lines added are not the same since I've
fixed some of the whitespace issues in the relocated code blocks.
However they are functionally the same. Compile tested locally, plus
these two have been in linux-next for a while.
There is also a trivial one line system.h related fix for the Tilera
arch from Chris Metcalf to fix an implict include.."
* 'systemh-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
irq_work: fix compile failure on tile from missing include
ia64: populate the cmpxchg header with appropriate code
alpha: fix build failures from system.h dismemberment
Chris Wilson