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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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=65280
Tested-by: shui yangwei <yangweix.shui@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <daniel.vetter@ffwll.ch>
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: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Spruce up the commit message a lot.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make assert_sprites_disabled() operational on all platforms where
we currently have sprite support enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV doesn't have the old video overlay.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again follow the same sequence for all generations, because doing
otherwise just doesn't make sense.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Egbert Eich <eich@suse.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use port I/O for VGA register access, so adding display_mmio_offset
is just wrong.
This reverts commit 56a12a5092.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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ä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The LP watermark registers don't exist on VLV, so don't touch them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Multiple nouveau regression fixes, hdmi audio, s/r and dac load detection
* 'drm-nouveau-fixes-3.10' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nv50/kms: use dac loadval from vbios, where it's available
drm/nv50/disp: force dac power state during load detect
drm/nv50-nv84/fifo: fix resume regression introduced by playlist race fix
drm/nv84/disp: Fix HDMI audio regression
Daniel writes:
Three regression fixes and one no-lvds quirk update. The regression Egbert
Eich tracked down goes back to 2.6.37 ... ugh. The other two are pretty
minor: One bogus modeset state checker WARN and a patch to prevent X
dying in a SIGBUS after a gpu hang with failed (or not implement as on
gen2/3) gpu reset.
* tag 'drm-intel-fixes-2013-06-04' of git://people.freedesktop.org/~danvet/drm-intel: (368 commits)
drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.
drm/i915: no lvds quirk for hp t5740
drm/i915: Quirk the pipe A quirk in the modeset state checker
drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus
Linux 3.10-rc4
parisc: parport0: fix this legacy no-device port driver!
parport_pc: disable PARPORT_PC_SUPERIO on parisc architecture
parisc/PCI: lba: fix: convert to pci_create_root_bus() for correct root bus resources (v2)
parisc/PCI: Set type for LBA bus_num resource
MAINTAINERS: update parisc architecture file list
parisc: kernel: using strlcpy() instead of strcpy()
parisc: rename "CONFIG_PA7100" to "CONFIG_PA7000"
parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50
parisc: memory overflow, 'name' length is too short for using
powerpc/cputable: Fix typo on P7+ cputable entry
powerpc/perf: Add missing SIER support
powerpc/perf: Revert to original NO_SIPR logic
powerpc/pci: Remove the unused variables in pci_process_bridge_OF_ranges
powerpc/pci: Remove the stale comments of pci_process_bridge_OF_ranges
powerpc/pseries: Always enable CONFIG_HOTPLUG_CPU on PSERIES SMP
...
Regression from merging the old nv50/nvd9 code together, and may be
needed to fully fix fdo#64904.
The value is ignored completely by the hardware starting from nva3.
Reported-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reported-by: Maarten Maathuis <madman2003@gmail.com>
Reported-by: Sven Joachim <svenjoac@gmx.de>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Code refactoring in commit 8e9e3d2dea
(drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
nv84 by removing too much old code without adding it in the new one.
This patch adds the missing code within the new code layout resulting in
HDMI audio working again.
It should work on any HDMI head, but due to lacking ahrdware I could
only test the (1st) one.
It also might be possible that similar code is needed for nva3, which I
can't test.
Signed-off-by: Alexander Stein <alexander.stein@informatik.tu-chemnitz.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
for DDC. Thus the code will always have to rely on a LVDS panel
mode supplied by VBT.
In most cases this succeeds, so this didn't get detected for quite
a while.
This regression seems to have been introduced in
commit f899fc64cd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jul 20 15:44:45 2010 -0700
drm/i915: use GMBUS to manage i2c links
Signed-off-by: Egbert Eich <eich@suse.de>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about which commit likely introduced this issue.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... 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 <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the DP madness is cleared out, this is all only per-platform.
So move it out from the intel clock limits structure.
While at it drop the intel prefix on the static functions, call the
vtable entry find_dpll (since it's for the display pll) and rip out
the now unnecessary forward declarations.
Note that the parameters of ->find_dpll are still unchanged, but they
eventually need to be moved over to just take in a pipe configuration.
But currently a lot of things are still missing from the pipe
configuration (reflock, output-specific dpll limits and preferences,
downclocked dotclock). So this will happen in a later step.
Note that intel_g4x_limit has a peculiar case where it selects
intel_limits_i9xx_sdvo as the limit. This is pretty bogus and also not
used since the only output types left are DP and native TV-out which
both use special pre-tuned dpll values.
v2: Re-add comment for the find_pll callback (requested by Paulo) and
elaborate on why the transformation is correct for g4x platforms (to
clarify a review question from Paulo). Double up on that by adding a
WARN as suggested by Paulo Zanoni on irc.
v3: Initialize limits to NULL since gcc is now unhappy.
v4: v2/3 will blow up with a NULL dereference in ->find_dpll for dp and
TV-out ports, spotted by Paulo on irc. So just give up on this madness for
now, and leave this to be fixed in a later patch.
v5: Since the ever-so-slight change for g4x might result in some dpll
parameter computation failing spuriously where before it didn't for
ports with preset dpll settings (DP & TV-out) override this. For
paranoia also do it in the ilk+ code.
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pineview is just different.
Also split out i9xx_clock from intel_clock and drop the now redundant
struct device * parameter.
Note that in this patch I kill an XXX comment about 100MHz clocks. I
couldn't figure out what this is about, and we don't seem to have any
bug reports about this either. I suspect that it's a remnant from when
the i9xx and ilk+ modeset code was all in the same file since ilk+
does indeed have a 100MHz clock. So I've just killed it to stop the
cargo-culting.
Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since this is run in the compute config stage we need to check
the new_ pointers, i.e the stage output routing, not the current
modeset layout. Also there was a little logic bug in properly skipping
connectors: The old code did not skip any unused connectors and so
clamped to whatever was left in there (usually 0 if that connector
hasn't seen a EDID 1.4 screen ever since boot-up).
This has been broken when moving the pipe bpp selection in
commit 4e53c2e010
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 27 00:44:58 2013 +0100
drm/i915: precompute pipe bpp before touching the hw
To avoid too much casting switch from drm_ to intel_ types.
Also add a bit of debug output to help reconstructing what's going
on.
v2: Try to clarify this a bit:
- s/pipe_config_set_bpp/compute_baseline_pipe_bpp/ to make it clearer
at which stage this function is run. Also add a comment about what
it does.
- Extract the sink clamping into it's own function.
v3: Actually make it compile.
v4: Split out all the prep refactoring to make the bugfix stick out
really badly. Also elaborate a bit in the commit message about the
nature of the bugfix.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As a prep work to fix it up:
- Use intel_connector instead of drm_connector to avoid too much
upcasting in the bugfix patch.
- Extract the connector bpp clamping from the loop-over-connectors
logic.
- Bikeshed function names (to make it clearer that
acompute_baseline_pipe_bpp runs in the compute stage of the modeset
sequence) and add a comment to make it clearer what it does.
No functional change in this patch.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's not supported yet. Fixes display issues when
users force it on.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The current radeon driver initialization routines, when using KMS, are written
so that the IRQ installation routine is called before initializing the WB buffer
and the CP rings. With some ASICs, though, the IRQ routine tries to access the
GFX_INDEX ring causing a call to RREG32 with the value of -1 in
radeon_fence_read. This, in turn causes the system to completely hang with some
cards, requiring a hard reset.
A call stack that can cause such a hang looks like this (using rv515 ASIC for the
example here):
* rv515_init (rv515.c)
* radeon_irq_kms_init (radeon_irq_kms.c)
* drm_irq_install (drm_irq.c)
* radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
* rs600_irq_process (rs600.c)
* radeon_fence_process - due to SW interrupt (radeon_fence.c)
* radeon_fence_read (radeon_fence.c)
* hang due to RREG32(-1)
The patch moves the IRQ installation to the card startup routine, after the ring
has been initialized, but before the IRQ has been set. This fixes the issue, but
requires a check to see if the IRQ is already installed, as is the case in the
system resume codepath.
I have tested the patch on three machines using the rv515, the rv770 and the
evergreen ASIC. They worked without issues.
This seems to be a known issue and has been reported on several bug tracking
sites by various distributions (see links below). Most of reports recommend
booting the system with KMS disabled and then enabling KMS by reloading the
radeon module. For some reason, this was indeed a usable workaround, however,
UMS is now deprecated and disabled by default.
Bug reports:
https://bugzilla.redhat.com/show_bug.cgi?id=845745https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789https://bbs.archlinux.org/viewtopic.php?id=156964
Signed-off-by: Adis Hamzić <adis@hamzadis.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Last year, a patch was made for the "HP t5740e Thin Client" (see
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
This device reports an lvds panel, but does not really have one.
The predecessor of this device is the "hp t5740", which also does not have
an lvds panel. This patch will add the same quirk for this device.
Signed-off-by: Ben Mesman <ben@bnc.nl>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we always force the pipe A to on we can't use the hw state to
decide whether it should be on. Hence quirk the quirk.
The problem is that crtc->active tracks the state of the entire
display pipe, i.e. including planes, encoders and all. But our hw
state readout simply looks at the pipe. But with the pipe A quirk we
force-enable that (together with it's pll). To fix that mismatch we
have two options:
- Quirk the checked state to match what our sw tracking states if the
pipe A quirk is in effect.
- Improve the hw state readout to not get fooled by the pipe A quirk.
Since we already have similar state clamping in e.g. assert_pipe I've
opted for the first variant. Also note that we don't really loose any
state checking: Individual pieces of the abstract crtc pipe are
checked in the enable/disable functions with the various asssert_*
checks we have, and the hw state check code doesn't check anything if
the pipe is off anyway.
v2: Pimp commit message after discussion with Chris and only apply the
quirk for the quirk if we're checking pipe A. Otherwise we'll miss
state checking for pipe B on i830M ...
v3: Make the code comment consistent with the improved commit message,
too (Chris).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64764
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-Tested-by: mlsemon35@gmail.com (v1)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson noticed that since
commit 1f83fee08d [v3.9]
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Nov 15 17:17:22 2012 +0100
drm/i915: clear up wedged transitions
X can again get -EIO when it does not expect it. And even worse score
a SIGBUS when accessing gtt mmaps. The established ABI is that we
_only_ return an -EIO from execbuf - all other ioctls should just
work. And since the reset code moves all bos out of gpu domains and
clears out all the last_seqno/ring tracking there really shouldn't be
any reason for non-execbuf code to ever touch the hw and see an -EIO.
After some extensive discussions we've noticed that these spurios -EIO
are caused by i915_gem_wait_for_error:
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html
That is easy to fix by returning 0 instead of -EIO, since grabbing the
dev->struct_mutex does not yet mean that we actually want to touch the
hw. And so there is no reason at all to fail with -EIO.
But that's not the entire since, since often (at least it's easily
googleable) dmesg indicates that the reset fails and we declare the
gpu wedged. Then, quite a bit later X wakes up with the "Timed out
waiting for the gpu reset to complete" DRM_ERROR message in
wait_for_errror and brings down the desktop with an -EIO/SIGBUS.
So clearly we're missing a wakeup somewhere, since the gpu reset just
doesn't take 10 seconds to complete. And indeed we're do handle the
terminally wedged state wrong.
Fix this all up.
References: https://bugs.freedesktop.org/show_bug.cgi?id=63921
References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only need to do them if the pipe is actually running and if the
framebuffers have changed. Removes two "wait for vblank timed out"
messages when doing a suspend/resume cycle on my i855gm.
v2: s/to_intel_ctrc(crtc)/intel_crtc/ spotted by Chris.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
People don't like typedefs these days. Eliminate their use from intel_fb.c.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use container_of() instead of a cast to get struct intel_fbdev
from struct drm_fb_helper.
Also populate the fb_info->par correctly with the drm_fb_helper pointer
instead of the intel_fbdev pointer.
There's no actual functional change since the drm_fb_helper happens to
be the first member inside intel_fbdev.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
