We need it in the fdi m_n computation, which nicely kills almost
all ugly special cases in there.
It looks like we also need this to handle 12bpc hdmi correctly.
Eventually it might be better to switch things around and put the
target clock into adjusted_mode->clock and create a new pipe_config
parameter for the port link clock.
v2: Add a massive comment in the code to explain this mess.
v3: s/dp_target_clock/pixel_target_clock in anticipation of the hdmi
use-case.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
without losing our sanity.
v2: Rebased on top of Takashi Iwai's fix to (again) fix the target
clock handling for eDP. Luckily the new code is sane enough and just
does the right thing!
v3: Move ->has_dp_encoder to this patch (Jesse).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the cpu transcoder.
To handle the pch vs transcoder stuff a bit better, extract transcoder
set_m_n helpers. To make them simpler, set intel_crtc->cpu_transcoder
als in ironlake_crtc_mode_set, so that gen5+ (where the cpu m_n
registers are all at the same offset) can use it.
Haswell modeset is decently confused about dp vs. edp vs. fdi. dp vs.
edp works exactly the same as dp (since there's no pch dp any more),
so use that as a check. And only set up the fdi m_n values if we
really have a pch encoder present (which means we have a VGA encoder).
On ilk+ we've called ironlake_set_m_n both for cpu_edp and for pch
encoders. Now that dp_set_m_n handles all dp links (thanks to the
pch encoder check), we can ditch the cpu_edp stuff from the
fdi_set_m_n function.
Since the dp_m_n values are not readily available, we need to
carefully coax the edp values out of the encoder. Hence we can't (yet)
kill this superflous complexity.
v2: Rebase on top of the ivb fdi B/C check patch - we need to properly
clear intel_crtc->fdi_lane, otherwise those checks will misfire.
v3: Rebased on top of a s/IS_HASWELL/HAS_DDI/ patch from Paulo Zanoni.
v4: Drop the addition of has_dp_encoder, it's in the wrong patch (Jesse).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRWLTrAAoJEHm+PkMAQRiGe8oH/iMy48mecVWvxVZn74Tx3Cef
xmW/PnAIj28EhSPqK49N/Ow6AfQToFKf7AP0ge20KAf5teTq95AY+tH74DAANt8F
BjKXXTZiR5xwBvRkq7CR5wDcCvEcBAAz8fgTEd6SEDB2d2VXFf5eKdKUqt1avTCh
Z6Hup5kuwX+ddtwY2DCBXtp2n6fL0Rm5yLzY1A3OOBye1E7VyLTF7M5BR603Q44P
4kRLxn8+R7jy3hTuZIhAeoS8TKUoBwVk7DmKxEzrhTHZVOmvwE9lEHybRnIyOpd/
k1JnbRbiPsLsCVFOn10SQkGDAIk00lro3tuWP2C1ljERiD/OOh5Ui9nXYAhMkbI=
=q15K
-----END PGP SIGNATURE-----
Merge tag 'v3.9-rc5' into drm-intel-next-queued
Backmerge Linux 3.9-rc5 since I want to merge a few dp clock cleanups
for -next, but they will conflict all over the place with
commit 9d1a455b0c
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Mar 18 11:25:36 2013 +0100
drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()
from -fixes.
Conflicts:
drivers/gpu/drm/i915/intel_dp.c: Simply adjacent lines changed.
drivers/gpu/drm/i915/intel_panel.c: A field rename in -next
conflicts with a bugfix in -fixes. Take the version from
-fixes and apply the rename.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The active output is only the currently selected one, which does not
imply that it's actually enabled. Since we don't use the sdvo encoder
side dpms support, we need to check whether the chip-side sdvo port is
enabled instead.
v2: Fix up Bugzilla links.
v3: Simplify logic a bit (Chris).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60138
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031
Cc: Egbert Eich <eich@pdx.freedesktop.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Egbert Eich <eich@pdx.freedesktop.org> (v2)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't need this until we start using the wait event commands.
v2: move to i915_irq.c (Jesse)
drop unneeded sprite flip done enables (Ville)
v3: drop the DPFLIPSTAT enables altogether (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Slightly different than other platforms.
v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
v3: drop turbo defines from this patch (Ville)
use PCI_DEVFN(2,0) instead of open coding (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Add checkpatch bikeshed about missing space.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Needed to handle pre/post enable/disable paths on VLV and avoid a few
fields that are marked reserved on VLV.
v2: don't set color range or DP PLL fields (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Need to make sure sprites are disabled before shutting off a pipe.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No constant alpha yet though, that needs a new ioctl and/or property to
get/set.
v2: use drm_plane_format_cpp (Ville)
fix up vlv_disable_plane, remove IVB bits (Ville)
remove error path rework (Ville)
fix component order confusion (Ville)
clean up platform init (Ville)
use compute_offset_xtiled (Ville)
v3: fix up more format confusion (Ville)
update to new page offset function (Ville)
v4: remove incorrect formats from framebuffer_init (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we couldn't find a pipe we shouldn't return true. This might be even
better as a WARN though, since it should be impossible to have the port
enabled without a pipe selected.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we couldn't find a pipe we shouldn't return true. This might be even
better as a WARN though, since it should be impossible to have the port
enabled without a pipe selected.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the clocks stabilise between each
stage. If we are not actually changing the clock sources, then we can
return early.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Appease checkpatch by deleting a space after a ~]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Earlier code would leave both bits set, so any reset after the first
would only reset media.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville pointed out that my assumption that no unsupported pixel format
can get past the pipe config computation stage to the platform
update_plane callbacks is wrong. The reason is that this function
still checks the old fb->depth value instead of the new pixel_format.
While checking with all the other places that use this I've noticed
that intel_framebuffer_init already has all the platform checks we
need, so replace those checks with a WARN_ON.
Since fb->depth isn't set for YUV pixel formats and since we already
can't create an fb with an rgb layout not support on the running
platform I /think/ this patch doesn't fix any bug.
But it surely looks better!
v2: BGR formats are also only gen4+, so add the corresponding WARN_ON,
too (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've mostly switched over to the new more flexible schema, but
there's one check left in the modeset code.
Motivated by a question from Ville whether there's really no way an
unsupported pixel_format can escape into our platform update_plane
callbacks.
v2: Ville noticed that the fb->depth check is redudant when we already
check fb->pixel_format.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As Thomas Gleixner spotted, it's rather horrible racy:
- We can miss almost a full tick, so need to compensate by 1 jiffy.
- We need to re-check the condition when having timed-out, since a
the last check could have been before the timeout expired. E.g. when
we've been preempted or a long irq happened.
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Jack Winter <jbh@alchemy.lu>
Cc: Jack Winter <jbh@alchemy.lu>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since
commit bcf9dcc1e6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Jul 15 09:42:38 2012 +0100
drm/i915: Workaround hang with BSD and forcewake on SandyBridge
and
commit 0cc2764cc4
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Sat Sep 1 22:59:48 2012 -0700
drm/i915: use cpu_relax() in wait_for_atomic
these two macros are essentially the same, so unify them. We keep the
_us version since it's a nice documentation for smaller timeouts.
v2: Fixup time unit conversion, _wait_for takes ms (Ville).
Cc: Jack Winter <jbh@alchemy.lu>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- It's a static function
- I just added a few more users to it
- Its sister ironlake_enable_display_irq is not marked as inline
- The compiler will still inline if it thinks it should do
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- gen4 and earlier (save for g4x) only really have a 8bpc pipe, with
the possibility to dither to 6bpc using the panel fitter
- g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly.
- TV/SDVO out are the only connectors available on platforms with
a pipe bpp != 8, add code to force the pipe to 8bpc unconditionally.
<rant>
The dither handling on gmch platforms is one giant disaster. I'm hoping
somewhat that vlv enabling will fix this up, but given that the 6bpc
handling for edp was simply added with another quick hack, I don't have
high hopes ...
</rant>
v2: Neither vlv nor g4x have 12bpc pipes. Still set pipe_bpp to 12*3,
but let the crtc code clamp things down to 10bpc on these platforms.
v3: Fix a bpc vs. bpp mixup in the gen4 and earlier pipe_bpp limiter
code.
v4: Drop the hunk in intel_hdmi.c about g4x/vlv 12bpc, it was wrong.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc
float layout, but we don't really support it.
- 10bpc is a gen4+ feature, fix up the support for it.
- Update_plane should never see a wrong fb bpp value, BUG in the
corresponding cases.
v2: Rebase on top of Ville's plane pixel layout changes.
v3: Actually drop the old gen4 check for 10bpc planes, spotted
by Ville Syrjälä.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The old code only handled either 6bpc or 8bpc. Since it's easy to do,
reorganize the code to be a bit more generic so that it can also handle
10bpc and 12bpc. Note that we still start with 8bpc, so there's no
functional change.
Also, since we no don't need to compute the 6BPC flag in the mode_valid
callback, we can consolidate things a bit. That requires though that
the link bw computation is moved up in the compute_config callback.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
computed pipe_bpp.
There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
a 2nd change we now unconditionally force the lvds bpc value - this
shouldn't matter in reality when the panel setup is consistent, but
better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
what we actually want, since otherwise at least the pixelclock
computations are wrong (I'm not sure whether the port would accept
e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
the next higher bpc value, since otherwise there's no way to make
use of the 12 bpc mode (since the next patch will remove the 12bpc
plane format, it doesn't exist).
Both of these changes are due to the removal of the
pipe_bpp = min(display_bpp, plane_bpp);
statement.
Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
all available bpp values in an outer loop and the codeblock that
computes derived values (once a good configuration is found) has been
moved out of the for loop maze. This is prep work to allow us to
successively fall back on bpc values, and also correctly support bpc
values != 8 or 6.
v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.
v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.
v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.
v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.
v6: Fix spelling in a comment.
v7: Debug output improvements for the bpp computation.
v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!
v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.
v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.
v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.
v12: Rebased.
v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.
v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to compute this earlier. To avoid a big complicated patch,
this patch here just does the big search&replace and still calls the
old functions at the same places.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we have a useful struct for this, let's use it. Some neat
pointer-chasing required, but it's all there already.
v2: Rebased on top of the added Haswell limited color range support.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is used way too often in the enable/disable paths. And will
be even more useful in the future.
Note that correct semantics of this change highly depend upon
correct updating of intel_crtc->config: Like with all other
modeset state, we need to call ->disable with the old config,
but ->mode_set and ->enable with the new config.
v2: Do not yet use the flag in the ->disable callbacks - atm we don't
yet have support for the information stored in the pipe_config in the
hw state readout code, so this will be wrong at boot-up/resume.
v3: Rebased on top of the hdmi/dp ddi encoder merging.
v4: Fixup stupid rebase error which lead to a NULL vfunc deref.
v5: On haswell the VGA port is on the PCH!
v6: s/IS_HASWELL/HAS_DDI/, spotted by Paulo Zanoni. Also add a missing
parameter name in a function declaration.
v7: Don't forget to git add ...
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Completely unused by now. Separate patch in case I've missed a
place somewhere which dereferences the helper vtable but actually
shouldn't do so.
v2: Resolve rebase conflict with Egbert Eich's hpd infrastructure
rework.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Used by SDVO (and hopefully, eventually HDMI, if we ever get around
to fixing up the low dotclock CEA modes ...).
This required adding a new encoder->mode_set callback to be able to
pass around the intel_crtc_config.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only used by the lvds encoder. Note that we shouldn't do the same
simple conversion with the FORCE_6BPC flag, since that's much better
handled by moving all the pipe_bpc computation around.
This requires that we pass the pipe config around to encoders, so
that they can set special attributes and set constraints. To do so
introduce a new ->compute_config encoder callback, which is called in
stead of the drm crtc helper's ->mode_fixup.
To avoid massive churn all over the codebase we don't want to convert
all existing ->mode_fixup functions. Instead I've opted to convert
them on an as-needed basis (mostly to cut down on rebase conflicts and
to have more freedom to experiment around while developing the
patches).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To make decent modeset state checking possible (e.g. for the check
mode with atomic modesetting) we want to have the full pipe
configuration and state checks done before we touch the hw.
To ensure that all the little bits&pieces that are now moved to the
pipe_config handle this correctly, move its computation to the right
spot now, before we touch the hw in the disable_pipes step.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently only containing the requested and the adjusted mode. And
only crtc callbacks are converted somewhat to it, encoders will be
done on a as-needed basis (simply too much churn in one patch
otherwise).
Future patches will add tons more useful stuff to this struct,
starting with the very simple.
v2: Store the pipe_config in the intel_crtc, so that the ->mode-set,
->enable and also ->disable have easy access to it.
v3: Store the pipe config in the right crtc ...
v4: Rebased.
v5: Fixup an OOPS when trying to kfree an ERR_PTR.
v6: Used drm_moode_copy and some other small cleanups as suggested
by Ville Syrjälä.
v7: drm_mode_copy preserves the mode id of the destination, so no need
to clear it again (Ville).
v8: Break a long line spotted by Paulo.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The backlight device .get_brightness callback is supposed to return the
actual brightness by querying the hardware, not the cached value. See
Documentation/ABI/stable/sysfs-class-backlight. The callback is there to
support the actual_brightness sysfs file.
With the backlight_level and backlight device brightness now in sync, one
can reliably get the cached value through the brightness sysfs file.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A single point of truth would be better than two, but achieving that would
require more abstractions for CONFIG_BACKLIGHT_CLASS_DEVICE=n with not a
whole lot of real benefits. Take the short route and just keep the
backlight levels in sync. In particular, update backlight device brightness
on opregion brightness changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now with Egbert Eich's hpd infrastructure rework merged this is dead
simple. And we need this to make output detection work on SDVO - with
the cleaned-up drm polling helpers outputs which claim to have hpd
support are no longer polled.
Now SDVO claims to do that, but it's not actually wired up. So just do
it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When disabling a sprite, wait for the sprite to stop fetching data
from memory before unpinning the fb.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Noticed while reviewing the hotplug irq setup code. Just looks better.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since for_each_sg_page supports already memory w/o backing pages we can
revert the corresponding workaround.
This reverts commit 5bd4687e57.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The i915 driver uses sg lists for memory without backing 'struct page'
pages, similarly to other IO memory regions, setting only the DMA
address for these. It does this, so that it can program the HW MMU
tables in a uniform way both for sg lists with and without backing pages.
Without a valid page pointer we can't call nth_page to get the current
page in __sg_page_iter_next, so add a helper that relevant users can
call separately. Also add a helper to get the DMA address of the current
page (idea from Daniel).
Convert all places in i915, to use the new API.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From the w/a database:
'To prevent false VT-d type 6 error:
The primary display plane must be 256KiB aligned, and require an extra
128 PTEs of padding afterward;
The sprites planes must be 128KiB aligned, and require an extra 64 PTEs
of padding afterward;
The cursors must be 64KiB aligned, and require an extra 2 PTEs of
padding afterward.'
As we use the same function to pin the primary and sprite planes, we can
simply use the more strict requirements for scanouts for both.
Instead of using explicit padding PTEs following the scanout objects, we
should be able to use the scratch page that is always mapped into the
unused PTEs to avoid the VT-d error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=59626
References: https://bugs.freedesktop.org/show_bug.cgi?id=59627
References: https://bugs.freedesktop.org/show_bug.cgi?id=59631
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Apply s/vtd_wa/vtd_scanout_wa/ bikeshed since Damien likes
it, too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now since we have replaced the bits to show interest in hotplug IRQs
we can go and nuke the 'hotplug_supported_mask'.
Signed-off-by: Egbert Eich <eich@suse.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After
"Convert HPD interrupts to make use of HPD pin assignment in encoders."
This function is now basically the same as i915_hpd_irq_setup().
Consolidating both functions in one requires one more check for
I915_HAS_HOTPLUG(dev) in the i965 code path and one more check for
IS_G4X(dev) in the i915 code path. These are considered harmless.
Signed-off-by: Egbert Eich <eich@suse.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup patch conflict and make it compile.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a regression introduced in
commit e5868a318d
Author: Egbert Eich <eich@suse.de>
Date: Thu Feb 28 04:17:12 2013 -0500
DRM/i915: Convert HPD interrupts to make use of HPD pin assignment in encode
Due to the irq setup rework in 3.9, see
commit 20afbda209
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Dec 11 14:05:07 2012 +0100
drm/i915: Fixup hpd irq register setup ordering
Egbert Eich's hpd rework blows up on pch-split platforms - it walks
the encoder list before that has been set up completely. The new init
sequence is:
1. irq enabling
2. modeset init
3. hpd setup
We need to move around the ibx setup a bit to fix this.
Ville Syrjälä pointed out in his review that we can't touch SDEIER
after the interrupt handler is set up, since that'll race with Paulo
Zanoni's PCH interrupt race fix:
commit 44498aea29
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Feb 22 17:05:28 2013 -0300
drm/i915: also disable south interrupts when handling them
We fix that by unconditionally enabling all interrupts in SDEIER, but
masking them as-needed in SDEIMR. Since only the single-threaded
setup/teardown (or suspend/resume) code touches that, no further
locking is required.
While at it also simplify the mask handling - we start out with all
interrupts cleared in the postinstall hook, and never enable a hpd
interrupt before hpd_irq_setup is called.
And finally, for consistency rename the ibx hpd setup function to
ibx_hpd_irq_setup.
v2: Fix race around SDEIER writes (Ville).
v3: Remove the superflous posting read for SDEIER, spotted by Ville.
Ville also wondered whether we shouldn't clear SDEIIR, since now
SDE interrupts are enabled before we have an irq handler installed.
But the master interrupt control bit in DEIER is still cleared, so we
should be fine.
Cc: Egbert Eich <eich@suse.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62798
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows to enable HPD interrupts for individual pins to only receive
hotplug events from lines which are connected and working.
v2: Restructured initailization of const arrays following a suggstion
by Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Egbert Eich <eich@suse.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To clean up hotplug support we add a new enum to intel_encoder:
enum hpd_pin. It allows the encoder to request a hpd line but leave
the details which IRQ is responsible on which chipset generation
to i915_irq.c.
This way requesting hotplug support will become really simple on
the encoder/connector level.
Signed-off-by: Egbert Eich <eich@suse.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will poke userspace into probing for configuration changes that may
have occurred across suspend/resume.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the other bits in place, we can do this safely.
v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Needed for VT switchless resume.
v2: cursor state is now handled correctly in crtc_enable (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To be used to restore sprite state on resume.
v2: move sprite tracking bits up so we don't track modified sprite state
v3: use src_x/y in sprite suspend/resume code (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than building a config which may or may not work, let the driver
build an initial fb config. This allows the driver to use the BIOS boot
configuration for example, displaying kernel messages and the initial fb
console on the same outputs the BIOS lit up at boot time. If that
fails, the driver can still fall back the same way as the core.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wrap a preallocated region of stolen memory within an ordinary GEM
object, for example the BIOS framebuffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is a minute window for a race between put-fence removing the fence
and for a new transaction by an external party on the GTT mmap. That is
we must zap the mmap prior to removing the fence and not afterwards.
Fixes regression from
commit 61050808bb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 17 15:31:31 2012 +0100
drm/i915: Refactor put_fence() to use the common fence writing routine
v2: Remember the fence to remove with a local variable (gcc)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to HSW PM programming guide, frequency bits starts at
24 instead of 25.
v2: Paulo Zanoni noticed that only frequency bits can be set at
GEN6_RPNSWREQ. All others are read only.
CC: Ben Widawsky <ben@bwidawsk.net>
CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If TRANS_DDI_FUNC_CTL has been wrongly programmed with an incorrect
port, we are currently trying to read PORT_CLK_SEL(port) with an
uninitialized value.
Handle that case by returning PORT_CLK_SEL_NONE and warning about it.
v2: Move the warning inside intel_ddi_get_crtc_pll (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>
HSW doesn't overclock the same way as IVB or SNB. I do not know about
VLV, so I've kept that off as well. I'm still working on getting the doc
updates to explain how we overclock on Haswell.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add missing () spotted by Wu Fengguang's kernel build robot.
Acked by Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
"Just three revert/disable by default patches, one of them cc: stable
(since the offending commit was cc: stable, too)."
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
Revert "drm/i915: write backlight harder"
drm/i915: don't disable the power well yet
Revert "drm/i915: set TRANSCODER_EDP even earlier"
Inki writes:
Includes bug fixes and code cleanups.
And it considers some restrictions to G2D hardware.
With this, the malfunction and page fault issues to g2d driver
would be fixed.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: Check g2d cmd list for g2d restrictions
drm/exynos: Add a new function to get gem buffer size
drm/exynos: Deal with g2d buffer info more efficiently
drm/exynos: Clean up some G2D codes for readability
drm/exynos: Fix G2D core malfunctioning issue
drm/exynos: clear node object type at gem unmap
drm/exynos: Fix error routine to getting dma addr.
drm/exynos: Replaced kzalloc & memcpy with kmemdup
drm/exynos: fimd: calculate the correct address offset
drm/exynos: Make mixer_check_timing static
drm/exynos: modify the compatible string for exynos fimd
This reverts commit cf0a6584aa.
Turns out that cargo-culting breaks systems. Note that we can't revert
further, since
commit 770c12312a
Author: Takashi Iwai <tiwai@suse.de>
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening lid
fixed a regression in 3.6-rc kernels for which we've never figured out
the exact root cause. But some further inspection of the backlight
code reveals that it's seriously lacking locking. And especially the
asle backlight update is know to get fired (through some smm magic)
when writing specific backlight control registers. So the possibility
of suffering from races is rather real.
Until those races are fixed I don't think it makes sense to try
further hacks. Which sucks a bit, but sometimes that's how it is :(
References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org (the reverted commit was cc: stable, too)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're still not 100% ready to disable the power well, so don't disable
it for now. When we disable it we break the audio driver (because some
of the audio registers are on the power well) and machines with eDP on
port D (because it doesn't use TRANSCODER_EDP).
Also, instead of just reverting the code, add a Kernel option to let
us disable it if we want. This will allow us to keep developing and
testing the feature while it's not enabled.
This fixes problems caused by the following commit:
commit d6dd9eb1d9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jan 29 16:35:20 2013 -0200
drm/i915: dynamic Haswell display power well support
References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit cc464b2a17.
The reason is that Takashi Iwai reported a regression bisected to this
commit:
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
His machine has eDP on port D (usual desktop all-in-on setup), which
intel_dp.c identifies as an eDP panel, but the hsw ddi code
mishandles.
Closer inspection of the code reveals that haswell_crtc_mode_set also
checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell
that doesn't make much sense (since there's no edp on the pch), but
what this function _really_ checks is whether that edp connector is on
port A or port D. It's just that on ilk-ivb port D was on the pch ...
So that explains why this seemingly innocent change killed eDP on port
D. Furthermore it looks like everything else accidentally works, since
we've never enabled eDP on port D support for hsw intentionally (e.g.
we still register the HDMI output for port D in that case).
But in retrospective I also don't like that this leaks highly platform
specific details into common code, and the reason is that the drm
vblank layer sucks. So instead I think we should:
- move the cpu_transcoder into the dynamic pipe_config tracking (once
that's merged).
- fix up the drm vblank layer to finally deal with kms crtc objects
instead of int pipes.
v2: Pimp commit message with the better diagnosis as discussed with
Paulo on irc.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When KMS has parsed an EDID "detailed timing", it leaves the frame rate
zeroed. Consecutive (debug-) output of that mode thus yields 0 for
vsync. This simple fix also speeds up future invocations of
drm_mode_vrefresh().
While it is debatable whether this qualifies as a -stable fix I'd apply
it for consistency's sake; drm_helper_probe_single_connector_modes()
does the same thing already for all probed modes.
Cc: stable@vger.kernel.org
Signed-off-by: Torsten Duwe <duwe@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
EDID spreads some values across multiple bytes; bit-fiddling is needed
to retrieve these. The current code to parse "detailed timings" has a
cut&paste error that results in a vsync offset of at most 15 lines
instead of 63.
See
http://en.wikipedia.org/wiki/EDID
and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why
that needs to be a left shift.
Cc: stable@vger.kernel.org
Signed-off-by: Torsten Duwe <duwe@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
So don't read it when capturing the error state. This solves
"unclaimed register" messages on Haswell when we have a GPU hang.
V2: Check for HAS_PCH_SPLIT instead of Gen5+ because VLV still has
this register.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't read it when capturing the error state. This solves some
"unclaimed register" messages on Haswell when we hang the GPU.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The first version of commit "drm/i915: there's no DSPADDR register on
Haswell" added 2 "!IS_HASWELL" checks. When reviewing the patch, Ben
suggested to make these checks more future-proof, so when Daniel
applied the patch he fixed the first check but not the second. This
commit makes the second check also "future-proof".
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The port number should always be correctly set. Do the same thing as the
switch above and use BUG() to signal that branch is not supposed to be
taken.
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>
We are really talking about the transcoder function here and the disable
version uses trancoder in its name already, so let's try to be
consistent.
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>
In the case where the hardware has been wrongly programmed and the EDP
TRANS_DDI_FUNC_CTL register has a bogus value in its EDP Input field, we
were using the pipe variable uninitialized.
In this case, shutdown the transcoder. It will be programmed correctly
the next time we try to enabled eDP.
Note from Paulo's review: Wrong modeset sequence can easily lead to
frozen machines hence the disable_ddi call might be risky. But since
things are awry already, doesn't matter too much.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add note about Paulo's caution about potential hangs.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our static analysis tool noticed that 'reg' could be used uninitialized if
we are trying to get a PLL to drive VGA and SPLL is already in use
(plls->spll_refcoung != 0).
In the (error) case above, let's return false to the caller and emit an
error.
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>
Bspec mentions this for HSW+. I can't quite tell what the effects are,
and I don't easily have a way to test this.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We do this for HDMI already, so I don't know why we wouldn't do
it for SDVO as well.
This is completely untested due to lack of hardware.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This comment looks like some historical leftover. Get rid of it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Change the gen6+ max delay if the pcode read was successful (not the
inverse).
The previous code was all sorts of wrong and has existed since I broke
it:
commit 42c0526c93
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Wed Sep 26 10:34:00 2012 -0700
drm/i915: Extract PCU communication
I added some parentheses for clarity, and I also corrected the debug
message message to use the mask (wrong before I came along) and added a
print to show the value we're changing from.
Looking over the code, I'm not actually sure what we're trying to do. I
introduced the bug simply by extracting the function not implementing
anything new. We already set max_delay based on the capabilities
register (which is what we use elsewhere to determine min and max).
This would potentially increase it, I suppose? Jesse, I can't find the
document which explains the definitions of the pcode commands, maybe you
have it around.
Based on Jesse's response, this could potentially be for -fixes, or
stable, or maybe lead to us dropping it entirely. As the current code is
is, things won't completely break because of the aforementioned
capabilities register, and in my experimentation, enabling this has no
effect, it goes from 1100->1100.
I found this while reviewing Jesse's VLV patches.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Bikeshed-away the redudant parens spotted by Chris Wilson.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Recommended by Chris.
v2: Make it GEN7_FEATURES, and use it for vlv and hsw also (Ben)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The index variable points at a page table, not a page directory or a
pde. Ben Widawsky fix this up correctly in his ppgtt cleanup, but I've
botched the job and copy&pasted the old confusion from the original
gen6 ppgtt code in
commit def886c376
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jan 24 14:44:56 2013 -0800
drm/i915: vfuncs for ppgtt
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Port C is for eDP. Port B is shared between HDMI and DP.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We'll re-enable select bits as needed after testing and power measurement.
v2: split out wake handling bits (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Can prevent a hang when we get to tessellation. We need to set bit 15
as well for this workaround.
v2: update changelog with accurate info
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes up broken logic introduced in
commit 90b107c8f7
Author: Shobhit Kumar <shobhit.kumar@intel.com>
Date: Wed Mar 28 13:39:32 2012 -0700
drm/i915: Enable HDMI on ValleyView
That one was probably a rebase fail along the way.
v2: clean up init ordering (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Pimp commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We could split this out into a separate routine at some point as an
optimization.
v2: use FORCEWAKE_KERNEL (Ville)
Note: Ville mentioned in his review that he declines to be responsible
if this blows up due to the lack of "readback a register != FW_ACK,
but from the same cacheline" magic we have in other forcewake
implementations.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Bikeshed overtly long lines according to checkpatch.pl. Nope,
this time around I didn't screw up printk message since I've left
those alone.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Planes are fixed to pipes in VLV.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
creating SG table for the buffers having more than 204 physical pages i.e.
equal to SG_MAX_SINGLE_ALLOC.
When using sg_alloc_table_from_pages interface, in place of sg_alloc_table,
page list will be passes to get each contiguous section which is represented
by a single entry in the table. For a Contiguous Buffer, number of entries
should be equal to 1.
Following check is causing the failure which is not applicable for Non-Contig
buffers:
if (WARN_ON_ONCE(nents > max_ents))
return -EINVAL;
Above patch is well tested for EXYNOS4 and EXYNOS5 for with/wihtout IOMMU
supprot. NOUVEAU and RADEON platforms also depends on drm_prime_pages_to_sg
helper function.
This set is base on "exynos-drm-fixes" branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The existing gtt setup code is correct - and so doesn't need to be fixed to
handle compact dma scatter lists similarly to the previous patches. Still,
take the for_each_sg_page macro into use, to get somewhat simpler code.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far we created a sparse dma scatter list for gem objects, where each
scatter list entry represented only a single page. In the future we'll
have to handle compact scatter lists too where each entry can consist of
multiple pages, for example for objects imported through PRIME.
The previous patches have already fixed up all other places where the
i915 driver _walked_ these lists. Here we have the corresponding fix to
_create_ compact lists. It's not a performance or memory footprint
improvement, but it helps to better exercise the new logic.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far the assumption was that each dma scatter list entry contains only
a single page. This might not hold in the future, when we'll introduce
compact scatter lists, so prepare for this everywhere in the i915 code
where we walk such a list.
We'll fix the place _creating_ these lists separately in the next patch
to help the reviewing/bisectability.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is needed since currently sg_for_each_page assumes that we have
a valid page in each sg item. It is only a real problem for
CONFIG_SPARSEMEM where the page is dereferenced, in other cases the
iterator works ok with an invalid page pointer.
We can remove this workaround when we have fixed sg_page_iter to work on
scatterlists without backing pages.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Daniel writes:
Bunch of fixes, all pretty high-priority
- Fix execbuf argument checking (Kees Cook)
- Optionally obfuscate kernel addresses in dumps (Kees Cook)
- Two patches from Takashi Iwai to fix DP link training regressions he's
seen.
- intel-gfx is no longer subscribers-only (well, just no longer moderated
in an annoying way for non-subscribers), update MAINTAINERS
- gm45 gmbus irq fallout fix (Jiri Kosina)
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: stop using GMBUS IRQs on Gen4 chips
MAINTAINERS: intel-gfx is no longer subscribers-only
drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()
Revert "drm/i915: try to train DP even harder"
drm/i915: bounds check execbuffer relocation count
drm/i915: restrict kernel address leak in debugfs
While testing the mgag200 kms driver on the HP ProLiant Gen8, a
bug was seen. Once the bootloader would load the selected kernel,
the screen would go black. At first it was assumed that the
mgag200 kms driver was hanging. But after setting up the grub
serial output, it was seen that the driver was being loaded
properly. After trying serval monitors, one finaly displayed
the message "Frequency Out of Range". By comparing the kms pll
algorithm with the previous mgag200 xorg driver pll algorithm,
discrepencies were found. Once the kms pll algorithm was
modified, the expected pll values were produced. This fix was
tested on several monitors of varying native resolutions.
Signed-off-by: Julia Lemire <jlemire@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch checks command list from user for g2d restrictions.
For now, g2d driver wasn't considered for G2D hardware restrictions
properly. The below is the restrictions to G2D hardware and this patch
considers them.
- width or height value in the command list
has to be in valid range (1 to 8000 pixels)
- The requested area should be less than buffer size.
- right has to be bigger than left.
- bottom has to be bigger than top.
Changelog v2:
- Fix merge conflict.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch adds a new function to get gem buffer size. And this
funtion could be used for g2d driver or others can get gem buffer
size to check if the buffer is valid or not.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <inki.dae@samsung.com>
This patch adds g2d_buf_info structure and buffer relevant
variables moves into the g2d_buf_info to manage g2d buffer
information more efficiently.
Changelog v2:
- Fix merge conflict.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch just cleans up G2D codes for readability.
For this, it changes the member of g2d_cmdlist_node, obj_type into
buf_type.
Changelog v2:
- Revert irrelevant codes.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch fixes G2D core malfunctioning issue once g2d dma is started.
Without 'DMA_HOLD_CMD_REG' register setting, there is only one interrupt
after the execution to all command lists have been completed. And that
induces watchdog. So this patch sets 'LIST_HOLD' command to the register
so that command execution interrupt can be occured whenever each command
list execution is finished.
Changelog v2:
- Consider for interrupt setup to each command list and all command lists
And correct typo.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch clears node object type in G2D unmap cmdlist.
The obj_type of cmdlist node has to be cleared in
g2d_unmap_cmdlist_gem() so that the node can be reused
in g2d_map_cmdlist_gem().
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
