user/sven/linux.git/include/drm, branch v4.0

drm/ttm: device address space != CPU address space

2015-03-04T23:04:39Z

We need to store device offsets in 64 bit as the device address space may be larger than the CPU's. Fixes GPU init failures on radeons with 4GB or more of vram on 32 bit kernels. We put vram at the start of the GPU's address space so the gart aperture starts at 4 GB causing all GPU addresses in the gart aperture to get truncated. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89072 [airlied: fix warning on nouveau build] Signed-off-by: Alex Deucher Cc: thellstrom@vmware.com Acked-by: Thomas Hellstrom Signed-off-by: Dave Airlie

drm/mm: Support 4 GiB and larger ranges

2015-03-04T23:01:37Z

The current implementation is limited by the number of addresses that fit into an unsigned long. This causes problems on 32-bit Tegra where unsigned long is 32-bit but drm_mm is used to manage an IOVA space of 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 (or 4 GiB - 4 KiB for page granularity). This commit changes the start and size of the range to be an unsigned 64-bit integer, thus allowing much larger ranges to be supported. [airlied: fix i915 warnings and coloring callback] Signed-off-by: Thierry Reding Reviewed-by: Alex Deucher Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie fixupo

drm/i915/bdw: PCI IDs ending in 0xb are ULT.

2015-02-23T09:31:18Z

When reviewing patch that fixes VGA on BDW Halo Jani noticed that we also had other ULT IDs that weren't listed there. So this follow-up patch add these pci-ids as halo and fix comments on i915_pciids.h Cc: Jani Nikula Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Vivi Signed-off-by: Jani Nikula

drm/dp: add drm_dp_link_power_down() helper

2015-02-01T20:06:42Z

We had _power_up(), but drivers also need to be able to power down. Signed-off-by: Rob Clark Reviewed-by: Thierry Reding Reviewed-by: Alex Deucher

drm/bridge: make bridge registration independent of drm flow

2015-01-28T07:45:40Z

Currently, third party bridge drivers(ptn3460) are dependent on the corresponding encoder driver init, since bridge driver needs a drm_device pointer to finish drm initializations. The encoder driver passes the drm_device pointer to the bridge driver. Because of this dependency, third party drivers like ptn3460 doesn't adhere to the driver model. In this patch, we reframe the bridge registration framework so that bridge initialization is split into 2 steps, and bridge registration happens independent of drm flow: --Step 1: gather all the bridge settings independent of drm and add the bridge onto a global list of bridges. --Step 2: when the encoder driver is probed, call drm_bridge_attach for the corresponding bridge so that the bridge receives drm_device pointer and continues with connector and other drm initializations. The old set of bridge helpers are removed, and a set of new helpers are added to accomplish the 2 step initialization. The bridge devices register themselves onto global list of bridges when they get probed by calling "drm_bridge_add". The parent encoder driver waits till the bridge is available in the lookup table(by calling "of_drm_find_bridge") and then continues with its initialization. The encoder driver should also call "drm_bridge_attach" to pass on the drm_device to the bridge object. drm_bridge_attach inturn calls "bridge->funcs->attach" so that bridge can continue with drm related initializations. Signed-off-by: Ajay Kumar Acked-by: Inki Dae Tested-by: Rahul Sharma Tested-by: Javier Martinez Canillas Tested-by: Gustavo Padovan Tested-by: Sjoerd Simons Signed-off-by: Thierry Reding

drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init

2015-01-28T07:45:40Z

Assign the pointer to bridge ops structure(drm_bridge_funcs) in the bridge driver itself, instead of passing it to drm_bridge_init. This will allow bridge driver developer to pack bridge private information inside the bridge object and pass only the drm-relevant information to drm_bridge_init. Signed-off-by: Ajay Kumar Acked-by: Inki Dae Tested-by: Rahul Sharma Tested-by: Javier Martinez Canillas Tested-by: Gustavo Padovan Tested-by: Sjoerd Simons Signed-off-by: Thierry Reding

Merge tag 'topic/atomic-core-2015-01-27' of git://anongit.freedesktop.org/drm-intel into drm-next

2015-01-27T23:34:27Z

* tag 'topic/atomic-core-2015-01-27' of git://anongit.freedesktop.org/drm-intel: drm/atomic: Fix potential use of state after free drm/atomic-helper: debug output for modesets drm/atomic-helpers: Saner encoder/crtc callbacks drm/atomic-helpers: Recover full cursor plane behaviour drm/atomic-helper: add connector->dpms() implementation drm/atomic: Add drm_crtc_state->active drm: Add standardized boolean props drm/plane-helper: Fix transitional helper kerneldocs drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb Conflicts: include/drm/drm_crtc_helper.h

Merge tag 'drm/tegra/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next

2015-01-27T23:27:29Z

drm/tegra: Changes for v3.20-rc1 The biggest part of these changes is the conversion to atomic mode- setting. A lot of cleanup and demidlayering was required before the conversion, with the result being a whole lot of changes. Besides the atomic mode-setting support, the host1x bus now has the proper infrastructure to support suspend/resume for child devices. Finally, a couple of smaller cleanup patches round things off. * tag 'drm/tegra/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux: (54 commits) drm/tegra: Use correct relocation target offsets drm/tegra: Add minimal power management drm/tegra: dc: Unify enabling the display controller drm/tegra: Track tiling and format in plane state drm/tegra: Track active planes in CRTC state drm/tegra: Remove unused ->mode_fixup() callbacks drm/tegra: Atomic conversion, phase 3, step 3 drm/tegra: Atomic conversion, phase 3, step 2 drm/tegra: dc: Use atomic clock state in modeset drm/tegra: sor: Implement ->atomic_check() drm/tegra: hdmi: Implement ->atomic_check() drm/tegra: dsi: Implement ->atomic_check() drm/tegra: rgb: Implement ->atomic_check() drm/tegra: dc: Store clock setup in atomic state drm/tegra: Atomic conversion, phase 3, step 1 drm/tegra: Atomic conversion, phase 2 drm/tegra: Atomic conversion, phase 1 drm/tegra: dc: Do not needlessly deassert reset drm/tegra: Output cleanup functions cannot fail drm/tegra: Remove remnants of the output midlayer ...

drm/atomic: Add ->atomic_check() to encoder helpers

2015-01-27T09:14:42Z

This callback can be used instead of the legacy ->mode_fixup() and is passed the CRTC and connector states. It can thus use these states to validate the modeset and cache values in the state to be used during the actual modeset. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding

drm/plane: Add optional ->atomic_disable() callback

2015-01-27T09:14:42Z

In order to prevent drivers from having to perform the same checks over and over again, add an optional ->atomic_disable callback which the core calls under the right circumstances. v2: pass old state and detect edges to avoid calling ->atomic_disable on already disabled planes, remove redundant comment (Daniel Vetter) v3: rename helper to drm_atomic_plane_disabling() to clarify that it is checking for transitions, move helper to drm_atomic_helper.h, clarify check for !old_state and its relation to transitional helpers Here's an extract from some discussion rationalizing the behaviour (for a full version, see the reference below): > > Hm, thinking about this some more this will result in a slight difference > > in behaviour, at least when drivers just use the helper ->reset functions > > but don't disable everything: > > - With transitional helpers we assume we know nothing and call > > ->atomic_disable. > > - With atomic old_state->crtc == NULL in the same situation right after > > boot-up, but we asssume the plane is really off and _dont_ call > > ->atomic_disable. > > > > Should we instead check for (old_state && old_state->crtc) and state that > > drivers need to make sure they don't have stuff hanging around? > > I don't think we can check for old_state because otherwise this will > always return false, whereas we really want it to force-disable planes > that could be on (lacking any more accurate information). For > transitional helpers anyway. > > For the atomic helpers, old_state will never be NULL, but I'd assume > that the driver would reconstruct the current state in ->reset(). By the way, the reason for why old_state can be NULL with transitional helpers is the ordering of the steps in the atomic transition. Currently the Tegra patches do this (based on your blog post and the Exynos proto- type): 1) atomic conversion, phase 1: - implement ->atomic_{check,update,disable}() - use drm_plane_helper_{update,disable}() 2) atomic conversion, phase 2: - call drm_mode_config_reset() from ->load() - implement ->reset() That's only a partial list of what's done in these steps, but that's the only relevant pieces for why old_state is NULL. What happens is that without ->reset() implemented there won't be any initial state, hence plane->state (the old_state here) will be NULL the first time atomic state is applied. We could of course reorder the sequence such that drivers are required to hook up ->reset() before they can (or at the same as they) hook up the transitional helpers. We could add an appropriate WARN_ON to this helper to make that more obvious. However, that will not solve the problem because it only gets rid of the special case. We still don't know whether old_state->crtc == NULL is the current state or just the initial default. So no matter which way we do this, I don't see a way to get away without requiring specific semantics from drivers. They would be that: - drivers recreate the correct state in ->reset() so that old_state->crtc != NULL if the plane is really enabled or - drivers have to ensure that the real state in fact mirrors the initial default as encoded in the state (plane disabled) References: http://lists.freedesktop.org/archives/dri-devel/2015-January/075578.html Reviewed-by: Daniel Vetter Reviewed-by: Gustavo Padovan Signed-off-by: Thierry Reding