Make input and output of find_section const, and fix the fallout. We
shouldn't modify the VBT, so make the compiler help us here.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_bios.c | 60 ---
1 file changed, 31 insertions(+),
Make input and output of validate_vbt const, and fix the fallout. We
shouldn't modify the VBT, so make the compiler help us here.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_bios.c | 50 ---
1 file changed, 26 insertions(+),
We need to tell BDW ULT and ULX apart.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
Add support for changing cdclk frequency during runtime on BDW. The
procedure is quite a bit different on BDW from the one on HSW, so
add a separate function for it.
Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
so take that into account when computing the max pixel
Bspec says we shouldn't enable IPS on BDW when the pipe pixel rate
exceeds 95% of the core display clock. Apparently this can cause
underruns.
There's no similar restriction listed for HSW, so leave that one alone
for now.
v2: Add pipe_config_supports_ips() (Chris)
v3: Compare against the max
Rather that extracting the current cdclk freuqncy every time someone
wants to know it, cache the current value and use that. VLV/CHV already
stored a cached value there so just expand that to cover all platforms.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
V2: Rebased to the
Implement cdclk extraction for g33, 965gm and g4x platforms. The details
came from configdb. Sadly there isn't anything there for other gen3/gen4
chipsets.
So far I've tested this on one ELK where it gave me a HPLL VCO of 5333
MHz and cdclk of 444 MHz which seems perfectly sane for this machine.
Print a warning if we fall through the .get_display_clock_speed() function
pointer setup. We end up assuming a 133MHz cdclk which should mean that
at least we avoid any 0 deivisions and whatnot. But this could at least
help remind people that they have to provide this function for new platforms.
Keep the cdclk maximum supported frequency around in dev_priv so that we
can verify certain things against it before actually changing the cdclk
frequency.
For now only VLV/CHV have support changing cdclk frequency, so other
plarforms get to assume cdclk is fixed.
Signed-off-by: Ville Syrjälä
ilk_get_aux_clock_divider() is now a subset of
hsw_get_aux_clock_divider() so unify them.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 23 +++
1 file changed, 3 insertions(+),
This patch series rebases Ville's original cdclk patch series
excluding the ones that have been reviewed.
http://lists.freedesktop.org/archives/intel-gfx/2014-November/055633.html
The patches include modifications to
drm/i915: Fix i855_get_display_clock_speed()
drm/i915: Fix 852GM/GMV cdclk
Actually read the HPLLCC register insted of assuming it's 0. Fix the
HPLLCC bit definitions and all the missing ones from the 852GME spec.
852GME, 854 and 855 all seem to match the same HPLLC encoding even
though only some of the values are valid is some of the platforms.
Signed-off-by: Ville
Implement support for changing the cdclk frequency during runtime on
HSW. VLV/CHV already have support for this, so we can follow their
example for the most part. Only the actual hardware programming differs,
the rest is pretty much the same.
The pipe pixel rate stuff is handled a bit differently
Rather than reading out the current cdclk value use the cached value we
have tucked away in dev_priv.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
drivers/gpu/drm/i915/intel_dp.c
Limit CHV maximum cdclk to 320MHz.
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 09f3518..d79421a
Combined Valleyview, Haswell and Broadwell '*_modeset_global_pipes()'
into one function 'intel_modeset_global_pipes()'
v2:
- we don't modify 'disable_pipes', so passing this as a pointer
is removed (based on Ville's comment)
- introduced a new function 'intel_calc_cdclk()' that combines
It seems 852GM/GMV uses a different HPLLCC encoding than the other
85x platforms. For 852GM/GMV cdclk is always 133MHz. Try to detect that
using the PCI revision (sinc the device ID seems useless for that). I'm
not at all sure this is a good idea, but according to the specs it
should work.
On 04/14/2015 05:31 PM, Chris Wilson wrote:
In order to use userptr, the kernel tracks the owner's mm with a
mmu_notifier. Setting that is very expensive - it involves taking all
mm_locks and a stop_machine(). This tracking lives only for as long as
the client is using userptr objects - so if
From: Satheeshakrishna M satheeshakrishn...@intel.com
PORT_CLK_SEL programming is needed only on HSW/BDW.
v2:
- don't program PORT_CLK_SEL from mst encoders either (imre)
v3:
- fix the check for GEN9+ in intel_mst_pre_enable_dp() (damien)
Signed-off-by: Satheeshakrishna M
On Wed, Apr 15, 2015 at 04:42:56PM +0300, Imre Deak wrote:
From: Vandana Kannan vandana.kan...@intel.com
Add CDCLK specific display clock initialization sequence as per BSpec.
Note that the CDCLK initialization/uninitialization are done at their
current place only for simplicity, in a
From: Suketu Shah suketu.j.s...@intel.com
Add triggers for DC9 as per details provided in bxt_enable_dc9
and bxt_disable_dc9 implementations.
v1:
- Add SKL check in gen9_disable_dc5 as it is possible for DC5
to remain disabled only for SKL.
- Add additional checks for whether DC5 is already
From: Jesse Barnes jbar...@virtuousgeek.org
Broxton has the same panel fitter registers as Skylake.
v2:
- add MISSING_CASE for future platforms (daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Sagar Kamble
Hi Dave,
One more drm-misch pull for 4.1 with mostly simple stuff and boring
refactoring. Even the cursor fix from Matt is just to make a really anal
igt happy.
Cheers, Daniel
The following changes since commit 502e95c6678505474f1056480310cd9382bacbac:
drm/vgem: implement virtual GEM
I ended up needing this bit too, so maybe better have it committed.
On ti, 2015-03-17 at 14:45 +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
It may save someone a bit of debugging time one day.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Hi Mika,
On Wed, Apr 15, 2015 at 04:07:10PM +0300, Mika Kahola wrote:
This patch series rebases Ville's original cdclk patch series
excluding the ones that have been reviewed.
I believe you still have the authorship problem in that series. It'll be
great to have it fixed so Daniel doesn't pull
On Wed, Apr 15, 2015 at 04:42:58PM +0300, Imre Deak wrote:
Extend the VLV/CHV DPIO (PHY) documentation with the BXT specifics.
v2:
- add more detail about the mapping between ports and transcoders (ville)
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä
Hi Daniel,
On 04/15/2015 03:17 AM, Daniel Vetter wrote:
This was a bit too much cargo-culted, so lets make it solid:
- vblank-count doesn't need to be an atomic, writes are always done
under the protection of dev-vblank_time_lock. Switch to an unsigned
long instead and update comments.
On Wed, Apr 15, 2015 at 04:07:10PM +0300, Mika Kahola wrote:
This patch series rebases Ville's original cdclk patch series
excluding the ones that have been reviewed.
http://lists.freedesktop.org/archives/intel-gfx/2014-November/055633.html
The patches include modifications to
BTW
Hi,
I forgot to update authorships. I'll fix this and resend the patch
series.
Thanks for pointing this out!
-Mika-
On Wed, 2015-04-15 at 14:16 +0100, Damien Lespiau wrote:
Hi Mika,
On Wed, Apr 15, 2015 at 04:07:10PM +0300, Mika Kahola wrote:
This patch series rebases Ville's original
From: Deepak S deepa...@linux.intel.com
This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.
v2: Define individual bits GTFIFOCTL (Ville)
v3: move WA to uncore_early_sanitize (ville)
Signed-off-by: Deepak S deepa...@linux.intel.com
---
On Wed, Apr 15, 2015 at 03:08:56PM +0100, Tvrtko Ursulin wrote:
On 04/14/2015 05:31 PM, Chris Wilson wrote:
In order to use userptr, the kernel tracks the owner's mm with a
mmu_notifier. Setting that is very expensive - it involves taking all
mm_locks and a stop_machine(). This tracking
Hi Dave -
As promised, here's a batch of fixes for drm-next/4.1.
BR,
Jani.
The following changes since commit 6e0aa8018f9c676b115b7ca6c20a056fc57c68a9:
Merge tag 'v4.0-rc6' into drm-intel-next (2015-03-30 16:37:08 +0200)
are available in the git repository at:
On Wed, Apr 15, 2015 at 11:02:33AM +0530, Sonika Jindal wrote:
The HDMI translation table is added back to bspec, so adding it,
and defaulting the 800mV+0dB entry.
The HDMI translation table was removed by following commit as per HW team's
recommendation:
commit 7ff446708bd1 (drm/i915/skl:
From: Vandana Kannan vandana.kan...@intel.com
Add CDCLK specific display clock initialization sequence as per BSpec.
Note that the CDCLK initialization/uninitialization are done at their
current place only for simplicity, in a future patch - when more of the
runtime PM features will be enabled -
Extend the VLV/CHV DPIO (PHY) documentation with the BXT specifics.
v2:
- add more detail about the mapping between ports and transcoders (ville)
Signed-off-by: Imre Deak imre.d...@intel.com
---
Documentation/DocBook/drm.tmpl | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 18 --
On Wednesday 15 April 2015 04:48 PM, Ville Syrjälä wrote:
On Wed, Apr 15, 2015 at 02:16:18PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.
v2: Define
From: Vandana Kannan vandana.kan...@intel.com
Add PHY specific display initialization sequence as per BSpec.
Note that the PHY initialization/uninitialization are done
at their current place only for simplicity, in a future patch - when more
of the runtime PM features will be enabled - these
This is used by the next commit to disable all planes on a crtc
without caring what type it is.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 38 +---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
To make it clear that it isn't called during crtc enable.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
This makes disabling planes more explicit.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/intel_display.c | 36 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 18 +--
drivers/gpu/drm/i915/intel_display.c | 196 --
drivers/gpu/drm/i915/intel_sprite.c | 25 +---
3 files changed, 134 insertions(+), 105
They're the same code, so why not?
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 158 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 -
drivers/gpu/drm/i915/intel_sprite.c | 68 ---
3
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 50
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_fbc.c | 2 +-
3 files changed, 29 insertions(+), 24 deletions(-)
Some of the flags that were used are still useful when transitioning
to atomic, so keep those around for now. This removes some of the
complications of crtc-primary_enabled, making it easier to remove.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
This allows disabling all planes affecting a crtc without caring what type it
is.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/intel_display.c | 91 ++--
2 files changed,
On Wed, Apr 15, 2015 at 04:42:57PM +0300, Imre Deak wrote:
From: Vandana Kannan vandana.kan...@intel.com
Add PHY specific display initialization sequence as per BSpec.
Note that the PHY initialization/uninitialization are done
at their current place only for simplicity, in a future patch -
On 4/14/2015 9:53 AM, Paulo Zanoni wrote:
2015-04-13 11:53 GMT-03:00 Todd Previte tprev...@gmail.com:
Adds in an EDID read after the DPCD read to accommodate test 4.2.2.1 in the
Displayport Link CTS Core 1.2 rev1.1. This test requires an EDID read for
all HPD plug events. To reduce the amount
Since the removal of the user pin_ioctl, the only means for pinning an
object is either through binding to the scanout or during execbuf
reservation. As the later prevents a call to set-tiling, we need only
check if the obj is pinned into the display plane to see if we need
reject the set-tiling
Hi Daniel,
I am having a look at this now, as have some time.
So, to sum up what I think you want.
1. Re-base and apply the patches (so that the known holes are closed in
the Nouveau driver).
2. Add DRIVER_KMS_LEGACY_CONTEXT to include/drm/drmP.h
3. Add DRIVER_KMS_LEGACY_CONTEXT to
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the
Adds in an EDID read after the DPCD read to accommodate test 4.2.2.1 in the
Displayport Link CTS Core 1.2 rev1.1. This test requires an EDID read for
all HPD plug events. To reduce the amount of code, this EDID read is also
used for Link CTS tests 4.2.2.3, 4.2.2.4, 4.2.2.5 and 4.2.2.6. Actual
This is the 6th iteration of the Displayport compliance testing patch set for
performing compliance testing operations of the i915 driver. High level changes
are listed below, with the specifics for each patch listed in the commit
messages.
Kernel:
Changes for V4:
- Removed the code for link
Update the hot plug function to handle the SST case. Instead of placing
the SST case within the long/short pulse block, it is now handled after
determining that MST mode is not in use. This way, the topology management
layer can handle any MST-related operations while SST operations are still
Updates the EDID compliance test function to perform the EDID read as
required by the tests. This read needs to take place in the kernel for
reasons of speed and efficiency. The results of the EDID read operations
are handed off to userspace so that the userspace app can set the display
mode
For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
This patch adds 3 debugfs files for handling Displayport compliance testing
and supercedes the previous patches that implemented debugfs support for
compliance testing. Those patches were:
- [PATCH 04/17] drm/i915: Add debugfs functions for Displayport
compliance testing
This patch is a combination of changes that does the following:
- Ignore disconnected Displayport connectors in check_link_status
- Move the DPCD read further up in intel_dp_check_link_status()
- Adds a new function that checks the HW HPD pin status
- Replace the
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that repeated AUX transactions after a failure (no response /
invalid response) must have a minimum delay of 400us before the resend can
occur. Tests 4.2.1.1 and 4.2.1.2 are two tests that require this specifically.
The debug message is missing a newline at the end and it makes the
logs hard to read when a device defers a lot. Simple 2-character fix
adds the newline at the end.
Signed-off-by: Todd Previte tprev...@gmail.com
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Paulo Zanoni
Add the skeleton framework for supporting automation for Displayport compliance
testing. This patch adds the necessary framework for the source device to
appropriately respond to test automation requests from a sink device.
V2:
- Addressed previous mailing list feedback
- Fixed compilation issue
Since the pin_ioctl is defunct, we only care about whether an object is
pinned into the display for debug purposes.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
WaIdleLiteRestore is an execlists-only workaround, and requires the driver
to ensure that any context always has HEAD!=TAIL when attempting lite
restore.
Add two extra MI_NOOP instructions at the end of each request, but keep
the requests tail pointing before the MI_NOOPs. We may not need to
WaIdleLiteRestore is an execlists-only workaround, and requires the driver
to ensure that any context always has HEAD!=TAIL when attempting lite
restore.
Add two extra MI_NOOP instructions at the end of each request, but keep
the requests tail pointing before the MI_NOOPs. We may not need to
On Wed, Apr 15, 2015 at 05:17:13PM +0100, Michel Thierry wrote:
WaIdleLiteRestore is an execlists-only workaround, and requires the driver
to ensure that any context always has HEAD!=TAIL when attempting lite
restore.
Add two extra MI_NOOP instructions at the end of each request, but keep
On 4/15/2015 5:40 PM, Chris Wilson wrote:
On Wed, Apr 15, 2015 at 05:17:13PM +0100, Michel Thierry wrote:
WaIdleLiteRestore is an execlists-only workaround, and requires the driver
to ensure that any context always has HEAD!=TAIL when attempting lite
restore.
Add two extra MI_NOOP instructions
Adds in an EDID read after the DPCD read to accommodate test 4.2.2.1 in the
Displayport Link CTS Core 1.2 rev1.1. This test requires an EDID read for
all HPD plug events. To reduce the amount of code, this EDID read is also
used for Link CTS tests 4.2.2.3, 4.2.2.4, 4.2.2.5 and 4.2.2.6. Actual
Let's know beforehand if PSR is ready and will be enabled so we can
prevent DRRS to get enabled.
v2: Removing is_edp_psr func that is not used after this patch.
Rename match_conditions and document it since it is now external.
Moving to a propper place as pointed out by Sivakumar.
Use
With PSR enabled being pre computed on pipe_config we can now
prevent DRRS to be enabled along with PSR.
v2: Rebase after changing previous patch
Cc: Ramalingam C ramalinga...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Reviewed-by: Ramalingam C ramalinga...@intel.com
---
On Wed, Apr 15, 2015 at 06:11:33PM +0100, Michel Thierry wrote:
WaIdleLiteRestore is an execlists-only workaround, and requires the driver
to ensure that any context always has HEAD!=TAIL when attempting lite
restore.
Add two extra MI_NOOP instructions at the end of each request, but keep
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the
Update the hot plug function to handle the SST case. Instead of placing
the SST case within the long/short pulse block, it is now handled after
determining that MST mode is not in use. This way, the topology management
layer can handle any MST-related operations while SST operations are still
Updates the EDID compliance test function to perform the EDID read as
required by the tests. This read needs to take place in the kernel for
reasons of speed and efficiency. The results of the EDID read operations
are handed off to userspace so that the userspace app can set the display
mode
On Wed, Apr 15, 2015 at 07:41:39PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.
v2: Define individual bits GTFIFOCTL (Ville)
v3: move WA to
On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
Hi Daniel,
On 04/15/2015 03:17 AM, Daniel Vetter wrote:
This was a bit too much cargo-culted, so lets make it solid:
- vblank-count doesn't need to be an atomic, writes are always done
under the protection of
Hi Daniel, hi Ville,
please find the reworked NS2501 DVO patch with changes as suggested
attached.
Unfortunately, the relation between the DVO scaler settings and the
actual mode
values remain still somewhat mysterious, so the mode settings remain a
table lookup
at this time. On the bright
On Wed, Apr 15, 2015 at 07:34:43PM +0200, Daniel Vetter wrote:
This was a bit too much cargo-culted, so lets make it solid:
- vblank-count doesn't need to be an atomic, writes are always done
under the protection of dev-vblank_time_lock. Switch to an unsigned
long instead and update
On Wed, 2015-04-15 at 17:15 +0300, Imre Deak wrote:
From: Satheeshakrishna M satheeshakrishn...@intel.com
PORT_CLK_SEL programming is needed only on HSW/BDW.
v2:
- don't program PORT_CLK_SEL from mst encoders either (imre)
v3:
- fix the check for GEN9+ in intel_mst_pre_enable_dp()
2015-04-15 12:37 GMT-03:00 Todd Previte tprev...@gmail.com:
On 4/14/2015 9:53 AM, Paulo Zanoni wrote:
2015-04-13 11:53 GMT-03:00 Todd Previte tprev...@gmail.com:
Adds in an EDID read after the DPCD read to accommodate test 4.2.2.1 in
the
Displayport Link CTS Core 1.2 rev1.1. This test
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6196
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
This was a bit too much cargo-culted, so lets make it solid:
- vblank-count doesn't need to be an atomic, writes are always done
under the protection of dev-vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile
2015-04-15 14:15 GMT-03:00 Todd Previte tprev...@gmail.com:
Displayport compliance test 4.2.2.6 requires that a source device be capable
of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6192
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Wed, Apr 15, 2015 at 04:07:23PM +0300, Mika Kahola wrote:
Limit CHV maximum cdclk to 320MHz.
Signed-off-by: Mika Kahola mika.kah...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1
2015-04-15 16:28 GMT-03:00 Todd Previte tprev...@gmail.com:
Move the DPCD read to the top and check for an interrupt from the sink to
catch
Displayport automated testing requests necessary to support Displayport
compliance testing. The checks for active connectors and link status are moved
Let's know beforehand if PSR is ready and will be enabled so we can
prevent DRRS to get enabled.
WARN_ON(!drm_modeset_is_locked(crtc-mutex)) on intel_psr_ready()
has been removed on v3. We don't dereferrence crtc here anymore so
we don't need this check. All configs are now checked from received
Move the DPCD read to the top and check for an interrupt from the sink to catch
Displayport automated testing requests necessary to support Displayport
compliance testing. The checks for active connectors and link status are moved
below the check for the interrupt.
The main reason for doing this
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6195
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6190
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -3
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6190
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -3
On Tue, Mar 17, 2015 at 11:39:55AM +0200, Imre Deak wrote:
From: Vandana Kannan vandana.kan...@intel.com
Rename vlv_cdclk_freq to cdclk_freq so that it can be used for all
platforms as required. Needed by the next patch.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
On Wed, Apr 15, 2015 at 04:07:24PM +0300, Mika Kahola wrote:
Combined Valleyview, Haswell and Broadwell '*_modeset_global_pipes()'
into one function 'intel_modeset_global_pipes()'
v2:
- we don't modify 'disable_pipes', so passing this as a pointer
is removed (based on Ville's comment)
-
Adds in an EDID read after the DPCD read to accommodate test 4.2.2.1 in the
Displayport Link CTS Core 1.2 rev1.1. This test requires an EDID read for
all HPD plug events. To reduce the amount of code, this EDID read is also
used for Link CTS tests 4.2.2.3, 4.2.2.4, 4.2.2.5 and 4.2.2.6. Actual
From: Imre Deak imre.d...@intel.com
Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across
suspend/resume, so fix this.
This was introduced in
commit ddeea5b0c36f3665446518c609be91f9336ef674
Author: Imre Deak imre.d...@intel.com
Date: Mon May 5 15:19:56 2014 +0300
Let userspace know the status of Panel Self-Refresh by virtue of a
property on the appropriate connector.
v2: Only attach the property if the driver is capable of PSR.
v3: Add docbook courtesy of Damien.
v4: Mark the initial value as 'unsupported' - it will be determined
correctly when we
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Remove pinned check from madvise_ioctl - Reviewer:
Patch drm/i915/vlv: check
From: Jesse Barnes jbar...@virtuousgeek.org
Same as IBX and G4x, they all share the same genetic material.
v2: we all need a bit more port in our lives
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
From: Mika Kuoppala mika.kuopp...@linux.intel.com
We just allocated the intel_ringbuffer with kzalloc. There
is no chance of the ringbuf-obj being other than NULL
so remove the redudant check.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
From: Gaurav K Singh gaurav.k.si...@intel.com
On CHT, changes are required for calculating the correct m,n p with
minimal error +/- for the required DSI clock, so that the correct dividor
ctrl values are written in cck regs for DSI. This patch has been tested
on CHT RVP with 1200 x 1920 panel.
From: Mika Kuoppala mika.kuopp...@linux.intel.com
commit 939fd762083f988be271da8c96398178daf9baf0
Author: Mika Kuoppala mika.kuopp...@linux.intel.com
Date: Thu Jan 30 19:04:44 2014 +0200
drm/i915: Get rid of acthd based guilty batch search
Failed to cleanup properly as it made the head
With frontbuffer tracking taking care of fbc
we were duplicating fbc update call on these cases here.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 12
drivers/gpu/drm/i915/intel_drv.h |
1 - 100 of 158 matches
Mail list logo
