IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When crtc_funcs->dpms callback is called, exynos_crtc->dpms
and exynos_encoder->dpms are changed to new mode. But if user
requests dpms mode operation, OFF -> ON, when crtc's dpms callback
is called, exynos_encoder->dpms is also changed to ON. This
makes encoder's dpms callback call be ignored so display power
couldn't become on again.
This patch removes exynos_encoder->dpms changing and adds 'updated'
variable to exynos_drm_encoder structure to avoid duplicated overlay
updating.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Useful for places where a given chipset may or may not have a given
resource, and we want to avoid having to spray checks for the mm's
existance around everywhere.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Yuly Novikov <ynovikov@chromium.org>
[Jani: ripped this change separate from the scaling mode change support]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prepare for supporting scaling mode configuration also in eDP.
Includes a drive-by-removal of an outdated comment about fitting mode.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At some point the DPCD size was increased, but the debug print not. While
at it, switch to using hex dump.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like HSW, VLV does not have a sprite scale. Set
intel_plane->can_scale accordingly.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise we may remove the only console for a nomodeset system.
We became more aggressive in our kicking with
commit e188719a2891f01b3100dca4ae3a055fb5a7ab52
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jun 12 11:28:17 2012 +0200
drm/i915: kick any firmware framebuffers before claiming the gtt
Reported-and-tested-by: monnier@iro.umontreal.ca
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54615
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org # v3.6
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 28dcc2d60cb570d9f549c329b2f51400553412a1
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Sep 3 16:25:12 2012 +0300
drm/i915: do not expose a dysfunctional backlight interface to userspace
prevents backlight interface creation if the BIOS has not set the backlight
PWM CTL registers that contain the max PWM value. It's apparently normal on
those machines, so demote the message about it to debug level.
Reported-by: Orion Poplawski <orion@cora.nwra.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56330
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SDVOB may be multiplexed with HDMIB. If it's not SDVOB, the same i2c
adapter may be used for HDMIB, with the adjusted config (i.e. with GPIO
bit-banging instead of gmbus). Restore i2c adapter config before error
return from intel_sdvo_init(), letting HDMIB enjoy the joys of gmbus.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 63abf3edaf42d0b9f278df90fe41c7ed4796b6b1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Dec 8 16:48:21 2010 +0000
drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
added a default fallback if BIOS provides an invalid pin mapping, but
failed to force GPIO bit-banging on it. Finish the job, and also clean up
the function a bit. With bit-banging, setting the gmbus speed has no
effect, so drop it.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Extend comment about gmbus in the code a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that all the eDP enablement bits are there, we can actually try to
use the eDP.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's an important step :)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The cdclk frequency is not always the same, so the value here should
be adjusted to match it.
Version 2: call intel_ddi_get_cdclk_freq instead of reading
CDCLK_FREQ, because the register is just for earlier HW steppings.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
See the documentation for the DDI_FUNC_CTL register, EDP Input Select
bits: when the EDP input selection is B, the VTOTAL_B must be
programmed with the VTOTAL_EDP value, same thing for selection C.
V2: Use I915_READ as suggested by Daniel Vetter.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Same thing as the previous commits. Not renaming this one since it
exists since way before Haswell.
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>
Same as the other registers. This one also appeared on Haswell for the
first time, so that's why we are renaming it.
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>
Because the PIPECONF register is actually part of the CPU transcoder,
not the CPU pipe.
Ideally we would also rename PIPECONF to TRANSCONF to remind people
that they should use the transcoder instead of the pipe, but let's
keep it like this for now since most Gens still name it PIPECONF.
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>
We need to check if any of the pipes is using TRANSCODER_EDP.
V2: DDI_BUF_CTL was renamed, so fix the usage here.
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>
Because there's one instance of the register per CPU transcoder and
not per CPU pipe. This is another register that appeared for the first
time on Haswell, and even though its Haswell name is
PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's
just use the new naming scheme before it confuses more people.
Notice that there's a big improvement on intel_ddi_get_hw_state due to
the new TRANSCODER_EDP.
V2: Also rename the register to TRANS_DDI_FUNC_CTL as suggested by
Damien Lespiau.
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>
This register appeared in Haswell. It does not have an EDP version
because the EDP transcoder is always tied to the DDIA clock. Notice
that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder
is TRANSCODER_EDP we might introduce a bug, that's why this is a
transcoder register even though it does not have an EDP version.
Even though Haswell names this register PIPE_CLK_SEL, it will be
renamed to TRANS_CLK_SEL in the future, so let's just start using the
real name that makes more sense and avoids misusage.
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>
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>
Copy and paste typo in the apci rework.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=49351
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
When internal users want VRAM we shouldn't return GART memory instead.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Driver internal users shouldn't be limited in their allocation size.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When allocating more than 2GB of GART the array of pages
gets to big for kzalloc, use vzalloc instead.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
GART and VRAM size limits need to be a power of two.
Fix values greater than 1GB and simplify those checks a bit.
v2: also fix radeon_vram_limit usage, and simplify test even more.
v3: agd5f: fix spelling as noticed by Klaus Schnass
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Like in the case of native hdmi, which is fixed already in
commit adf00b26d18e1b3570451296e03bcb20e4798cdd
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Tue Sep 25 13:23:34 2012 -0300
drm/i915: make sure we write all the DIP data bytes
we need to clear the entire sdvo buffer to avoid upsetting the
display.
Since infoframe buffer writing is now a bit more elaborate, extract it
into it's own function. This will be useful if we ever get around to
properly update the ELD for sdvo. Also #define proper names for the
two buffer indexes with fixed usage.
v2: Cite the right commit above, spotted by Paulo Zanoni.
v3: I'm too stupid to paste the right commit.
v4: Ben Hutchings noticed that I've failed to handle an underflow in
my loop logic, breaking it for i >= length + 8. Since I've just lost C
programmer license, use his solution. Also, make the frustrated 0-base
buffer size a notch more clear.
Reported-and-tested-by: Jürg Billeter <j@bitron.ch>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Cc: stable@vger.kernel.org
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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 bfa3384a9a84aaaa59443bbd776c142e7dba4b0f
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 a60f0e38d72a5e24085d6e7e27a4cadc20ae268a
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>
