- 10 Jun, 2013 2 commits
-
-
Damien Lespiau authored
This makes, arguably, the condition on state easier to read. Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
The hotplug_mask is no longer used as the hpd interrupt setup is now handled in the core. Signed-off-by:
-
- 07 Jun, 2013 8 commits
-
-
Ville Syrjälä authored
Don't enable the cursor until g4x_fixup_plane() had a chance to do cast its magic spell. Egbert writes: "Today I had the chance to test this. First I tried if I can still reproduce the blank with this patch added when I disable my voodoo g4x_fixup_plane(): It turned out it still happens however very rarely (like 1 out of 20 tries). When I reenabled my voodoo the issue still occurred. I had to switch two lines around, ie: intel_enable_plane(dev_priv, plane, pipe); if (IS_G4X(dev)) g4x_fixup_plane(dev_priv, pipe); + intel_crtc_update_cursor(crtc, true); to avoid the blank screen issue - which is it didn't happen in ~75 tries." v2: Add a comment to remind people of the ordering constraints Acked-by:Egbert Eich <eich@suse.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
WaFbcNukeOn3DBlt for IVB, HSW. According BSPec: "Workaround: Do not enable Render Command Streamer tracking for FBC. Instead insert a LRI to address 0x50380 with data 0x00000004 after the PIPE_CONTROL that follows each render submission." v2: Chris noticed that flush_domains check was missing here and also suggested to do LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets use the module parameter check. v3: Adding Wa name as Damien suggested. v4: Ville noticed VLV doesn't support fbc at all and comment came wrong from spec. v5: Ville noticed than on blt a Cache Clean LRI should be used instead the Nuke one. v6: Check for flush domain on blt (by Ville). Check for scanout dirty (by Chris). v7: Apply proper fbc_dirty implemented by Chris. v8: remove unused variables. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Chris Wilson authored
This is required for tracking render damage for use with FBC and will be used in subsequent patches. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to disable trickle feed for all primary planes into a separate function. Signed-off-by:
-
Ville Syrjälä authored
We disable trickle feed in all the (relevant) clock gating functions, except ironlake_init_clock_gating(). Copy paste the same code there as well. Signed-off-by:
-
Ville Syrjälä authored
According to BSpec, trickle feed should be disabled for BW and mobile CL. Those constraints seem to match all of our gen4 chipsets. Trickle feed is disabled via the MI_ARB_STATE register instead of per plane controls on gen4. Reviewed-by:
-
Ville Syrjälä authored
The docs say that the trickle feed disable bit is present (for primary planes only, not video sprites) on CTG, and that it must be set for ELK. Just set it for all g4x chipsets. v2: Do it in init_clock_gating too Reviewed-by:
-
Daniel Vetter authored
We always limited the link bw calculations to 24bpp. Tested with my shiny new high-bpc screen, seems to work as advertised. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65280Tested-by:
shui yangwei <yangweix.shui@intel.com> Reviewed-by:
-
- 06 Jun, 2013 19 commits
-
-
Daniel Vetter authored
For various reasons the hw state readout might not be able to faithfully match the hw state: - broken hw (like the case which motivated this patch here where the sdvo encoder does not implemented mandatory functionality correctly). - platforms which are not supported fully with the pipe config infrastructure - if our code doesn't support a given hw configuration natively, e.g. special restrictions on the per-pipe panel fitters when they're used in high-quality scaling modes. In all these cases both fastboot and the hw state cross checker need to be aware of these cases and act accordingly. To be able to do this add a new quirk flag to the pipe config structure. The specific case at hand is an sdvo encoder which doesn't implement the get_timings function, so adjusted_mode flags will be wrong. The strange thing though is that the encoder _does_ work, even though it doesn't implement any of the timings functions (so neither get nor set, neither for input nor output timings). Not that non-compliant sdvo encoder are any surprise at all ... v2: - Don't read random garbage from the dtd if the get_timings call failed (suggested by Chris). - Still check the interlaced flag, that's read out from someplace else. We want maximal paranoia, after all. Reviewed-by:
-
Wang Xingchao authored
Haswell Display audio depends on power well in graphic side, it should request power well before use it and release power well after use. I915 will not shutdown power well if it detects audio is using. This patch protects display audio crash for Intel Haswell C3 stepping board. Signed-off-by:
Wang Xingchao <xingchao.wang@linux.intel.com> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Wang Xingchao authored
For Intel Haswell chip, HDA controller and codec have power well dependency from GPU side. This patch added support to request/release power well in audio driver. Power save feature should be enabled to get runtime power saving. There's deadlock when request_module(i915) in azx_probe. It looks like: device_lock(audio pci device) -> azx_probe -> module_request (or symbol_request) -> modprobe (userspace) -> i915 init -> drm_pci_init -> pci_register_driver -> bus_add_driver -> driver_attach -> which in turn tries all locks on pci bus, and when it tries the one on the audio device, it will deadlock. This patch introduce a work to store remaining probe stuff, and let request_module run in safe work context. Signed-off-by:
Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Takashi Iwai authored
This is a preliminary work for the upcoming Haswell HDMI audio fixes. azx_first_init() function can be safely called after the f/w loader, since the f/w loader doesn't require the sound hardware initialization beforehand. Moving it into azx_probe_continue() cleans up the code flow a bit. Signed-off-by:
-
Wang Xingchao authored
The device can support runtime PM no matter whether it support signal wakeup or not. For some chips like Haswell which doesnot support PME by default, this patch let haswell Display HD-A controller enter runtime suspend, and bring more power saving whith power-well feature enabled. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Paulo Zanoni authored
CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but without proper front buffer invalidation on the last 2k lines, so don't enable FBC on these cases for now. v2: Use gen >= 5, not gen > 4 (Daniel). Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniel Vetter authored
Incomplete since ilk+ support needs proper pch dpll tracking first. SDVO get_config parts based on a patch from Jesse Barnes, but fixed up to actually work. v2: Make sure that we call encoder->get_config _after_ we get_pipe_config to be consistent in both setup_hw_state and the modeset state checker. Otherwise the clever trick with handling the pixel mutliplier on i915G/GM where the encoder overrides the default value of 1 from the crtc get_pipe_config function doesn't work. Spotted by Imre Deak. v3: Actually cross-check the pixel mutliplier (but not on pch split platforms for now). Now actually also tested on a i915G with a sdvo encoder plugged in. Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Adding more context from Ville's reply to Rodrigo's question why we need this: "The spec says that on some hardware you need to PLL running before you can poke at the palette registers. I didn't actually try to anger the hardware so I'm not really sure what would happen otherwise, but IIRC Jesse said something about a hard system hang..." And generally documenting such ordering constraints with asserts is Just Good. Signed-off-by:
-
Ville Syrjälä authored
Make assert_sprites_disabled() operational on all platforms where we currently have sprite support enabled. Signed-off-by:
-
Ville Syrjälä authored
Ever since gen4 primary planes were fixed to pipes. And for gen2-3, don't check plane B if it doesn't exist. Signed-off-by:
-
Ville Syrjälä authored
Disable/restore sprite planes around mode-set just like we do for the primary and cursor planes. Now that we have working sprite clipping, this actually works quite decently. Previosuly we didn't even bother to disable sprites when changing mode, which could lead to a corrupted sprite appearing on the screen after a modeset (at least on my IVB). Not sure if all hardware generations would be so forgiving when enabled sprites end up outside the pipe dimensons. v2: Disable rather than enable sprites in ironlake_crtc_disable() Signed-off-by:
-
Ville Syrjälä authored
VLV doesn't have the old video overlay. Signed-off-by:
-
Ville Syrjälä authored
First disable FBC, then IPS, then disable all planes, and finally disable the pipe. v2: Mention IPS in the commit message Signed-off-by:
-
Ville Syrjälä authored
Again follow the same sequence for all generations, because doing otherwise just doesn't make sense. Signed-off-by:
-
Ville Syrjälä authored
Follow the same sequence when enabling the cursor plane during modeset. No point in doing this stuff in different order on different generations. This should also avoid a needless wait for vblank for the g4x cursor workaround when the cursor gets enabled anyway. Acked-by:
-
Ville Syrjälä authored
Loading the palette after the planes are enabled can risk showing incorrect colors. ILK+ already load the palette before even the pipe is enabled. Just follow the same order for gen2-4 and VLV. According to BSpec the requirements for palette access are display core clock and display PLL running. In certain platforms just the core clock may be enough. But we definitely should have both running when this gets called during the modeset. v2: Amend the commit message with some display PLL/core clock info Signed-off-by:
-
Ville Syrjälä authored
We use port I/O for VGA register access, so adding display_mmio_offset is just wrong. This reverts commit 56a12a50. Signed-off-by:
-
Paulo Zanoni authored
So we can remove some duplicate code. All the PCHs are very similar and right now the code is the same. I plan to add more code, so we would have more duplicated code. Signed-off-by:
-
Chris Wilson authored
By stashing a pointer of who opened the device and keeping a list of open fd, we can then walk each client and inspect how many objects they have open. For example, i915_gem_objects: 1102 objects, 613646336 bytes 663 [662] objects, 468783104 [468750336] bytes in gtt 37 [37] active objects, 46874624 [46874624] bytes 626 [625] inactive objects, 421908480 [421875712] bytes 282 unbound objects, 6512640 bytes 85 purgeable objects, 6787072 bytes 28 pinned mappable objects, 3686400 bytes 40 fault mappable objects, 27783168 bytes 2145386496 [536870912] gtt total Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096 unbound) gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0 unbound) xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344 inactive, 6508544 unbound) v2: Use existing drm->filelist as pointed out by Ben. v3: Not even stashing the task_struct is required as Ben pointed out drm_file->pid. Signed-off-by:Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
- 05 Jun, 2013 5 commits
-
-
Daniel Vetter authored
This way we can simplify the code quite a bit. Also add a WARN in the sdvo code to complain about a bogus value and kill the readout code in intel_ddi.c that Jesse sneaked in. HW state readout for the pixel multiplier will work a bit differently in the end. v2: Rebase on top of the fdi pixel mutliplier handling fix. Reviewed-by:
-
Jani Nikula authored
Two exactly same error messages on different error paths makes debugging difficult. Clarify the messages and distinguish them from each other. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Daniel Vetter authored
Only lvds/tv did actually check for cloning or not, but many more places should. Notices because my ivb tried to enable both cpu edp and vga on the first crtc - the resulting confusion between has_pch_encoder, has_dp_encoder but not actually being a pch dp encoder resulting in hilarity (hitting a BUG). We _really_ need an igt to random-walk our modeset space more exhaustively. The bug seems to have been exposed due to a race in the hw load detection support for VGA: Right after a hotplug VGA was still detected as connected, but obviously reading the EDID wasn't possible any more. Hence why restarting X a bit later fixed things. Due to the 1024x756 fallback resolution suddenly more outputs had the same resolution. On top of that SNA was confused with the possible_clones mask, trying to clone outputs which cannot be cloned. That bug is now fixed with commit fc1e0702b25e647cb423851fb7228989fec28bd6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed May 29 11:25:28 2013 +0100 sna: fixup up possible_clones kms->X impedance mismatch v2: Kill intel_encoder_check_is_cloned, spotted by Paulo. v3: Drop the now unused pipe param. v4: Kill the stray printk Chris spotted. v5: Elaborate on how the bug in userspace happened and why it was racy to reproduce. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Reviewed-by: -
Ville Syrjälä authored
Fix the DSPCLK_GATE_D access for VLV. The code incorrectly tried to poke at the ILK+ version of the register which is at the wrong offset. Signed-off-by:
-
Ville Syrjälä authored
The LP watermark registers don't exist on VLV, so don't touch them. Signed-off-by:
-
- 04 Jun, 2013 6 commits
-
-
Daniel Vetter authored
Panel fitters on ivb/hsw are not created equal since not all of them support the new high-quality upscaling mode. To offset this the hw allows us to freely assign the pfits to pipes. Since our code currently doesn't support this we might fall over when taking over firmware state. So check for this case and WARN about it. We can then improve the code once we've hit this in the wild. Or once we decide to support the improved upscale modes, though that requires global arbitrage of modeset resources across crtcs. v2: Check for IS_GEN7 instead of IS_IVB || IS_HSW as suggested by Paulo in his review comment. Suggested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Daniel Vetter authored
We can get at this easily through intel_crtc->config now. v2: Drop more stuff gcc spotted. v3: Drop even more stuff gcc spotted. v4: Yet more ... Reviewed-by:
-
Daniel Vetter authored
... not the port clock. This allows us to kill the funny semantics around pixel_target_clock. Since the dpll code still needs the real port clock, add a new port_clock field to the pipe configuration. Handling the default case for that one is a bit tricky, since encoders might not consistently overwrite it when retrying the crtc/encoder bw arbitrage step in the compute config stage. Hence we need to always clear port_clock and update it again if the encoder hasn't put in something more specific. This can't be done in one step since the encoder might want to adjust the mode first. I was a bit on the fence whether I should subsume the pixel multiplier handling into the port_clock, too. But then I decided against this since it's on an abstract level still the dotclock of the adjusted mode, and only our hw makes it a bit special due to the separate pixel mulitplier setting (which requires that the dpll runs at the non-multiplied dotclock). So after this patch the adjusted_mode accurately describes the mode we feed into the port, after the panel fitter and pixel multiplier (or line doubling, if we ever bother with that) have done their job. Since the fdi link is between the pfit and the pixel multiplier steps we need to be careful with calculating the fdi link config. v2: Fix up ilk cpu pll handling. v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config to make it clearer that we transmit the adjusted_mode without the pixel multiplier taken into account. The old code multiplied the the available link bw with the pixel multiplier, which results in the same fdi configuration, but is much more confusing. v4: Rebase on top of Imre's is_cpu_edp removal. v5: Rebase on top of Paulo's haswell watermark fixes, which introduce a new place which looked at the pixel_clock and so needed conversion. v6: Split out prep patches as requested by Paulo Zanoni. Also rebase on top of the fdi dotclock handling fix in the fdi lanes/bw computation code. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6) Signed-off-by: -
Daniel Vetter authored
This prepares a bit for the next big patch, where we switch the semantics of the different clocks in the pipe config around. Since I've broken cpu eDP PLL handling in the first version I've figured some refactoring is in order. Split out on request from Paulo Zanoni. Reviewed-by:
-
Daniel Vetter authored
We currently mutliply the link_bw of the fdi link with the pixel multiplier, which is wrong: The FDI link doesn't suddenly grow more bandwidth. In reality the pixel mutliplication only happens in the PCH, before the pixels are fed into the port. But since we our code treats the uses the target clock after pixels are doubled (tripled, ...) already, we need to correct this. Semantically it's clearer to divide the target clock to get the fdi dotclock instead of multiplying the bw, so do that instead. Note that the target clock is already multiplied by the same factor, so the division will never loose accuracy for the M/N computation. The lane computation otoh used the wrong value, we also need to feed the fdi dotclock to that. Split out on a request from Paulo Zanoni. v2: Also fix the lane computation, it used the target clock to compute the bw requirements, not the fdi dotclock (i.e. adjusted with the pixel multiplier). Since sdvo only uses the pixel multiplier for low-res modes (with a dotclock below 100MHz) we wouldn't ever have rejected a bogus mode, but just used an inefficient fdi config. v3: Amend the commit message to explain better what the change for the fdi lane config computation is all about. Requested by Paulo. Reviewed-by:
-
Daniel Vetter authored
Since I stand by my rule that splitting functions should only do an exact copy, this is a follow-up patch. Suggested-by:
Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
