aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2016-11-28drm/msm/rd: support for 64b iovaRob Clark1-2/+2
For backwards compat, the rd format puts the high 32b after the size field in the GPUADDR packet. Signed-off-by: Rob Clark <[email protected]>
2016-11-28drm/msm: convert iova to 64bRob Clark15-32/+34
For a5xx the gpu is 64b so we need to change iova to 64b everywhere. On the display side, iova is still 32b so it can ignore the upper bits. (Although all the armv8 devices have an iommu that can map 64b pa to 32b iova.) Signed-off-by: Rob Clark <[email protected]>
2016-11-28drm/edid: Consider alternate cea timings to be the same VICVille Syrjälä1-12/+54
CEA-861 specifies that the vertical front porch may vary by one or two lines for specific VICs. Up to now we've only considered a mode to match the VIC if it matched the shortest possible vertical front porch length (as that is the variant we store in cea_modes[]). Let's allow our VIC matching to work with the other timings variants as well so that that we'll send out the correct VIC if the variant actually used isn't the one with the shortest vertical front porch. Cc: Shashank Sharma <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Adam Jackson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Andrzej Hajda <[email protected]>
2016-11-28drm: bridge: dw-hdmi: add ASoC dependencyArnd Bergmann1-0/+1
The newly added sound driver depends on SND_SOC_HDMI_CODEC, which in turn only makes sense when ASoC is enabled, as shown by this warning: warning: (DRM_MSM && DRM_STI && DRM_MEDIATEK_HDMI && DRM_I2C_NXP_TDA998X && DRM_DW_HDMI_I2S_AUDIO) selects SND_SOC_HDMI_CODEC which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC) Since the audio driver is probably useless without the audio subsystem, adding a dependency here seems the right solution. Fixes: 2761ba6c0925 ("drm: bridge: add DesignWare HDMI I2S audio support") Acked-by: Kuninori Morimoto <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-11-28drm: Fix shift operations for drm_fb_helper::drm_target_preferred()Chris Wilson1-6/+7
smatch correctly warns: drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn: should '1 << i' be a 64 bit type? drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn: should '1 << i' be a 64 bit type? Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2016-11-28drm: Avoid NULL dereference for DRM_LEGACY debug messageChris Wilson1-1/+2
smatch warns: drivers/gpu/drm/drm_lock.c:188 drm_legacy_lock() warn: variable dereferenced before check 'master->lock.hw_lock' (see line 177) Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-11-28drm: Use u64_to_user_ptr() helper for blob ioctlsChris Wilson1-6/+6
Remove the ugly sparse casts by using the helper u64_to_user_ptr() instead. Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-11-28drm/nouveau: Queue hpd_work on (runtime) resumeHans de Goede1-1/+10
We need to call drm_helper_hpd_irq_event() on resume to properly detect monitor connection / disconnection on some laptops, use hpd_work for this to avoid deadlocks. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau: Rename acpi_work to hpd_workHans de Goede2-17/+17
We need to call drm_helper_hpd_irq_event() on resume to properly detect monitor connection / disconnection on some laptops. For runtime-resume (which gets called on resume from normal suspend too) we must call drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock. Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI blocks to make it suitable for generic work. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/kms/nv50: Fix atomic pageflip events.Mario Kleiner1-0/+2
The new atomic modesetting/pageflip code for nv50+ for Linux 4.10+ no longer uses pageflip irq's to signal flip completion. Instead it polls for flip completion from within a kthread/work queue. This creates a race between the vblank irq handler updating the vblank count and timestamp for the vblank of flip completion, and the kthread's polling code detecting flip completion and sending out the flip completion event. Depending on who executes a few microseconds earlier, the flip completion event will either contain correct count/timestamp or a stale count/timestamp from the previous vblank. This error was observed for about 50% of all executed flips, e.g., observable under DRI2 by the Xorg.log filling with flip handler warning messages. Call drm_accurate_vblank_count() before sending out flip completion events to enforce a vblank count/ts update for the vblank of flip completion and avoid stale counts/timestamps. This fix leads to one redundant call to drm_update_vblank_count for each completed flip, but no other side effects. On a ~6 year old Core i7 M620@ 2.67GHz the redundant call costs about 10 usecs per flip Successfully tested on GeForce 9500/9600/330M so far. Signed-off-by: Mario Kleiner <[email protected]> Cc: Ben Skeggs <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/fb/ram/gp100-: fix memory detection where FBP_NUM != FBPA_NUMBen Skeggs1-2/+2
In this situation, we'd have ended up detecting less VRAM than we have. Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/volt: pointers are 32-bitBen Skeggs3-17/+17
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/vmap: pointers are 32-bitBen Skeggs3-17/+17
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/timing: pointers are 32-bitBen Skeggs2-13/+13
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/therm: pointers are 32-bitBen Skeggs1-10/+10
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/perf: pointers are 32-bitBen Skeggs3-14/+16
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/iccsense: pointers are 32-bitBen Skeggs1-4/+4
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/fan: pointers are 32-bitBen Skeggs2-10/+10
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/cstep: pointers are 32-bitBen Skeggs3-23/+23
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-28drm/nouveau/bios/boost: pointers are 32-bitBen Skeggs3-23/+23
Signed-off-by: Ben Skeggs <[email protected]>
2016-11-27drm/msm: set dma_mask properlyRob Clark1-1/+7
Previous value really only made sense on armv7 without LPAE. Everything that supports more than 4g of memory also has iommu's that can map anything. Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm: Remove bad calls to of_node_put()Archit Taneja1-7/+2
In add_components_mdp, we parse the endpoints in MDP output ports using the helper for_each_endpoint_of_node(). Our function calls of_node_put() on the endpoint node before we iterate over the next one. This is already done by the helper, and results in trying to decrement the refcount twice. Remove the extra of_node_put calls. This fixes warnings seen when we try to insert the driver as a module on IFC6410. Reported-by: Ilia Mirkin <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: move LM bounds check into plane->atomic_check()Rob Clark2-2/+15
The mode_config->max_{width,height} is for the maximum size of a fb, not the max scanout limits (of the layer-mixer). It is legal, and in fact common, to create a larger fb, only only scan-out a smaller part of it. For example multi-monitor configurations for x11, or android wallpaper layer (which is created larger than the screen resolution for fast scrolling by just changing the src x/y coordinates). Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: dump smp state on errors tooRob Clark2-2/+6
If the dumpstate modparam is enabled, for debugging error irq's, also dump SMP state. Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: add debugfs to show smp block statusRob Clark6-3/+116
Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: handle SMP block allocations "atomically"Rob Clark7-245/+193
Previously, SMP block allocation was not checked in the plane's atomic_check() fxn, so we could fail allocation SMP block allocation at atomic_update() time. Re-work the block allocation to request blocks during atomic_check(), but not update the hw until committing the atomic update. Since SMP blocks allocated at atomic_check() time, we need to manage the SMP state as part of mdp5_state (global atomic state). This actually ends up significantly simplifying the SMP management, as the SMP module does not need to manage the intermediate state between assigning new blocks before setting flush bits and releasing old blocks after vblank. (The SMP registers and SMP allocation is not double-buffered, so newly allocated blocks need to be updated in kms->prepare_commit() released blocks in kms->complete_commit().) Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: dynamically assign hw pipes to planesRob Clark6-80/+172
(re)assign the hw pipes to planes based on required caps, and to handle situations where we could not modify an in-use plane (ie. SMP block reallocation). This means all planes advertise the superset of formats and properties. Userspace must (as always) use atomic TEST_ONLY step for atomic updates, as not all planes may be available for use on every frame. The mapping of hwpipe to plane is stored in mdp5_state, so that state updates are atomically committed in the same way that plane/etc state updates are managed. This is needed because the mdp5_plane_state keeps a pointer to the hwpipe, and we don't want global state to become out of sync with the plane state if an atomic update fails, we hit deadlock/ backoff scenario, etc. The use of state_lock keeps multiple parallel updates which both re-assign hwpipes properly serialized. Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: add skeletal mdp5_stateRob Clark2-0/+65
Add basic state duplication/apply mechanism. Following commits will move actual global hw state into this. The state_lock allows multiple concurrent updates to proceed as long as they don't both try to alter global state. The ww_mutex mechanism will trigger backoff in case of deadlock between multiple threads trying to update state. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Archit Taneja <[email protected]>
2016-11-27drm/msm: subclass drm_atomic_stateRob Clark4-0/+51
This will give the kms backends a slot to stash their own hw specific global state. Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: introduce mdp5_hw_pipeRob Clark7-87/+199
Split out the hardware pipe specifics from mdp5_plane. To start, the hw pipes are statically assigned to planes, but next step is to assign the hw pipes during plane->atomic_check() based on requested caps (scaling, YUV, etc). And then hw pipe re-assignment if required if required SMP blocks changes. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Archit Taneja <[email protected]>
2016-11-27drm/msm/mdp5: rip out mode_changedRob Clark2-21/+4
It wasn't really doing the right thing if, for example, position or height changed. Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: don't be so castyRob Clark1-5/+7
Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: drop mdp5_plane::nameRob Clark1-15/+11
Just use plane->name now that it is a thing. In a following patch, once we dynamically assign hw pipes to planes, it won't make sense to name planes the way we do, so this also partly reduces churn in following patch. Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: nuke mdp5_plane_complete_flip()Rob Clark3-23/+10
We can do this all from mdp5_plane_complete_commit(), so simplify things a bit and drop mdp5_plane_complete_flip(). Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: drop mdp5_crtc::nameRob Clark1-17/+11
Plane's (pipes) can be assigned dynamically with atomic, so it doesn't make much sense to name the pipe after it's primary plane. Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm/mdp5: small renameRob Clark1-4/+4
These are really plane-id's, not crtc-id's. Only connection to CRTCs is that they are used as primary-planes. Current name is just legacy from when we only supported RGB/primary planes. Lets pick a better name now. Signed-off-by: Rob Clark <[email protected]>
2016-11-27drm/msm: support multiple address spacesRob Clark16-80/+208
We can have various combinations of 64b and 32b address space, ie. 64b CPU but 32b display and gpu, or 64b CPU and GPU but 32b display. So best to decouple the device iova's from mmap offset. Signed-off-by: Rob Clark <[email protected]>
2016-11-26drm/msm/mdp5: clip img size to src sizeRob Clark1-2/+2
If fb dimensions are larger than what can be scanned out, but the src dimensions are not, the hw can still handle this. So clip. Signed-off-by: Rob Clark <[email protected]>
2016-11-26drm/msm: use DRM_DEBUG_DRIVER()Rob Clark1-2/+2
Signed-off-by: Rob Clark <[email protected]>
2016-11-26drm/msm/mdp5: 8x16 actually has 8 mixer stagesRob Clark1-1/+1
Signed-off-by: Rob Clark <[email protected]>
2016-11-26drm/msm/mdp5: no scaling support on RGBn pipes for 8x16Rob Clark2-7/+4
Looks like cut/paste error from the other device cfgs (which do support scaling on RGBn pipes). Signed-off-by: Rob Clark <[email protected]>
2016-11-26drm/msm/mdp5: handle non-fullscreen base plane caseRob Clark1-18/+28
If the bottom-most layer is not fullscreen, we need to use the BASE mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT). The blend_setup() code pretty much handled this already, we just had to figure this out in _atomic_check() and assign the stages appropriately. Also fix the case where there are zero enabled planes, where we also need to enable BORDER_OUT. Signed-off-by: Rob Clark <[email protected]>
2016-11-25drm/i915/guc: Remove spurious includeArkadiusz Hiler1-1/+0
Cc: Chris Wilson <[email protected]> Cc: Michal Winiarski <[email protected]> Signed-off-by: Arkadiusz Hiler <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Chris Wilson <[email protected]>
2016-11-25drm/i915/guc: Init send_mutex in intel_uc_init_early()Arkadiusz Hiler4-1/+8
send_mutex is used to serialise communication with GuC via intel_guc_send(). Since functions that utilize it are no longer limited to submission, initialization should be handled as a part of general setup. v2: move initialization to *_early() Cc: Chris Wilson <[email protected]> Cc: Michal Winiarski <[email protected]> Signed-off-by: Arkadiusz Hiler <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Chris Wilson <[email protected]>
2016-11-25drm/i915/guc: Move guc_{send,recv}() to intel_uc.cArkadiusz Hiler4-130/+163
guc_send(), guc_recv() and related functions were introduced in the i915_guc_submission.c and their scope was limited only to that file. Those are not submission specific though. This patch moves moves them to intel_uc.c with intel_ prefix added. v2: rename intel_guc_log_* functions and clean up intel_guc_send usages Cc: Chris Wilson <[email protected]> Cc: Michal Winiarski <[email protected]> Signed-off-by: Arkadiusz Hiler <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Chris Wilson <[email protected]>
2016-11-25drm/i915/guc: Drop guc2host/host2guc from namesArkadiusz Hiler5-76/+75
To facilitate code reorganization we are renaming everything that contains guc2host or host2guc. host2guc_action() and host2guc_action_response() become guc_send() and guc_recv() respectively. Other host2guc_*() functions become simply guc_*(). Other entities are renamed basing on context they appear in: - HOST2GUC_ACTIONS_& become INTEL_GUC_ACTION_* - HOST2GUC_{INTERRUPT,TRIGGER} become GUC_SEND_{INTERRUPT,TRIGGER} - GUC2HOST_STATUS_* become INTEL_GUC_STATUS_* - GUC2HOST_MSG_* become INTEL_GUC_RECV_MSG_* - action_lock becomes send_mutex v2: drop unnecessary backslashes and use BIT() instead of '<<' v3: shortened enum names and INTEL_GUC_STATUS_* Cc: Chris Wilson <[email protected]> Cc: Michal Winiarski <[email protected]> Signed-off-by: Arkadiusz Hiler <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]>
2016-11-25drm/i915: Rename intel_guc.h to intel_uc.hArkadiusz Hiler4-5/+5
GuC is not the only one micro controller we have. There are also HuC and DMC. Making the file more general will help with code organization. Cc: Chris Wilson <[email protected]> Cc: Michal Winiarski <[email protected]> Signed-off-by: Arkadiusz Hiler <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-11-25drm: hdlcd: Fix cleanup orderRobin Murphy1-1/+1
If hdlcd_drm_bind() fails at drm_fbdev_cma_init(), its cleanup will call drm_mode_config_cleanup() as if to balance drm_mode_config_reset(). The net result is that drm_connector_cleanup() will clean up the active connectors long before component_unbind_all() gets called, so when the connector later tries to clean up itself after being unbound, Bad Things can happen: [ 4.121888] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 4.129951] pgd = ffffff80091e0000 [ 4.133345] [00000000] *pgd=00000009ffffe003, *pud=00000009ffffe003, *pmd=0000000000000000 [ 4.141613] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 4.147144] Modules linked in: [ 4.150188] CPU: 0 PID: 122 Comm: kworker/u12:2 Not tainted 4.8.0-rc2+ #989 [ 4.157097] Hardware name: ARM Juno development board (r1) (DT) [ 4.162981] Workqueue: deferwq deferred_probe_work_func [ 4.168173] task: ffffffc975d93200 task.stack: ffffffc975dac000 [ 4.174055] PC is at drm_connector_cleanup+0x58/0x1c0 [ 4.179074] LR is at tda998x_unbind+0x24/0x40 [ 4.183401] pc : [<ffffff80084c46f0>] lr : [<ffffff800850414c>] pstate: 00000045 [ 4.190750] sp : ffffffc975dafa10 [ 4.194041] x29: ffffffc975dafa10 x28: ffffffc9768152a8 [ 4.199325] x27: ffffffc97ff46450 x26: ffffff8008d99000 [ 4.204608] x25: dead000000000100 x24: dead000000000200 [ 4.209891] x23: ffffffc976bf91e8 x22: 0000000000000000 [ 4.215172] x21: ffffffc976bf9170 x20: ffffffc976bf9170 [ 4.220454] x19: ffffffc976bf9018 x18: 0000000000000000 [ 4.225737] x17: 0000000074ce71ee x16: 000000008ff5d35f [ 4.231019] x15: ffffffc97681e91c x14: ffffffffffffffff [ 4.236301] x13: ffffffc97681e185 x12: 0000000000000038 [ 4.241583] x11: 0101010101010101 x10: 0000000000000000 [ 4.246866] x9 : 0000000040000000 x8 : 0000000000210d00 [ 4.252148] x7 : ffffffc97fea8c00 x6 : 000000000000001b [ 4.257430] x5 : ffffff80084b7b8c x4 : 0000000000000080 [ 4.262712] x3 : ffffff8008504128 x2 : ffffffc975df3800 [ 4.267993] x1 : 0000000000000000 x0 : 0000000000000000 ... [ 4.750937] [<ffffff80084c46f0>] drm_connector_cleanup+0x58/0x1c0 [ 4.756990] [<ffffff800850414c>] tda998x_unbind+0x24/0x40 [ 4.762354] [<ffffff8008507918>] component_unbind.isra.4+0x28/0x50 [ 4.768492] [<ffffff8008507a0c>] component_unbind_all+0xcc/0xd8 [ 4.774373] [<ffffff80084d5adc>] hdlcd_drm_bind+0x234/0x418 [ 4.779909] [<ffffff8008507b58>] try_to_bring_up_master+0x140/0x1a0 [ 4.786133] [<ffffff8008507c50>] component_add+0x98/0x170 [ 4.791496] [<ffffff8008504b90>] tda998x_probe+0x18/0x20 [ 4.796774] [<ffffff80086bf914>] i2c_device_probe+0x164/0x258 [ 4.802481] [<ffffff800850d094>] driver_probe_device+0x204/0x2b0 [ 4.808447] [<ffffff800850d28c>] __device_attach_driver+0x9c/0xf8 [ 4.814498] [<ffffff800850b108>] bus_for_each_drv+0x58/0x98 [ 4.820033] [<ffffff800850cd64>] __device_attach+0xc4/0x138 [ 4.825567] [<ffffff800850d338>] device_initial_probe+0x10/0x18 [ 4.831446] [<ffffff800850c124>] bus_probe_device+0x94/0xa0 [ 4.836981] [<ffffff800850c5b0>] deferred_probe_work_func+0x78/0xb0 [ 4.843207] [<ffffff80080d2998>] process_one_work+0x118/0x378 [ 4.848914] [<ffffff80080d2c40>] worker_thread+0x48/0x498 [ 4.854276] [<ffffff80080d8918>] kthread+0xd0/0xe8 [ 4.859036] [<ffffff8008082e90>] ret_from_fork+0x10/0x40 [ 4.864314] Code: f2fbd5b9 f2fbd5b8 f8478ee0 eb17001f (f9400013) [ 4.870472] ---[ end trace a643cfe4ce1d838b ]--- Fix this by moving the drm_mode_config_cleanup() much later such that it correctly balances drm_mode_config_init(). Suggested-by: Russell King <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
2016-11-25drm/i915: Don't sanitize has_decoupled_mmio if platform is not broxtonAnder Conselvan de Oliveira2-2/+2
The check in __intel_uncore_early_sanitize() to disable decoupled mmio would disable it for every platform that is not broxton. While that's not a problem now since only broxton supports that, simply setting .has_decoupled_mmio in a new platform's device info wouldn't suffice. So avoid future confusion and change the workaround to only change the value of has_decoupled_mmio for broxton. v2: git add compile fix. (Ander) Cc: Praveen Paneri <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Imre Deak <[email protected]> Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Imre Deak <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1479993807-29353-1-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-11-25drm/i915: Pass dev_priv to intel_setup_outputs()Ander Conselvan de Oliveira14-115/+105
Pass dev_priv to intel_setup_outputs() and functions called by it, since those are all intel i915 specific functions. Also, in the majority of the functions dev_priv is used more often than dev. In the rare cases where there are a few calls back into drm core, a local dev variable was added. v2: Don't convert dev to &dev_priv->drm in intel_dsi_init. (Ville) Signed-off-by: Ander Conselvan de Oliveira <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1479910904-11005-1-git-send-email-ander.conselvan.de.oliveira@intel.com
Powered by cgit, Gruvboxed by Blaster4385.