... even if the actual infoframe is smaller than the maximum possible
size.
If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
be correctly calculated in some cases (e.g., when changing the port),
and this will lead to black screens on HDMI monitors. The ECC value is
generated by the hardware.
I don't see how this should break anything since we're writing 0 and
that should be the correct value, so this patch should be safe.
Notice that on IVB and older we actually have 64 bytes available for
VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
others are either read-only ECC values or marked as "reserved". On HSW
we only have 32 bytes, and the ECC value is stored on its own separate
read-only register. See BSpec.
This patch fixes bug #46761, which is marked as a regression
introduced by commit 4e89ee174b:
drm/i915: set the DIP port on ibx_write_infoframe
Before commit 4e89 we were just failing to send AVI infoframes when we
needed to change the port, which can lead to black screens in some
cases. After commit 4e89 we started sending infoframes, but with a
possibly wrong ECC value. After this patch I hope we start sending
correct infoframes.
Version 2:
- Improve commit message
- Try to make the code more clear
Cc: stable@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
NVIDIA do that at startup too on Fermi, so perhaps the heap of 0x10
intrs we receive are normal and we can ignore them.
On Kepler NVIDIA *don't* do this, but the hardware appears to come up
with the bit masked off by default - so that's probably why :)
This should silence some interrupt spam seen on Fermi+ boards.
Backported patch from reworked nouveau kernel tree.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The last patches moved a lot of code from ironlake_crtc_mode_set to
sub-functions, so these variables became useless. You could get
warnings by enabling -Wunused-but-set-variable.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The set_m_n code was spread all over the mode_set function.
Version 2:
Don't set the DP M/N registers on ironlake_set_m_n. Daniel Vetter has
plans to add some encoder-specific callbacks. Also, on this version we
don't change the order we're writing the registers, making the code
change safer.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As noticed by Daniel Vetter, intel_pipe_choose_bpp_dither should
already check for invalid bpp values and set a valid value, so remove
the recheck inside ironlake_crtc_mode_set and also replace a "default"
switch case inside ironlake_set_pipeconf with a BUG().
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
when __ARCH_HAS_VGA_DEFAULT_DEVICE is not defined, aka EFIFB is not used,
for static path, vga_default setting is through vga_arbiter_add_pci_device.
and later x86 pci_fixup_video, will skip setting again.
- subsys_initcall(vga_arb_device_init) come first to call
vga_arbiter_add_pci_device. It will call pci_get_dev to hold one reference.
for hotplug add path, even vga_arbiter_add_pci_device is called via
notifier, but it will check VGA_RSRC_LEGACY_MASK that is not set for
hotplug path. So x86 pci_fixup_video will take over to call
vga_set_default_device(). It will not hold one refrence.
Later for hotplug remove path, vga_arbiter_del_pci_device that does not
check VGA_RSRC_LEGACY_MASK will call put_device and it will cause ref_count
to decrease extra. that will have that pci device get deleted early
wrongly.
Need to make get/put balance for both cases.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: x86@kernel.org
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Julia Lawall <julia@diku.dk>
Cc: Matthew Garrett <mjg@redhat.com>
Manual backmerge of -rc7 to resolve a silent conflict leading to
compile failure in drivers/gpu/drm/i915/intel_hdmi.c.
This is due to the bugfix in -rc7:
commit b98b601672
Author: Wang Xingchao <xingchao.wang@intel.com>
Date: Thu Sep 13 07:43:22 2012 +0800
drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
Since this code moved around a lot in -next git put that snippet at
the wrong spot. I've tried to fix this by making the conflict explicit
by merging a version for next with:
commit 3cce574f01
Author: Wang Xingchao <xingchao.wang@intel.com>
Date: Thu Sep 13 11:19:00 2012 +0800
drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally
But that failed to solve the entire problem. To avoid pushing out
further -nightly branch to our QA where this is broken, do the
backmerge and manually add the stuff git adds to -next from the patch
in -fixes.
Note that this doesn't show up in git's merge diff (and hence is also
not handled by git rerere), which adds to the reasons why I'd like to
fix this with a verbose backmerge. The git merge diff only shows a
bunch of trivial conflicts of the "code changed in lines next to each
another" kind.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should never happen, but the silent "return" makes me wonder
every time I try to debug InfoFrame bugs, so promote this to BUG() to
make sure people will complain if we ever break this.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
Essentially just flush my -fixes queue before I head off to xdc.
- gen2 regression fixer, we've enabled the lvds stuff too late. Not
causing any known issues, but this restores the sequence before a
refactor that landed in 3.5, and lvds is a fickle beast. And seriously,
who runs gen2 still ...
- downgrade a BUG to a WARN - we haven't root-caused/fixed the underlying
issue yet, but this should help bug reporters quite a bit.
- properly disable hdmi audio - we've lost track of this, which resulted
in the alsa driver again losing track of the unplug event.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
drm/i915: Reduce a pin-leak BUG into a WARN
drm/i915: enable lvds pin pairs before dpll on gen2
This fixes the gpio reset problem so the Retina MBP works, but avoids
breaking the Dell systems. Ben will work on a better solution for 3.7.
Tested by me on retina MBP.
Signed-off-by: Dave Airlie <airlied@redhat.com>
fixes a resume regression on pre-r6xx asics.
* 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: Prevent leak of scratch register on resume from suspend
Compare the adjusted clock as well as the crtc mode
clock. This handles cases where the driver adjusts
the clock for specific special cases.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need the calculate the pixel clock before allocating a PPLL
in order to insure the clocks really match.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If several non-DP displays use the same pixel clock
we can use the same PPLL for all of them. If all
relevant displays have the same pixel clock, this
allows the driver to:
- use fewer PPLLs which saves power
- support more than two non-DP displays on DCE4+
The current drm modesetting infrastructure doesn't
really provide a good framework for validating combinations
that work or won't work, so it's possible you could go from
a working configuration to a non-working one by changing the
mode a one of the displays. However, there this is better
than what was there before.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For DP we can use the same PPLL for all active DP
encoders. Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work. Also clean up the code
a bit.
v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
- document functions
- break in main encoder search loop after matching.
no need to keep checking additional encoders.
v4: - same as v3, but re-apply to drm-next as the corner
cases are fixed properly in subsequent patches.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54471
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
MiscInfo field should be programmed with the crtc id
rather than the pll id. However, at this point the
two are the same for chips with this version of the table.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use the proper struct in the union. That field
has the same offset in every struct, so no functional
change.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Roughly based on how nouveau is handling it. Instead of
adding the bo_va when the address is set add the bo_va
when the handle is opened, but set the address to zero
until userspace tells us where to place it.
This fixes another bunch of problems with glamor.
v2: agd5f: fix build after dropping patch 7/8.
Signed-off-by: Christian König <deathsimple@vodafone.de>
The no_wait param isn't used anywhere, and actually isn't
very usefull at all.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
It doesn't really belong into the object functions,
also rename it to avoid collisions with struct radeon_bo_va.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Even GPUs can have a null pointer dereference, so move
the IB pool to another offset to catch those.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
When a VM is used on more than one ring we need to
sync to the last user.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
This applies on top of drm/radeon: Mark all possible functions / structs as static.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Let's allow GCC to optimize better.
This exposed some five unused functions, but this patch doesn't remove them.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Currently doing the update with the CP.
v2: Rebased on Jeromes bugfix. Make validity comparison
more human readable.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Make sure that the ib bo is bound and is page table is up to date
in the virtual address space.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Removing the need to wait for anything.
Still not ideal, since we need to free pt on va remove.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Move flushing the VMs as function into the rings.
First step to make VM operations async.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Store a reference to the VM into the IB structure, that
makes calculating the IBs address a bit less complicated.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Several encoder setup functions had the same duplicated
code for selecting the proper bpc setting for various
atom tables. Consolidate it.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>