aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2016-08-10drm/amdgpu: remove unused VM definesChristian König1-2/+0
Not used for a long time. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-08-10drm/amd/amdgpu: Simplify bitfield operations in gfx v8Tom St Denis2-229/+47
This patch introduces a new macro WREG32_FIELD which is used to write to a register with a new value in a field. It's designed to replace the pattern: tmp = RREG32(mmFoo); tmp &= ~REG__FIELD_MASK; tmp |= new_value << REG__FIELD__SHIFT; WREG32(mmFoo, tmp) with: WREG32_FIELD(Foo, FIELD, new_value); Unlike WREG32_P() it understands offsets/masks and doesn't require the caller to shift the value (or mask properly). It's applied where suitable in the gfx_v8_0.c driver to start with. Signed-off-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-08-10drm/amd/amdgpu: Simplify various gfx v8 functionsTom St Denis1-41/+20
Signed-off-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-08-10drm/amd/amdgpu: Correct whitespace in GFX v8Tom St Denis1-25/+16
Fix various whitespace issues in gfx v8 driver. Signed-off-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-08-10drm/amdgpu: Change the virtual_display type from int to char*.Emily Deng5-7/+35
For virtual display feature, as there may be multiple GPUs, for user could choose whiche GPU need to enable this feature, change the type of virtual_display from int to char*. The variable will be set like this virtual_display="xxxx:xx:xx.x;xxxx:xx:xx.x;". Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-08-10drm/amdgpu: Fix memory trashing if UVD ring test failsJay Cornwall1-1/+2
fence_put was called on an uninitialized variable. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jay Cornwall <jay@jcornwall.me> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-08-10drm/i915: Move setting of request->batch into its single callsiteChris Wilson3-17/+13
request->batch_obj is only set by execbuffer for the convenience of debugging hangs. By moving that operation to the callsite, we can simplify all other callers and future patches. We also move the complications of reference handling of the request->batch_obj next to where the active tracking is set up for the request. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470832906-13972-2-git-send-email-chris@chris-wilson.co.uk
2016-08-10drm/i915: Mark unmappable GGTT entries as PIN_HIGHChris Wilson2-3/+4
We allocate a few objects into the GGTT that we never need to access via the mappable aperture (such as contexts, status pages). We can request that these are bound high in the VM to increase the amount of mappable aperture available. However, anything that may be frequently pinned (such as logical contexts) we want to use the fast search & insert. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470832906-13972-1-git-send-email-chris@chris-wilson.co.uk
2016-08-10drm/i915: Fix nesting of rps.mutex and struct_mutex during powersave initChris Wilson1-3/+2
During intel_gt_powersave_init() we take the RPS mutex to ensure that all locking requirements are met as we talk to the punit, but we also require the struct_mutex for allocating a slice of the global GTT for a power context on Valleyview. struct_mutex must be the outer lock here, as we nest rps.mutex inside later on. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 773ea9a80132 ("drm/i915: Perform static RPS frequency setup before...") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470833904-29886-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-08-10drm/i915: Flush GT idle status upon resetChris Wilson1-0/+3
Upon resetting the GPU, we force the engines to be idle by clearing their request lists. However, I neglected to clear the GT active status and so the next request following the reset was not marking the device as busy again. (We had to wait until any outstanding retire worker finally ran and cleared the active status.) Fixes: 67d97da34917 ("drm/i915: Only start retire worker when idle") Testcase: igt/pm_rps/reset Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468397438-21226-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit b913b33c43db849778f044d4b9e74b167898a9bc) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-08-10drm/i915: Remove LVDS and PPS suspend time save/restoreImre Deak2-38/+0
In the preceding patches we made sure that: - the LVDS encoder takes care of reiniting both the LVDS register and its PPS - the eDP encoder takes care of reiniting its PPS - the PPS register unlocking workaround is applied explicitly whenever the PPS context is lost Based on the above we can safely remove the opaque LVDS and PPS save / restore from generic code. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470827254-21954-6-git-send-email-imre.deak@intel.com
2016-08-10drm/i915: Apply the PPS register unlock workaround more consistentlyImre Deak6-9/+34
Atm, we apply this workaround somewhat inconsistently at the following points: driver loading, LVDS init, eDP PPS init, system resume. As this workaround also affects registers other than PPS (timing, PLL) a more consistent way is to apply it early after the PPS HW context is known to be lost: driver loading, system resume and on VLV/CHV/BXT when turning on power domains. This is needed by the next patch that removes saving/restoring of the PP_CONTROL register. This also removes the incorrect programming of the workaround on HSW+ PCH platforms which don't have the register locking mechanism. v2: (Ville) - Don't apply the workaround on BXT. - Simplify platform checks using HAS_DDI(). v3: - Move the call of intel_pps_unlock_regs_wa() to the more logical vlv_display_power_well_init() (also fixing CHV) (Ville). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470827254-21954-5-git-send-email-imre.deak@intel.com
2016-08-10drm/i915/dp: Restore PPS HW state from the encoder resume hookImre Deak1-15/+16
Similarly to the previous patch, initialize the PPS from the DP encoder's resume hook. Note that as opposed to LVDS we can't do this during encoder enabling, since we need the PPS for DP detection as well. The PPS init code is now the same for init and resume, so factor out a new intel_dp_pps_init() helper for this. v2: - Factor out intel_dp_pps_init() (Ville). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470827254-21954-4-git-send-email-imre.deak@intel.com
2016-08-10drm/i915/lvds: Restore initial HW state during encoder enablingImre Deak2-13/+102
Atm the LVDS encoder depends on the PPS HW context being saved/restored from generic suspend/resume code. Since the PPS is specific to the LVDS and eDP encoders a cleaner way is to reinitialize it during encoder enabling, so do this here for LVDS. Follow-up patches will init the PPS for the eDP encoder similarly and remove the suspend/resume time save / restore. v2: - Apply BSpec +1 offset and use DIV_ROUND_UP() when programming the power cycle delay. (Ville) v3: (Ville) - Fix +1 vs. round-up order. - s/reset_on_powerdown/powerdown_on_reset/ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470827254-21954-3-git-send-email-imre.deak@intel.com
2016-08-10drm/i915: Merge TARGET_POWER_ON and PANEL_POWER_ON flag definitionsImre Deak3-6/+5
These two flags mean the same thing, so remove the duplication. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470827254-21954-2-git-send-email-imre.deak@intel.com
2016-08-10drm/i915: Merge the PPS register definitionsImre Deak6-170/+117
The PPS registers are pretty much the same everywhere, the differences being: - Register fields appearing, disappearing from one platform to the next: panel-reset-on-powerdown, backlight-on, panel-port, register-unlock - Different register base addresses - Different number of PPS instances: 2 on VLV/CHV/BXT, 1 everywhere else. We can merge the separate set of PPS definitions by extending the PPS instance argument to all platforms and using instance 0 on platforms with a single instance. This means we'll need to calculate the register addresses dynamically based on the given platform and PPS instance. v2: - Simplify if ladder in intel_pps_get_registers(). (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470827254-21954-1-git-send-email-imre.deak@intel.com
2016-08-10drm/i915/guc: re-optimise i915_guc_client layoutDave Gordon2-5/+2
As we're tweaking the GuC-related code in debugfs, we can drop the no-longer-used 'q_fail' and repack the structure. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-08-10drm/i915/guc: use for_each_engine_id() where appropriateDave Gordon2-14/+17
Now that host structures are indexed by host engine-id rather than guc_id, we can usefully convert some for_each_engine() loops to use for_each_engine_id() and avoid multiple dereferences of engine->id. Also a few related tweaks to cache structure members locally wherever they're used more than once or twice, hopefully eliminating memory references. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-08-10drm/i915/guc: add engine mask to GuC client & pass to GuCDave Gordon2-6/+12
The Context Descriptor passed by the kernel to the GuC contains a field specifying which engine(s) the context will use. Historically, this was always set to "all of them", but if we had a separate client for each engine, we could be more precise, and set only the bit for the engine that the client was associated with. So this patch enables this usage, in preparation for having multiple clients, though at this point there is still only a single client used for all supported engines. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-08-10drm/i915/guc: refactor guc_init_doorbell_hw()Dave Gordon1-24/+30
We have essentially the same code in each of two different loops, so we can refactor it into a little helper function. This also reduces the amount of work done during startup, as we now only reprogram h/w found to be in a state other than that expected, and so avoid the overhead of setting doorbell registers to the state they're already in. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-08-10drm/i915/guc: doorbell reset should avoid used doorbellsDave Gordon1-1/+7
guc_init_doorbell_hw() borrows the (currently single) GuC client to use in reinitialising ALL the doorbell registers (as the hardware doesn't reset them when the GuC is reset). As a prerequisite for accommodating multiple clients, it should only reset doorbells that are supposed to be disabled, avoiding those that are marked as in use by any client. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-08-10drm/i915: Use RCU to annotate and enforce protection for breadcrumb's bhChris Wilson4-26/+27
The bottom-half we use for processing the breadcrumb interrupt is a task, which is an RCU protected struct. When accessing this struct, we need to be holding the RCU read lock to prevent it disappearing beneath us. We can use the RCU annotation to mark our irq_seqno_bh pointer as being under RCU guard and then use the RCU accessors to both provide correct ordering of access through the pointer. Most notably, this fixes the access from hard irq context to use the RCU read lock, which both Daniel and Tvrtko complained about. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470761272-1245-3-git-send-email-chris@chris-wilson.co.uk
2016-08-10drm/i915: Move missed interrupt detection from hangcheck to breadcrumbsChris Wilson6-67/+56
In commit 2529d57050af ("drm/i915: Drop racy markup of missed-irqs from idle-worker") the racy detection of missed interrupts was removed when we went idle. This however opened up the issue that the stuck waiters were not being reported, causing a test case failure. If we move the stuck waiter detection out of hangcheck and into the breadcrumb mechanims (i.e. the waiter) itself, we can avoid this issue entirely. This leaves hangcheck looking for a stuck GPU (inspecting for request advancement and HEAD motion), and breadcrumbs looking for a stuck waiter - hopefully make both easier to understand by their segregation. v2: Reduce the error message as we now run independently of hangcheck, and the hanging batch used by igt also counts as a stuck waiter causing extra warnings in dmesg. v3: Move the breadcrumb's hangcheck kickstart to the first missed wait. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97104 Fixes: 2529d57050af (waiter"drm/i915: Drop racy markup of missed-irqs...") Testcase: igt/drv_missed_irq Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470761272-1245-2-git-send-email-chris@chris-wilson.co.uk
2016-08-10drm/i915: Always mark the writer as also a read for busy ioctlChris Wilson1-4/+14
One of the few guarantees we want the busy ioctl to provide is that the reported busy writer is included in the set of busy read engines. This should be provided by the ordering of setting and retiring the active trackers, but we can do better by explicitly setting the busy read engine flag for the last writer. v2: More comments inside __busy_write_id() to explain why both fields are set. Fixes: 3fdc13c7a3cb ("drm/i915: Remove (struct_mutex) locking for busy-ioctl") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470762505-12799-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-09drm/amdgpu: fix vm init error pathChunming Zhou1-1/+4
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-08-09drm/dp_helper: Rate limit timeout errors from drm_dp_i2c_do_msg()Lyude1-1/+11
Timeouts can be errors, but timeouts are also usually normal behavior and happen a lot. Since the kernel already lets us know when we're suppressing messages due to rate limiting, rate limit timeout errors so we don't make too much noise in the kernel log. Signed-off-by: Lyude <cpaul@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470443443-27252-8-git-send-email-cpaul@redhat.com
2016-08-09drm/dp_helper: Print first error received on failure in drm_dp_dpcd_access()Lyude1-1/+1
Since we always retry in drm_dp_dpcd_access() regardless of the error, we're going to make a lot of noise if the aux->transfer function prints it's own errors (as is the case with radeon). If we can print the error code here, this reduces the need for drivers to do this. So instead of having to print "dp_aux_ch timed out" over 32 times we can just print once. Signed-off-by: Lyude <cpaul@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470443443-27252-2-git-send-email-cpaul@redhat.com
2016-08-09drm/i915: Correct typo for __i915_gem_active_get_rcu in a commentChris Wilson2-2/+2
I mistyped and added an extra _request_ to __i915_gem_active_get_rcu() Also, the same happened to another comment for i915_gem_active_get_rcu() Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470758602-1338-1-git-send-email-chris@chris-wilson.co.uk
2016-08-09drm/amdkfd: print doorbell offset as a hex valueColin Ian King1-1/+1
The doorbell offset is formatted with a 0x prefix to suggest it is a hexadecimal value, when in fact %d is being used and this is confusing. Use %X instead to match the proceeding 0x prefix. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2016-08-09Revert "drm/radeon: work around lack of upstream ACPI support for D3cold"Alex Deucher1-9/+0
This reverts commit bdfb76040068d960cb9e226876be8a508d741c4a. Now that d3cold is upstream, there is no more need for this workaround.
2016-08-09Revert "drm/amdgpu: work around lack of upstream ACPI support for D3cold"Alex Deucher1-9/+0
This reverts commit c63695cc5e5f685e924e25a8f9555f6e846f1fc6. Now that d3cold support is upstream, there is no more need for this workaround. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97248
2016-08-09drm/cirrus: Fix NULL pointer dereference when registering the fbdevBoris Brezillon1-2/+11
cirrus_modeset_init() is initializing/registering the emulated fbdev and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid"), DRM internals can access/test some of the fields in mode_config->funcs as part of the fbdev registration process. Make sure dev->mode_config.funcs is properly set to avoid dereferencing a NULL pointer. Reported-by: Mike Marshall <hubcap@omnibond.com> Reported-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Fixes: c61b93fe51b1 ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid") Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-09drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS".Mario Kleiner1-0/+14
According to E-EDID spec 1.3, table 3.9, a digital video sink with the "DFP 1.x compliant TMDS" bit set is "signal compatible with VESA DFP 1.x TMDS CRGB, 1 pixel / clock, up to 8 bits / color MSB aligned". For such displays, the DFP spec 1.0, section 3.10 "EDID support" says: "If the DFP monitor only supports EDID 1.X (1.1, 1.2, etc.) without extensions, the host will make the following assumptions: 1. 24-bit MSB-aligned RGB TFT 2. DE polarity is active high 3. H and V syncs are active high 4. Established CRT timings will be used 5. Dithering will not be enabled on the host" So if we don't know the bit depth of the display from additional colorimetry info we should assume 8 bpc / 24 bpp by default. This patch adds info->bpc = 8 assignement for that case. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-09drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"Mario Kleiner1-15/+5
This reverts commit 013dd9e03872 ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown") This commit introduced a regression into stable kernels, as it reduces output color depth to 6 bpc for any video sink connected to a Displayport connector if that sink doesn't report a specific color depth via EDID, or if our EDID parser doesn't actually recognize the proper bpc from EDID. Affected are active DisplayPort->VGA converters and active DisplayPort->DVI converters. Both should be able to handle 8 bpc, but are degraded to 6 bpc with this patch. The reverted commit was meant to fix Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331 A followup patch implements a fix for that specific bug, which is caused by a faulty EDID of the affected DP panel by adding a new EDID quirk for that panel. DP 18 bpp fallback handling and other improvements to DP sink bpc detection will be handled for future kernels in a separate series of patches. Please backport to stable. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-09drm/edid: Add 6 bpc quirk for display AEO model 0.Mario Kleiner1-0/+8
Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331 reports that the "AEO model 0" display is driven with 8 bpc without dithering by default, which looks bad because that panel is apparently a 6 bpc DP panel with faulty EDID. A fix for this was made by commit 013dd9e03872 ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown"). That commit triggers new regressions in precision for DP->DVI and DP->VGA displays. A patch is out to revert that commit, but it will revert video output for the AEO model 0 panel to 8 bpc without dithering. The EDID 1.3 of that panel, as decoded from the xrandr output attached to that bugzilla bug report, is somewhat faulty, and beyond other problems also sets the "DFP 1.x compliant TMDS" bit, which according to DFP spec means to drive the panel with 8 bpc and no dithering in absence of other colorimetry information. Try to make the original bug reporter happy despite the faulty EDID by adding a quirk to mark that panel as 6 bpc, so 6 bpc output with dithering creates a nice picture. Tested by injecting the edid from the fdo bug into a DP connector via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering is selected. This patch should be backported to stable. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-08drm/tilcdc: Change tilcdc_crtc_page_flip() to tilcdc_crtc_update_fb()Jyri Sarha3-9/+6
Change tilcdc_crtc_page_flip() to tilcdc_crtc_update_fb(). The function is not used as a page_flip() callback anymore so it is only confusing to call it that. The function should only be used by dummy primary plane commit() callback. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Remove unnecessary pm_runtime_get() and *_put() callsJyri Sarha1-8/+0
Remove unnecessary pm_runtime_get() and *_put() calls from commit phase callbacks. Those calls are not needed since we have the whole commit phase between pm_runtime_get_sync() and pm_runtime_put_sync(). Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Get rid of legacy dpms mechanismJyri Sarha3-70/+50
Get rid of legacy dpms mechanism. This simplifies the code quite a bit. The old start() and stop() functions become tilcdc_crtc_enable() and *_disable(). The functions are added with all the necessary mechanisms from the old dpms function and they are used directly as the crtc helper enable() and disable() callbacks. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Use drm_atomic_helper_resume/suspend()Jyri Sarha2-53/+9
Use drm_atomic_helper_resume/suspend() and get rid off all the obsolete register level context restoring code. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Enable and disable interrupts in crtc start() and stop()Jyri Sarha2-48/+39
Enable and disable interrupts in crtc start() and stop(). None of the interrupts can fire if CRTC is disabled, so it is cleaner - when considering suspend/resume code etc. - to enable the interrupts when CRTC is turned on and to disable them when CRTC is turned off. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: tfp410: Add atomic modeset helpers to connector funcsJyri Sarha1-1/+5
Add atomic modeset helpers to tfp410 connector funcs. Property handling related helpers, atomic reset helper, and new dpms helper is needed in connector for atomic modeseting to work. The default helper functions are enough. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: tfp410: Set crtc panel info at init phaseJyri Sarha1-1/+1
Set crtc panel info at init phase. Setting it at prepare callback does it multiple times for no good reason and it is also too late when atomic modeset is used. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: panel: Add atomic modeset helpers to connector funcsJyri Sarha1-1/+5
Add atomic modeset helpers to panel connector funcs. Property handling related helpers, atomic reset helper, and new dpms helper is needed in connector for atomic modeseting to work. The default helper functions are enough. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: panel: Set crtc panel info at init phaseJyri Sarha1-2/+3
Set crtc panel info at init phase. Setting it at prepare callback does it multiple times for no good reason and it is also too late when atomic modeset is used. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Remove tilcdc_verify_fb()Jyri Sarha1-21/+0
Remove tilcdc_verify_fb(). The tilcdc_verify_fb() function is not needed because the same checks are implemented in tilcdc_plane_atomic_check(). Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Remove obsolete crtc helper functionsJyri Sarha1-208/+0
Remove obsolete crtc helper functions. These are not needed when atomic modeset is used. Note that the drm_crtc_helper_funcs mode_fixup() is still needed. The crtc's check() callback can not do its job here. The plane's check() callback needs to set drm_crtc_state's ->mode_changed to true if the pixel format for the framebuffer changes. Because of this drm_mode_config_funcs atomic_check() callback needs to call drm_atomic_helper_check_modeset() once more after it has called drm_atomic_helper_check_planes(). If the fixing of the adjusted_mode would be done in drm_crtc_helper_funcs atomic_check() callback, it would get over written by the extra drm_atomic_helper_check_modeset() call. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Set DRIVER_ATOMIC and use atomic crtc helpersJyri Sarha2-8/+14
Set DRIVER_ATOMIC and use atomic helpers and rename commit and prepare crtc helpers to enable and disable. This makes the final jump to mode setting, but there is lot of obsolete code to clean up. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Add drm_mode_config_reset() call to tilcdc_load()Jyri Sarha1-0/+3
Add drm_mode_config_reset() call to tilcdc_load(). This is need to initialize atomic state variables at load time. Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Add atomic mode config funcsJyri Sarha1-0/+71
Add atomic mode config funcs. The atomic_commit implementation is a copy-paste from drm_atomic_helper_commit(), leaving out the async test. The similar copy-paste implementation appears to be used in many other drivers too. The standard drm_atomic_helper_check() is used for checking. The drm_atomic_helper_check() can not be used in drm_mode_config_funcs atomic_check() callback because the plane's check implementation may update crtc state's ->mode_changed flag. Because of this the drm_atomic_helper_check_modeset() has to be called once more after drm_atomic_helper_check_planes() (see drm_atomic_helper_check_modeset() documentation). Signed-off-by: Jyri Sarha <jsarha@ti.com>
2016-08-08drm/tilcdc: Add tilcdc_crtc_atomic_check()Jyri Sarha1-0/+27
Add tilcdc_crtc_atomic_check(). Checks the display mode validity and the presence of the mandatory primary plane. The drm_crtc_helper_funcs mode_fixup() callback is left untouched and the check function does no try to do its job on purpose, despite what the mode_fixup() callback's documentations suggests. The plane's check() callback needs to set drm_crtc_state's ->mode_changed to true if the pixel format for the framebuffer changes. Because of this drm_mode_config_funcs atomic_check() callback needs to call drm_atomic_helper_check_modeset() once more after it has called drm_atomic_helper_check_planes(). If the fixing of the adjusted_mode would be done in drm_crtc_helper_funcs atomic_check() callback, it would get over written by the extra drm_atomic_helper_check_modeset() call. Signed-off-by: Jyri Sarha <jsarha@ti.com>