Daniel complained that we keep adding stuff to the bottom of the file,
so we constantly have conflicts. So reorganize everything and split
them file-by-file, also sorting the files in alphabetical order. This
way, patches touching different files will have a smaller chance of
conflicting. Of course, this commit will conflict with everybody on
the list :)
Also remove a few useless comments and make some things fit into 80
lines.
v2: - Conflict with intel_ddi_get_config
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not valid for later non-PCH split platforms such as VLV.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Call intel_ddi_get_config() to get the pipe_bpp settings from
DDI.
The sync polarity settings from DDI are irrelevant for CRT
output, so override them with data from the ADPA register.
v2: Extract intel_crt_get_flags()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691
Tested-by: Qingshuai Tian <qingshuai.tian@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Flat out skip anything to do with PLL if we have a DSI encoder (and thus
DSI PLL). Also skip PLL computation if the encoder has already set
clocks. This allows for some tidying up of the code, including a
superfluous call to intel_limit() for LVDS downclock path.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During SDVO initialisation it would be useful to a have a record of the
individual devices we try to enable and later probe - in particular to
be able to see which fail.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Obtaining the forcwake requires expensive and time consuming
serialisation. And we often try to obtain the forcewake multiple times
in very quick succession. We can reduce the overhead of these sequences
by delaying the forcewake release, and so not hammer the hw quite so
hard.
I was hoping this would help with the spurious
[drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
found on Haswell. Alas not.
v2: Fix teardown ordering - unmap the regs after turning off forcewake,
and make sure we do turn off forcewake - both found by Ville.
v3: As we introduce intel_uncore_fini(), use it to make sure everything
is disabled before we hand back to the BIOS.
Note: I have no claims for improved performance, stablity or power
comsumption for this patch. We should not be hitting the registers often
enough for this to improve benchmarks, but given the nature of our hw it
is likely to improve long term stability.
Signed-off-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>
The | operation has higher precedence than "?:" so the macro always
returns GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1.
This regression has been introduce in "drm/i915: Add second slice l3
remapping".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i9xx_crtc_clock_get() no longer populates adjusted_mode.clock, so we
must get the pixel clock from port_clock in intel_crtc_mode_get().
This bug caused Chris's 845g machine to lockup during boot, and it
was introduced in:
commit 18442d0878
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Sep 13 16:00:08 2013 +0300
drm/i915: Fix port_clock and adjusted_mode.clock readout all over
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69713
Tested-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>
Future generations will be changing these registers (thanks to design
for giving us an early heads up). To help abstract, create the
definition of the base of the register block, and define all registers
relative to that.
Design has promised to not change the offsets relative to the base.
v2: Also change IS_HASWELL checks to HAS_PSR
CC: Rodrigo Vivi <rodrigo.vivi@gmail.com>
CC: Intel GFX <intel-gfx@lists.freedesktop.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reduce AUX transactions for non-eDP.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already restore planes during the modeset operation, so no need to do
another loop over the planes and try to restore them again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Call intel_uncore_early_sanitize() first thing during resume to prevent
stale BIOS leftovers from being reported as unclaimed register access.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915_restore_state() -> i915_restore_display() will attempt to
re-disable VGA during resume. So the power well needs to be powered on
before that.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_modeset_init() will already attempt to disable VGA. In order to do
that, it needs the power well to be on. So move the power well init
to happen before intel_modeset_init() during driver load.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The VGA plane needs to be disabled before we start doing any
modeset operations on resume.
This should also guarantee that the power well will be enabled
when we call i915_redisable_vga() since it gets explicitly powered on
during resume, and will get powered back off during the modeset
operation if no longer needed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VGA registers live inside the power well on HSW, so in order to write
the VGA MSR register we need the power well to be on.
We really must write to the register to properly clear the
VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when
the power well is down. It seems that the implicit zeroing done by
the power well is not enough to propagate the VGA_MSR_MEM_EN bit to
whomever is actually responsible for the memory decode ranges.
If we leave VGA memory decode enabled, and then turn off the power well,
all VGA memory reads will return zeroes. But if we first disable VGA
memory deocde and then turn off the power well, VGA memory reads
return all ones, indicating that the access wasn't claimed by anyone.
For the vga arbiter to function correctly the IGD must not claim the
VGA memory accesses.
Previously we were doing the VGA_MSR register access while the power well
was excplicitly powered up during driver init. But ever since
commit 6e1b4fdad5
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Sep 5 20:40:52 2013 +0300
drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done
we delay the VGA memory disable until fbcon has initialized, and so
there's a possibility that the power well got turned off during the
fbcon modeset. Also vgacon_save_screen() will need the power well to be
on to be able to read the VGA memory.
So immediately after enabling the power well during init grab a refence
for VGA purposes, and after all the VGA handling is done, release it.
v2: Add intel_display_power_put() for the num_pipes==0 case
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix up the patch wiggle screw-up that I've done and which
Paulo catched. Also polish spelling in the patch headline.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It only controls the setting of the vbt.edp_support variable, which in
turn only controls one debug output plus can also force-disable the
lvds output.
Since the value only restricted this logic to mobile ilk there's the
slight risk that this will break lvds on desktop ilk or on snb/ivb
platforms. But with the vbt it's better when we know what's going on
here, so let's rip it out and see what happens.
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no reason to init a DP connector if the encoder just supports
HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
AUX transactions to detect if there's something there. Same goes for a
DP connector that doesn't support HDMI, but I'm not sure these
actually exist.
v2: - Use bit fields
- Remove useless identation level
- Replace DRM_ERROR with DRM_DEBUG_KMS
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our code makes a lot of assumptions regarding what each DDI port
actually supports, and the VBT should tell us what is really happening
in the hardware. So parse the information provided by the VBT and
check if any of our assumptions is wrong.
Our driver also has a history of not really trusting the VBT, so a
WARN here could mean that:
a) our coding assumptions are wrong
b) the VBT is wrong
c) we're incorrectly parsing the VBT
d) the checks are wrong
But I really hope we won't ever trigger any of those WARNs.
v2: Don't check the redundant "Capabilities" field from byte 24 since
it doesn't seem to be used.
v3: Rebase
v4: Replace WARN with DRM_DEBUG_KMS
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our code currently assumes that port X will use the DP AUX channel X
and the DDC pin X. The VBT should tell us how things are mapped, so
add some WARNs in case we discover our assumptions are wrong (or in
case the VBT is just wrong, which is also perfectly possible).
Why would someone wire port B to AUX C and DDC D?
v2: Rebase
v3: Convert WARNs to DRM_DEBUG_KMS
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently use the recommended values from BSpec, but the VBT
specifies the correct value to use for the hardware we have, so use
it. We also fall back to the recommended value in case we can't find
the VBT.
In addition, this code also provides some infrastructure to parse more
information about the DDI ports. There's a lot more information we
could extract and use in the future.
v2: - Move some code to init_vbt_defaults.
v3: - Rebase
- Clarify the "DVO Port" matching code
v4: - Use I915_MAX_PORTS
- Change the HAS_DDI checks
- Replace DRM_ERROR with DRM_DEBUG_KMS
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently treat the child_device_config as a simple struct, but
this is not correct: new BDB versions change the meaning of some
offsets, so the struct needs to be adjusted for each version.
Since there are too many changes (today we're in version 170!), making
a big versioned union would be too complicated, so child_device_config
is now a union of 3 things: (i) a "raw" byte array that's safe to use
anywhere; (ii) an "old" structure that's the one we've been using and
should be safe to keep in the SDVO and TV code; and (iii) a "common"
structure that should contain only fields that are common for all the
known VBT versions.
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>
We never took the lock ourselves and all callers expect the struct_mutex
to be locked upon return (be it success or error), thereore dropping the
lock along the error paths looks to be a vestigial error from
commit db1b76ca6a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 9 16:51:37 2013 +0200
drm/i915: don't frob mm.suspended when not using ums
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's actually no real risk since we already check for stricter
constraints earlier (using UINT_MAX / sizeof (struct
drm_i915_gem_exec_object2) as the limit). But in eb_create we use
signed integers, which steals a factor of 2. Luckily struct
drm_i915_gem_exec_object2 for this to not matter.
Still, be consistent and use unsigned integers.
Similar use unsinged integers when checking for overflows in the
relocation entry processing.
I've also added a new subtests to igt/gem_reloc_overflow to also
test for overflowing args->buffer_count values.
v2: Give the variables again tighter scope to make it clear that the
computation is purely local and doesn't leak out to the 2nd block.
Requested by Chris Wilson.
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>
And the gratious overallocation of crtcs. Seems to go back to the ums
days of yonder ...
We also still need it to make the fbdev emulation happy, but I don't
think there's really a need. Especially since the current fbdev
emulation doesn't actually support cloning.
v2: Use sizeof(*pointer) pattern (Jani).
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No buffer overflows here, but better safe than sorry.
v2:
- Fixup the sizeof conversion, I've missed the pointer deref (Jani).
- Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
- Use kmalloc_array for the execbuf fastpath to avoid the memset
(Chris). I've opted to leave all other conversions as-is since they
aren't in a fastpath and dealing with cleared memory instead of
random garbage is just generally nicer.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop the contentious kmalloc_array hunk in execbuf.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Done while reviewing all our allocations for fubar. Also a few errant
cases of lacking () for the sizeof operator - just a bit of OCD.
I've left out all the conversions that also should use kcalloc from
this patch (it's only 2).
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm-intel-next-2013-09-21:
- clock state handling rework from Ville
- l3 parity handling fixes for hsw from Ben
- some more watermark improvements from Ville
- ban badly behaved context from Mika
- a few vlv improvements from Jesse
- VGA power domain handling from Ville
drm-intel-next-2013-09-06:
- Basic mipi dsi support from Jani. Not yet converted over to drm_bridge
since that was too fresh, but the porting is in progress already.
- More vma patches from Ben, this time the code to convert the execbuffer
code. Now that the shrinker recursion bug is tracked down we can move
ahead here again. Yay!
- Optimize hw context switching to not generate needless interrupts (Chris
Wilson). Also some shuffling for the oustanding request allocation.
- Opregion support for SWSCI, although not yet fully wired up (we need a
bit of runtime D3 support for that apparently, due to Windows design
deficiencies), from Jani Nikula.
- A few smaller changes all over.
[airlied: merge conflict fix in i9xx_set_pipeconf]
* tag 'drm-intel-next-2013-09-21-merged' of git://people.freedesktop.org/~danvet/drm-intel: (119 commits)
drm/i915: assume all GM45 Acer laptops use inverted backlight PWM
drm/i915: cleanup a min_t() cast
drm/i915: Pull intel_init_power_well() out of intel_modeset_init_hw()
drm/i915: Add POWER_DOMAIN_VGA
drm/i915: Refactor power well refcount inc/dec operations
drm/i915: Add intel_display_power_{get, put} to request power for specific domains
drm/i915: Change i915_request power well handling
drm/i915: POSTING_READ IPS_CTL before waiting for the vblank
drm/i915: don't disable ERR_INT on the IRQ handler
drm/i915/vlv: disable rc6p and rc6pp residency reporting on BYT
drm/i915/vlv: honor i915_enable_rc6 boot param on VLV
drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF
drm/i915: Do remaps for all contexts
drm/i915: Keep a list of all contexts
drm/i915: Make l3 remapping use the ring
drm/i915: Add second slice l3 remapping
drm/i915: Fix HSW parity test
drm/i915: dump crtc timings from the pipe config
drm/i915: register backlight device also when backlight class is a module
drm/i915: write D_COMP using the mailbox
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Pull drm fixes from Dave Airlie:
"Nothing too major, radeon still has some dpm changes for off by
default.
Radeon, intel, msm:
- radeon: a few more dpm fixes (still off by default), uvd fixes
- i915: runtime warn backtrace and regression fix
- msm: iommu changes fallout"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (27 commits)
drm/msm: use drm_gem_dumb_destroy helper
drm/msm: deal with mach/iommu.h removal
drm/msm: Remove iommu include from mdp4_kms.c
drm/msm: Odd PTR_ERR usage
drm/i915: Fix up usage of SHRINK_STOP
drm/radeon: fix hdmi audio on DCE3.0/3.1 asics
drm/i915: preserve pipe A quirk in i9xx_set_pipeconf
drm/i915/tv: clear adjusted_mode.flags
drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER
drm/radeon/cik: fix overflow in vram fetch
drm/radeon: add missing hdmi callbacks for rv6xx
drm/i915: Use a temporary va_list for two-pass string handling
drm/radeon/uvd: lower msg&fb buffer requirements on UVD3
drm/radeon: disable tests/benchmarks if accel is disabled
drm/radeon: don't set default clocks for SI when DPM is disabled
drm/radeon/dpm/ci: filter clocks based on voltage/clk dep tables
drm/radeon/dpm/si: filter clocks based on voltage/clk dep tables
drm/radeon/dpm/ni: filter clocks based on voltage/clk dep tables
drm/radeon/dpm/btc: filter clocks based on voltage/clk dep tables
drm/radeon/dpm: fetch the max clk from voltage dep tables helper
...
A small fix + deal with fallout of iommu changes + use new
drm_gem_dumb_destroy helper.
* 'msm-fixes-3.12-rc2' of git://people.freedesktop.org/~robclark/linux:
drm/msm: use drm_gem_dumb_destroy helper
drm/msm: deal with mach/iommu.h removal
drm/msm: Remove iommu include from mdp4_kms.c
drm/msm: Odd PTR_ERR usage
We still need an API exported by msm iommu driver (but not visible in
any public header anymore). For now, just declare the prototype
ourselves, but when msm iommu driver provides a better option, use that
instead.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The include file has been removed and the file does not
need it anyway, so remove it. Fixes a compile error.
Signed-off-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The variable priv->kms is not initialized yet.
Found by "scripts/coccinelle/tests/odd_ptr_err.cocci".
PTR_ERR should access the value just tested by IS_ERR.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
More radeon fixes for 3.12. Kind of all over the place: UVD, DPM,
tiling, etc.
* 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix hdmi audio on DCE3.0/3.1 asics
drm/radeon/cik: fix overflow in vram fetch
drm/radeon: add missing hdmi callbacks for rv6xx
drm/radeon/uvd: lower msg&fb buffer requirements on UVD3
drm/radeon: disable tests/benchmarks if accel is disabled
drm/radeon: don't set default clocks for SI when DPM is disabled
drm/radeon/dpm/ci: filter clocks based on voltage/clk dep tables
drm/radeon/dpm/si: filter clocks based on voltage/clk dep tables
drm/radeon/dpm/ni: filter clocks based on voltage/clk dep tables
drm/radeon/dpm/btc: filter clocks based on voltage/clk dep tables
drm/radeon/dpm: fetch the max clk from voltage dep tables helper
drm/radeon: fix missed variable sized access
drm/radeon: Make r100_cp_ring_info() and radeon_ring_gfx() safe (v2)
drm/radeon/cik: Add tiling mode index for 1D tiled depth/stencil surfaces
drm/radeon/cik: Fix encoding of number of banks in tiling configuration info
drm/radeon/cik: Fix printing of client name on VM protection fault
drm/radeon: additional gcc fixes for radeon_atombios.c
drm/radeon: avoid UVD corruption on AGP cards using GPU gart
In
commit 81e49f8114
Author: Glauber Costa <glommer@openvz.org>
Date: Wed Aug 28 10:18:13 2013 +1000
i915: bail out earlier when shrinker cannot acquire mutex
SHRINK_STOP was added to tell the core shrinker code to bail out and
go to the next shrinker since the i915 shrinker couldn't acquire
required locks. But the SHRINK_STOP return code was added to the
->count_objects callback and not the ->scan_objects callback as it
should have been, resulting in tons of dmesg noise like
shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete nr=-xxxxxxxxx
Fix discusssed with Dave Chinner.
References: http://www.spinics.net/lists/intel-gfx/msg33597.html
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Glauber Costa <glommer@openvz.org>
Cc: Glauber Costa <glommer@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Acked-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This regression has been introduced in
commit 9f11a9e4e5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jun 13 00:54:58 2013 +0200
drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
Ville brough up the idea that this is just the pipe A quirk gone
wrong.
Note that after resume the bios might or might not have enabled pipe A
already. We have a bit of magic to make sure that on resume we set up
a decent mode for pipe A, but I fear if I just smash pipe A to always
on we'd enable it in a bogus state and hang the hw. Hence the
readback.
v2: Clarify the logic a bit as suggested by Chris. Also amend the
commit message to clarify why we don't unconditionally enable the
pipe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462
References: https://lkml.org/lkml/2013/8/26/238
Cc: Meelis Roos <mroos@ut.ee>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use |= instead of = as suggested by Chris.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The native TV encoder has it's own flags to adjust sync modes and
enabled interlaced modes which are totally irrelevant for the adjusted
mode. This worked out nicely since the input modes used by both the
load detect code and reported in the ->get_modes callbacks all have no
flags set, and we also don't fill out any of them in the ->get_config
callback.
This changed with the additional sanitation done with
commit 2960bc9cce
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Jul 30 13:36:32 2013 +0300
drm/i915: make user mode sync polarity setting explicit
sinc now the "no flags at all" state wouldn't fit through core code
any more. So fix this up again by explicitly clearing the flags in the
->compute_config callback.
Aside: We have zero checking in place to make sure that the requested
mode is indeed the right input mode we want for the selected TV mode.
So we'll happily fall over if userspace tries to pull us. But that's
definitely work for a different patch series. So just add a FIXME
comment for now.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
Tested-by: Nicolas Suzor <nic@suzor.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix a bug that was introduced in commit c4c11dd160 ("drm/i2c: tda998x:
add video and audio input configuration") when Sebastian cleaned up my
original patch. Without this being fixed, audio is muted when the
display is turned off, never to be re-enabled.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Darren Etheridge <detheridge@ti.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Missing ULL when calculating the amount of vram
leads to an overflow when the amount of vram is >= 4G.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
When dpm was merged, I added a new asic struct for
rv6xx, but it never got properly updated when the
hdmi callbacks were added due to the two patch sets
being developed in parallel.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
In
commit edc3d8848d
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Thu May 23 13:55:35 2013 +0300
drm/i915: avoid big kmallocs on reading error state
we introduce a two-pass mechanism for splitting long strings being
formatted into the error-state. The first pass finds the length, and the
second pass emits the right portion of the string into the accumulation
buffer. Unfortunately we use the same va_list for both passes, resulting
in the second pass reading garbage off the end of the argument list. As
the two passes are only used for boundaries between read() calls, the
corruption is only rarely seen.
This fixes the root cause behind
commit baf27f9b17
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Jun 29 23:26:50 2013 +0100
drm/i915: Break up the large vsnprintf() in print_error_buffers()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQEcBAABAgAGBQJSQMORAAoJEHm+PkMAQRiGj14H/1bjhtfNjPdX7MVQAzA+WpwX
s7h1IQu2Si9S5S1lBiM2sBTOssVcmfheO9x4yqm7JNOD1RnssWKOM3q+zVOLstwd
GD3gluJPeraD5EyYSqEJ9ILPQ3gbxb4wOlT0Z291TW6E8XhLRr0RTOJPksRsgvLH
Ckm9uJh6ArS6ZXfXiaDQfd+xHAQJkUfW6nMSA0g9ZO9C6KIDRvcbUmrY3m4HhfIk
mK0TXCBs+AXGDIjTEB8JgIQL/5y1Qn0c4R+2uTU/4YWwyLvJTV1e44kGoleukMMT
6Pw/TNlUEN161dbSaqCyF3sfXHDYQ5valycI2PDgitMtPSxbzsU1VDizS8+daRg=
=lEmF
-----END PGP SIGNATURE-----
Merge tag 'v3.12-rc2' into drm-intel-next
Backmerge Linux 3.12-rc2 to prep for a bunch of -next patches:
- Header cleanup in intel_drv.h, both changed in -fixes and my current
-next pile.
- Cursor handling cleanup for -next which depends upon the cursor
handling fix merged into -rc2.
All just trivial conflicts of the "changed adjacent lines" type:
drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_drv.h
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Starting with UVD3 message and feedback buffers have their
own 256MB segment, so no need to force them into VRAM any more.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The tests are only usable if the acceleration engines have
been successfully initialized.
Based on an initial patch from: Alex Ivanov <gnidorah@p0n4ik.tk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This is a partial revert of c6cf7777a3.
We need to take into account the clk voltage dependencies of the
board. Not doing so can lead to stability issues on certain
boards if the clks exceed the levels in the dep tables.
DPM already takes that into account, so for optimal performance,
use DPM.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Filter out mclk and sclk levels higher than listed in the clk
voltage dependency tables. Supporting these clocks will require
additional driver tweaking that isn't supported yet.
See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=68235
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Filter out mclk and sclk levels higher than listed in the clk
voltage dependency tables. Supporting these clocks will require
additional driver tweaking that isn't supported yet.
See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=68235
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
