aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-09-09drm/i915: Reorder i915_add_request to separate the phases betterChris Wilson1-14/+14
Let's avoid mixing sealing the hardware commands for the request and adding the request to the software tracking. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Drive request submission through fence callbacksChris Wilson7-4/+48
Drive final request submission from a callback from the fence. This way the request is queued until all dependencies are resolved, at which point it is handed to the backend for queueing to hardware. At this point, no dependencies are set on the request, so the callback is immediate. A side-effect of imposing a heavier-irqsafe spinlock for execlist submission is that we lose the softirq enabling after scheduling the execlists tasklet. To compensate, we manually kickstart the softirq by disabling and enabling the bh around the fence signaling. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Reviewed-by: John Harrison <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Update reset path to fix incomplete requestsChris Wilson10-99/+185
Update reset path in preparation for engine reset which requires identification of incomplete requests and associated context and fixing their state so that engine can resume correctly after reset. The request that caused the hang will be skipped and head is reset to the start of breadcrumb. This allows us to resume from where we left-off. Since this request didn't complete normally we also need to cleanup elsp queue manually. This is vital if we employ nonblocking request submission where we may have a web of dependencies upon the hung request and so advancing the seqno manually is no longer trivial. ABI: gem_reset_stats / DRM_IOCTL_I915_GET_RESET_STATS We change the way we count pending batches. Only the active context involved in the reset is marked as either innocent or guilty, and not mark the entire world as pending. By inspection this only affects igt/gem_reset_stats (which assumes implementation details) and not piglit. ARB_robustness gives this guide on how we expect the user of this interface to behave: * Provide a mechanism for an OpenGL application to learn about graphics resets that affect the context. When a graphics reset occurs, the OpenGL context becomes unusable and the application must create a new context to continue operation. Detecting a graphics reset happens through an inexpensive query. And with regards to the actual meaning of the reset values: Certain events can result in a reset of the GL context. Such a reset causes all context state to be lost. Recovery from such events requires recreation of all objects in the affected context. The current status of the graphics reset state is returned by enum GetGraphicsResetStatusARB(); The symbolic constant returned indicates if the GL context has been in a reset state at any point since the last call to GetGraphicsResetStatusARB. NO_ERROR indicates that the GL context has not been in a reset state since the last call. GUILTY_CONTEXT_RESET_ARB indicates that a reset has been detected that is attributable to the current GL context. INNOCENT_CONTEXT_RESET_ARB indicates a reset has been detected that is not attributable to the current GL context. UNKNOWN_CONTEXT_RESET_ARB indicates a detected graphics reset whose cause is unknown. The language here is explicit in that we must mark up the guilty batch, but is loose enough for us to relax the innocent (i.e. pending) accounting as only the active batches are involved with the reset. In the future, we are looking towards single engine resetting (with minimal locking), where it seems inappropriate to mark the entire world as innocent since the reset occurred on a different engine. Reducing the information available means we only have to encounter the pain once, and also reduces the information leaking from one context to another. v2: Legacy ringbuffer submission required a reset following hibernation, or else we restore stale values to the RING_HEAD and walked over stolen garbage. v3: GuC requires replaying the requests after a reset. v4: Restore engine IRQ after reset (so waiters will be woken!) Rearm hangcheck if resetting with a waiter. Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Arun Siluvery <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Replace wait-on-mutex with wait-on-bit in reset workerChris Wilson3-20/+27
Since we have a cooperative mode now with a direct reset, we can avoid the contention on struct_mutex and instead try then sleep on the I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is cleared, all is fine. Otherwise, we sleep for a bit and try again. In the worst case we sleep for an extra second waiting for the mutex to be released (no one touching the GPU is allowed the struct_mutex whilst the I915_RESET_IN_PROGRESS bit is set). But when we have a direct reset, this allows us to clean up the reset worker faster. v2: Remember to call wake_up_bit() after changing (for the faster wakeup as promised) Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Perform a direct reset of the GPU from the waiterChris Wilson5-20/+40
If a waiter is holding the struct_mutex, then the reset worker cannot reset the GPU until the waiter returns. We do not want to return -EAGAIN form i915_wait_request as that breaks delicate operations like i915_vma_unbind() which often cannot be restarted easily, and returning -EIO is just as useless (and has in the past proven dangerous). The remaining WARN_ON(i915_wait_request) serve as a valuable reminder that handling errors from an indefinite wait are tricky. We can keep the current semantic that knowing after a reset is complete, so is the request, by performing the reset ourselves if we hold the mutex. uevent emission is still handled by the reset worker, so it may appear slightly out of order with respect to the actual reset (and concurrent use of the device). Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Mark up all locked waitersChris Wilson8-14/+38
In the next patch we want to handle reset directly by a locked waiter in order to avoid issues with returning before the reset is handled. To handle the reset, we must first know whether we hold the struct_mutex. If we do not hold the struct_mtuex we can not perform the reset, but we do not block the reset worker either (and so we can just continue to wait for request completion) - otherwise we must relinquish the mutex. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Expand bool interruptible to pass flags to i915_wait_request()Chris Wilson12-32/+37
We need finer control over wakeup behaviour during i915_wait_request(), so expand the current bool interruptible to a bitmask. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Drop local struct_mutex around intel_init_emon[ilk]Chris Wilson1-2/+0
Access to intel_init_emon() is strictly ordered by gt_powersave, using struct_mutex around it is overkill (and will conflict with the caller holding struct_mutex themselves). Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Separate out reset flags from the reset counterChris Wilson8-117/+101
In preparation for introducing a per-engine reset, we can first separate the mixing of the reset state from the global reset counter. The loss of atomicity in updating the reset state poses a small problem for handling the waiters. For requests, this is solved by advancing the seqno so that a waiter waking up after the reset knows the request is complete. For pending flips, we still rely on the increment of the global reset epoch (as well as the reset-in-progress flag) to signify when the hardware was reset. The advantage, now that we do not inspect the reset state during reset itself i.e. we no longer emit requests during reset, is that we can use the atomic updates of the state flags to ensure that only one reset worker is active. v2: Mika spotted that I transformed the i915_gem_wait_for_error() wakeup into a waiter wakeup. Signed-off-by: Chris Wilson <[email protected]> Cc: Arun Siluvery <[email protected]> Cc: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Simplify ELSP queue request trackingChris Wilson7-264/+184
Emulate HW to track and manage ELSP queue. A set of SW ports are defined and requests are assigned to these ports before submitting them to HW. This helps in cleaning up incomplete requests during reset recovery easier especially after engine reset by decoupling elsp queue management. This will become more clear in the next patch. In the engine reset case we want to resume where we left-off after skipping the incomplete batch which requires checking the elsp queue, removing element and fixing elsp_submitted counts in some cases. Instead of directly manipulating the elsp queue from reset path we can examine these ports, fix up ringbuffer pointers using the incomplete request and restart submissions again after reset. Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Arun Siluvery <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Reorder submitting the requests to ELSPChris Wilson1-38/+38
Just rearrange the code to reduce churn in the next patch. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Compute the ELSP register location onceChris Wilson1-9/+7
Similar to the issue with reading from the context status buffer, see commit 26720ab97fea ("drm/i915: Move CSB MMIO reads out of the execlists lock"), we frequently write to the ELSP register (4 writes per interrupt) and know we hold the required spinlock and forcewake throughout. We can further reduce the cost of writing these registers beyond the I915_WRITE_FW() by precomputing the address of the ELSP register. We also note that the subsequent read serves no purpose here, and are happy to see it go. v2: Address I915_WRITE mistakes in changelog text data bss dec hex filename 1259784 4581 576 1264941 134d2d drivers/gpu/drm/i915/i915.ko 1259720 4581 576 1264877 134ced drivers/gpu/drm/i915/i915.ko Saves 64 bytes of address recomputation. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Record the position of the workarounds in the tail of the requestChris Wilson2-8/+11
Rather than blindly assuming we need to advance the tail for resubmitting the request via the ELSP, record the position. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Only queue requests during execlists submissionChris Wilson1-24/+4
Leave the more complicated request dequeueing to the tasklet and instead just kick start the tasklet if we detect we are adding the first request. v2: Play around with list operators until we agree upon something Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-09drm/i915: Add a sw fence for collecting up dma fencesChris Wilson3-0/+428
This is really a core kernel struct in disguise until we can finally place it in kernel/. There is an immediate need for a fence collection mechanism that is more flexible than fence-array, in particular being able to easily drive request submission via events (and not just interrupt driven). The same mechanism would be useful for handling nonblocking and asynchronous atomic modesets, parallel execution and more, but for the time being just create a local sw fence for execbuf. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-08drm/sun4i: add missing header dependenciesBaoyou Xie3-0/+3
We get 5 warnings when building kernel with W=1: drivers/gpu/drm/sun4i/sun4i_framebuffer.c:33:23: warning: no previous prototype for 'sun4i_framebuffer_init' [-Wmissing-prototypes] drivers/gpu/drm/sun4i/sun4i_framebuffer.c:47:6: warning: no previous prototype for 'sun4i_framebuffer_free' [-Wmissing-prototypes] drivers/gpu/drm/sun4i/sun4i_rgb.c:202:5: warning: no previous prototype for 'sun4i_rgb_init' [-Wmissing-prototypes] drivers/gpu/drm/sun4i/sun4i_dotclock.c:151:5: warning: no previous prototype for 'sun4i_dclk_create' [-Wmissing-prototypes] drivers/gpu/drm/sun4i/sun4i_dotclock.c:186:5: warning: no previous prototype for 'sun4i_dclk_free' [-Wmissing-prototypes] In fact, these functions are declared in drivers/gpu/drm/sun4i/sun4i_framebuffer.h, drivers/gpu/drm/sun4i/sun4i_rgb.h, drivers/gpu/drm/sun4i/sun4i_dotclock.h, so this patch adds missing header dependencies. Signed-off-by: Baoyou Xie <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
2016-09-08drm: Fix error path in drm_mode_page_flip_ioctl()Imre Deak1-1/+1
This fixes the error path for platforms that don't define the new page_flip_target() hook. Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2") Testcase: igt/kms_flip/basic-flip-vs-dpms CC: Michel Dänzer <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-09-08drm/sun4i: Add a DRC driverMaxime Ripard3-1/+143
The A33 pipeline also has a component called DRC. Even though its exact features and programming model is not known (or documented), it needs to be clocked for the pipeline to carry the video signal all the way. Add a minimal driver for it that just claim the needed resources for the pipeline to operate properly. Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Chen-Yu Tsai <[email protected]> Acked-by: Peter Korsgaard <[email protected]>
2016-09-08drm/sun4i: backend: Handle the SATMaxime Ripard3-0/+71
The A33 has an block called SAT that is part of the backend that needs to be clocked and out of reset to be able for the backend to operate properly. Extend the binding to have the SAT resources listed, and claim them when the backend probes. Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Chen-Yu Tsai <[email protected]>
2016-09-08drm/sun4i: support A33 tconMaxime Ripard4-6/+22
The A33 has a significantly different pipeline, with components that differ too. Make sure we had compatible for them. Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Chen-Yu Tsai <[email protected]>
2016-09-08drm/sun4i: support TCONs without channel 1Maxime Ripard2-13/+23
Some Allwinner SoCs, such as the A33, have a variation of the TCON that doesn't have a second channel (or it is not wired to anything). Make sure we can handle that case. Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Chen-Yu Tsai <[email protected]>
2016-09-07drm/i915: Move HAS_GUC definition to platform definitionCarlos Santa2-1/+7
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platform - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Make HWS_NEEDS_PHYSICAL the exceptionCarlos Santa4-23/+30
Make the .hws_needs_physical the exception by switching the flag on earlier platforms since they are fewer to support. Remove the flag on later GPUs hardware since they all use GTT hws by default. Switch the logic as well in the driver to reflect this change Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_GMCH_DISPLAY definition to platformCarlos Santa2-2/+7
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_L3_DPF definition to platform definitionCarlos Santa2-1/+6
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platformCarlos Santa2-2/+6
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_HW_CONTEXTS definition to platformCarlos Santa2-1/+7
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Introduce GEN2_FEATURES for device infoCarlos Santa1-20/+15
Introducing a GEN2_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for 830, 845g, i85x, i865g. CC: Ben Widawsky <[email protected]> Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Introduce GEN3_FEATURES for device infoCarlos Santa1-24/+18
Introducing a GEN3_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for i915g, i915gm, i945g, i945gm, g33 and pnv. CC: Ben Widawsky <[email protected]> Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Introduce GEN4_FEATURES for device infoCarlos Santa1-18/+18
Introducing a GEN4_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for i965g, i965gm, g45 and gm45. CC: Ben Widawsky <[email protected]> Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_GMBUS_IRQ definition to platform definitionCarlos Santa2-1/+8
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Introduce GEN5_FEATURES for device infoCarlos Santa1-11/+10
Introducing a GEN5_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for ilk. CC: Ben Widawsky <[email protected]> Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_DP_MST definition to platform definitionCarlos Santa2-2/+4
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_RC6p definition to platform definitionCarlos Santa2-1/+5
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_RC6 definition to platform definitionCarlos Santa2-1/+7
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definitionCarlos Santa2-2/+5
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915 Move HAS_CSR definition to platform definitionCarlos Santa2-1/+7
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Get rid of HAS_CORE_RING_FREQCarlos Santa2-5/+1
No need for HAS_CORE_RING_FREQ as that flag is actually the same as .has_llc. Feedback from V. Syrjala. Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Remove runtime PM for SNBCarlos Santa1-1/+0
Remove runtime PM support for SNB as it breaks hotplug support. Feedback from V. Syrjala. Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_RUNTIME_PM definition to platformCarlos Santa2-5/+8
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Introduce GEN6_FEATURES for device infoCarlos Santa1-14/+12
Introducing a GEN6_FEAUTRES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for snb. CC: Ben Widawsky <[email protected]> Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Remove .is_mobile field from platform structCarlos Santa3-67/+25
As recommended by Ville Syrjala removing .is_mobile field from the platform struct definition for vlv and hsw+ GPUs as there's no need to make the distinction in later hardware anymore. Keep it for older GPUs as it is still needed for ilk-ivb. Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Move HAS_PSR definition to platform struct definitionCarlos Santa2-4/+6
[patch series] Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definition Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Split hsw_get_dpll()Manasi Navare2-33/+63
Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code that calculates the pll so that it doesn't depend on crtc state. This will be used for acquiring port pll when doing upfront link training. Reviewed-by: Durgadoss R <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Split skl_get_dpll()Jim Bride2-48/+87
Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code does not directly depend on crtc state, so that the code can be used for upfront link training. Reviewed-by: Manasi Navare <[email protected]> Signed-off-by: Jim Bride <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Split bxt_ddi_pll_select()Durgadoss R2-66/+105
Split out of bxt_ddi_pll_select() the logic that calculates the pll dividers and dpll_hw_state into a new function that doesn't depend on crtc state. This will be used for enabling the port pll when doing upfront link training. v2: * Refactored code so that bxt_clk_div need not be exported (Durga) v1: * Rebased on top of intel_dpll_mgr.c (Durga) * Initial version from Ander on top of intel_ddi.c Reviewed-by: Manasi Navare <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Signed-off-by: Durgadoss R <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versionsManasi Navare1-45/+60
Split intel_ddi_pre_enable() into encoder type specific versions that don't depend on crtc_state. The necessary parameters are passed as function arguments. This split will be necessary for implementing DP upfront link training. v3: * Rebased onto latest kernel (Manasi) v2: * Rebased onto kernel v4.7 (Jim) Reviewed-by: Durgadoss R <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Signed-off-by: Jim Bride <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Remove ddi_pll_sel from intel_crtc_stateAnder Conselvan de Oliveira5-81/+45
The value of ddi_pll_sel is derived from the selection of shared dpll, so just calculate the final value when necessary. v2: Actually remove it from crtc state and delete remaining usages. (CI) Reviewed-by: Durgadoss R <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07drm/i915: Don't pass crtc_state to intel_dp_set_link_params()Ander Conselvan de Oliveira4-9/+19
Decouple intel_dp_set_link_params() from struct intel_crtc_state. This will be useful for implementing DP upfront link training. v2: * Rebased on atomic state changes (Manasi) Reviewed-by: Durgadoss R <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2016-09-07ARM: dts: am335x-boneblack: Add HDMI audio supportJyri Sarha1-4/+67
Add HDMI audio support. Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, sound node, and updates the tda19988 node to follow the new binding. Signed-off-by: Jyri Sarha <[email protected]> Signed-off-by: Russell King <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.