Before Haswell we used to have the CPU pipes and the PCH transcoders.
We had the same amount of pipes and transcoders, and there was a 1:1
mapping between them. After Haswell what we used to call CPU pipe was
split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A,
B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder
(only used for VGA).
For all the outputs except for EDP we have an 1:1 mapping on the CPU
pipes and CPU transcoders, so if you're using CPU pipe A you have to
use CPU transcoder A. When have an eDP output you have to use
transcoder EDP and you can attach this CPU transcoder to any of the 3
CPU pipes. When using VGA you need to select a pair of matching CPU
pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the
PCH transcoder.
For now we're just creating the cpu_transcoder definitions and setting
cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the
registers was ported to use transcoder instead of pipe. The goal is to
keep the code backwards-compatible since on all cases except when
using eDP we must have pipe == cpu_transcoder.
V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau
and Daniel Vetter.
We currently need the haswell_crtc_off chunk because TRANSCODER_EDP
can be used by any CRTC, so when you stop using it you have to stop
saying you're using it, otherwise you may have at some point 2 CRTCs
claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled
one), then the HW state readout code will get completely confused.
In other words:
Imagine the following case:
xrandr --output eDP1 --auto --crtc 0
xrandr --output eDP1 --off
xrandr --output eDP1 --auto --crtc 2
After the last command you could get a "pipe A assertion failure
(expected off, current on)" because CRTC 0 still claims it's using
TRANSCODER_EDP, so the HW state readout function will read it
(through PIPECONF) and expect it to be off, when it's actually on
because it's being used by CRTC 2.
So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we
make sure we're pointing to our own original CRTC which is certainly
not used by any other CRTC.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Ironlake we have one PCH transcoder and FDI per pipe, so we know
that if ironlake_crtc_driving_pch returns false we can disable the PCH
transcoder and we also know that when we disable the crtc we can also
disable the PCH transcoder.
On Haswell there is only 1 PCH transcoder and FDI and they can be used
by any CRTC. So if for one specific crtc haswell_crtc_driving_pch
returns false we can't assert anything about the state of the PCH
transcoder or the FDI link without checking if any other CRTC is using
the PCH.
So on this commit remove the "assert_fdi_{t,r}x_disabled" form
haswell_crtc_enable and also only disable FDI and the PCH transcoder
if the port being disabled was actually a PCH port (we only have one
port using PCH: the VGA port).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By forking Ironlake and Haswell functions. The only callers are
{ironlake,haswell}_crtc_enable anyway, and this way we won't need to
add other checks on the Haswell version for the next gens.
V2: Even simpler, as pointed by Jani Nikula.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions were forked from their Ironlake versions, so now fix
the gen checks to reflect the fact that they will only run on Haswell.
It is worth noticing that we are not considering IBX/CPT possible on
Haswell anymore. So far on Haswell enablement we kept trying to still
consider IBX/CPT as a possibility with a Haswell CPU, but this was
never tested, I really doubt it will work with the current code and we
don't really have plans to support it. Future patches will remove the
IBX/CPT code from other Haswell functions. Notice that we still have a
WARN on haswell_crtc_mode_set in case we detect non-LPT PCH.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The last commit forked a Haswell version, so now we remove Haswell
code from these functions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The way we enable and disable the PCH on Haswell changed considerably
since now we have only one PCH transcoder, so we can't keep the same
asserts and we also can't just unconditionally disable the PCH
transcoder for non-PCH outputs. So let's fork a Haswell version.
These new functions look exactly the same as the ironlake versions.
The next patches will introduce the differences.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Identical #define is now available in include/drm/drm_dp_helper.h, nuke the
dupe.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That thing has grown way too big already.
Also move around a comment to the right spot.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise dp aux won't work on some hsw platforms, since they use a
different rawclk than the 125MHz clock used thus far.
To absolutely not change anything, round up: That way we get the old
63 divider for the default 125MHz clock.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need this when the bios forgets even to set that bit up. Most seem
to do that, even when they don't set up anything else in the panel
power sequencer.
Note that on IBX the rawclk is variable according to Bspec, but
everyone is using 125MHz. The rawclk is fixed to 125MHz on CPT, but
luckily we still have the same register available. On hsw, different
variants have different clocks, hence we need to check the register.
Since other pieces are driven by the rawclock, too, keep the little
helper in a central place.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like we already do for the LVDS panels. This seems to help greatly
in setting up the backlight, since the BIOS might refuse to cooperate.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
v2: Move the backlight_off call from panel_off to edp_backlight_off,
noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3 changes:
- If a given value is unset, use the maximal limits from the eDP spec.
- Write back the new values, since otherwise the panel power sequencing
hw will not dtrt.
- Revert the early bail-out in case the register values are unset.
The last change reverts
commit bfa3384a9a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Apr 10 11:58:04 2012 -0700
drm/i915: check PPS regs for sanity when using eDP
v2:
- Unlock the PP regs as the very first thing. This is a required w/a
for cpu eDP on port A, and generally a good idea.
- Fixup the panel power control port selection bits.
v3: Paulo Zanoni noticed that I've fumbled the computation of the spec
limit values. Fix them up. We've also noticed that the t8/t9 values in
the vbt/bios-programmed pp are much larger than any limits. My guess
is that this is to conceal any backlight enable/disable delays. So by
using the much shorter limits from the spec, which only concerns the
sink, we risk that we might display before the backlight is fully on,
or disable the output while the backlight still has afterglow. I've
figured I don't care too much, since this will only happen when both
the pp regs are not programmed, and the vbt tables don't contain
anything useful.
v4: Don't set the port selection bits on hsw/LPT, they don't exist any
more.
v5: Fixup spelling issues in comments, as noticed by Jesse Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Haswell does not have a scaler in the sprite pipeline anymore, so let's
ensure:
1/ We bail out of update_plate() when someone is trying to ask to
display a scaled framebuffer,
2/ We never write to the nonexistent SPR_SCALE register
v2: Smash in the fixup from Damien in the disable_plane function.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (for v1)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (for v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... like the comment says. No idea whether this has any effect, but
I guess it's better to not lie to the display by acking a test request
and never following through with it. This goes back to the commit that
originally introduced this code:
commit a60f0e38d7
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Oct 20 15:09:17 2011 -0700
drm/i915: add DP test request handling
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Meh'ed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only really required for dp 1.2. I've hoped this would help with some
link training woes I'm fighting, but alas those are only dp 1.1
devices.
Also move a comment that went misplaced in the recent refactorings to
the right spot again.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.
Hence extend the various dpcd arrays in the radeon driver, use
proper symbolic constants where applicable (one place overallocated
the dpcd array to 25 bytes). Then also drop the rd_interval cache -
radeon_dp_link_train_init re-reads the dpcd block, so the values we'll
consume in train_cr and train_ce will always be fresh.
To avoid needless diff-churn, #define the old size of dpcd as the new
one and keep it around.
v2: Alex Deucher noticed one place where I've forgotten to replace 8
with DP_RECEIVER_CAP_SIZE.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Safe for the minor difference that the intel versions get an offset
into the link_status as an argument, both are the same again.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
radeon and intel use the exact same definition.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
v2: Kill 2 more helpers in intel_dp.c that I've missed.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
radeon and intel use the exact same definition.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I want to move some dp link training helpers into this place, so in
the future this won't be just about i2c any longer.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the cached EDID from intel_dp and intel_lvds_connector to
intel_connector. Unify cached EDID handling for LVDS and eDP, in
preparation for adding more generic EDID caching later.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The caller, not intel_connector_update_modes(), should free the edid. This
improves the reusability of intel_connector_update_modes().
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pave the way for sharing some logic between eDP and LVDS.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Create a generic struct intel_panel for sharing a data structure and code
between eDP and LVDS panels. Add the new struct to intel_connector so that
later on we can have generic EDID and mode reading functions with EDID
caching that transparently fallback to fixed mode when EDID is not
available.
Add intel_panel as a dummy first, and move data (such as the mentioned
fixed mode) to it in later patches.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup tiny conflict in intel_dp_destroy.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we do EDID caching in intel_dp_init, we can do the fixed mode
initialization there too. This should not change the functionality apart
from initializing fixed mode earlier. Particularly retain the behaviour of
only falling back to VBT if EDID is not available to not regress
commit 47f0eb2234
Author: Keith Packard <keithp@keithp.com>
Date: Mon Sep 19 14:33:26 2011 -0700
drm/i915: Only use VBT panel mode on eDP if no EDID is found
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As there is 1:1 mapping between encoder and connector for the LVDS, the
goal is to simply reduce the amount of noise within the connector
functions, i.e. we split the encoder/connector for LVDS as best we can and
try to only operate on the LVDS connector from the connector funcs and the
LVDS encoder form the encoder funcs.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Get rid of saved int_lvds_connector and int_edp_connector in
drm_i915_private.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduce a local structure to move LVDS specific information away from the
drm_i915_private and onto the LVDS connector.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for introducing intel_lvds_connector to move some of the
LVDS specific storage away from drm_i915_private, first rename the encoder
to avoid potential confusion.
Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABAgAGBQJQgvdwAAoJEHm+PkMAQRiG+3AH/i2XsqqN3VctL0nnbWfvds+Q
aKulfIdJTjKiVAsawPUtRqReZ8ijiebrgA/53lZLlrFOoPPQ5+LHmnSyQF6gErOY
NuAE1lijXDRM1pwBlhvOBbAj26wUobGjqONFJ9OkKr758Ue8ds/Q7UdxyEgmYgmg
tvVMzfRcICzryUV3PcqL+3cNPpCUdT6wGGRJ9DCv/jvGiWKExWhOle5oltrmxk+D
NsqRcws5pEubfHE4J8BvNWr8lE1kHfYVhrJETiLJUiN2XAJcbI4Jy7rU/3EGteNS
0HMZdaPPjV874lohdM70X2225SbYrCVkAYB5hnZCTeC3tYyCawBBPMQoyAiOcmU=
=+861
-----END PGP SIGNATURE-----
Merge tag 'v3.7-rc2' into drm-intel-next-queued
Linux 3.7-rc2
Backmerge to solve two ugly conflicts:
- uapi. We've already added new ioctl definitions for -next. Do I need to say more?
- wc support gtt ptes. We've had to revert this for snb+ for 3.7 and
also fix a few other things in the code. Now we know how to make it
work on snb+, but to avoid losing the other fixes do the backmerge
first before re-enabling wc gtt ptes on snb+.
And a few other minor things, among them git getting confused in
intel_dp.c and seemingly causing a conflict out of nothing ...
Conflicts:
drivers/gpu/drm/i915/i915_reg.h
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_modes.c
include/drm/i915_drm.h
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A set of fixes and some minor cleanups for -rc2:
- A series from Arnd that fixes warnings in drivers and other code
included by ARM defconfigs. Most have been acked by corresponding
maintainers (and seem quite hard to argue not picking up anyway in the
few exception cases).
- A few misc patches from the list for integrator/vt8500/i.MX
- A batch of fixes to OMAP platforms, fixing:
- boot problems on beaglebone,
- regression fixes for local timers
- clockdomain locking fixes
- a few boot/sparse warnings
- For Tegra:
- Clock rate calculation overflow fix
- Revert a change that removed timer clocks and a fix for symbol name clashes
- For Renesas:
- IO accessor / annotation cleanups to remove warnings
- For Kirkwood/Dove/mvebu:
- Fixes for device trees for Dove (some minor cleanups, some fixes)
- Fixes for the mvebu gpio driver
- Fix build problem for Feroceon due to missing ifdefs
- Fix lsxl DTS files
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQgembAAoJEIwa5zzehBx3tbwQAJVxDjt0bNFhPDmPVnh4O3qE
qpmCQ4UZ3u153gkXO9973qZNso635yPYtiUA53TAr9kxX4La690IcBOLNMK2TwYZ
enBeg0JtjV+25lkYcsFGnggj8YNXzsL47SVymFxqiu4s4XLuQfUlBWpYyLjYVa6p
1zE5Q6oUVZMJxbqBEK3LaZ9ifV7RxG9xwpx6QiXQlPpZkKqDVYCs/efPXfXBoOeq
KinO/p6fDOQoKrYt1Kdfw5AhmHBrSw/K630/IjZHaIc6j3nDU5UjP0zhO0CE3zDH
NrYctUfJqR9VEKvrpO24RFFYiDaGK1Oge/GhmAAftiLoKK8qxTehKnxe3BUAsMnD
wldxsBBym1rDbr0ehxC9pV6ZtJhA7KZLoPNZpqwSbBYqFnmEG3pZwQV9wToswpmw
1jPJpzZOpe14edHvsixaPuaY3ACnzkkfUWu1wOlg33W5WhPInieMJuJ8hmL+1SVJ
g6Z6/7pjpHhC5CEhVqc5FJjRk1Jk+WsFa1FICoDjnkRW1Hg9DLvdUReEl+8xYuvI
oHqLvDrTabVs9ZDnyT5avBrovWVZjSxZ+TxwMIeQGU1QhW4b8hIjPx09EBb1Hy6F
BiZO3Q9zqm0+C+P1S0Cb3npumwG16ry7f6+51QXRXWNcgWWjm1ggZpWpmPY+g0Ra
BO6UABZwuUm8HzpJaEu1
=alOZ
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM soc fixes from Olof Johansson:
"A set of fixes and some minor cleanups for -rc2:
- A series from Arnd that fixes warnings in drivers and other code
included by ARM defconfigs. Most have been acked by corresponding
maintainers (and seem quite hard to argue not picking up anyway in
the few exception cases).
- A few misc patches from the list for integrator/vt8500/i.MX
- A batch of fixes to OMAP platforms, fixing:
- boot problems on beaglebone,
- regression fixes for local timers
- clockdomain locking fixes
- a few boot/sparse warnings
- For Tegra:
- Clock rate calculation overflow fix
- Revert a change that removed timer clocks and a fix for symbol
name clashes
- For Renesas:
- IO accessor / annotation cleanups to remove warnings
- For Kirkwood/Dove/mvebu:
- Fixes for device trees for Dove (some minor cleanups, some fixes)
- Fixes for the mvebu gpio driver
- Fix build problem for Feroceon due to missing ifdefs
- Fix lsxl DTS files"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
ARM: kirkwood: fix buttons on lsxl boards
ARM: kirkwood: fix LEDs names for lsxl boards
ARM: Kirkwood: fix disabling CACHE_FEROCEON_L2
gpio: mvebu: Add missing breaks in mvebu_gpio_irq_set_type
ARM: dove: Add crypto engine to DT
ARM: dove: Remove watchdog from DT
ARM: dove: Restructure SoC device tree descriptor
ARM: dove: Fix clock names of sata and gbe
ARM: dove: Fix tauros2 device tree init
ARM: dove: Add pcie clock support
ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory
ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable
ARM: s3c: mark s3c2440_clk_add as __init_refok
spi/s3c64xx: use correct dma_transfer_direction type
ARM: OMAP4: devices: fixup OMAP4 DMIC platform device error message
ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck
ARM: OMAP: resolve sparse warning concerning debug_card_init()
ARM: OMAP4: Fix twd_local_timer_register regression
ARM: tegra: add tegra_timer clock
ARM: tegra: rename tegra system timer
...
We were programming register 0x42020 twice on those platforms. Once
should be enough.
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>
With the consolidated registers, it appears that we're setting the same
bis several times. Let's just collect the bits we want to set and program
it once.
v2: More cleanup. Also program 0x42004 and 0x45000 for FBC on non
mobile platforms (Paulo Zanoni)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Undo the functional change as discussed on irc.]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A collection of warning fixes on non-ARM code from Arnd Bergmann:
* 'testing/driver-warnings' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: s3c: mark s3c2440_clk_add as __init_refok
spi/s3c64xx: use correct dma_transfer_direction type
pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
SCSI: ARM: make fas216_dumpinfo function conditional
SCSI: ARM: ncr5380/oak uses no interrupts
Merge misc fixes from Andrew Morton:
"Seven fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (7 patches)
lib/dma-debug.c: fix __hash_bucket_find()
mm: compaction: correct the nr_strict va isolated check for CMA
firmware/memmap: avoid type conflicts with the generic memmap_init()
pidns: remove recursion from free_pid_ns()
drivers/video/backlight/lm3639_bl.c: return proper error in lm3639_bled_mode_store() error paths
kernel/sys.c: fix stack memory content leak via UNAME26
linux/coredump.h needs asm/siginfo.h
Fix this build error:
drivers/firmware/memmap.c:240:19: error: conflicting types for 'memmap_init'
arch/ia64/include/asm/pgtable.h:565:17: note: previous declaration of 'memmap_init' was here
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Bernhard Walle <bwalle@suse.de>
Cc: Glauber Costa <glommer@parallels.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit cb6b6df111 ("xen/pv-on-hvm kexec: add quirk for Xen 3.4 and
shutdown watches.") added the xen_strict_xenbus_quirk() function with an
old K&R-style declaration without proper typing, causing gcc to rightly
complain:
drivers/xen/xenbus/xenbus_xs.c:628:13: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
because we really don't live in caves using stone-age tools any more,
and the kernel has always used properly typed ANSI C function
declarations.
So if a function doesn't take arguments, we tell the compiler so
explicitly by adding the proper "void" in the prototype.
I'm sure there are tons of other examples of this kind of stuff in the
tree, but this is the one that hits my workstation config, so..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
and add support for Intel Atom CE4110/4150/4170.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQfr/HAAoJEMsfJm/On5mBrtYP/2VtUeaU2vAkFm4DeF0SHhQu
Gbzwm8zBp4Dx4FI5mo079SZ5ySL9xkRUCjwWbkaA0KEbU75NBx2VA2/v46VCTypv
qbRpYr5vU4LirIXV5S5RNB40Vu2lEyoFiuKp3T6fJy0Eslj06uKlkZjfdAoVnZV6
A9kRgyTi6ubmygQYFWoxFGhmhE4yEO3l2cWtcXwXFjtCAfA5YUsRt6+wkTzKvl/5
ncMaM+oCyYicr8BUL+u5v3Ot3Tr0COmEhFBIiId/LStJEVUzGjIKj7G/O0gc5ak8
/jrsrBFDmjj+a5NH6CL4rOzFA7BMUAScciE+IlPF6O6DJ07K6rETo8+QV5XwW/1B
xUmbiN5eS81VBHu8DxP9PKoUmqjkYqWXmiFV3fi3o+DhScUO3nFpi86eXiVQ+NoX
8wwaakmqd1yWRD2VazNtcN+ZxYxAyPysdPjjJKeYeR8fKsG5HAdmxX1RwZjnY/YB
xFurt65HyBeXnK/eeH8kiBjjKu1KI3UGafKgdO46mjA0RdDv5Jsb8w2lanwVl+QG
zkopo3x3PgSib4O0PsG8f77LMLYvO76U5WxnjaYRWiU3JekJnVtzo2vUSD2oiAaU
CMGyKY9kKSZEYTOynqFlPrQZ6gonKU/sQkeWt8CQwX3L/wBRNNe8KPUEOJkQQEpZ
dghs1Aaekqj3EnBriPQb
=Y96u
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
"Drop some leftover dependencies on CONFIG_EXPERIMENTAL, and add
support for Intel Atom CE4110/4150/4170."
* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (coretemp) Add support for Atom CE4110/4150/4170
Documentation/hwmon: remove CONFIG_EXPERIMENTAL
hwmon: (pmbus) remove CONFIG_EXPERIMENTAL
Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and
ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one.
The transforms done are:
PCH_DSPCLK_GATE_D -> ILK_DSPCLK_GATE_D
ILK_DSPCLK_GATE -> ILK_DSPCLK_GATE_D
DPARBUNIT_CLOCK_GATE_DISABLE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE
ILK_DPARB_CLK_GATE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE
DPFDUNIT_CLOCK_GATE_DISABLE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
ILK_DPFD_CLK_GATE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
ILK_CLK_FBC -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE
DPFCRUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE
ILK_DPFC_DIS1 -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE
DPFCUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE
ILK_DPFC_DIS2 -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE
We have a VHRUNIT_CLOCK_GATE_DISABLE define for the pre-ILK DSPCLK_GATE_D.
Even if the same bit is used in ILK_DSPCLK_GATE_D, other bits in the
register change, so I went with re-defining it, well more precisely rename
IVB_VRHUNIT_CLK_GATE, which is not specific to IVB+. So:
IVB_VRHUNIT_CLK_GATE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE
VHRUNIT_CLOCK_GATE_DISABLE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE (ILK+ code)
This commit is only a renaming commit, further commits will clean up the
logic.
v2: Rename bit 5 and 7 to _ENABLE as setting them to 1 enables clock
gating on their respective units, contrary to all of the other bits
(Paulo Zanoni)
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>
Here are some tty and serial driver fixes for your 3.7-rc1 tree.
Again, the UABI header file fixes, and a number of build and runtime serial
driver bugfixes that solve problems people have been reporting (the staging
driver is a tty driver, hence the fixes coming in through this tree.)
All of these have been in the linux-next tree for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEABECAAYFAlCBmVQACgkQMUfUDdst+ynEuwCfexOnEj0evTfXN32kqG50MglI
o/UAnixeFbfSrHtFOybIEKiHchG2QX9F
=LPFk
-----END PGP SIGNATURE-----
Merge tag 'tty-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull TTY fixes from Greg Kroah-Hartman:
"Here are some tty and serial driver fixes for your 3.7-rc1 tree.
Again, the UABI header file fixes, and a number of build and runtime
serial driver bugfixes that solve problems people have been reporting
(the staging driver is a tty driver, hence the fixes coming in through
this tree.)
All of these have been in the linux-next tree for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'tty-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
staging: dgrp: check return value of alloc_tty_driver
staging: dgrp: check for NULL pointer in (un)register_proc_table
serial/8250_hp300: Missing 8250 register interface conversion bits
UAPI: (Scripted) Disintegrate include/linux/hsi
tty: serial: sccnxp: Fix bug with unterminated platform_id list
staging: serial: dgrp: Add missing #include <linux/uaccess.h>
serial: sccnxp: Allows the driver to be compiled as a module
tty: Fix bogus "callbacks suppressed" messages
net, TTY: initialize tty->driver_data before usage
Here are the USB patches against your 3.7-rc1 tree.
There are the usual UABI header file movements, and we finally are now
able to remove the dbg() macro that is over 15 years old (that had to
wait for after some other trees got merged into yours during the big
3.7-rc1 merge window.)
Other than that, nothing major, just a number of bugfixes and new device
ids. It turns out that almost all of the usb-serial drivers had bugs in
how they were handling their internal data, leaking memory, hence all of
those fixups.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEABECAAYFAlCBmLkACgkQMUfUDdst+yn8uACg2QF+GZm1DZvCjBHMSuiaNM3Q
jxEAnA8LkdQWb0wr55RFiPQl/uB0rD0E
=nNHn
-----END PGP SIGNATURE-----
Merge tag 'usb-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg Kroah-Hartman:
"Here are the USB patches against your 3.7-rc1 tree.
There are the usual UABI header file movements, and we finally are now
able to remove the dbg() macro that is over 15 years old (that had to
wait for after some other trees got merged into yours during the big
3.7-rc1 merge window.)
Other than that, nothing major, just a number of bugfixes and new
device ids. It turns out that almost all of the usb-serial drivers
had bugs in how they were handling their internal data, leaking
memory, hence all of those fixups.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'usb-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (42 commits)
USB: option: add more ZTE devices
USB: option: blacklist net interface on ZTE devices
usb: host: xhci: New system added for Compliance Mode Patch on SN65LVPE502CP
USB: io_ti: fix sysfs-attribute creation
USB: iuu_phoenix: fix sysfs-attribute creation
USB: spcp8x5: fix port-data memory leak
USB: ssu100: fix port-data memory leak
USB: ti_usb_3410_5052: fix port-data memory leak
USB: oti6858: fix port-data memory leak
USB: iuu_phoenix: fix port-data memory leak
USB: kl5kusb105: fix port-data memory leak
USB: io_ti: fix port-data memory leak
USB: keyspan_pda: fix port-data memory leak
USB: f81232: fix port-data memory leak
USB: io_edgeport: fix port-data memory leak
USB: kobil_sct: fix port-data memory leak
USB: cypress_m8: fix port-data memory leak
usb: acm: fix the computation of the number of data bits
usb: Missing dma_mask in ehci-vt8500.c when probed from device-tree
usb: Missing dma_mask in uhci-platform.c when probed from device-tree
...
ehci_fsl_setup_phy is supposed to return an int, but had a void return
value in the case of controller_ver being invalid.
Introduced by commit 3735ba8db8 ("powerpc/usb: fix bug of CPU hang
when missing USB PHY clock"), which missed one return.
Signed-off-by: Ben Collins <ben.c@servergy.com>
Cc: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Single-threaded forcewake was only used on some early pre-production
ivybridge machines, all the latest ones should use mt forcewake. And
we already assume this in other places of the code (e.g. DERRMR
support in the ddx, or the latest intel_gt_reset patch to reset any
lingering forcewake references left behind by the bios), so don't
bother here, too.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull media fixes from Mauro Carvalho Chehab:
"Media fixes for:
- one Kconfig fix patch;
- one patch fixing DocBook breakage due to the drivers/media UAPI
changes;
- the remaining UAPI media changes (DVB API).
I'm aware that is is a little late for the UAPI renames for the DVB
API, but IMHO, it is better to merge it for 3.7, due to two reasons:
1) There is a major rename at 3.7 (not only uapi changes, but also
the entire media drivers were reorganized on 3.7, in order to
simplify the Kconfig logic, and easy drivers selection, especially
for hybrid devices). By confining all those renames there at 3.7
it will cause all the harm at for media developers on just one
shot. Stable backports upstream and at distros will likely
welcome it as well, as they won't need to check what changed on
3.7 and what was postponed for on 3.8.
2) The V4L2 DocBook Makefile creates a cross-reference between the
media API headers and the specs. This helps us _a_lot_ to be sure
that all API improvements are properly documented. Every time a
header changes from one place to another, DocBook/media/Makefile
needs to be patched. Currently, the DocBook breakage patch
depends on the DVB UAPI."
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] Kconfig: Fix dependencies for driver autoselect options
DocBook/media/Makefile: Fix build due to uapi breakage
UAPI: (Scripted) Disintegrate include/linux/dvb
This is the final remaining piece of Haswell DP enablement. After this
patch, just calling intel_dp_init on any port will make DP work. We
still do not do this because we're currently initializing HDMI on all
the ports, so if we replace intel_hdmi_init with intel_dp_init, we
will break HDMI, and we can't call both because they share the same
registers.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
