- 05 Aug, 2013 14 commits
-
-
Jani Nikula authored
VLV wants encoder enabling before the pipe is up. This is currently achieved through calling the ->enable callback early, right after the ->pre_enable callback, in valleyview_crtc_enable(). This loses both the distinction between ->pre_enable and ->enable on VLV and the possibility to use a hook at the end of the modeset sequence. Rearrange the DP callbacks to make it possible to move ->enable call later. Basically do everything in ->pre_enable on VLV, and make ->enable a NOP. There should be no functional changes. v2: Rebase. v3: Explain why this is needed in the commit message (Chris). Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Otherwise we get flooded by the kernel warning us that we are doing long sequences of IO without serialisation. For example, WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef() Modules linked in: CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G W 3.11.0-rc2+ #4 Call Trace: [<c2028564>] ? warn_slowpath_common+0x63/0x78 [<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef [<c20285dd>] ? warn_slowpath_null+0xf/0x13 [<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef [<c227b060>] ? vlv_dpio_write+0x1c/0x21 [<c2262b3b>] ? intel_dp_set_signal_levels+0x24a/0x385 [<c2264909>] ? intel_dp_complete_link_train+0x25/0x1d1 [<c2264c55>] ? intel_dp_check_link_status+0xf7/0x106 [<c2238ced>] ? i915_hotplug_work_func+0x17b/0x221 [<c203a204>] ? process_one_work+0x12e/0x210 [<c203a5e4>] ? worker_thread+0x116/0x1ad [<c203a4ce>] ? rescuer_thread+0x1cb/0x1cb [<c203d8f5>] ? kthread+0x67/0x6c [<c2457ebb>] ? ret_from_kernel_thread+0x1b/0x30 [<c203d88e>] ? init_completion+0x18/0x18 v2: Retire the locking in vlv_crtc_enable() and do it close to the meat. Signed-off-by:
-
Jesse Barnes authored
Art confirms that this should work fine. Since most panels are 18bpp with dithering from 24bpp, the existing code wouldn't be enabled in most cases. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
SNB and IVB have slightly a different way to read out the watermark latency values. Signed-off-by:
-
Ville Syrjälä authored
The LP1+ watermark latency values need to be multiplied by 5 to make them suitable for watermark calculations. However on pre-HSW platforms we're going to need the raw value later when we have to write it to the WM_LPn registers' latency field. So delay the multiplication until it's needed. Note: Paulo complains that the units of wm (now in 100ns) aren't really clear and I agree. But that can be fixed later on ... Signed-off-by:
-
Ville Syrjälä authored
Move parsing of MCH_SSKPD to a separate function, we'll add other platforms there later. Note: Chris spotted an empty struct initializer and wondered whether that is hiding a compilier warning. Ville explained that it should have been part of the patch that extends this function to snb/ivb, which don't have all levels hsw has. I've figured it's ok to keep it here with a small note. Signed-off-by:
-
Ville Syrjälä authored
The latency values fit in uint16_t, so let's save a few bytes. Signed-off-by:
-
Ville Syrjälä authored
The FBC watermark doesn't depend on the latency value, so no point in passing it in. Note: It actually depends upon the latency, but only through priv_val ... Signed-off-by:
-
Ville Syrjälä authored
These functions are appropriate for everything since ILK. Signed-off-by:
-
Ville Syrjälä authored
hsw_wm_get_pixel_rate() isn't specific to HSW. In fact it should be made to handle all gens, but for now it depends on the PCH panel fitter state, so give it an ilk_ prefix. Signed-off-by:
-
Ville Syrjälä authored
Using the destination width in the sprite WM calculations isn't correct. We should be using the source width. Note: This doesn't affect hsw since it does not support sprite scaling. Signed-off-by:
-
Ville Syrjälä authored
Don't subtract one from the sprite width before watermark calculations. Signed-off-by:
-
Ville Syrjälä authored
For calculating watermarks we want to know whether sprites are scaled. Pass that information to update_sprite_watermarks() so that eventually we may do some watermark pre-computing. Signed-off-by:
-
Chris Wilson authored
Some of our macros we trying to convert from an drm_device to a drm_i915_private and then use the pointer inline. This is not only cumbersome but prone to error. Replacing it with a typesafe function should help catch those errors in future. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: Squash in fixup to correctly order static vs. inline qualifiers, static comes first. Also fix up another offender.] Signed-off-by:
-
- 04 Aug, 2013 17 commits
-
-
Stéphane Marchesin authored
Signed-off-by:
Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
-
Chris Wilson authored
The PTE layouts are the same for both ppgtt and gtt, so we can simplify the setup for ppgtt by copying the encoding function pointer from gtt. This prevents bugs where we update one function pointer, but forget the other. For instance, commit 4d15c145 Author: Ben Widawsky <ben@bwidawsk.net> Date: Thu Jul 4 11:02:06 2013 -0700 drm/i915: Use eLLC/LLC by default when available only extends the gtt to use eLLC/LLC cacheing and forgets to also update the ppgtt function pointer. v2: Actually mention the bug being fixed (Kenneth) Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Chris Wilson authored
Almost invariably the reason why FBC cannot be turned on is the same every time (disabled via parameter, too many pipes, pipe too large etc) as modesetting and framebuffer configuration changes less frequently than trying to enable FBC. Signed-off-by:
-
Daniel Vetter authored
In the old days of the crtc helpers we've only had the encoder and crtc ->mode_fixup callbacks. So when the lvds connector wanted to adjust the crtc timings it had to set a driver-private mode flag to tell the crtc mode fixup code to not overwrite them with the generic ones. When converting things to the new infrastructure I've kept the entire logic and only moved the flag to pipe_config->timings_set. But this logic is pretty tricky and already caused regressions: commit 21d8a475 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 12 08:07:30 2013 +0200 drm/i915: fix pfit regression for non-autoscaled resolutions So take advantage of the flexibility our own modeset infrastructure affords us and prefill default crtc timings. This allows us to rip out ->timings_set. Note that we overwrite things again when retrying the pipe config computation due to bandwidth constraints to avoid bogus crtc timings if the encoder only does relative adjustments (which is how the pfit code works). Only a theoretical concern though since platforms where we retry (pch-split platforms) do not need adjustements (since only the old gmch pfit needs that). But let's better be safe than sorry. Since we now initialize the crtc timings before calling the encoder->compute_config functions the crtc initialization in the gmch pfit code is now redudant and so can be removed. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add a paragraph to the commit message to explain why we can ditch the crtc timings initialization call from the gmch pfit code, to answer a question from Rodrigo's review.] Signed-off-by:
-
Daniel Vetter authored
The encoder->mode_set callback from the crtc helpers is now completely unused in our driver. Good riddance! Reviewed-by:
-
Daniel Vetter authored
Same conversion as for hdmi/dp. Reviewed-by:
-
Daniel Vetter authored
Does nothing, so trivial conversion. But update the outdated comment while at it. Reviewed-by:
-
Daniel Vetter authored
Usual drill applies. Again I've not switched the upcast helpers to use intel_encoder instead of drm_encoder since that's much more invasive and will change also the hdmi and ddi encoders. Reviewed-by:
-
Daniel Vetter authored
Again drop the intel_ prefix from the intel_crtc local variable to save a bit of space. But here I didn't switch the upcast macros to intel_encoder since all our infoframe interfaces still use drm_encoder. That needs to be changed first. Reviewed-by:
-
Daniel Vetter authored
Also drop the intel_ prefix from the local intel_crtc variable and reorder the upcast macros a bit for more reuse. Reviewed-by:
-
Daniel Vetter authored
Also switch to intel_encoder for the upcast helper while at it. Reviewed-by:
-
Daniel Vetter authored
It's what all callers (except for the destroy callback which is called from drm core) actually want. Reviewed-by:
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
Everyone is now using our own ->compute_config callback, which means we can now also make that callback mandatory. Reviewed-by:
-
Daniel Vetter authored
This is the last encoder ->mode_fixup callback we have left, so convert it. Note that we want to only rip out the encoder->mode_fixup callback. But we still have the dvo_slave->mode_fixup callback. dvo is gen2 only, so we won't ever touch this again. Hence why I didn't go through all 6-7 dvo slave drivers and give them the same treatment. I'll add a note to the commit message about this when merging, presuming there's nothing else in the patch that needs to be fixed up. Reviewed-by:
-
Daniel Vetter authored
More natural and will soon be even better! Reviewed-by:
-
Chris Wilson authored
Fixes regression from commit 4906557e Author: Rodrigo Vivi <rodrigo.vivi@gmail.com> Date: Thu Jul 11 18:45:05 2013 -0300 drm/i915: Hook PSR functionality Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67526Signed-off-by:
-
- 26 Jul, 2013 4 commits
-
-
Daniel Vetter authored
We need the correct clock to accurately assess whether we need to enable the double wide pipe mode or not. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: Stuart Abercrombie <sabercrombie@google.com> Reviewed-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
The w/a db makes the recommendation to both use a non-default value for the initial clock and then to retry with an alternative clock for Haswell with the Lakeport PCH. "On LPT:H, use a divider value of 63 decimal (03Fh). If there is a failure, retry at least three times with 63, then retry at least three times with 72 decimal (048h)." Signed-off-by:
-
Egbert Eich authored
For HPD storm detection we now mask out individual interrupt source bits. We have already seen a case where HPD interrupt enable bits were assigned to the wrong pins. To track these conditions more easily add some debugging messages. v2: Spelling fixes as suggested by Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Egbert Eich <eich@suse.de> Reviewed-by:
-
- 25 Jul, 2013 5 commits
-
-
Imre Deak authored
This fixes a typo which set the wrong vsync and possibly also hsync polarity for any modes with positive vsync polarity. Signed-off-by:
Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Daniel Vetter authored
Just use a spinlock to protect them. v2: Rebase onto the new object create refcount fix patch. v3: Don't kill dev_priv->mm.object_memory as requested by Chris and hence just use a spinlock instead of atomic_t. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
The TRACE_EVENT_CONDITION is supposed to generate more efficient code than if (cond) trace(), which is what we are currently using inside the register access functions. v2: Rebase onto uncore Signed-off-by:
-
Chris Wilson authored
The INTEL_INFO() macro extracts the dev_private pointer from the device, so passing in the dev_private->dev is a long winded circumlocution. v2: rebase onto uncore Signed-off-by:
-
Chris Wilson authored
Detangle the confusion that NOTRACE variants of the register read/write routines were directly using the raw register access. We need for those routines to reuse the common code for serializing register access and ensuring the correct register power states. This is only possible now that the only routines that required raw access use their own API. Signed-off-by:
-
