Commit Graph

18042 Commits

Author SHA1 Message Date
Thierry Reding
f1c37e1adc drm/plane: Pass old state to ->atomic_update()
In most situations it will be useful to have the old state passed to the
->atomic_update() callback. For example if a plane is being disabled the
new state's .crtc field will be NULL, but some drivers may rely on this
field to program the CRTCs registers.

v2: rename variable to old_plane_state and remove redundant comment as
suggested by Daniel Vetter, remove an Exynos hunk that doesn't apply to
drm-next and add a hunk for pending MSM mdp5 changes

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-25 13:27:58 +01:00
Jasper St. Pierre
aa54e2ee80 drm/atomic_helper: Cope with plane->crtc == NULL in disable helper
The drm core can call the plane disable hook multiple times, which
means it can get called when plane->crtc is already NULL. That in turn
means we can't get at the implicit acquire ctx we use in the atomic
helpers for legacy entries points.

We could try to pass drm_modeset_legacy_acquire_ctx a drm_device
pointer so that it can cope with a NULL crtc. But that still doesn't
work since the cursor ioctls (remapped with the universal cursor plane
support code) only grabs the crtc locks. So the global acquire context
isn't set eitehr.

The real solution here would be to bite the bullet and wire up
explicit acquire context parameters to all relevant functions. We need
to do that anyway (to be able to get rid of some small allocations
which we can't cope with failing). But that's a lot of work and better
done once atomic has settled a bit.

So meanwhile just catch this case in the helper and bail out.

Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Completely rewrite commit message and comment but keep
Jasper's logic and author credits since his patch is the only
short-term solution that works.]
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-25 13:12:43 +01:00
Daniel Vetter
9c04b7e369 drm/atomic: Drop per-plane locking TODO
I've forgotten to remove that in my per-plane locking patch.

Reported-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-25 13:12:43 +01:00
Daniel Vetter
ab58e3384b drm/atomic-helper: Skip vblank waits for unchanged fbs
Especially with legacy cursor ioctls existing userspace assumes that
you can pile up lots of updates in one go. The super-proper way to
support this would be a special commit mode which overwrites the last
update. But getting there will be quite a bit of work.

Meanwhile do what pretty much all the drivers have done for the plane
update functions: Simply skip the vblank wait for the buffer cleanup
if the buffer is the same. Since the universal cursor plane code will
not recreate framebuffers needlessly this allows us to not slow down
legacy pageflip events while someone moves the cursor around.

v2: Drop the async plane update hunk from a previous attempt at this
issue.

v3: Fix up kerneldoc.

v4: Don't oops so badly. Reported by Jasper.

Cc: Rob Clark <robdclark@gmail.com>
Cc: "Jasper St. Pierre" <jstpierre@mecheye.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Tested-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-25 13:12:42 +01:00
Daniel Vetter
b0ff4b93f6 drm: Document that drm_dev_alloc doesn't need a parent
Possible for purely virtual debug devices.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-25 13:12:42 +01:00
Dan Carpenter
e048a0b260 amdkfd: fix an error handling bug in pqm_create_queue()
The call to kernel_queue_uninit(NULL) will trigger a BUG(), and also the
error code is incorrect.

Fixes: 45102048f7 ('amdkfd: Add process queue manager module')
Reviewed-by: Oded Gabbay <oded.gabbay@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-25 13:24:51 +03:00
Dan Carpenter
66333cb3d7 amdkfd: fix some error handling in ioctl
There is a typo here so the errors from kfd_bind_process_to_device()
are not detected.

Reviewed-by: Oded Gabbay <oded.gabbay@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-25 13:21:30 +03:00
Gustavo Padovan
5baf5d44fb drm/exynos: avoid leak if exynos_dpi_probe() fails
The component must be deleted if the probe fails.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-25 11:58:43 +09:00
Gustavo Padovan
1c9ff4ab43 drm/exynos: Fix exynos_dpi_remove() parameter
exynos_dpi_remove() should receive a exynos_drm_display but when
DRM_EXYNOS_DPI was disabled it was receiving a struct device resulting in
ia compiler warning.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-25 11:58:41 +09:00
Inki Dae
1d50aa9c6f drm/exynos: vidi: add component support
This patch adds component support for vidi driver.

vidi driver is a kms driver so it doesn't need to be registered
to exynos_drm_subdrv_list. For this, it changes for the component
framework to be used for vidi driver.

This patch fixes below error also,

# echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
[   55.618529] ------------[ cut here ]------------
[   55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203 exynos_drm_crtc_dpms+0x88/0x17c()
[   55.631268] Modules linked in:
[   55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7 #1154
[   55.641885] [<c0014400>] (unwind_backtrace) from [<c0011570>] (show_stack+0x10/0x14)
[   55.649597] [<c0011570>] (show_stack) from [<c04764f4>] (dump_stack+0x84/0xc4)
[   55.656802] [<c04764f4>] (dump_stack) from [<c00218b8>] (warn_slowpath_common+0x6c/0x88)
[   55.664866] [<c00218b8>] (warn_slowpath_common) from [<c0021970>] (warn_slowpath_null+0x1c/0x24)
[   55.673632] [<c0021970>] (warn_slowpath_null) from [<c027a780>] (exynos_drm_crtc_dpms+0x88/0x17c)
[   55.682482] [<c027a780>] (exynos_drm_crtc_dpms) from [<c027a910>] (exynos_drm_crtc_commit+0x14/0x44)
[   55.691622] [<c027a910>] (exynos_drm_crtc_commit) from [<c025521c>] (drm_crtc_helper_set_mode+0x3d0/0x51c)
[   55.701233] [<c025521c>] (drm_crtc_helper_set_mode) from [<c0255d68>] (drm_crtc_helper_set_config+0x87c/0x9dc)
[   55.711230] [<c0255d68>] (drm_crtc_helper_set_config) from [<c026afa8>] (drm_mode_set_config_internal+0x58/0xd4)
[   55.721380] [<c026afa8>] (drm_mode_set_config_internal) from [<c025c208>] (restore_fbdev_mode+0xcc/0xec)
[   55.730834] [<c025c208>] (restore_fbdev_mode) from [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
[   55.741424] [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c025e0a8>] (drm_fb_helper_set_par+0x1c/0x60)
[   55.752271] [<c025e0a8>] (drm_fb_helper_set_par) from [<c025e174>] (drm_fb_helper_hotplug_event+0x88/0xc4)
[   55.761906] [<c025e174>] (drm_fb_helper_hotplug_event) from [<c02571c4>] (drm_helper_hpd_irq_event+0xc8/0x134)
[   55.771898] [<c02571c4>] (drm_helper_hpd_irq_event) from [<c028e27c>] (vidi_store_connection+0x90/0xc8)
[   55.781268] [<c028e27c>] (vidi_store_connection) from [<c0125f80>] (kernfs_fop_write+0xc0/0x180)
[   55.790045] [<c0125f80>] (kernfs_fop_write) from [<c00cdf60>] (vfs_write+0xa0/0x1ac)
[   55.797757] [<c00cdf60>] (vfs_write) from [<c00ce468>] (SyS_write+0x44/0x9c)
[   55.804790] [<c00ce468>] (SyS_write) from [<c000e6a0>] (ret_fast_syscall+0x0/0x30)
[   55.812328] ---[ end trace 3c0fe4386702d4dd ]---

This issue occurs when modeset to vidi is tried in case that drm_vblank_init
is called prior to crtc creation of vidi driver. In this case, crtc number
of vidi is invalid so any requests with the crtc number will fail.
This patch guarantees drm_vblank_init to be called after all kms drivers
are ready by using component framework.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-25 11:58:37 +09:00
Inki Dae
33e2192fb1 drm/exynos: fix exynos_drm_component_del
This patch resolves the issue that component object isn't removed
correctly.

A given component object couldn't be placed to head of drm_component_list
so all component objects added to the drm_component_list should be checked
to remove the given component object.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-25 11:58:27 +09:00
Julia Lawall
be19d93369 drm/exynos/ipp: fix error return code
Propagate the returned error code on failure.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 23:52:04 +09:00
Inki Dae
4846e45208 drm/exynos: clean up machine compatible string check
Use 'for' statemant instead of hard-coded 'if' statement.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:57 +09:00
Gustavo Padovan
820687befe drm/exynos: move Exynos platform drivers registration to init
Registering the Exynos DRM subdevices platform drivers in the probe
function is causing an infinite loop. Fix this by moving it to the
exynos_drm_init() function to register the drivers on module init.

Registering drivers in the probe functions causes a deadlock in the parent
device lock. See Grant Likely explanation on the topic:

"I think the problem is that exynos_drm_init() is registering a normal
(non-OF) platform device, so the parent will be /sys/devices/platform.
It immediately gets bound against exynos_drm_platform_driver which
calls the exynos drm_platform_probe() hook. The driver core obtains
device_lock() on the device *and on the device parent*.

Inside the probe hook, additional platform_drivers get registered.
Each time one does, it tries to bind against every platform device in
the system, which includes the ones created by OF. When it attempts to
bind, it obtains device_lock() on the device *and on the device
parent*.

Before the change to move of-generated platform devices into
/sys/devices/platform, the devices had different parents. Now both
devices have /sys/devices/platform as the parent, so yes they are
going to deadlock.

The real problem is registering drivers from within a probe hook. That
is completely wrong for the above deadlock reason. __driver_attach()
will deadlock. Those registrations must be pulled out of .probe().

Registering devices in .probe() is okay because __device_attach()
doesn't try to obtain device_lock() on the parent."

 INFO: task swapper/0:1 blocked for more than 120 seconds.
       Not tainted 3.18.0-rc3-next-20141105 #794
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 swapper/0       D c052534c     0     1      0 0x00000000
 [<c052534c>] (__schedule) from [<c0525b34>] (schedule_preempt_disabled+0x14/0x20)
 [<c0525b34>] (schedule_preempt_disabled) from [<c0526d44>] (mutex_lock_nested+0x1c4/0x464

 [<c0526d44>] (mutex_lock_nested) from [<c02be908>] (__driver_attach+0x48/0x98)
 [<c02be908>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
 [<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
 [<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
 [<c02bef94>] (driver_register) from [<c029e99c>] (exynos_drm_platform_probe+0x34/0x234)
 [<c029e99c>] (exynos_drm_platform_probe) from [<c02bfcf0>] (platform_drv_probe+0x48/0xa4)
 [<c02bfcf0>] (platform_drv_probe) from [<c02be680>] (driver_probe_device+0x13c/0x37c)
 [<c02be680>] (driver_probe_device) from [<c02be954>] (__driver_attach+0x94/0x98)
 [<c02be954>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
 [<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
 [<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
 [<c02bef94>] (driver_register) from [<c029e938>] (exynos_drm_init+0x70/0xa0)
 [<c029e938>] (exynos_drm_init) from [<c00089b0>] (do_one_initcall+0xac/0x1f0)
 [<c00089b0>] (do_one_initcall) from [<c074bd90>] (kernel_init_freeable+0x10c/0x1d8)
 [<c074bd90>] (kernel_init_freeable) from [<c051eabc>] (kernel_init+0x8/0xec)
 [<c051eabc>] (kernel_init) from [<c000f268>] (ret_from_fork+0x14/0x2c)
 3 locks held by swapper/0/1:
  #0:  (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98
  #1:  (&dev->mutex){......}, at: [<c02be918>] __driver_attach+0x58/0x98
  #2:  (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98

Changelog v2:
- call platform_driver_register after all kms and non kms drivers are
  registered
- rebased it to exynos-drm-next

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:57 +09:00
Gustavo Padovan
b67139571e Revert "drm/exynos: fix null pointer dereference issue"
This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af.

Moving subdriver probe to exynos_drm_platform_probe() was making
exynos_drm_device_subdrv_probe() fail because the platform data wasn't set
yet. It only gets set in exynos_drm_load.

We need to find a smarter way to fix this issue.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:56 +09:00
Andrzej Hajda
5af3d9bb78 drm/exynos/dpi: stop using display->ctx pointer
The patch replaces accesses to display->ctx pointer by container_of
construct. The field is removed as well as dpi was the last user of it.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:56 +09:00
Andrzej Hajda
4cfde1f2af drm/exynos/dpi: embed display into private context
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dpi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dpi devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:56 +09:00
Andrzej Hajda
63b3be3270 drm/exynos/dp: stop using display->ctx pointer
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:56 +09:00
Andrzej Hajda
1df6e5fb79 drm/exynos/dp: embed display into private context
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dp
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dp devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:56 +09:00
Andrzej Hajda
2f26bd7227 drm/exynos/vidi: stop using display->ctx pointer
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:56 +09:00
Andrzej Hajda
7340426aff drm/exynos/vidi: embed display into private context
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to vidi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple vidi devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:55 +09:00
Andrzej Hajda
0d8424f83c drm/exynos/hdmi: stop using display->ctx pointer
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:55 +09:00
Andrzej Hajda
930865fbe2 drm/exynos/hdmi: embed display into private context
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to hdmi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple hdmi devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:55 +09:00
Andrzej Hajda
400c8ac8fc drm/exynos/fimd: stop using manager->ctx pointer
The patch replaces accesses to manager->ctx pointer by container_of
construct. As fimd was the last user of ctx the patch removes
this field as well.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:55 +09:00
Andrzej Hajda
e152dbd77b drm/exynos/fimd: embed manager into private context
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple FIMD devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:55 +09:00
Andrzej Hajda
e1819aad14 drm/exynos/vidi: stop using manager->ctx pointer
The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:55 +09:00
Andrzej Hajda
f01833cd2b drm/exynos/vidi: embed manager into private context
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to vidi private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:54 +09:00
Andrzej Hajda
8f0be8304d drm/exynos/mixer: stop using manager->ctx pointer
The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:54 +09:00
Andrzej Hajda
8103ef1b5f drm/exynos/mixer: embed manager into private context
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:54 +09:00
YoungJun Cho
0cef83a5fd drm/exynos: dsi: set TE GPIO IRQ status as IRQ_NOAUTOEN
The exynos_dsi_te_irq_handler() works only dsi(DPMS) is on.
So it is enough to enable and disable TE GPIO IRQ in
exynos_dsi_enable(disable)_irq() like DSI IRQ.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>a
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:54 +09:00
YoungJun Cho
ecb84157b5 drm/exynos: dsi: move TE irq handler registration position
The drm_helper_hpd_irq_event() does dpms control and
the panel is initialized and displayed on by it.
So the exynos_dsi_te_irq_handler() should be registered
beforehand.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:54 +09:00
Joonyoung Shim
adf67abff0 drm/exynos: use irq_flags instead of triggering
The drm_handle_vblank should be called whenever be vsync, te interrupt
means vsync on i80 interface.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:54 +09:00
YoungJun Cho
87ab85b3cc drm/exynos: fimd: add triggering unset routine in fimd_trigger()
There is a case like set config which requires triggering
but vblank is not enabled yet.
So triggering unset routine is required to exit from
triggering mode.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:54 +09:00
YoungJun Cho
1c905d9508 drm/exynos: fimd: modify I80 i/f irq relevant routine
For the I80 interface, the video interrupt pending register(VIDINTCON1)
should be handled in fimd_irq_handler() and the video interrupt control
register(VIDINTCON0) should be handled in fimd_enable_vblank() and
fimd_disable_vblank() like RGB interface.
So this patch moves each set / unset routines into proper positions.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:53 +09:00
YoungJun Cho
999d8b31fa drm/exynos: fimd: add fimd_enable_shadow_channel_path() to cleanup
This function is valid only the SoC has SHADOWCON register
and it should be used together with fimd_enable_video_output()
to match the ENWIN_F bit in WINCON# and C#_EN_F bit in SHADOWCON.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:53 +09:00
YoungJun Cho
f181a543c7 drm/exynos: fimd: add fimd_enable_video_output() to cleanup
This bit is used for video output and logic signal control.
So it is better for readability.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:53 +09:00
YoungJun Cho
74944a58f9 drm/exynos: fimd: move shadow unprotection position
The C#_EN_F in SHADOWCON register is updated per frame.
So it should be protected by fimd_shadow_protect_win().

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:53 +09:00
Joonyoung Shim
9b67eb7365 drm/exynos: move triggering checking
It's better to be checking whether triggerring in fimd_trigger function.
Also it will return if in triggerring on fimd_te_handler, then it can't
execute remain codes.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:53 +09:00
Joonyoung Shim
3c3c9c1d90 drm/exynos: add has_vtsel flag
The exynos fimd provides video type selection bits from system register
but exynos3 series don't has it, so needs has_vtsel flag and we can
distinguish whether set video type selection bits.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:53 +09:00
Krzysztof Kozlowski
030794a368 drm/exynos: Fix DSI resuming fail because power domain being off
During system resume from suspend to RAM the Exynos DRM driver forced
CRTC mode thus turning display on (DPMS_ON). This lead to runtime resuming
of DSI which failed because whole LCD power domain was off and it was
not allowed to turn on because of system resume in progress.

Forcing mode should not be needed and removing it solves this particular
problem.

This necessary fix for following scenario reproduced on Exynos DRM:
1. Power domain is off before suspending the system.
2. System is suspended to RAM.
3. Resuming starts. The Exynos DRM driver resume callback is called.
4. The Exynos DRM driver calls drm_helper_resume_force_mode() which turns
   on the screen by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
5. The Exynos DSI driver calls pm_runtime_get. The driver runtime
   resumes and this should turn LCD power domain on.
6. Unfortunately the domain cannot be turned on because system resume is
   in progress and genpd->prepared_count is positive.

Steps to reproduce:
1. Add runtime PM to Exynos DSI driver.
2. Build Exynos DRM/FB without FRAMEBUFFER_CONSOLE.
3. Enable the connector and screen (e.g. with modeset-vsync).
4. echo 3 > /sys/devices/platform/exynos-drm/graphics/fb0/blank
5. echo mem > /sys/power/state
6. Resume.
[   77.712469] PM: early resume of devices complete after 3.854 msecs
[   77.712739] exynos-dsi 11c80000.dsi: pm_genpd_resume()
[   77.712758] exynos4-fimc 11800000.fimc: pm_genpd_resume()
[   77.712774] exynos4-fimc 11810000.fimc: pm_genpd_resume()
[   77.712787] exynos-drm-fimc 11820000.fimc: pm_genpd_resume()
[   77.712802] exynos-drm-fimc 11830000.fimc: pm_genpd_resume()
[   77.712815] s5p-mipi-csis 11880000.csis: pm_genpd_resume()
[   77.712829] s5p-mipi-csis 11890000.csis: pm_genpd_resume()
[   77.712843] exynos-fimc-lite 12390000.fimc-lite: pm_genpd_resume()
[   77.712856] exynos-fimc-lite 123a0000.fimc-lite: pm_genpd_resume()
[   77.713788] exynos4-fb 11c00000.fimd: pm_genpd_resume()
[   77.713912] wake disabled for irq 184
[   77.713923] wake disabled for irq 185
[   77.714082] wake disabled for irq 173
[   77.715676] wake disabled for irq 176
[   77.718540] exynos4-fb 11c00000.fimd: pm_genpd_runtime_resume()
[   77.718567] exynos4-fb 11c00000.fimd: state restore latency exceeded, new value 1708 ns
[   77.718636] exynos-dsi 11c80000.dsi: pm_genpd_runtime_resume()
[   77.892366] exynos-dsi 11c80000.dsi: PLL failed to stabilize
[   77.892377] exynos-dsi 11c80000.dsi: failed to configure DSI PLL
[   78.192168] exynos-dsi 11c80000.dsi: timeout waiting for reset
[   78.211578] exynos-dsi 11c80000.dsi: waiting for bus lanes timed out
[   78.307173] exynos-dsi 11c80000.dsi: xfer timed out: d1 00 (null)
[   78.307190] panel_s6e8aa0 11c80000.dsi.0: error -110 reading dcs seq(0xd1)
[   78.307199] panel_s6e8aa0 11c80000.dsi.0: read id failed

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:52 +09:00
YoungJun Cho
d41bb38f22 drm/exynos: dsi: move DSIM_STATE_ENABLED set position
The command mode panel should draw image earlier than the display
on command execution to prevent showing garbage GRAM screen data.
So should set dsi->state as DSIM_STATE_ENABLED between calling
exynos_dsi_set_display_enable() and drm_panel_enable() to transmit
image data before executing display on command.
And moves the display on command execution routine from prepare()
to enable() in drm_panel_funcs also.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:52 +09:00
YoungJun Cho
b301ae24bb drm/exynos: fimd: move handle vblank position in TE handler
For providing VBLANK information, drm_handle_vblank() should
be called properly, but it is blocked by wait_vsync_event
condition which is set by manager_ops->wait_for_vblank().
So moves it out from wait_vsync_event routine.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:52 +09:00
YoungJun Cho
bd953de943 drm/exynos: fimd: remove unnecessary waiting vblank routine
The exynos_drm_crtc_dpms() waits until pended page flip
queue is empty, calls the drm_vblank_off() then calls
manager->ops->dpms() when mode is DRM_MODE_DPMS_OFF.
The fimd_dpms() is one of manager->ops->dpms()s and
finally calls fimd_window_suspend().
But there is no active window and vblank is already off
when it is called.
So addtional waiting vblank is not necessary any more.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:52 +09:00
YoungJun Cho
dcb622aa88 drm/exynos: fimd: support Exynos4415 SoC
This patch supports Exynos4415 SoC.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:52 +09:00
YoungJun Cho
4bc6d6445e drm/exynos: dsi: support Exynos4415 SoC
This patch supports Exynos4415 SoC.

Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:52 +09:00
Vivek Gautam
b128aefe0b drm/exynos: dp: Remove support for unused dptx-phy
Now that we have moved to generic phy based bindings,
we don't need to have any code related to older dptx-phy.
Nobody is using this dptx-phy anymore, so removing the
same.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:51 +09:00
Gustavo Padovan
9755884772 drm/exynos: remove leftover hdmi function declarations
They are not implemented anywhere, so wipe them out.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:51 +09:00
Gustavo Padovan
60cb85862e drm/exynos: update documentation to reflect code changes
Description of the @create_connector callback was missing,
and the @manager was no longer needed.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:51 +09:00
Gustavo Padovan
4a5827fbc2 drm/exynos: Save up space using bool var as bitfields
Save a few bytes by compiling them all in the same byte.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:51 +09:00
Gustavo Padovan
5d0e6fec7f drm/exynos: remove unused wait_for macro
This is a leftover, all code using this macro have been removed/
changed already.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:51 +09:00
Gustavo Padovan
cc2d861c5f drm/exynos: Replace repeated declarations by #include "exynos_drm_drv.h"
Re-declare struct is not a good practice, let's use the original
drm and exynos declarations.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:51 +09:00
Gustavo Padovan
d2c1bba3f6 drm/exynos: Replace repeated declaration by include <drm/drmP.h>
Re-declare struct is not a good practice, let's use the original
drm declarations.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:50 +09:00
Gustavo Padovan
f859d6e859 drm/exynos: remove extra declaration of struct exynos_overlay
The struct is defined in the same file, declare it here is just
unnecessary

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:50 +09:00
Gustavo Padovan
b5b1a4bb15 drm/exynos: remove extra declaration of struct exynos_drm_manager
The struct is defined in the same file, declare it here is just
unnecessary.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:50 +09:00
Gustavo Padovan
ff9c87ce9b drm/exynos: remove uneeded declaration of struct dma_iommu_mapping
It is not even used in this header anymore.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:50 +09:00
Andrzej Hajda
5cd5db8040 drm/exynos: dsi: stop using display->ctx pointer
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:50 +09:00
Andrzej Hajda
e5169723da drm/exynos: dsi: remove redundant encoder field
The patch removes redundant encoder field from private DSI context.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:50 +09:00
Andrzej Hajda
e2d2a1e0a2 drm/exynos: dsi: simplify device pointer evaluation
The patch replaces multiple evaluation of device address
with local variable.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:49 +09:00
Andrzej Hajda
2900c69c52 drm/exynos: dsi: remove global variable exynos_dsi_display
exynos_dsi_display is used by internal Exynos DRM framework for
representing pair encoder->connecter. As it should be mapped 1:1 to dsi
private context it seems more reasonable to embed it directly
in that context. As a result further code simplification will be possible.
Moreover it will be possible to handle multiple DSI devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:49 +09:00
Andrzej Hajda
7239067795 drm/exynos: remove ifdeferry from initialization code
The patch replaces separate calls to driver (de)registration by
loops over the array of drivers. As a result it significantly
decreases number of ifdefs. Additionally it moves device registration
related ifdefs to header file.

Changelog v2:
- Rebased.
- Consider non kms driver in respect to infinite loop issue.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:49 +09:00
Inki Dae
421ee18d4e drm/exynos: fix null pointer dereference issue
This patch fixes null pointer dereference issue incurred
when ipp driver is enabled and Exynos drm driver is closed.

Non kms driver should register its own sub driver to setup necessary
resources, which is done by load(). So null pointer dereference
occurs when ipp driver is enabled and Exynos drm driver is closed
because ipp core device is registered after component_master_add_with_match
call.

This patch makes exynos_drm_device_subdrv_probe() to be called after all non
kms drivers are registered.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:49 +09:00
Inki Dae
e9fbdcb45a drm/exynos: fix possible infinite loop issue
This patch fixes possible infinite loop issue by postponing
registration to non kms drivers after component_master_add_with_match
call, which can be incurred in all cases that non kms driver is probed
and then component bind is failed

This patch should be applied on top of below patches,
	http://comments.gmane.org/gmane.comp.video.dri.devel/117740
	http://www.spinics.net/lists/linux-samsung-soc/msg38624.html

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:49 +09:00
Inki Dae
2d15118750 drm/exynos: g2d: fix null pointer dereference
This patch fixes a null pointer dereference issue incurred by
calling g2d_remove when exynos_drm_platform_probe is failed.

cmdlist_pool of g2d is allocated when g2d sub driver is probed.
So if exynos_drm_platform_probe is failed, the g2d sub driver is
not probed and the cmdlist_pool is still NULL.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:48 +09:00
Inki Dae
fbdf093d62 drm/exynos: resolve infinite loop issue on non multi-platform
This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:48 +09:00
Inki Dae
5cbb37df37 drm/exynos: resolve infinite loop issue on multi-platform
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
2014-11-24 18:02:47 +09:00
Ville Syrjälä
bdfa7542d4 drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset
During a GPU reset we need to get pending page flip cleared out
since the ring contents are gone and flip will never complete
on its own. This used to work until the mmio vs. CS flip race
detection came about. That piece of code is looking for a
specific surface address in the SURFLIVE register, but as
a flip to that address may never happen the check may never
pass. So we should just skip the SURFLIVE and flip counter
checks when the GPU gets reset.

intel_display_handle_reset() tries to effectively complete
the flip anyway by calling .update_primary_plane(). But that
may not satisfy the conditions of the mmio vs. CS race
detection since there's no guarantee that a modeset didn't
sneak in between the GPU reset and intel_display_handle_reset().
Such a modeset will not wait for pending flips due to the ongoing GPU
reset, and then the primary plane updates performed by
intel_display_handle_reset() will already use the new surface
address, and thus the surface address the flip is waiting for
might never appear in SURFLIVE. The result is that the flip
will never complete and attempts to perform further page flips
will fail with -EBUSY.

During the GPU reset intel_crtc_has_pending_flip() will return
false regardless, so the deadlock with a modeset vs. the error
work acquiring crtc->mutex was avoided. And the reset_counter
check in intel_crtc_has_pending_flip() actually made this bug
even less severe since it allowed normal modesets to go through
even though there's a pending flip.

This is a regression introduced by me here:
 commit 75f7f3ec60
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Tue Apr 15 21:41:34 2014 +0300

    drm/i915: Fix mmio vs. CS flip race on ILK+

Testcase: igt/kms_flip/flip-vs-panning-vs-hang
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-11-24 09:54:23 +02:00
Benjamin Herrenschmidt
91ed6fd2c3 gpu/radeon: Set flag to indicate broken 64-bit MSI
Some radeon ASICs don't support all 64 address bits of MSIs despite
advertising support for 64-bit MSIs in their configuration space.

This breaks on systems such as IBM POWER7/8, where 64-bit MSIs can
be assigned with some of the high address bits set.

This makes use of the newly introduced "no_64bit_msi" flag in structure
pci_dev to allow the MSI allocation code to fallback to 32-bit MSIs
on those adapters.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
CC: <stable@vger.kernel.org>
---

Adding Alex's review tag. Patch to the driver is identical to the
reviewed one, I dropped the arch/powerpc hunk rewrote the subject
and cset comment.
2014-11-24 14:12:56 +11:00
Rob Clark
46df9adb2e drm/atomic: shutdown *current* encoder
In disable_outputs() we need to shut down the outgoing encoder, not the
incoming one (we have already swapped-state at this point).  Without
this, we end up telling the driver to crtc->dpms(OFF) without first
encoder->dpms(OFF), and that makes some hw quite unhappy.

v2: missing WARN_ON() hunk and comment

Reviewed-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 16:06:15 -05:00
Rob Clark
934ce1c236 drm/atomic: check mode_changed *after* atomic_check
The intention is that drivers can set crtc_state->mode_changed in their
atomic_check() fxns if they encounter a scenario that requires full
modeset.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-21 16:06:10 -05:00
Oded Gabbay
a49493b548 amdkfd: Remove DRM_AMDGPU dependency from Kconfig
This patch removes the dependency of amdkfd upon DRM_AMDGPU symbol in amdkfd's
Kconfig file.

This is done because amdgpu driver is not yet upstreamed and therefore,
DRM_AMDGPU symbol is not present in any Kconfig file.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-21 22:36:09 +02:00
Rob Clark
4dd14fe6fb drm/msm/mdp4: fix mixer setup for multi-crtc + planes
On mdp4 there is a single global LAYERMIXER_IN_CFG register.  The
previous logic to share that between multiple crtcs didn't actually
handle plane-disable very well.  Easier just to look at all of the
crtcs each time.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 15:32:37 -05:00
Oded Gabbay
824cb7d136 amdkfd: explicitely include io.h in kfd_doorbell.c
This patch fixes a compilation error when using certain configuration by
including the file io.h in kfd_doorbell.c

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-11-21 22:04:44 +02:00
Rob Clark
d6ac4a84e7 drm/msm/mdp5: dpms(OFF) cleanups
When disabling the interface (INTF), the change doesn't latch until next
vblank, so we need to wait for vblank.

Also, to be pedantic, in the crtc, set all the mixer stages to unused.
It shouldn't really matter, since at this point we have already disabled
the INTF and waited for necessary vblank.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:59:24 -05:00
Rob Clark
ed8519636e drm/msm/mdp5: atomic
Convert mdp5 over to atomic helpers.  Extend/wrap drm_plane_state to
track plane zpos and to keep track of the needed when applying the
atomic update.  In mdp5's plane->atomic_check() we also need to check
for updates which require SMP reallocation, in order to trigger full
modeset.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:59:18 -05:00
Rob Clark
3e2f29e413 drm/msm: atomic fixes
Fixes for a couple little issues found in testing.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:57:22 -05:00
Rob Clark
32c0e3e24c drm/msm/mdp5: remove global mdp5_ctl_mgr
A bit cleaner.. and won't resulting in an attempt to kfree() a static
global in unload path.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:57:21 -05:00
Rob Clark
42238da8b1 drm/msm/mdp5: don't use void * for opaque types
For example, use 'struct mdp5_smp *' everywhere instead of 'void *', but
only declare it as 'struct mdp5_smp;' in common headers, so the struct
body is still private.  The accomplishes the desired modularity while
still letting the compiler provide some type checking for us.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:57:20 -05:00
Stephane Viau
0deed25b65 drm/msm: add multiple CRTC and overlay support
MDP5 currently support one single CRTC with its private pipe.
This change allows the configuration of multiple CRTCs with
the possibility to attach several public planes to these CRTCs.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:57:19 -05:00
Rob Clark
ac7a570406 drm/msm/mdp5: set rate before enabling clk
Set a "safe" rate at first, in order to read out the hw revision.  And
then after set the optimal value.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:57:18 -05:00
Stephane Viau
2e362e1772 drm/msm/mdp5: introduce mdp5_cfg module
The hardware configuration modification from a version to another
is quite consequent. Introducing a configuration module
(mdp5_cfg) may make things more clear and easier to access when a
new hardware version comes up.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:57:17 -05:00
Stephane Viau
bfcdfb0e62 drm/msm/mdp5: make SMP module dynamically configurable
The Shared Memory Pool (SMP) has its own limitation, features and
state. Some examples are:
 - the number of Memory Macro Block (MMB) and their size
 - the number of lines that can be fetched
 - the state of MMB currently allocated
 - the computation of number of blocks required per plane
 - client IDs ...

In order to avoid private data to be overwritten by other modules,
let's make these private to the SMP module.

Some of these depend on the hardware configuration, let's add them
to the mdp5_config struct.

In some hw configurations, some MMBs are statically tied to RGB
pipes and cannot be re-allocated dynamically. This change
introduces the concept of MMB static usage and makes sure that
dynamic MMB requests are dimensioned accordingly.

A note on passing a pipe pointer, instead of client IDs:
Client IDs are SMP-related information. Passing PIPE information
to SMP lets SMP module to find out which SMP client(s) are used.
This allows the SMP module to access the PIPE pointer, which can
be used for FIFO watermark configuration.
By the way, even though REG_MDP5_PIPE_REQPRIO_FIFO_WM_* registers
are part of the PIPE registers, their functionality is to reflect
the behavior of the SMP block. These registers access is now
restricted to the SMP module.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:57:16 -05:00
Rob Clark
d1a717bd27 drm/msm/hdmi: remove useless kref
A left-over from prior to component framework.  The original intent was
to deal with hdmi getting unloaded before the master component, but that
isn't really going to work anyways.  These days with the component
framework taking care to unload the master component first, we don't
have to worry about this.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:56:19 -05:00
Stephane Viau
3f307963fc drm/msm/mdp5: get the core clock rate from MDP5 config
The core clock rate depends on the hw configuration. Once we have
read the hardware revision, we can set the core clock to its
maximum value.
Before then, the clock is set at a rate supported by all MDP5
revisions.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:56:18 -05:00
Rob Clark
f6a8eaca0e drm/msm/mdp5: use irqdomains
For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the
mdp block.  In order to decouple hdmi/eDP/etc, register an irq domain
in mdp5.  When hdmi/dsi/etc are used with mdp4, they can directly setup
their irqs in their DT nodes as normal.  When used with mdp5, instead
set the mdp device as the interrupt-parent, as in:

	mdp: qcom,mdss_mdp@fd900000 {
		compatible = "qcom,mdss_mdp";
		interrupt-controller;
		#interrupt-cells = <1>;
		...
	};

	hdmi: qcom,hdmi_tx@fd922100 {
		compatible = "qcom,hdmi-tx-8074";
		interrupt-parent = <&mdp>;
		interrupts = <8 0>;   /* MDP5_HW_INTR_STATUS.INTR_HDMI */
		...
	};

There is a slight awkwardness, in that we cannot disable child irqs
at the mdp level, they can only be cleared in the child block.  So
you must not use threaded irq handlers in the child.  I'm not sure
if there is a better way to deal with that.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-21 08:56:18 -05:00
Daniel Vetter
e7f1d0b735 drm/i915: Update DRIVER_DATE to 20141121
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-21 10:37:14 +01:00
Dave Airlie
a0fc608178 Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
fix one regression and one endian issue.

* 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: fix endian swapping in vbios fetch for tdp table
  drm/radeon: disable native backlight control on pre-r6xx asics (v2)
2014-11-21 12:19:19 +10:00
Dave Airlie
ed1e8777a5 Merge branch 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-next
- More CI dpm fixes
- Initial DPM fan control for SI/CI (disabled by default)
- GPUVM multi-ring efficiency improvements
- Some cursor fixes

* 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux: (22 commits)
  drm/radeon: update the VM after setting BO address v4
  drm/radeon: sync PT updates as shared v2
  drm/radeon: sync PD updates as shared
  drm/radeon: fence BO_VAs manually
  drm/radeon: use one VMID for each ring
  drm/radeon: track VM update fences separately
  drm/radeon: fence PT updates manually v2
  drm/radeon: split semaphore and sync object handling v2
  drm/radeon: remove unnecessary VM syncs
  drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr
  drm/radeon: rework vm_flush parameters
  drm/radeon/ci: disable needless sclk changes
  drm/radeon/ci: force pcie level before sclk and mclk
  drm/radeon/ci: use different smc command for pcie dpm
  drm/radeon/ci: apply disp voltage changes before clk changes
  drm/radeon: fix PCC debugging message for CI DPM
  drm/radeon/dpm: add thermal dpm support for CI
  drm/radeon/dpm: add smc fan control for CI (v2)
  drm/radeon/dpm: add smc fan control for SI (v2)
  drm/radeon: work around a hw bug in MGCG on CIK
  ...
2014-11-21 12:17:43 +10:00
Markus Elfring
a3a1a6674f drm/vmwgfx: Deletion of an unnecessary check before the function call "vfree"
The vfree() function performes also input parameter validation. Thus the test
around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-21 12:16:40 +10:00
Markus Elfring
e9196d2385 drm/udl: Deletion of an unnecessary check before the function call "vunmap"
The vunmap() function performes also input parameter validation. Thus the test
around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-21 12:16:35 +10:00
Markus Elfring
c084481735 drm/tilcdc: Deletion of an unnecessary check before the function call "drm_fbdev_cma_hotplug_event"
The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-21 12:16:31 +10:00
Markus Elfring
9084acf19b drm/edid: Deletion of an unnecessary check before the function call "release_firmware"
The release_firmware() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-21 12:16:27 +10:00
Daniel Vetter
fc2d2bc1f1 drm/atomic: Add missing ERR_PTR casting
This is an oversight from

commit f52b69f1ec
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Nov 19 18:38:08 2014 +0100

    drm/atomic: Don't overrun the connector array when hotplugging

Cc: Dave Airlie <airlied@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-21 12:13:44 +10:00
Thomas Hellstrom
355a701838 drm/gem: Warn on illegal use of the dumb buffer interface v2
It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.

This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.

v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-21 12:12:41 +10:00
Jesse Barnes
89a35ecdc6 drm/i915/g4x: fix g4x infoframe readout
Need to check the port too.

Reported-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 22:51:25 +01:00
Chris Wilson
d9e600b2e4 drm/i915: Only call mod_timer() if not already pending
The final arrangement of updating timer->expires and calling mod_timer()
used in

commit 672e7b7c18
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Nov 19 09:47:19 2014 +0000

    drm/i915: Don't continually defer the hangcheck

turns out to be very unsafe. Try again.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 22:48:34 +01:00
Daniel Vetter
bbd440fb81 drm/i915: Don't rely upon encoder->type for infoframe hw state readout
encoder->type can change underneath us and doesn't need to reflect
actual hw state (since we don't construct it from hw state like
e.g. encoder->crtc crtc->config).

And this can indeed happen:
1) Boot with plugged-in hdmi screen. Since we only set ->type in the
   probe functions this means we won't detect any infoframes since
   type is still unkown.
2) First probe sets type to HDMI.
3) If the first modeset now does _not_ happen on the HDMI pipe with
   infoframes encoder->get_config suddenly sees infoframes and the
   state checker gets angry.

Fix this by only relying on actual hw state when figuring out whether
the ddi port is in hdmi mode and sends infoframes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reported-by: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 22:37:04 +01:00
Christian König
2f2624c235 drm/radeon: update the VM after setting BO address v4
This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.

v2: fix vm lock
v3: immediately update unmaps as well
v4: use drm_free_large instead of kfree

Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:20 -05:00
Christian König
d1968e1db8 drm/radeon: sync PT updates as shared v2
Only invalidating PTEs needs to be executed synchronized to using the PT.

v2: fix sync to uses

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:19 -05:00
Christian König
43ac885764 drm/radeon: sync PD updates as shared
We never invalidate PD entries and making them valid can
run with other users in parallel.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:19 -05:00
Christian König
94214635f0 drm/radeon: fence BO_VAs manually
This allows us to finally remove the VM fence and
so allow concurrent use of it from different engines.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:18 -05:00
Christian König
7c42bc1aa2 drm/radeon: use one VMID for each ring
Use multiple VMIDs for each VM, one for each ring. That allows
us to execute flushes separately on each ring, still not ideal
cause in a lot of cases rings can share IDs.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:18 -05:00
Christian König
ad1a58a45a drm/radeon: track VM update fences separately
Note for each fence if it's a VM page table update or not. This allows
us to determine the last VM update in a sync object and so to figure
out if we need to flush the TLB or not.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:17 -05:00
Christian König
587cdda8f7 drm/radeon: fence PT updates manually v2
This allows us to add the real execution fence as shared.

v2: fix typo

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:16 -05:00
Christian König
975700d2cc drm/radeon: split semaphore and sync object handling v2
Previously we just allocated space for four hardware semaphores
in each software semaphore object. Make software semaphore objects
represent only one hardware semaphore address again by splitting
the sync code into it's own object.

v2: fix typo in comment

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:16 -05:00
Christian König
e0602c35fe drm/radeon: remove unnecessary VM syncs
The PD/PTs reservation object now contains everything needed.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:15 -05:00
Christian König
85761f605a drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr
That's useless when all callers drop the reservation
immediately after calling the function.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:15 -05:00
Christian König
faffaf620f drm/radeon: rework vm_flush parameters
Use ring structure instead of index and provide vm_id and pd_addr separately.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:14 -05:00
Alex Deucher
d967be9b80 drm/radeon/ci: disable needless sclk changes
The current code always reprogrammed the sclk levels,
but we don't currently handle disp sclk requirements
so just skip it.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:13 -05:00
Alex Deucher
7f6233ca87 drm/radeon/ci: force pcie level before sclk and mclk
Preferred ordering.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:13 -05:00
Alex Deucher
e745c3c9aa drm/radeon/ci: use different smc command for pcie dpm
Use unforce levels rather than enable mask instruction.
This is the preferred method.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:12 -05:00
Alex Deucher
f281d0a37c drm/radeon/ci: apply disp voltage changes before clk changes
Apply voltage changes for displays before changing clocks.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:12 -05:00
Alex Deucher
66648b81ce drm/radeon: fix PCC debugging message for CI DPM
Add missing newline and print the bad gpio shift.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:11 -05:00
Alex Deucher
0e4ed1c190 drm/radeon/dpm: add thermal dpm support for CI
Not currently used.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:10 -05:00
Alex Deucher
e03cea367f drm/radeon/dpm: add smc fan control for CI (v2)
Enable smc fan control for CI boards.  Should
reduce the fan noise on systems with a higher
default fan profile.

v2: disable by default, add additional fan setup, rpm control

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73338

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:10 -05:00
Alex Deucher
39471ad39d drm/radeon/dpm: add smc fan control for SI (v2)
Enable smc fan control for SI boards.  Should
reduce the fan noise on systems with a higher
default fan profile.

v2: disable by default, add rpm controls

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73338

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 13:00:09 -05:00
Alex Deucher
28731d5818 drm/radeon: fix endian swapping in vbios fetch for tdp table
Value needs to be swapped on BE.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2014-11-20 11:13:18 -05:00
Alex Deucher
b7bc596ebb drm/radeon: disable native backlight control on pre-r6xx asics (v2)
Just use the acpi interface.  That's what windows uses on this
generation and it's the only thing that seems to work reliably
on these generation parts.

You can still force the native backlight interface by setting
radeon.backlight=1

Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=88501

v2: merge into above if/else block

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2014-11-20 11:12:55 -05:00
Alex Deucher
4bb62c95a7 drm/radeon: work around a hw bug in MGCG on CIK
Always need to set bit 0 of RLC_CGTT_MGCG_OVERRIDE
to avoid unreliable doorbell updates in some cases.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2014-11-20 11:11:43 -05:00
Michel Dänzer
3feba08d79 drm/radeon: Move radeon_cursor_move(_locked) to replace forward declaration
No functional change.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 11:11:42 -05:00
Michel Dänzer
78b1a6010b drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
The cursor_set2 hook provides the cursor hotspot position within the
cursor image. When the hotspot position changes, we can adjust the cursor
position such that the hotspot doesn't move on the screen. This prevents
the cursor from appearing to intermittently jump around on the screen
when the position of the hotspot within the cursor image changes.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20 11:11:41 -05:00
Imre Deak
99990f1b0b drm/i915: remove the IRQs enabled WARN from intel_disable_gt_powersave
This function can be called now with i915 interrupts enabled, so the
corresponding WARN is incorrect, remove it. I think this was spotted by
Paulo during his review, but since I already removed the same WARN
from intel_suspend_gt_powersave() I missed then his point.

Spotted-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 17:00:59 +01:00
Daniel Vetter
cc1df8a3fe drm/i915: Use ggtt error obj capture helper for gen8 semaphores
Spotted while reading and trying to understand how our error capture
code deals with full ppgtt.

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20 16:59:49 +01:00
Imre Deak
2837ac4069 drm/i915: vlv: increase timeout when setting idle GPU freq
I saw punit timeouts in vlv_set_rps_idle() while running various
subtests of pm_rpm. Increasing the timeout to 100ms got rid of the
issue.

Testcase: igt/pm_rpm
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Guo Jinxian <jinxianx.guo@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 16:58:29 +01:00
Imre Deak
738c05c07d drm/i915: vlv: fix cdclk setting during modeset while suspended
Currently after doing DPMS-OFF on all outputs CDCLK won't be set to its
minimum value as it should. A subsequent modeset to turn off all outputs
will thus run with all power domains disabled, and notice that it needs
to change CDCLK to its minimum value. Since the power domains are
disabled this will emit a register-access-while-suspended WARN and fail
to set the minimum freq.

The proper solution for this is to set the minimum frequency during
DPMS-OFF. That needs a bigger rework that would take into account the
user DPMS setting too during the calculation of the new modesetting
configuration. Until that's done this stop-gap solution gets the PIPE-A
power domain during setting the CDCLK; this domain covers the HW blocks
needed for this.

Idea to use PIPE-A domain from Ville.

Testcase: igt/pm_rpm
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 16:58:11 +01:00
Daniel Vetter
55072d194c drm/i915: Dump hdmi pipe_config state
Makes it easier to debug infoframe mismatches.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20 16:10:28 +01:00
Zhe Wang
7c859007fd drm/i915: Gen9 shadowed registers
For MMIO registers which are shadowed, force wake is not needed to
write to these registers.

v2: Rebase on top of nightly (Damien)

v3: Rebase on top of "Gen9 multiple-engine forcewake" changes

v4: (Mika, Bob, done by Damien)
- Reorder the shadowed registers by popularity

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Zhe Wang <zhe1.wang@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 15:08:41 +01:00
Zhe Wang
4597a88a1e drm/i915/skl: Gen9 multi-engine forcewake
Enable multi-engine forcewake for Gen9.

v2: (Damien)
- Rebase on top of nightly
- Move the register range definitions to intel_uncore.c
- Whitespace fixes

v3: (Addressing Mika's comment, done by Damien)
- Use REG_RANGE() (introduced after the patch was written)
- Add a SKL_NEEDS_FORCE_WAKE() macro that gets rid of a useless
  comparison to FORCEWAKE (reg 0xa18c is not used on SKL)

v4: (Damien)
- Use newly introduced ASSIGN_READ/WRITE_MMIO_VFUNCS() macros

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Zhe Wang <zhe1.wang@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 15:08:35 +01:00
Ville Syrjälä
6b312cd366 drm/i915: Read power well status before other registers for drpc info
Trying to read the status of the power wells right after taking forcewake
for the other register reads makes little sense. Most of the time the
power wells will still be up due to the recent forcewake. Instead do the
power well status read first, and only then read the register needing
forcewake. This way the reported power well status can actually reflect
what's going on in the system.

Cc: Deepak S <deepak.s@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 13:03:34 +01:00
Daniel Vetter
656bfa3afc drm/i915: Pin tiled objects for L-shaped configs
Let's just throw in the towel on this one and take the cheap way out.

Based on a patch from Chris Wilson, but checking for a different bit.
Chris' patch checked for even bank layout, this one here for a magic
bit. Given the evidence we've gathered (not much) both work I think,
but checking for the magic bit might be more accurate.

Anyway, works on my gm45 here.

For paranoi restrict to gen4 (and mobile), since we've only ever seen
this on gm45 and i965gm.

Also add some debugfs output so that we can skip the tiled swapping
tests properly in these cases.

v2: Clean up the quirk'ed pin count in free_object to avoid upsetting
the WARN_ON. Spotted by Chris.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28813
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45092
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 13:03:33 +01:00
Tom O'Rourke
6985b35218 drm/i915: Update ring freq for full gpu freq range
In __gen6_update_ring_freq, use the full range of
possible gpu frequencies from max_freq to min_freq.
The actual gpu frequency could be outside the range
from max_freq_softlimit to min_freq_softlimit due
to power/thermal constraints.

Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 13:03:33 +01:00
Tom O'Rourke
c7f3153a61 drm/i915: change initial rps frequency for gen8
In gen8_enable_rps, change the initial rps setting
to the min_freq_softlimit (same as gen6_enable_rps).

Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 13:03:32 +01:00
Tom O'Rourke
f4ab408c4b drm/i915: Keep min freq above floor on HSW/BDW
Set the min_freq_softlimit to max(RPe, 450MHz).

Setting a floor can ensure a minimum experience
level.  The 450MHz value came from a power and
performance study of various types of workloads
(3D, Media, GPGPU, idle, etc).

v2: rebased

Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 13:03:32 +01:00
Tom O'Rourke
93ee29203f drm/i915: Use efficient frequency for HSW/BDW
Added gen6_init_rps_frequencies() to initialize
the rps frequency values.  This function replaces
parse_rp_state_cap().  In addition to reading RPn,
RP0, and RP1 from RP_STATE_CAP register, the new
function reads efficient frequency (aka RPe) from
pcode for Haswell and Broadwell and sets the turbo
softlimits.  The turbo minimum frequency softlimit
is set to RPe for Haswell and Broadwell and to RPn
otherwise.

For RPe, the efficiency is based on the frequency/power
ratio (MHz/W); this is considering GT power and not
package power.  The efficent frequency is the highest
frequency for which the frequency/power ratio is within
some threshold of the highest frequency/power ratio.
A fixed decrease in frequency results in smaller
decrease in power at frequencies less than RPe than
at frequencies above RPe.

v2: Following suggestions from Chris Wilson and
Daniel Vetter to extend and rename parse_rp_state_cap
and to open-code a poorly named function.

Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Remove unused variables.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20 13:03:31 +01:00
Daniel Vetter
f548c0e9d4 drm/i915: Can i915_gem_init_ioctl
Found one more!

With this we can clear up the ggtt init code a bit, yay!

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20 13:03:31 +01:00
Daniel Vetter
377e91b204 drm/i915: Sanitize ->lastclose
With this all the ums nonsense around gem setup/teardown has
disappeared, yay!

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20 13:03:30 +01:00
Daniel Vetter
8725548307 drm/i915: Ditch dev_priv->ums.mm_suspend
Again just complicates gem init functions and makes a general mess out
of everything.

Good riddance!

v2: In my enthusiasm to start removing dri1/ums crud I went overboard a
bit and killed parts of hangcheck. Resurrect it.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20 13:02:57 +01:00
Dave Airlie
cc5ac1ca79 Merge branch 'amdkfd-v6' of git://people.freedesktop.org/~gabbayo/linux into drm-next
Merge AMDKFD it seems clean enough.
* 'amdkfd-v6' of git://people.freedesktop.org/~gabbayo/linux: (29 commits)
  amdkfd: Implement the Get Version IOCTL
  amdkfd: Implement the Get Process Aperture IOCTL
  amdkfd: Implement the Get Clock Counters IOCTL
  amdkfd: Implement the Set Memory Policy IOCTL
  amdkfd: Implement the create/destroy/update queue IOCTLs
  amdkfd: Add interrupt handling module
  amdkfd: Add device queue manager module
  amdkfd: Add process queue manager module
  amdkfd: Add packet manager module
  amdkfd: Add module parameter of scheduling policy
  amdkfd: Add kernel queue module
  amdkfd: Add mqd_manager module
  amdkfd: Add queue module
  amdkfd: Add binding/unbinding calls to amd_iommu driver
  amdkfd: Add basic modules to amdkfd
  amdkfd: Add topology module to amdkfd
  amdkfd: Add amdkfd skeleton driver
  amdkfd: Add IOCTL set definitions of amdkfd
  Update MAINTAINERS and CREDITS files with amdkfd info
  drm/radeon: Add radeon <--> amdkfd interface
  ...
2014-11-20 14:32:32 +10:00
Zach Reizner
8975626ea3 drm/cirrus: allow 32bpp framebuffers for cirrus drm
This patch allows framebuffers for cirrus to be created with
32bpp pixel formats provided that they do not violate certain
restrictions of the cirrus hardware.

v2: Use pci resource length for vram size.

Signed-off-by: Zach Reizner <zachr@google.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:42:46 +10:00
Haixia Shi
ebfdd6d5e8 drm/udl: add support to export a handle to a FD on UDL.
Only importing an FD to a handle is currently supported on UDL,
but the exporting functionality is equally useful.

Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:41:37 +10:00
Haixia Shi
09a58da052 drm/udl: add cache flags definitions for udl_gem_object
By default set udl_gem_object as cacheable, but set WC flag when attaching
dmabuf. In udl_gem_mmap() update cache attributes based on the flags, similar
to exynos_drm_gem_mmap().

Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:41:32 +10:00
Zach Reizner
a7ca52e108 drm/cirrus: fix leaky driver load error handling
Before this patch, cirrus_device_init could have failed while
cirrus_mm_init succeeded and the driver would have reported overall
success on load. This patch causes cirrus_device_init to return on
the first error encountered.

Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:41:26 +10:00
Daniel Vetter
b0fcfc8995 drm/atomic_helper: Make it clear that commit_planes gets the old state
Oversight from my kerneldoc cleanup when doing the original atomic
helper series - I've only applied this clarification to the modeset
related helpers, and not the plane update code. Remedy this asap.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:35:22 +10:00
Daniel Vetter
3758b34193 drm: s/enum_blob_list/enum_list/ in drm_property
I guess for hysterical raisins this was meant to be the way to read
blob properties. But that's done with the two-stage approach which
uses separate blob kms object and the special-purpose get_blob ioctl.

Shipping userspace seems to have never relied on this, and the kernel
also never put any blob thing onto that property. And nowadays it
would blow up, e.g. in drm_property_destroy. Also it makes no sense to
return values in an ioctl that only returns metadata about everything.

So let's ditch all the internal code for the blob list, rename the
list to be unambiguous and sprinkle comments all over the place to
explain this peculiar piece of api.

v2: Squash in fixup from Rob to remove now unused variables.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:35:21 +10:00
Daniel Vetter
1a49863349 drm/crtc: Polish kerneldoc
- Make it clear that it's a negative errno (more in line with
  everything else).
- Clean up the confusion around get_properties vs. getproperty ioctls:
  One reads per-obj property values, the other reads property
  metadata.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:35:20 +10:00
Daniel Vetter
f52b69f1ec drm/atomic: Don't overrun the connector array when hotplugging
Yet another fallout from not considering DP MST hotplug. With the
previous patches we have stable indices, but it might still happen
that a connector gets added between when we allocate the array and
when we actually add a connector. Especially when we back off due to
ww mutex contention or similar issues.

So store the sizes of the arrays in struct drm_atomic_state and double
check them. We don't really care about races except that we want to
use a consistent value, so ACCESS_ONCE is all we need. And if we
indeed notice that we'd overrun the array then just give up and
restart the entire ioctl.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:35:20 +10:00
Daniel Vetter
6f75cea66c drm/atomic: Only destroy connector states with connection mutex held
Otherwise the connector might have been unplugged and destroyed while
we didn't look. Yet another fallout from DP MST hotplugging that I
didn't consider.

To make sure we get this right add an appropriate WARN_ON to
drm_atomic_state_clear (obviously only when we actually have a state
to clear up). And reorder all the state_clear and backoff calls to
make it work out properly.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:35:19 +10:00
Daniel Vetter
c7eb76f493 drm/atomic: Ensure that drm_connector_index is stable
I've totally forgotten that with DP MST connectors can now be
hotplugged. And failed to adapt Rob's drm_atomic_state code (which
predates connector hotplugging) to the new realities.

The first step is to make sure that the connector indices used to
access the arrays of pointers are stable. The connection mutex gives
us enough guarantees for that, which means we won't unecessarily block
on concurrent modesets or background probing.

So add a locking WARN_ON and shuffle the code slightly to make sure we
always hold the right lock.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:35:18 +10:00
Rob Clark
7f907bf284 drm/irq: BUG_ON() -> WARN_ON()
Let's make things a bit easier to debug when things go bad (potentially
under console_lock).

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:33:51 +10:00
Tetsuo Handa
881fdaa5e4 drm/ttm: Avoid memory allocation from shrinker functions.
Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d791 ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
> > changed to use sc->gfp_mask rather than GFP_KERNEL.
> >
> > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> > -                       GFP_KERNEL);
> > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> >
> > But this bug is caused by sc->gfp_mask containing some flags which are not
> > in GFP_KERNEL, right? Then, I think
> >
> > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
> >
> > would hide this bug.
> >
> > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
>
> Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
> Just do
>
> 	struct page *pages_to_free[16];
>
> and rework the code to free 16 pages at a time.  Easy.

Well, ttm code wants to process 512 pages at a time for performance.
Memory footprint increased by 512 * sizeof(struct page *) buffer is
only 4096 bytes. What about using static buffer like below?
----------
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.

Commit a91576d791 ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags
which are not in GFP_KERNEL.

  https://bugzilla.kernel.org/show_bug.cgi?id=87891

Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would
avoid the BUG_ON(), but avoiding memory allocation from shrinker
function is better and reliable fix.

Shrinker function is already serialized by global lock, and
clean up function is called after shrinker function is unregistered.
Thus, we can use static buffer when called from shrinker function
and clean up function.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:31:56 +10:00
Fabian Frederick
2b0a3c4000 drm: remove unnecessary sizeof(u8)
sizeof(u8) is always 1.

Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:30:37 +10:00
Boris BREZILLON
aeb24cc0a3 drm: omapdrm: remove unused variable
Commit f9b9faf6d94dd29eab8c128905c7d091f955481d "drm: flip-work: change
drm_flip_work_init prototype" changed the drm_flip_work_init prototype
to a void function, which makes 'ret' an unused variable.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:29:39 +10:00
Gerd Hoffmann
3ce733b909 bochs: add page_flip
Implement crtc page_flip callback for bochsdrm.  The qemu stdvga has no
vblank signaling, so we have to fake it.  We do so by instantly calling
drm_send_vblank_event.  Tested with kmscon.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:27:31 +10:00
Gerd Hoffmann
49b70a31c1 bochs: fix bochsdrmfb mmap
Remove the mapping offset from the bo backing the fbdev framebuffer.
Wire up fbdev mmap function to map the backing bo using ttm_fbdev_mmap.
With that patch in place mmap(/dev/fb0) works as expected.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:27:09 +10:00
Gerd Hoffmann
9ecdb039b7 bochs: add endian switching support
Recently (qemu 2.2+) the qemu stdvga got a register to switch the vga
framebuffer endianness.  This patch adds code to explicitly set the
endianness of the framebuffer.  In most cases this has no effect as
the default is guest architecture endianness.  It is needed though in
case a architecture supports both big and little endian, i.e. for
ppc64le.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:26:54 +10:00
Gerd Hoffmann
fbd2f9fe97 bochs: little cleanup
Drop some leftover, commented code.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20 11:26:37 +10:00
Daniel Vetter
71b14ab618 drm/i915: No-Op enter/leave vt gem ioctl
We've killed ums support by now, it's time to reap the benefits. This
one here is getting in the way of doing some ring init cleanup.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-19 21:34:30 +01:00
Daniel Vetter
ac883c84e4 drm/i915: Drop checks for initialization
KMS always intializes, this was only a valid check when userspace
was still in control of the kernel driver.

v2: Comment that we outright reject all dri1/ums params.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 21:34:18 +01:00
Daniel Vetter
77f31815e1 drm/i915: Replace dri1 functions with drm_noop
Whether we'll reject them or no-op doesn't really matter ...

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 21:30:48 +01:00
Chris Wilson
5c6c600354 drm/i915: Remove DRI1 ring accessors and API
With the deprecation of UMS, and by association DRI1, we have a tough
choice when updating the ring access routines. We either rewrite the
DRI1 routines blindly without testing (so likely to be broken) or take
the liberty of declaring them no longer supported and remove them
entirely. This takes the latter approach.

v2: Also remove the DRI1 sarea updates

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fix rebase conflicts.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 21:17:11 +01:00
Thomas Daniel
7ba717cf36 drm/i915/bdw: Pin the ringbuffer backing object to GGTT on-demand
Same as with the context, pinning to GGTT regardless is harmful (it
badly fragments the GGTT and can even exhaust it).

Unfortunately, this case is also more complex than the previous one
because we need to map and access the ringbuffer in several places
along the execbuffer path (and we cannot make do by leaving the
default ringbuffer pinned, as before). Also, the context object
itself contains a pointer to the ringbuffer address that we have to
keep updated if we are going to allow the ringbuffer to move around.

v2: Same as with the context pinning, we cannot really do it during
an interrupt. Also, pin the default ringbuffers objects regardless
(makes error capture a lot easier).

v3: Rebased. Take a pin reference of the ringbuffer for each item
in the execlist request queue because the hardware may still be using
the ringbuffer after the MI_USER_INTERRUPT to notify the seqno update
is executed.  The ringbuffer must remain pinned until the context save
is complete.  No longer pin and unpin ringbuffer in
populate_lr_context() - this transient address is meaningless and the
pinning can cause a sleep while atomic.

v4: Moved ringbuffer pin and unpin into the lr_context_pin functions.
Downgraded pinning check BUG_ONs to WARN_ONs.

v5: Reinstated WARN_ONs for unexpected execlist states.  Removed unused
variable.

Issue: VIZ-4277
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 19:56:44 +01:00
Oscar Mateo
dcb4c12a68 drm/i915/bdw: Pin the context backing objects to GGTT on-demand
Up until now, we have pinned every logical ring context backing object
during creation, and left it pinned until destruction. This made my life
easier, but it's a harmful thing to do, because we cause fragmentation
of the GGTT (and, eventually, we would run out of space).

This patch makes the pinning on-demand: the backing objects of the two
contexts that are written to the ELSP are pinned right before submission
and unpinned once the hardware is done with them. The only context that
is still pinned regardless is the global default one, so that the HWS can
still be accessed in the same way (ring->status_page).

v2: In the early version of this patch, we were pinning the context as
we put it into the ELSP: on the one hand, this is very efficient because
only a maximum two contexts are pinned at any given time, but on the other
hand, we cannot really pin in interrupt time :(

v3: Use a mutex rather than atomic_t to protect pin count to avoid races.
Do not unpin default context in free_request.

v4: Break out pin and unpin into functions.  Fix style problems reported
by checkpatch

v5: Remove unpin_lock as all pinning and unpinning is done with the struct
mutex already locked.  Add WARN_ONs to make sure this is the case in future.

Issue: VIZ-4277
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 19:32:58 +01:00
Thomas Daniel
c86ee3a9f8 drm/i915/bdw: Clean up execlist queue items in retire_work
No longer create a work item to clean each execlist queue item.
Instead, move retired execlist requests to a queue and clean up the
items during retire_requests.

v2: Fix legacy ring path broken during overzealous cleanup

v3: Update idle detection to take execlists queue into account

v4: Grab execlist lock when checking queue state

v5: Fix leaking requests by freeing in execlists_retire_requests.

Issue: VIZ-4274
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Akash Goel <akash.goels@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 19:16:45 +01:00
Daniel Vetter
54499b2a92 Merge tag 'drm-intel-fixes-2014-11-19' into drm-intel-next-queued
So with all the code movement and extraction in intel_pm.c in -next
git is hopelessly confused with

commit 2208d655a9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Nov 14 09:25:29 2014 +0100

    drm/i915: drop WaSetupGtModeTdRowDispatch:snb

from -fixes. Worse even small changes in -next move around the
conflict context so rerere is equally useless. Let's just backmerge
and be done with it.

Conflicts:
	drivers/gpu/drm/i915/i915_drv.c
	drivers/gpu/drm/i915/intel_pm.c

Except for git getting lost no tricky conflicts really.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-19 18:17:38 +01:00
Imre Deak
2eb5252e2f drm/i915: disable rps irqs earlier during suspend/unload
After the previous patch RPS disabling doesn't depend any more on the
first level interrupts being disabled, so we can move it everywhere
earlier. Doing so let's us think about the uninitialization steps
afterwards independently of any asynchronous RPS events that can happen
atm. It also makes the system/runtime suspend time RPS disabling more
uniform. Finally this gets rid of the WARN in
intel_suspend_gt_powersave(), which we can hit if a final RPS work runs
after we disabled the first level interrupts.

Testcase: igt/pm_rpm
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 15:03:29 +01:00
Imre Deak
d4d70aa596 drm/i915: sanitize rps irq disabling
When disabling the RPS interrupts there is a tricky dependency between
the thread disabling the interrupts, the RPS interrupt handler and the
corresponding RPS work. The RPS work can reenable the interrupts, so
there is no straightforward order in the disabling thread to (1) make
sure that any RPS work is flushed and to (2) disable all RPS
interrupts. Currently this is solved by masking the interrupts using two
separate mask registers (first level display IMR and PM IMR) and doing
the disabling when all first level interrupts are disabled.

This works, but the requirement to run with all first level interrupts
disabled is unnecessary making the suspend / unload time ordering of RPS
disabling wrt. other unitialization steps difficult and error prone.
Removing this restriction allows us to disable RPS early during suspend
/ unload and forget about it for the rest of the sequence. By adding a
more explicit method for avoiding the above race, it also becomes easier
to prove its correctness. Finally currently we can hit the WARN in
snb_update_pm_irq(), when a final RPS work runs with the first level
interrupts already disabled. This won't lead to any problem (due to the
separate interrupt masks), but with the change in this and the next
patch we can get rid of the WARN, while leaving it in place for other
scenarios.

To address the above points, add a new RPS interrupts_enabled flag and
use this during RPS disabling to avoid requeuing the RPS work and
reenabling of the RPS interrupts. Since the interrupt disabling happens
now in intel_suspend_gt_powersave(), we will disable RPS interrupts
explicitly during suspend (and not just through the first level mask),
but there is no problem doing so, it's also more consistent and allows
us to unify more of the RPS disabling during suspend and unload time in
the next patch.

v2/v3:
- rebase on patch "drm/i915: move rps irq disable one level up" in the
  patchset

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 15:03:23 +01:00
Imre Deak
3cc134e3ee drm/i915: sanitize rps irq enabling
Atm we first enable the RPS interrupts then we clear any pending ones.
By this we could lose an interrupt arriving after we unmasked it. This
may not be a problem as the caller should handle such a race, but logic
still calls for the opposite order. Also we can delay enabling the
interrupts until after all the RPS initialization is ready with the
following order:

1. disable left-over RPS (earlier via intel_uncore_sanitize)
2. clear any pending RPS interrupts
3. initialize RPS
4. enable RPS interrupts

This also allows us to do the 2. and 4. step the same way for all
platforms, so let's follow this order to simplifying things.

Also make sure any queued interrupts are also cleared.

v2:
- rebase on the GEN9 patches where we don't support RPS yet, so we
  musn't enable RPS interrupts on it (Paulo)
v3:
- avoid enabling RPS interrupts on GEN>9 too (Paulo)
- clarify the RPS init sequence in the log message (Chris)
- add POSTING_READ to gen6_reset_rps_interrupts() (Paulo)
- WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts()
  (Paulo)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 15:03:17 +01:00
Imre Deak
e534770add drm/i915: move rps irq disable one level up
We disable the RPS interrupts for all platforms at the same spot, so
move it one level up in the callstack to simplify things.

No functional change.

v2:
- rebase on the GEN9 patches where RPS isn't supported yet, so we don't
  need to disable RPS interrupts on it (Paulo)
v3:
- avoid disabling the interrupts on GEN>9 too (Paulo)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 15:03:11 +01:00
Imre Deak
4a74de821a drm/i915: WARN if we receive any rps interrupts on gen>9
This extends

commit 132f3f1767
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Nov 10 15:34:33 2014 +0200

    drm/i915: WARN if we receive any gen9 rps interrupts

to GEN>9 platforms as suggested by Paulo.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 15:03:01 +01:00
Matt Roper
9dc806fc1a drm/i915: Don't store panning coordinates as 16.16 fixed point
When using the universal plane interface, the source rectangle
coordinates define the panning offset for the primary plane, which needs
to be stored in crtc->{x,y}.  The original universal plane code
negelected to set these panning offset fields, which was partially
remedied in:

        commit ccc759dc2a
        Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
        Date:   Wed Sep 24 14:20:22 2014 -0300

            drm/i915: Merge of visible and !visible paths for primary planes

However the plane source coordinates are provided in 16.16 fixed point
format and the above commit forgot to convert back to integer
coordinates before saving the values.  When we replace
intel_pipe_set_base() with plane->funcs->update_plane() in a future
patch, this bug becomes visible via the set_config entrypoint as well as
update_plane.

Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Testcase: igt/kms_plane
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 14:56:53 +01:00
Jesse Barnes
f061b9be74 drm/i915/ddi: set has_infoframe flag on DDI too v2
Just like we do in the HDMI code, set the infoframe flag if we detect
that infoframes are enabled.

v2: check for actual infoframe status as in hdmi code (Daniel)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 14:54:08 +01:00
Tom O'Rourke
151a49d079 drm/i915: Extend pcode mailbox interface
In sandybridge_pcode_read and sandybridge_pcode_write,
extend the mbox parameter from u8 to u32.

On Haswell and Sandybridge, bits 7:0 encode the mailbox
command and bits 28:8 are used for address control for
specific commands.

Based on suggestion from Ville Syrjälä.

Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 14:39:58 +01:00
Daniel Vetter
90bd1f46ca drm/i915: Tune down sink crc timeout dmesg output
For whatever reasons this can happen. For real testcases the test will
notice the -EIO and fall over, but we also have some testcases that
just read all debugfs files. And that shouldn't cause dmesg spam.

So tune it down a bit so that we still have the information for
debugging. And change the errno so that real testcases can easily
differentiate.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84890
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-19 11:46:35 +01:00
Chris Wilson
672e7b7c18 drm/i915: Don't continually defer the hangcheck
With multiple rings, we may continue to render on the blitter whilst
executing an infinite shader on the render ring. As we currently, rearm
the timer with each execbuf, in this scenario the hangcheck will never
fire and we will never detect the lockup on the render ring. Instead,
only arm the timer once per hangcheck, so that hangcheck runs more
frequently.

v2: Rearrange code to avoid triggering a BUG_ON in add_timer from
softirq context.

Testcase: igt/gem_reset_stats/defer-hangcheck*
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86225
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19 11:44:50 +01:00
Daniel Vetter
77c1aa84de drm/i915: Don't print header in error state for non-existing CS
This goes back to

commit 362b8af7ad
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Thu Jan 30 00:19:38 2014 -0800

    drm/i915: Move per ring error state to ring_error

Spotted while reading error states.

Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-18 16:23:13 +01:00
Jani Nikula
eb45fa0b93 drm/i915/audio: fix monitor presence indication after disable
Indicate the monitor has been disconnected on disable.

The regression has been introduced in

commit 5fad84a753
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Nov 4 10:30:23 2014 +0200

    drm/i915: rewrite hsw/bdw audio codec enable/disable sequences

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86424
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-18 11:17:37 +01:00
Jesse Barnes
cbc572a9a5 drm/i915/ddi: add break in DDI mode select switch
The lack of a break here wasn't for falling through to some other
important code, so made me do a double take.  Add a break just to make
things a little less confusing.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-18 09:14:32 +01:00
Daniel Vetter
70b0ea8656 drm/i915: Drop return value from lrc_setup_hardware_status_page
kmap never fails.

Spotted-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-18 09:09:32 +01:00
Matt Roper
6ac0483b35 drm/i915: Propagate invalid setcrtc cloning errors back to userspace
When invalid cloning configurations were detected during modeset, we
never copied the error code into the return value variable, leading us
to return 0 (success) to userspace.

This regression has been introduced in

commit 50f5275698
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Nov 7 13:11:00 2014 -0800

    drm/i915: use compute_config in set_config v4

Testcase: igt/kms_setmode
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86226
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 21:20:49 +01:00
Damien Lespiau
134ffa44d1 drm/i915/skl: Use the pipe config DPLL tracking to query the link clock
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 19:25:31 +01:00
Damien Lespiau
5416d87113 drm/i915/skl: Set the eDP link rate on DPLL0
On SKL DPLL0 is used to derive CDCLK but can also be used to drive an
eDP port (as long as we don't want SSC). DPLL0 is special enough to not
be handled by the shared DPLL framework (drives CDCLK, not supposed to
enable the HDMI mode), So we need to compute the configuration
separately from the other DPLLs.

Note that we don't need to reprogram DPLL0 (which would mean bringing
down CDCLK) to support the various eDP 1.3 link rates as they all share
the same VCO (8100).

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 19:19:44 +01:00
Rodrigo Vivi
b2b89f55df drm/i915: Add PSR docbook
Let's document PSR a bit. No functional changes.

v2: Add actual DocBook entry and accept Daniel's improvements.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 19:13:24 +01:00
Rodrigo Vivi
0bc12bcb1b drm/i915: Introduce intel_psr.c
No functional changes. Just cleaning and reorganizing it.

v2: Rebase it puting it to begin of psr rework. This helps to blame easily
at least latest changes.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 19:12:28 +01:00
Rodrigo Vivi
a4f1289eaa drm/i915: Make dp aux pack/unpack public outside intel_dp.c
No functional change. Just making it public for use outside intel_dp.c
Allowing split psr functions.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 19:12:22 +01:00
Ville Syrjälä
2fe486c7ea drm/i915: Drop WaRsForcewakeWaitTC0:vlv
GEN6_GT_THREAD_STATUS_REG doesn't seem to exist on VLV. Reads just give
0x0 no matter what the state of the render and media wells.

There was also some hint in the Gunit HAS that thread status not being
needed on VLV, and hence dropped when bringing stuff over from the IVB
design. Not really a definite comment about the specific register itself
though.

Also the w/a itself is no longer listed for VLV in the database. It was
there some time ago in the past, but I guess someone figured out the
mistake and dropped it.

So let's just drop it from the code as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 19:11:18 +01:00
Ville Syrjälä
eb88bd1b47 drm/i915: Drop the HSW special case from __gen6_gt_wait_for_thread_c0()
Bits [18:16] of GEN6_GT_THREAD_STATUS_REG have always had the same
meaning since SNB. So treating them as something special for HSW doesn't
make sense to me.

Also the bits *seem* to work exactly the same way on IVB, HSW GT2 and
HSW GT3. At least intel_reg_read gives the identical results on all
platforms with and without forcewake.

Also the HSW PM guide rev 0.99 (ww05 2013) doesn't say anything about
those bits. It just says to poll for bits [2:0]. As does the more recent
BDW PM guide.

So just drop the HSW special case and treat all platforms the same way.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 19:11:09 +01:00
Damien Lespiau
f5f7d3c6e4 drm/i915/skl: Remove spurious warn in get_ddi_pll()
When reading out a DDI config that uses a PLL that is not part of the
shared_dpll scheme (DPLL0), it's totally normal to end up in the
default: case of that switch.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 16:00:47 +01:00
Ville Syrjälä
ab3fb15730 drm/i915: Change CHV SKU400 GPU freq divider to 10
According to "Cherryview_GFXclocks_y14w36d1.xlsx" the GPU frequency
divider should be 10 in when the CZ clock is 400 MHz. Change the code
to agree so that we report the correct frequencies.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 15:34:44 +01:00
Ville Syrjälä
80b83b6217 drm/i915: Add missing newline to 'DDR speed' debug messages
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 15:34:31 +01:00
Ville Syrjälä
dd06f88cd0 drm/i915: Refactor vlv/chv GPU frequency divider setup
The divider used in the GPU frequency calculations is compatible between
vlv and chv. vlv just wants doubled values compared to chv.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 15:33:51 +01:00
Ville Syrjälä
ce611ef81f drm/i915: Improve PCBR debug information
Always print the final PCBR register value on both vlv and chv, and
also tell us whether the BIOS was a good citizen or not.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 15:31:14 +01:00
Ville Syrjälä
8d40c3ae51 drm/i915: Warn if GPLL isn't used on vlv/chv
Our freq<->opcode conversions assume that GPLL is always used.
Apparently that should be the case always, but let's scream if we
ever encounter something different.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 15:30:55 +01:00
Ville Syrjälä
c8e9627d2a drm/i915: Add a name for the Punit GPLLENABLE bit
Remove the magic number for the GPLLENABLE bit by adding a name for it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 15:30:38 +01:00
Ville Syrjälä
9a3b9c7a64 drm/i915: Silence valleyview_set_rps()
Even with the rps debug messages signficantly recuced  by
 commit 67956867aa
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Tue Sep 2 15:12:17 2014 +0300

    drm/i915: Don't spam dmesg with rps messages on vlv/chv

we still get an inordinate amount of spam from this. Just kill the debug
print. If someone wants to observe it they can just use the tracepoint.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 15:30:14 +01:00
Daniel Vetter
0485c9dc24 drm/i915: Kick fbdev before vgacon
It's magic, but it seems to work.

This fixes a regression introduced in

commit 1bb9e632a0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jul 8 10:02:43 2014 +0200

    drm/i915: Only unbind vgacon, not other console drivers

My best guess is that the vga fbdev driver falls over if we rip out
parts of vgacon. Hooray.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82439
Cc: stable@vger.kernel.org (v3.16+)
Reported-and-tested-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-11-17 10:18:21 +02:00
Daniel Vetter
2208d655a9 drm/i915: drop WaSetupGtModeTdRowDispatch:snb
This reverts the regressing

commit 6547fbdbff
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Dec 14 23:38:29 2012 +0100

    drm/i915: Implement WaSetupGtModeTdRowDispatch

that causes GPU hangs immediately on boot.

Reported-by: Leo Wolf <jclw@ymail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79996
Cc: stable@vger.kernel.org (v3.8+)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
[Jani: amended the commit message slightly.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-11-17 10:18:21 +02:00
Ville Syrjälä
afd6275dd1 drm/i915: Reinit display irqs and hpd from chv pipe-a power well
On chv the pipe-a power well is the new disp2d well, and it kills pretty
much everything in the display block. So we need to do the the same
dance that vlv does wrt. display irqs and hpd when the power well goes
up or down.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17 09:16:53 +01:00
Dave Airlie
d0d6c524bf Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next
Main pull for 3.19.  I may have another pull in a few days with some
mdp5 bits (and hopefully mdp5 atomic), but I figured there was no need
to hold up what we have already.  Main highlights so far:

1) a4xx gpu support (userspace gallium bits on mesa master)
2) mdp4/hdmi/core bits for atomic helpers.  Still missing mdp5
conversion, main hold up there is current hard-coded mixer setup isn't
clever enough to deal with disabling primary plane while crtc active.
3) various other misc cleanup/fixes/etc..

* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (21 commits)
  drm/msm: a4xx support for msm-drm
  drm/msm: Handle register offset differences between a3xx and a4xx
  drm/msm: small mmap offset cleanups
  drm/msm/mdp4: atomic
  drm/msm/hdmi: atomic
  drm/msm: atomic core bits
  drm/msm: bit of fb error checking
  drm/msm: fb prepare/cleanup
  drm/msm: remove unused compile-test stub
  drm/msm: small fence cleanup
  drm/msm/mdp5: drop attached planes table
  drm/msm/mdp4: drop attached planes table
  drm/msm/mdp4: don't care about fb in crtc
  drm/msm/mdp5: drop private primary ptr
  drm/msm/mdp4: drop private primary ptr
  drm/msm: Fix fbdev for 16- and 24-bit modes.
  drm/msm: Allow exported dma-bufs to be mapped
  drm/msm/hdmi: refactor bind/init
  drm/msm: update generated headers
  drm/msm/adreno: slight init order cleanup
  ...
2014-11-17 06:36:53 +10:00
Aravind Ganesan
23bd62fd41 drm/msm: a4xx support for msm-drm
Added a4xx GPU support.

Signed-off-by: Aravind Ganesan <aravindg@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-16 14:27:40 -05:00
Aravind Ganesan
91b74e9761 drm/msm: Handle register offset differences between a3xx and a4xx
Register offsets have changed between a3xx and a4xx GPUs.
To be able access these registers in common code, we create
a lookup table, and set of read-write APIs to access the
register through the lookup table.

Signed-off-by: Aravind Ganesan <aravindg@codeaurora.org>
[robclark: remove REG_ADRENO_UNDEFINED, just use zero, and minor
tweaks for latest generated headers]
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-16 14:27:39 -05:00
Rob Clark
257d06f704 drm/msm: small mmap offset cleanups
Use pre-computed iova when unmapping, to reduce the places we assume iova
and mmap offset are (at the moment) the same.  And get rid of an extra
drm_gem_free_mmap_offset() call (since it is already called from
drm_gem_object_release())

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-11-16 14:27:39 -05:00