Signed-off-by: Samuel Li <samuel.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine.
V1->V2: Follow Daniel's comment to pay attention to the stolen check for BDW
in kernel/early-quirks.c
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Next pull request, this time more of the drm de-midlayering work. The big
thing is that his patch series here removes everything from drm_bus except
the set_busid callback. Thierry has a few more patches on top of this to
make that one optional to.
With that we can ditch all the non-pci drm_bus implementations, which
Thierry has already done for the fake tegra host1x drm_bus.
Reviewed by Thierry, Laurent and David and now also survived some testing
on my intel boxes to make sure the irq fumble is fixed correctly ;-) The
last minute rebase was just to add the r-b tags from Thierry for the 2
patches I've redone.
* 'drm-init-cleanup' of git://people.freedesktop.org/~danvet/drm:
drm/<drivers>: don't set driver->dev_priv_size to 0
drm: Remove dev->kdriver
drm: remove drm_bus->get_name
drm: rip out dev->devname
drm: inline drm_pci_set_unique
drm: remove bus->get_irq implementations
drm: pass the irq explicitly to drm_irq_install
drm/irq: Look up the pci irq directly in the drm_control ioctl
drm/irq: track the irq installed in drm_irq_install in dev->irq
drm: rename dev->count_lock to dev->buf_lock
drm: Rip out totally bogus vga_switcheroo->can_switch locking
drm: kill drm_bus->bus_type
drm: remove drm_dev_to_irq from drivers
drm/irq: remove cargo-culted locking from irq_install/uninstall
drm/irq: drm_control is a legacy ioctl, so pci devices only
drm/pci: fold in irq_by_busid support
drm/irq: simplify irq checks in drm_wait_vblank
For QXL hw we really want the bits to be replaced as we change
the preferred mode on the fly, and the same goes for virgl when
I get to it, however the original fix for this seems to have caused
a wierd regression on Intel G33 that in a stunning display of failure
at opposition to his normal self, Daniel failed to diagnose.
So we are left doing this, ugly ugly ugly ugly, Daniel you fixed
that G33 yet?, ugly, ugly.
Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm-intel-next-2014-04-16:
- vlv infoframe fixes from Jesse
- dsi/mipi fixes from Shobhit
- gen8 pageflip fixes for LRI/SRM from Damien
- cmd parser fixes from Brad Volkin
- some prep patches for CHV, DRRS, ...
- and tons of little things all over
drm-intel-next-2014-04-04:
- cmd parser for gen7 but only in enforcing and not yet granting mode - the
batch copying stuff is still missing. Also performance is a bit ... rough
(Brad Volkin + OACONTROL fix from Ken).
- deprecate UMS harder (i.e. CONFIG_BROKEN)
- interrupt rework from Paulo Zanoni
- runtime PM support for bdw and snb, again from Paulo
- a pile of refactorings from various people all over the place to prep for new
stuff (irq reworks, power domain polish, ...)
drm-intel-next-2014-04-04:
- cmd parser for gen7 but only in enforcing and not yet granting mode - the
batch copying stuff is still missing. Also performance is a bit ... rough
(Brad Volkin + OACONTROL fix from Ken).
- deprecate UMS harder (i.e. CONFIG_BROKEN)
- interrupt rework from Paulo Zanoni
- runtime PM support for bdw and snb, again from Paulo
- a pile of refactorings from various people all over the place to prep for new
stuff (irq reworks, power domain polish, ...)
Conflicts:
drivers/gpu/drm/i915/i915_gem_context.c
Because the docs say ULX doesn't support it on HSW.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Describe the fifo parameter. It seems like kerneldoc doesn't properly
handle fields defined using a macro, so it will end up complaining about
this anyway and not generate the documentation for it either. At least
the kerneldoc is now complete.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the last patch to ditch the ->get_name callbacks the last
user is now gone.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The only user is the info debugfs file, so we only need something
human readable. Now for both pci and platform devices we've used the
name of the underlying device driver, which matches the name of the
drm driver in all cases. So we can just use that instead.
The exception is usb, which used a generic "USB". Not to harmful with
just one usb driver, but better to use "udl", too.
With that converted we can rip out all the ->get_name implementations.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was only ever used to pretty-print the irq driver name. And on
kms systems due to set_version bonghits we never set up the prettier
name, ever. Which make this a bit pointless.
Also, we can always dig out the driver-instance/irq relationship
through other means, so this isn't that useful. So just rip it out to
simplify the set_version/set_busid insanity a bit.
Also delete the temporary busname from drm_pci_set_busid, it's now
unused.
v2: Rebase on top of the new host1x drm_bus for tegra.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is only used for drm versions 1.0, and kms drivers have never
been there. So we can appropriately restrict this to legacy and hence
pci devices and inline everything.
v2: Make the dummy function actually return something, caught by Wu
Fengguang's 0-day tester.
v3: Fix spelling in comment (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that they're all unused we can get rid of them, including the
dummy version in drm_usb.c.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.
With that we can now also remove drm_dev_to_irq from drm_irq.c.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.
v2: Add the hunk lost in an earlier patch to this one (Thierry).
v3: Fix up the totally fumbled logic in drm_irq_install and use the
local variable consistently. Spotted by both Thierry and Laurent.
Shame on me for failing to properly test the rebase version of this
patch ...
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since really that's all it protects - legacy horror stories in
drm_bufs.c. Since I don't want to waste any more time on this I didn't
bother to actually look at what it protects in there, but it's at
least contained now.
v2: Move the spurious hunk to the right patch (Thierry).
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.
Unfortunately the vga switcheroo callbacks took this comment at face
value. The problem is that we can't just take the drm_global_mutex
because:
- It would lead to a locking inversion with the driver load/unload
paths.
- It wouldn't actually protect anything, for that we'd need to wrap
the entire vga switcheroo code in the drm_global_mutex. And I'm not
sure whether that would actually solve anything.
What we probably want is a try_to_grab_switcheroo reference kind of
thing which is used in the driver's ->open callback. Then we could
move all that ->can_switch madness into the vga switcheroo core where
it really belongs.
But since that would amount to real work take the easy way out and
just add a comment. It's definitely not going to make anything worse
since doing switcheroo state changes while restarting X just isn't
recommended. Even though the delayed switching code does exactly that.
v2:
- Simplify the ->can_switch implementations more (Thierry)
- Fix comment about the dev->open_count locking (Thierry)
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v1)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Completely unused. Hooray, midlayer mistakes that didn't cause work to
undo!
v2: Rebase on top of the recent tegra changes which added a host1x drm
bus.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only used in some legacy pci drivers, and dereferencing the PCI irq is
actually shorter ...
Since this removes all users for drm_dev_to_irq from the tree except
in drm_irq.c, move the inline helper in there. It'll disappear soon,
too.
v2: Polish commit message (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a ums-only ioctl, and we've only ever supported ums (at least
in upstream) on pci devices. So no point in keeping that piece of
legacy logic abstracted within the drm bus driver.
To keep things work without CONFIG_PCI also add a dummy ioctl.
v2: Block the irq_by_busid ioctl for modeset drivers.
v3: Spelling/whitespace polish (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Many drm connectors do not need mode validation.
The patch makes this callback optional and removes dumb implementations.
v2: Rebase:
- imx move to a shared (but still dummy) ->mode_valid implementation.
- probe helpers have been extracted to drm_probe_helper.c
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Populate PAR in infoframe structure. If there is a user setting for PAR, then
that value is set. Else, value is taken from CEA mode list if VIC is found.
Else, PAR is calculated from resolution. If none of these conditions are
satisfied, PAR is NONE as per initialization.
v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.
A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.
v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.
v3: Removed calculation of PAR for non-CEA modes as per discussion with
Ville.
A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Jesse Barnes <jesse.barnes@intel.com>
Cc: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Squash in fixup for htmldocs.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some i2c fixes over DisplayPort.
* 'drm-next-3.15-wip' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: Improve vramlimit module param documentation
drm/radeon: fix audio pin counts for DCE6+ (v2)
drm/radeon/dp: switch to the common i2c over aux code
drm/dp/i2c: Update comments about common i2c over dp assumptions (v3)
drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
drm/i915: support address only i2c-over-aux transactions
drm/tegra: dp: Support address-only I2C-over-AUX transactions
This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.
The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.
It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pullx86 core platform updates from Peter Anvin:
"This is the x86/platform branch with the objectionable IOSF patches
removed.
What is left is proper memory handling for Intel GPUs, and a change to
the Calgary IOMMU code which will be required to make kexec work
sanely on those platforms after some upcoming kexec changes"
* 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, calgary: Use 8M TCE table size by default
x86/gpu: Print the Intel graphics stolen memory range
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
x86/gpu: Add vfunc for Intel graphics stolen memory base address
Backmerge drm-next after the big s/crtc->fb/crtc->primary->fb/
cocinelle patch to avoid endless amounts of conflict hilarity in my
-next queue for 3.16.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If you are using the common dp over i2c functionality, it is
asumed that the aux transfer function does not modify the any
of the msg structure other than the reply field. Doing so
breaks the logic in the common code.
v2: update struct drm_dp_aux comments about assumptions
v3 (chk): rebased on upstream changes
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Pull request of 2014-04-04
Currently only a single patch fixing up mixed use of the ttm_bo_reserve and
ww_mutex APIs
* tag 'ttm-next-2014-04-04' of git://people.freedesktop.org/~thomash/linux:
drm/ttm: Hide the implementation details of reservation
This patch adds flags field to mipi_dsi_msg structure and two flags:
- MIPI_DSI_MSG_REQ_ACK - request ACK from peripheral for given message,
- MIPI_DSI_MSG_USE_LPM - use Low Power Mode to transmit message.
The first flag is usually helpful during DSI diagnostic, the second
flag is required by some peripherals during configuration phase.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The following error and warnings will be seen when compiling a C file
which includes <drm/drm_gem_cma_helper.h> but without <drm/drmP.h>
being included before.
include/drm/drm_gem_cma_helper.h:5:24: error: field ‘base’ has incomplete type
include/drm/drm_gem_cma_helper.h: In function ‘to_drm_gem_cma_obj’:
include/drm/drm_gem_cma_helper.h:16:9: warning: initialization from incompatible pointer type [enabled by default]
include/drm/drm_gem_cma_helper.h: At top level:
include/drm/drm_gem_cma_helper.h:24:34: warning: ‘struct drm_mode_create_dumb’ declared inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:24:34: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/drm/drm_gem_cma_helper.h:24:34: warning: ‘struct drm_device’ declared inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:24:34: warning: ‘struct drm_file’ declared inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:28:10: warning: ‘struct drm_device’ declared inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:28:10: warning: ‘struct drm_file’ declared inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:35:3: warning: ‘struct drm_device’ declared inside parameter list [enabled by default]
include/drm/drm_gem_cma_helper.h:46:14: warning: ‘struct drm_device’ declared inside parameter list [enabled by default]
Fix them by including <drm/drmP.h> in drm_gem_cma_helper.h.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion of the GTT to only those buffers that require CPU
access through the GTT.
For other drivers, allocating small bos from one end and large ones
from the other helps improve the quality of fragmentation.
Based on drm_mm work by Chris Wilson.
v3: Changed to use a TTM placement flag
v2: Updated kerneldoc
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Christian König <deathsimple@vodafone.de>
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: David Airlie <airlied@redhat.com>
- Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less
flicker for fastbooting.
- More flexible cloning for hdmi (Ville).
- Some PPGTT fixes from Ben.
- Ring init fixes from Naresh Kumar.
- set_cache_level regression fixes for the vma conversion from Ville&Chris.
- Conversion to the new dp aux helpers (Jani).
- Unification of runtime pm with pc8 support from Paulo, prep work for runtime
pm on other platforms than HSW.
- Larger cursor sizes (Sagar Kamble).
- Piles of improvements and fixes all over, as usual.
* tag 'drm-intel-next-2014-03-21' of git://anongit.freedesktop.org/drm-intel: (75 commits)
drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64
drm/i915/sdvo: fix questionable return value check
drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
drm/i915: Print how many objects are shared in per-process stats
drm/i915: Per-process stats work better when evaluated per-process
drm/i915: remove rps local variables
drm/i915: Remove extraneous MMIO for RPS
drm/i915: Rename and comment all the RPS *stuff*
drm/i915: Store the HW min frequency as min_freq
drm/i915: Fix coding style for RPS
drm/i915: Reorganize the overclock code
drm/i915: init pm.suspended earlier
drm/i915: update the PC8 and runtime PM documentation
drm/i915: rename __hsw_do_{en, dis}able_pc8
drm/i915: kill struct i915_package_c8
drm/i915: move pc8.irqs_disabled to pm.irqs_disabled
drm/i915: remove dev_priv->pc8.enabled
drm/i915: don't get/put PC8 when getting/putting power wells
drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
Userspace clients which wish to receive all DRM planes (primary and
cursor planes in addition to the traditional overlay planes) may set the
DRM_CLIENT_CAP_UNIVERSAL_PLANES capability.
v2: Hide behind drm.universal_planes module option [suggested by
Daniel Vetter]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Add a new drm_crtc_init_with_planes() to allow drivers to provide
specific primary and cursor planes at CRTC initialization. The existing
drm_crtc_init() interface remains to avoid driver churn in existing
drivers; it will initialize the CRTC with a plane helper-created primary
plane and no cursor plane.
v2:
- Move drm_crtc_init() to plane helper file so that nothing in the DRM
core depends on helpers. [suggested by Daniel Vetter]
- Keep cursor parameter to drm_crtc_init_with_planes() a void* until
we actually add cursor support. [suggested by Daniel Vetter]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Add a plane type property to allow userspace to distinguish plane types.
v2: Driver-specific churn eliminated now that drm_plane_init() and
drm_universal_plane_init() were separated out in a previous patch.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Add a new plane initialization interface for universal plane support
that allows a specific plane type (primary, cursor, or overlay) to
be specified.
drm_plane_init() remains as a compatibility API to reduce churn in
existing drivers. The 'bool priv' parameter has been changed to
'bool is_primary' under the assumption that all existing uses of
private planes were representing primary planes.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
When we expose non-overlay planes to userspace, they will become
accessible via standard userspace plane API's. We should be able to
handle the standard plane operations against primary planes in a generic
way via the modeset handler.
Drivers that can program primary planes more efficiently, that want to
use their own primary plane structure to track additional information,
or that don't have the limitations assumed by the helpers are free to
provide their own implementation of some or all of these handlers.
v3: Tweak kerneldoc formatting slightly to avoid ugliness
v2:
- Move plane helpers to a new file (drm_plane_helper.c)
- Tighten checks on update handler (check for scaling, CRTC coverage,
subpixel positioning)
- Pass proper panning parameters to modeset interface
- Disallow disabling primary plane (and thus CRTC) if other planes are
still active on the CRTC.
- Use a minimal format list that should work on all hardware/drivers.
Drivers may call this function with a more accurate plane list to
enable additional formats they can support.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
This function will be used by the universal plane helpers and may also
be useful for individual drivers.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
The DRM core currently only tracks "overlay"-style planes. Start
refactoring the plane handling to allow other plane types (primary and
cursor) to also be placed on the DRM plane list.
v2: Add drm_for_each_legacy_plane() iterator to smooth transition
of drivers with plane loops.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Currently drm_cflush_virt_rage() takes a char* so the caller probably
has to do pointless casting to avoid compiler warnings. Make the
argument void* instead to avoid such issues.
v2: Use void* arithmetic (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A function to be used to check whether a caller has put a ref object
(opened) a struct ttm_base_object
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The master management was previously protected by the drm_device::struct_mutex.
In order to avoid locking order violations in a reworked dropped master
security check in the vmwgfx driver, break it out into a separate master_mutex.
Locking order is master_mutex -> struct_mutex.
Also remove drm_master::blocked since it's not used.
v2: Add an inline comment about what drm_device::master_mutex is protecting.
v3: Remove unneeded struct_mutex locks. Fix error returns in
drm_setmaster_ioctl().
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Add a drm_is_legacy() helper, constify argument to drm_is_render_client(),
and use / change helpers where appropriate.
v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context.
v3: s/legacy_client/primary_client/
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Like for render-nodes, there is no point in maintaining the master concept
for control nodes, so set the struct drm_file::master pointer to NULL.
At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always
allowed when called through the control node. Previously the caller also
needed to be master.
v2: Adapt to refactoring of ioctl permission check.
v3: Formatting of logical expression. Use drm_is_control_client() instead of
drm_is_control().
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
This is always DRM_NAME, so we can just make it part of the format
string instead of asking prink to do it for us.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the logging code, we are currently checking is we need to output in
drm_ut_debug_printk(). This is too late. The problem is that when we write
something like:
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id,
drm_get_connector_name(connector),
connector->encoder->base.id,
drm_get_encoder_name(connector->encoder));
We start by evaluating the arguments (so call drm_get_connector_name() and
drm_get_connector_name()) before ending up in drm_ut_debug_printk() which will
then does nothing.
This means we execute a lot of instructions (drm_get_connector_name(), in turn,
calls snprintf() for example) to happily discard them in the normal case,
drm.debug=0.
So, let's put the test on drm_debug earlier, in the macros themselves.
Sprinkle an unlikely() as well for good measure.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This macro was trying to use the non existing DRM_UT_MODE debug category
and looks like it should be covered by DRM_LOG_KMS().
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
That comment wasn't super-readable, so I tried to improve it:
- Put the comment before the values it's documenting
- Add a mention to PRIME
- Reword things a bit to be a lighter read
- Add a note about the option to set the debug value at run-time
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Summary of what's included:
- SGX MMU support
- SGX IRQ handling (Page faults and blitter fences)
- Minor Cedarview and Poulsbo unification
- Work queue for ASLE interrupt work
- Various cleanups, style fixes and removal of dead code
* 'gma500-next' of git://github.com/patjak/drm-gma500:
drm/gma500: remove stub .open/postclose
drm/gma500: Code cleanup - inline documentation
drm/gma500: Code cleanup - style fixes
drm/gma500: Code cleanup - removal of centralized exiting of function
drm/gma500/cdv: Cedarview display cleanups
drm/gma500: Unify encoder mode fixup
drm/gma500: Unify _get_core_freq for cdv and psb
drm/gma500: Move asle interrupt work into a work task
drm/gma500: Remove dead code
drm/gma500: Add backing type and base align to psb_gem_create()
drm/gma500: Remove unused ioctls
drm/gma500: Always trap MMU page faults
drm/gma500: Hook up the MMU
drm/gma500: Add first piece of blitter code
drm/gma500: Give MMU code it's own header file
drm/gma500: Add support for SGX interrupts
drm/gma500: Make SGX MMU driver actually do something
Let the drivers specify the name of the I2C-over-AUX adapter to maintain
backwards compatibility in the sysfs when converting to the new
I2C-over-AUX helper infrastructure.
The i915 driver currently uses DPDDC-A to DPDDC-D as names for the DP
i2c adapters. These names show up in the i2c sysfs name attribute. We'd
like to be able to maintain that when switching over to the new helpers.
Due to i2c device and connector cleanup ordering issues we also recently
made the drm device (instead of connector) the parent of the i2c
adapters:
commit 80f65de3c9
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Feb 11 17:12:49 2014 +0200
drm/i915: dp: fix order of dp aux i2c device cleanup
With the name picked up from the adapter parent using dev_name(), it
would be the same for all i2c adapters with the current I2C-over-AUX
helpers.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the 3rd respin of the drm-anon patches. They allow module unloading, use
the pin_fs_* helpers recommended by Al and are rebased on top of drm-next. Note
that there are minor conflicts with the "drm-minor" branch.
* 'drm-next' of git://people.freedesktop.org/~dvdhrm/linux:
drm: init TTM dev_mapping in ttm_bo_device_init()
drm: use anon-inode instead of relying on cdevs
drm: add pseudo filesystem for shared inodes
Here's my drm documentation update and driver api polish pull request.
Alex reviewed the entire pile, I've applied a little bit of spelling
polish in a few places since then and otherwise the Usual Suspects (David,
Rob, ...) don't seem up to have another look at it (I've poked them on
irc). So I think it's as good as it gets ;-)
Note that I've dropped the final imx breaker patch since that's blocked on
imx getting sane. Once that's landed I'll ping you to pick up that
straggler.
* 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm: (34 commits)
drm/imx: remove drm_mode_connector_detach_encoder harder
drm: kerneldoc polish for drm_crtc.c
drm: kerneldoc polish for drm_crtc_helper.c
drm: drop error code for drm_helper_resume_force_mode
drm/crtc-helper: remove LOCKING from kerneldoc
drm: remove return value from drm_helper_mode_fill_fb_struct
drm/doc: Fix misplaced </para>
drm: remove drm_display_mode->private_size
drm: polish function kerneldoc for drm_modes.[hc]
drm/modes: drop maxPitch from drm_mode_validate_size
drm/modes: drop return value from drm_display_mode_from_videomode
drm/modes: remove drm_mode_height/width
drm: extract drm_modes.h for drm_crtc.h functions
drm: move drm_mode related functions into drm_modes.c
drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
drm/doc: Integrate drm_modes.c kerneldoc
drm/kms: rip out drm_mode_connector_detach_encoder
drm/doc: Add function reference documentation for drm_mm.c
drm/doc: Overview documentation for drm_mm.c
drm/mm: Remove MM_UNUSED_TARGET
...
All of these ioctls are unused and most of them just duplicate what drm
already provides.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Whenever we access minor->device, we are in a minor->kdev->...->fops
callback so the minor->kdev pointer *must* be valid. Thus, simply use
minor->kdev->devt instead of minor->device and remove the redundant field.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of accessing drm_minors_idr directly, this adds a small helper to
hide the internals. This will help us later to remove the drm_global_mutex
requirement for minor-lookup.
Furthermore, this also makes sure that minor->dev is always valid and
takes a reference-count to the device as long as the minor is used in an
open-file. This way, "struct file*"->private_data->dev is guaranteed to be
valid (which it has to, as we cannot reset it).
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Lets not trick ourselves into thinking "drm_device" objects are not
ref-counted. That's just utterly stupid. We manage "drm_minor" objects on
each drm-device and each minor can have an unlimited number of open
handles. Each of these handles has the drm_minor (and thus the drm_device)
as private-data in the file-handle. Therefore, we may not destroy
"drm_device" until all these handles are closed.
It is *not* possible to reset all these pointers atomically and restrict
access to them, and this is *not* how this is done! Instead, we use
ref-counts to make sure the object is valid and not freed.
Note that we currently use "dev->open_count" for that, which is *exactly*
the same as a reference-count, just open coded. So this patch doesn't
change any semantics on DRM devices (well, this patch just introduces the
ref-count, anyway. Follow-up patches will replace open_count by it).
Also note that generic VFS revoke support could allow us to drop this
ref-count again. We could then just synchronously disable any fops->xy()
calls. However, this is not the case, yet, and no such patches are
in sight (and I seriously question the idea of dropping the ref-cnt
again).
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Use enum for DRM_MINOR_* constants to avoid hard-coding the IDs.
Furthermore, add a DRM_MINOR_CNT so we can perform range-checks in
follow-ups.
This changes the IDs of the minor-types by -1, but they're not used as
indices so this is fine.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These members are all managed by DRM-core, lets group them together so
they're not split across the whole device.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With dev->anon_inode we have a global address_space ready for operation
right from the beginning. Therefore, there is no need to do a delayed
setup with TTM. Instead, set dev_mapping during initialization in
ttm_bo_device_init() and remove any "if (dev_mapping)" conditions.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
DRM drivers share a common address_space across all character-devices of a
single DRM device. This allows simple buffer eviction and mapping-control.
However, DRM core currently waits for the first ->open() on any char-dev
to mark the underlying inode as backing inode of the device. This delayed
initialization causes ugly conditions all over the place:
if (dev->dev_mapping)
do_sth();
To avoid delayed initialization and to stop reusing the inode of the
char-dev, we allocate an anonymous inode for each DRM device and reset
filp->f_mapping to it on ->open().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
No driver cares, and it should generally work. Add a big comment
when drivers can't use this for recompense.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rightfully no driver ever checked this - it can't fail.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It' unused and there's also not really any way to make it work with
the current code. So better rip it out.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Tune down yelling RETURNS.
- OCD align all the parameters the same.
- Add missing kerneldoc, which also means that we need to include the
kerneldoc from the drm_modes.h header now.
- Add missing Returns: sections.
- General polish and clarification - especially the kerneldoc for the
mode creation helpers seems to have been some good specimen of
copypasta gone wrong.
All actual code changes have all been extracted into prep patches
since there was simply too much to polish.
v2: More polish for the command line modeline functions.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Totally unused and actually redundant with maxX for display mode
validation. The fb helper otoh needs to check pitch limits,
but that is delegated into drivers instead.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It never fails and no one ever checked anyway.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's a neat FIXME asking whether this is really need. I'd
say really no.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I want to also include kerneldoc from the header (for static inline
functions and structs), but fishing the right pieces out of a giant
header is a real pain. So split things out.
Note that it's not a really clean header with sane include orders, but
given's drm historical knack for giant headers detangling this is a
major task.
v2: Also extract struct drm_cmdline_mode.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's only used by imx, and that one gets it wrong - there's no need
to deteach the encoder before removing it.
And really, neither current drm modesetting code nor all the userspace
we have can handle dynamic changes in the set of possible encoders for
a given connector. So let's just remove this before someone starts
doing something really nasty with it.
As a plus, one less kerneldoc comment to write.
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While at it do a tiny bit of interface cleanup and convert boolean
return values to bool. With this patch all exported functions and inline
helpers which are part of the drm_mm public interface are documented.
Also drop superflous extern function modifiers since most of drm_mm.h
doesn't use them - more consistent that way.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Fix the execbuf rebind performance regression due to topic/ppgtt (Chris).
- Fix up the connector cleanup ordering for sdvod i2c and dp aux devices (Imre).
- Try to preserve the firmware modeset config on driver load. And a bit of prep
work for smooth takeover of the fb contents (Jesse).
- Prep cleanup for larger gtt address spaces on bdw (Ben).
- Improve our vblank_wait code to make hsw modesets faster (Paulo).
- Display debugfs file (Jesse).
- DRRS prep work from Vandana Kannan.
- pipestat interrupt handler to fix a few races around vblank/pageflip handling
on byt (Imre).
- Improve display fuse handling for display-less SKUs (Damien).
- Drop locks while stalling for the gpu when serving pagefaults to improve
interactivity (Chris).
- And as usual piles of other improvements and small fixes all over.
* tag 'drm-intel-next-2014-02-14' of ssh://git.freedesktop.org/git/drm-intel: (65 commits)
drm/i915: fix NULL deref in the load detect code
drm/i915: Only bind each object rather than for every execbuffer
drm/i915: Directly return the vma from bind_to_vm
drm/i915: Simplify i915_gem_object_ggtt_unpin
drm/i915: Allow blocking in the PDE alloc when running low on gtt space
drm/i915: Don't allocate context pages as mappable
drm/i915: Handle set_cache_level errors in the status page setup
drm/i915: Don't pin the status page as mappable
drm/i915: Don't set PIN_MAPPABLE for legacy ringbuffers
drm/i915: Handle set_cache_level errors in the pipe control scratch setup
drm/i915: split PIN_GLOBAL out from PIN_MAPPABLE
drm/i915: Consolidate binding parameters into flags
drm/i915: sdvo: add i2c sysfs symlink to the connector's directory
drm/i915: sdvo: fix error path in sdvo_connector_init
drm/i915: dp: fix order of dp aux i2c device cleanup
drm/i915: add unregister callback to connector
drm/i915: don't reference null pointer at i915_sink_crc
drm/i915/lvds: Remove dead code from failing case
drm/i915: don't preserve inherited configs with nothing on v2
drm/i915/bdw: Split up PPGTT cleanup
...
- Yet more steps towards atomic modeset from Ville.
- DP panel power sequencing improvements from Paulo.
- irq code cleanups from Ville.
- 5.4 GHz dp lane clock support for bdw/hsw from Todd.
- Clock readout support for hsw/bdw (aka fastboot) from Jesse.
- Make pipe underruns report at ERROR level (Ville). This is to check our
improved watermarks code.
- Full ppgtt support from Ben for gen7.
- More fbc fixes and improvements from Ville all over the place, unfortunately
not yet enabled by default on more platforms.
- w/a cleanups from Ville.
- HiZ stall optimization settings (Chia-I Wu).
- Display register mmio offset refactor patch from Antti.
- RPS improvements for corner-cases from Jeff McGee.
* tag 'drm-intel-next-2014-02-07' of ssh://git.freedesktop.org/git/drm-intel: (166 commits)
drm/i915: Update rps interrupt limits
drm/i915: Restore rps/rc6 on reset
drm/i915: Prevent recursion by retiring requests when the ring is full
drm/i915: Generate a hang error code
drm/i915: unify FLIP_DONE macro names
drm/i915: vlv: s/spin_lock_irqsave/spin_lock/ in irq handler
drm/i915: factor out valleyview_pipestat_irq_handler
drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt
drm/i915: Reorganize display pipe register accesses
drm/i915: Treat using a purged buffer as a source of EFAULT
drm/i915: Convert EFAULT into a silent SIGBUS
drm/i915: release mutex in i915_gem_init()'s error path
drm/i915: check for oom when allocating private_default_ctx
drm/i915/vlv: WA to fix Voltage not getting dropped to Vmin when Gfx is power gated.
drm/i915: Get rid of acthd based guilty batch search
drm/i915: Use hangcheck score to find guilty context
drm/i915: Drop WaDisablePSDDualDispatchEnable:ivb for IVB GT2
drm/i915: Fix IVB GT2 WaDisableDopClockGating and WaDisablePSDDualDispatchEnable
drm/i915: Don't access snooped pages through the GTT (even for error capture)
drm/i915: Only print information for filing bug reports once
...
Conflicts:
drivers/gpu/drm/i915/intel_dp.c
This series of patches implements a small framework that abstracts away
some of the functionality that the DisplayPort AUX channel provides. It
comes with a set of generic helpers that use the driver implementations
to reduce code duplication.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTDhU1AAoJEN0jrNd/PrOh5OoP/1tmkV0cgcMp//M2i0hWptvU
ifO1SdwsnSMKajM8ytJuW+1e7UBStQg3QzpEwaTcvOuKHqE2WtDksh7yYUaj5Tv/
SB7n0cS6rxbdIQ9SCFDVHT+A9N/YUeCj8l9BxgabaNnguA4I8Dydp9cfm3fCq835
cWGf02TXw2H6V5mbNjaBggWSp4iqG/6+QxAn07o+u137kbTlRMO6pBjEflaVBCDP
rYIJ5q2UgN//wI4e+ESYEyU8Cze5Zaevk+/L4Qg9FNbzGSjeEmfVNLuPdLkZOYV6
6RSwOgSlZWGjMRsIWHta2u0VDQB/Wr0PjDqx4mWcYyrFJfms5yrc6R4JmQwGRFxi
ucSkL9Ak1LKK2NLhrfnzL1ogHkU/5EEPV1dDxK7P0Milzg2YUDwhv1zn+ssmtUuQ
zZrPYJNsG/rdNfA7BeGBpqjLnL93YWQXNbeIx2m/yQIT4YA63jkKgqz5p9NOvkjp
++JdGX0By1iOMG9SOOFVIOLorohVnYDqrp+klsIuXVJhw3/bvPLcXejRNPuODRoQ
aw/8nLwHubDvG2lJVgVFmrlofxcfeIbYsf0AE2wiATRjjZ37+YfCdFOpu2E0cMN1
mLquAHkpTupYr0SfKW1ofhJuxDcvkir7ud9zpqKRxfUh0xFmnCaaDh48FocWpdSG
MsPdMJ0g01uzzxlkFqKk
=SovB
-----END PGP SIGNATURE-----
Merge tag 'drm/dp-aux-for-3.15-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm: DisplayPort AUX framework for v3.15-rc1
This series of patches implements a small framework that abstracts away
some of the functionality that the DisplayPort AUX channel provides. It
comes with a set of generic helpers that use the driver implementations
to reduce code duplication.
* tag 'drm/dp-aux-for-3.15-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/dp: Allow registering AUX channels as I2C busses
drm/dp: Add DisplayPort link helpers
drm/dp: Add drm_dp_dpcd_read_link_status()
drm/dp: Add AUX channel infrastructure
Implements an I2C-over-AUX I2C adapter on top of the generic drm_dp_aux
infrastructure. It extracts the retry logic from existing drivers, which
should help in porting those drivers to this new helper.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v5:
- move comments partially to to header file
- keep MOT set between I2C messages
- return -EPROTO on short reads
Changes in v4:
- fix typo "bitrate" -> "bit rate"
Changes in v3:
- add back DRM_DEBUG_KMS and DRM_ERROR messages
- embed i2c_adapter within struct drm_dp_aux
- fix typo in comment
Add a helper to probe a DP link (read out the supported DPCD revision,
maximum rate, link count and capabilities) as well as power up the DP
link and configure it accordingly.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v5:
- export helpers
Changes in v4:
- fix a couple of typos in comments as pointed out by Alex Deucher
Changes in v3:
- split into drm_dp_link_power_up() and drm_dp_link_configure()
- do not change sink state for DPCD versions earlier than 1.1
- sleep for 1-2 ms after setting local sink to D0 state
- read and write consecutive registers where possible
- read DPCD revision when link is probed
- remove duplicate kerneldoc
The function reads the link status (6 bytes starting at offset 0x202)
from the DPCD so that it can be conveniently passed to other DPCD
helpers.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This is a superset of the current i2c_dp_aux bus functionality and can
be used to transfer native AUX in addition to I2C-over-AUX messages.
Helpers are provided to read and write the DPCD, either blockwise or
byte-wise. Many of the existing helpers for DisplayPort take a copy of a
portion of the DPCD and operate on that, without a way to write data
back to the DPCD (e.g. for configuration of the link).
Subsequent patches will build upon this infrastructure to provide common
functionality in a generic way.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v5:
- move comments partially to struct drm_dp_aux_msg in header file
- return -EPROTO on short reads in DPCD helpers
Changes in v4:
- fix a typo in a comment
Changes in v3:
- reorder drm_dp_dpcd_writeb() arguments to be more intuitive
- return number of bytes transferred in drm_dp_dpcd_write()
- factor out drm_dp_dpcd_access()
- describe error codes
This patch fix spelling typo in Documentation/DocBook.
It is because .html and .xml files are generated by make htmldocs,
I have to fix a typo within the source files.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull request of 2014-02-18
One compile fix and one memory leak.
* tag 'ttm-fixes-3.14-2014-02-18' of git://people.freedesktop.org/~thomash/linux:
drm/ttm: Fix memory leak in ttm_agp_backend.c
drm/ttm: declare 'struct device' in ttm_page_alloc.h
Some hardware may not support standard 64x64 cursors. Add
a drm cap to query the cursor size from the kernel. Some examples
include radeon CIK parts (128x128 cursors) and armada (32x64 or 64x32).
This allows things like device specific ddxes to remove asics specific
logic and also allows xf86-video-modesetting to work properly with hw
cursors on this hardware. Default to 64 if the driver doesn't specify
a size.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Declare 'struct device' explicitly in ttm_page_alloc.h as this file
does not include any file declaring it. This removes the following
warning:
warning: 'struct device' declared inside parameter list
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
This allows drivers to use them in custom initial_config functions.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like we have for connector type etc.
v2: drop static array (Chris)
v3: add kdoc (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just minor stuff really, on vlv dp fix and two patches to tune down some
opregion sanity check. Plus MAINTAINERS update for the new git repo, which
is the only reason I've really bothered with this pull request.
* tag 'drm-intel-fixes-2014-02-06' of ssh://git.freedesktop.org/git/drm-intel:
drm/i915: demote opregion excessive timeout WARN_ONCE to DRM_INFO_ONCE
drm: add DRM_INFO_ONCE() to print a one-time DRM_INFO() message
MAINTAINERS: Update drm/i915 git repo
drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen
memory would start there would place it on top of some ACPI
memory regions. So not a good idea as already stated.
The 9MB region after the ACPI regions at 0x1f700000 however
looks promising given that the macine reports the stolen memory
size to be 8MB. Looking at the PGTBL_CTL register, the GTT
entries are at offset 0x1fee00000, and given that the GTT
entries occupy 128KB, it looks like the stolen memory could
start at 0x1f700000 and the GTT entries would occupy the last
128KB of the stolen memory.
After some more digging through chipset documentation, I've
determined the BIOS first allocates space for something called
TSEG (something to do with SMM) from the top of memory, and then
it allocates the graphics stolen memory below that. Accordind to
the chipset documentation TSEG has a fixed size of 1MB on 855.
So that explains the top 1MB in the e820 region. And it also
confirms that the GTT entries are in fact at the end of the the
stolen memory region.
Derive the stolen memory base address on gen2 the same as the
BIOS does (TOM-TSEG_SIZE-stolen_size). There are a few
differences between the registers on various gen2 chipsets, so a
few different codepaths are required.
865G is again bit more special since it seems to support enough
memory to hit 4GB address space issues. This means the PCI
allocations will also affect the location of the stolen memory.
Fortunately there appears to be the TOUD register which may give
us the correct answer directly. But the chipset docs are a bit
unclear, so I'm not 100% sure that the graphics stolen memory is
always the last thing the BIOS steals. Someone would need to
verify it on a real system.
I tested this on the my 830 and 855 machines, and so far
everything looks peachy.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Just like DRM_INFO(), but only do it once.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge drm-next - I need to backmerge drm-intel-fixes patches
touching the error capture code to be able to merge Ben's cleanup
patches.
Conflicts:
drivers/gpu/drm/i915/i915_gpu_error.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJS4TK6AAoJEN0jrNd/PrOhwXoP/i09xa9CKOnpy8Ewdmgi5gBt
vnjzqjwmHzZRpNeWw2xvcqzv5kKgXkpPdMhNUjErlJTUC1S6uCf/Uj+ExppYYysW
7uxNjPQQc6jgX+0342MabKITeZyTk9iEWPqTDtHDP5O2vXi4XSaQTMm9HpWGe1qZ
1CTb0yJc1epXGJPutlqhJSZgKwzrs6Pm2Q/nsTdxpGPAoTQj9J0NebDaZwJmmFGi
qNyfI4DVBp1sj8AgtUkQQn9x5oLDpdvHKLPHsAWgHnNTKqRxY8C0EL+S2TYGa812
sx8jvZgjvBoPuwaOr4hcOx91OFdfOoKVap9D/corU+UjstF9lTd+PvAHzZMO5qte
yQhWmYFn1gGr/I9b9K/mAB98s83W7lMmSs/7HtiawvLtogZ/t8xvSp94R7X8SGd1
wYcw3NqzgDxrcpJjDOsLIw1Pa4PxXoChtV0SfiaEoVlGn5WSONS/8cKeNwbO6e9D
gKkd/zvCMsYqHt7p8zDizcQKi4W+8zYiZySOfLohZzhf0qaoQnnD5yirfiIpljqA
Ql40F4XP3OF3CliikcSwFhvrTUCLb08Ol0MV6FX1H1iMae0dgiFqtz7AihFTbKHZ
PQeskMgEemxhIqKEsH0JcpV3+YxLRlWy/3I+OO7QczsL0xKD30FQ9Xhsu9EFx8gu
jXVvMDldeefaVBuTdqCb
=NfNj
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.14-rc1 (update)
These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).
* tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Obtain head number from DT
drm/panel: update EDID BLOB in panel_simple_get_modes()
gpu: host1x: Remove unnecessary include
drm/tegra: Use proper data type
drm/tegra: Clarify how panel modes override others
drm/tegra: Fix possible CRTC mask for RGB outputs
drm/i915: Use drm_encoder_crtc_ok()
drm: Move drm_encoder_crtc_ok() to core
drm: provide a helper for the encoder possible_crtcs mask
drm/tegra: Don't check resource with devm_ioremap_resource()
drm/panel: Add support for Chunghwa CLAA101WA01A panel
drm/panel: Add support for Samsung LTN101NT05 panel
This address will be used to verify panel CRC for test and
validation purposes.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Fix whitespace fail.]
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Here's the vblank timestamp pull request you wanted.
I addressed the few bugs that Mario pointed out and added
the r-bs.
As it has been a while since I made the changes, I gave it a
quick spin on a few different i915 machines. Fortunately
everything still seems to be fine.
* 'drm-vbl-timestamp' of git://gitorious.org/vsyrjala/linux:
drm/i915: Add a kludge for DSL incrementing too late and ISR not working
drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
drm: Pass 'flags' from the caller to .get_scanout_position()
drm: Fix vblank timestamping constants for interlaced modes
drm/i915: Fix scanoutpos calculations for interlaced modes
drm: Change {pixel,line,frame}dur_ns from s64 to int
drm: Use crtc_clock in drm_calc_timestamping_constants()
drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings()
drm: Simplify the math in drm_calc_timestamping_constants()
drm: Improve drm_calc_timestamping_constants() documentation
drm/i915: Call drm_calc_timestamping_constants() earlier
drm/i915: Kill hwmode save/restore
drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos()
drm: Pass the display mode to drm_calc_timestamping_constants()
Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
CEA-861E Table 4. This is useful for filling up the detail in AVI
infoframe.
v2: Ville's review comments incorporated
Added picture aspect ratio as part of edid_cea_modes instead of DRM_MODE
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To make it clear what exactly mode_valid() should return.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().
v2: Fix radeon_drv.c compile warning (Mario)
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Using s64 for the timestamping constants is wasteful. Signed 32bit
integers get us a range of over +-2 seconds. Presuming that no-one
wants to a vrefresh rate less than 0.5, we can switch to using int
for the timestamping constants. We save a few bytes in drm_crtc and
avoid a bunch of 64bit math.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Rather than using crtc->hwmode, just pass the relevant mode to
drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode
usage from core drm.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We don't really use hwmode anymore in i915, so eliminating its use
from the core code seems prudent. Just pass the appropriate mode
to drm_calc_timestamping_constants().
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm-intel-next-2014-01-10:
- final bits for runtime D3 on Haswell from Paul (now enabled fully)
- parse the backlight modulation freq information in the VBT from Jani
(but not yet used)
- more watermark improvements from Ville for ilk-ivb and bdw
- bugfixes for fastboot from Jesse
- watermark fix for i830M (but not yet everything)
- vlv vga hotplug w/a (Imre)
- piles of other small improvements, cleanups and fixes all over
Note that the pull request includes a backmerge of the last drm-fixes
pulled into Linus' tree - things where getting a bit too messy. So the
shortlog also contains a bunch of patches from Linus tree. Please yell if
you want me to frob it for you a bit.
* 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel: (609 commits)
drm/i915/bdw: make sure south port interrupts are enabled properly v2
drm/i915: Include more information in disabled hotplug interrupt warning
drm/i915: Only complain about a rogue hotplug IRQ after disabling
drm/i915: Only WARN about a stuck hotplug irq ONCE
drm/i915: s/hotplugt_status_gen4/hotplug_status_g4x/
Using the new drm_crtc_mask() function, drm_encoder_crtc_ok() can now be
written in a significantly shorter way, so it can be moved to a header
file and be made static inline.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The encoder possible_crtcs mask identifies which CRTCs can be bound to
a particular encoder. Each bit from bit 0 defines an index in the list
of CRTCs held in the DRM mode_config crtc_list. Rather than having
drivers trying to track the position of their CRTCs in the list, expose
the code which already exists for calculating the appropriate mask bit
for a CRTC.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[treding@nvidia.com: add drm_crtc_index(), move to core]
Signed-off-by: Thierry Reding <treding@nvidia.com>
This was hidden in a generic void * dev->mm_private. But only ever
used for gem. But thanks to this fake generic pretension no one
noticed that Rob's drm drivers are now all broken.
So just give the offset manager a type pointer and fix up msm, omapdrm
and tilcdc.
v2: Fixup compile fail.
v3: Fixup rebase fail that David spotted.
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Anyway, nothing big here, Three more code cleanup patches from Rashika
Kheria, and one TTM/vmwgfx patch from me that tightens security around TTM
objects enough for them to opened using prime objects from render nodes:
Previously any client could access a shared buffer using the "name", also
without actually opening it. Now a reference is required, and for render nodes
such a reference is intended to only be obtainable using a prime fd.
vmwgfx-next 2014-01-13 pull request
* tag 'vmwgfx-next-2014-01-13' of git://people.freedesktop.org/~thomash/linux:
drivers: gpu: Mark functions as static in vmwgfx_fence.c
drivers: gpu: Mark functions as static in vmwgfx_buffer.c
drivers: gpu: Mark functions as static in vmwgfx_kms.c
drm/ttm: ttm object security fixes for render nodes
When a client looks up a ttm object, don't look it up through the device hash
table, but rather from the file hash table. That makes sure that the client
has indeed put a reference on the object, or in gem terms, has opened
the object; either using prime or using the global "name".
To avoid a performance loss, make sure the file hash table entries can be
looked up from under an RCU lock, and as a consequence, replace the rwlock
with a spinlock, since we never need to take it in read mode only anymore.
Finally add a ttm object lookup function for the device hash table, that is
intended to be used when we put a ref object on a base object or, in gem terms,
when we open the object.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Needed for some vm operations; most notably unmap_mapping_range() with
even_cows = 0.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This series of changes brings DRM panel support as well as initial code
to register DSI hosts and peripherals and bind them to DSI drivers. The
panel and DSI code are both used by the simple panel driver.
The Tegra-specific changes build on top of this work to add support for
various panels found on Tegra boards. New drivers enable the DSI host
found on Tegra114 and a special hardware block that calibrates the pads
used for DSI and CSI. The host1x and the display controller drivers gain
basic Tegra124 support. To round of the new features, the DRM driver now
sports a very simple PRIME implementation.
In addition there are various improvements such as the host1x API being
exported so that client drivers (like the Tegra DRM driver) can be built
as modules. HDMI now does better power management and legacy FBDEV can
now be disabled via Kconfig (though it's still enabled by default). A
few sparse warnings have been squashed and various parts of the code
have become more robust.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJStLL5AAoJEN0jrNd/PrOhtD0QAJwhRTuEh8xCJ7pu1eK3TMh2
BYCD5UOiqnPAcDjJlTsiX0NaNQQ15+9uIjSIbbk36tfZ5cWbiP5yURYyMZp1HjvP
woGqsdI4eHVXswXNPMMIeTRrQKNMoQV82uvFAnE3QsfFwdkB+9p5tSUxnqXSuJ5U
ZKv1AL4FC0FdAnvugEz1lBzxqthoLm0mQ9xwkoYN2hT9ak1bnZUljfGYp2G/0xqM
RqhKgboZapL4Aul8lLIqqTCgo9XS3xN8Zo8F3WwyuOYJTgGZ6EK25H2bMvPBx0NO
fBNeacVd2jaCrELL6ZdsodKuu+TbHM82Sc6mZTA3YxN/E4tFUTfT++LQF7w505mA
PGHiZylwfDUPhGRRA8tYEz+OVQvT1FMhKEswlhDki0RJF5OHReQdrmBl0HfiUfmn
cQC9/WzGIqIP68tuuxOf8tdKHbAP1sOf7WgjFrBVX86hktN2Aq2f4dYtB7tf1c5O
1wTY+NPho8avscCycWdcqAtrgz2/KHBo4KvO7f9dqiTFa+A6KXdqe1dZaFrsPBjL
N4SizpY9VW7zJnmW9dIhb7qopVNw4g9OzCfH9dmpqrCnHpNFfmXYqDuppcSz7X5h
fWpXtA6iAEVIa5CE44liZWv/5SU8Mowrb8YbBgC/EoMWphDfnzporvcHe94GLNiy
O1iUYmI3mv48JKs30bYD
=lQsh
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.14-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.14-rc1
This series of changes brings DRM panel support as well as initial code
to register DSI hosts and peripherals and bind them to DSI drivers. The
panel and DSI code are both used by the simple panel driver.
The Tegra-specific changes build on top of this work to add support for
various panels found on Tegra boards. New drivers enable the DSI host
found on Tegra114 and a special hardware block that calibrates the pads
used for DSI and CSI. The host1x and the display controller drivers gain
basic Tegra124 support. To round of the new features, the DRM driver now
sports a very simple PRIME implementation.
In addition there are various improvements such as the host1x API being
exported so that client drivers (like the Tegra DRM driver) can be built
as modules. HDMI now does better power management and legacy FBDEV can
now be disabled via Kconfig (though it's still enabled by default). A
few sparse warnings have been squashed and various parts of the code
have become more robust.
* tag 'drm/for-3.14-rc1' of git://anongit.freedesktop.org/tegra/linux: (121 commits)
drm/tegra: fix compile w/ CONFIG_DYNAMIC_DEBUG
drm/tegra: Add PRIME support
drm/tegra: Relocate some output-specific code
drm/tegra: Add Tegra124 DC support
drm/tegra: Fix small leak on error in tegra_fb_alloc()
drm/tegra: Make legacy fbdev support optional
drm/tegra: Sort reverse-dependencies alphabetically
drm/tegra: Fix return value check
drm/tegra: Add DSI support
drm/tegra: Disable outputs for power-saving
drm/tegra: Track HDMI enable state
drm/tegra: Fix HDMI audio frequency typo
drm/tegra: Do not export tegra_bo_ops
drm/tegra: Remove spurious blank line
drm/tegra: Increase compile test coverage
drm/tegra: Allow the driver to be built as a module
gpu: host1x: Add Tegra124 support
gpu: host1x: clk_round_rate() can return a zero upon error
gpu: host1x: Fix build warnings
gpu: host1x: Increase compile test coverage
...
- DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN to clarify
- Added DP_TEST_LINK_FAUX_PATTERN to support automated testing of Fast AUX
Signed-off-by: Todd Previte <tprevite@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is just used for a debugfs file, and we can easily reconstruct
this number by just walking the list twice. Which isn't really bad for
a debugfs file anyway.
So let's rip this out.
There's the other issue that the dev->vmalist itself is a bit useless,
since that can be reconstructed with all the memory mapping
information from proc. But remove that is a different topic entirely.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's racy, and it's only used in debugfs. There are simpler ways to
know whether something is going on (like looking at dmesg with full
debugging enabled). And they're all much more useful.
So let's just rip this out.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now dev->ioctl_count tries to prevent the device from disappearing if
it's still in use. And if we'd actually need this code it would be
hopelessly racy and broken.
But luckily the vfs already takes care of this. So we can just rip it
out.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Checking directly for the right capability is simpler. Also this rids
us of a few places that use DRM_CURRENTPID.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The real linux interfaces are soooo much easier on the eyes ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I've killed them a long time ago in drm/i915, let's get rid of this
remnant of shared drm core days for good.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't have any userspace interfaces that use HZ as a time unit, so
having our own DRM define is useless.
Remove this remnant from the shared drm core days.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The <linux/agp_backend.h> header provides dummy functions and
fallbacks, so no need for screaming macros.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Call drm_pci_agp_destroy directly, there's no point in the
indirection. Long term we want to shuffle this into each driver's
unload logic, but that needs cleared-up drm lifetime rules first.
v2: Add a dummy function for !CONFIG_PCI, spotted my David Herrmann.
v3: Fixup for the coding style police.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Wrapping a kfree is pointless.
v2: Add a comment to the kerneldoc for drm_agp_init to explain where
the kfree happens as requested by David. Note that for modeset drivers
agp cleanup is fairly complicated anyway: The drm_agp_clear is a noop
and drivers must call drm_agp_release on their own. Which they all
seem to do properly.
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The PCI bus helper is the only user of it. Call it directly before
device-registration to get rid of the callback.
Note that all drm_agp_*() calls are locked with the drm-global-mutex so we
need to explicitly lock it during initialization. It's not really clear
why it's needed, but lets be safe.
v2: Rebase on top of the agp_init interface change.
v3: Remove the rebase-fail where I've accidentally killed the ->irq_by_busid
callback a bit too early.
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Most place actually want to just check for dev->agp (most do, but a
few don't so this fixes a few potential NULL derefs). The only
exception is the agp init code which should check for the AGP driver
feature flag.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Thanks to the removal of REQUIRE_AGP we can use a void return value
and shed a bit of complexity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Only the two intel drivers need this and they can easily check for
working agp support in their driver ->load callbacks.
This is the only reason why agp initialization could fail, so allows
us to rip out a bit of error handling code in the next patch.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The current values seem to be defined in a format that's specific to the
i915, gma500 and radeon drivers. To make this more generally useful, use
the values as defined in the specification.
While at it, prefix the constants with DP_ for improved namespacing.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's really no need for the drm core to keep a list of all
devices of a given driver - the linux device model keeps perfect
track of this already for us.
The exception is old legacy ums drivers using pci shadow attaching.
So rename the lists to make the use case clearer and rip out everything
else.
v2: Rebase on top of David Herrmann's drm device register changes.
Also drop the bogus dev_set_drvdata for platform drivers that somehow
crept into the original version - drivers really should be in full
control of that field.
v3: Initialize driver->legacy_dev_list outside of the loop, spotted by
David Herrmann.
v4: Rebase on top of the newly created host1x drm_bus for tegra.
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This very much looks like a remnant of the old legady ums shadow
attach days. Now with the last users gone we can rip it out since
we won't ever support an ums drm driver again.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In case where debugfs support is disabled, define dummy functions to
avoid the need for #ifdefery in drivers.
Based on an earlier patch by Arnd Bergmann.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For error traces in situations that can run away, it is nice to have a
rate-limited version of DRM_ERROR() to avoid massive log flooding.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.
The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.
Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.
Signed-off-by: Thierry Reding <treding@nvidia.com>
MIPI DSI bus allows to model DSI hosts and DSI peripherals using the
Linux driver model. DSI hosts are registered by the DSI host drivers.
During registration DSI peripherals will be created from the children
of the DSI host's device tree node. Support for registration from
board-setup code will be added later when needed.
DSI hosts expose operations which can be used by DSI peripheral drivers
to access associated devices.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The set_need_resched() removal fix and yet another fix in
ttm_bo_move_memcpy().
* 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux:
drm/ttm: Remove set_need_resched from the ttm fault handler
drm/ttm: Don't move non-existing data
Addresses
"[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE".
In the first occurence it was used to try to be nice while releasing the
mmap_sem and retrying the fault to work around a locking inversion.
The second occurence was never used.
There has been some discussion whether we should change the locking order to
mmap_sem -> bo_reserve. This patch doesn't address that issue, and leaves
that locking order undefined. The solution that we release the mmap_sem if
tryreserve fails and wait for the buffer to become unreserved is something
we want in any case, and follows how the core vm system waits for pages
to be come unlocked while releasing the mmap_sem.
The code also outlines what needs to be changed if we want to establish the
locking order as mmap_sem -> bo::reserve.
One slight issue that remains with this code is that the fault handler might
be prone to starvation if another thread countinously reserves the buffer.
IMO that usage pattern is highly unlikely.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
If no reservation ticket is given to the execbuf reservation utilities,
try reservation with non-blocking semantics.
This is intended for eviction paths that use the execbuf reservation
utilities for convenience rather than for deadlock avoidance.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
So here's the Broadwell pull request. From a kernel driver pov there's
two areas with big changes in Broadwell:
- Completely new enumerated interrupt bits. On the plus side it now looks
fairly unform and sane.
- Completely new pagetable layout.
To ensure minimal impact on existing platforms we've refactored both the
irq and low-level gtt handling code a lot in anticipation of the bdw push.
So now bdw enabling in these areas just plugs in a bunch of vfuncs.
Otherwise it's all fairly harmless adjusting of switch cases and
if-ladders to shovel bdw into the right blocks. So minimized impact on
existing platforms. I've also merged the bdw-stage1 branch into our
-nightly integration branch for the past week to make sure we don't break
anything.
Note that there's still quite a flurry or patches floating around, but
I've figured I'll push this out. I plan to keep the bdw fixes separate
from my usual -fixes stream so that you can reject them easily in case it
still looks like too much churn. Also, bdw is for now hidden behind the
preliminary hw enabling module option. So there's no real pressure to get
follow-up patches all into 3.13.
* tag 'bdw-stage1-2013-11-08-v2' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits)
drm/i915: Mask the vblank interrupt on bdw by default
drm/i915: Wire up cpu fifo underrun reporting support for bdw
drm/i915: Optimize gen8_enable|disable_vblank functions
drm/i915: Wire up pipe CRC support for bdw
drm/i915: Wire up PCH interrupts for bdw
drm/i915: Wire up port A aux channel
drm/i915: Fix up the bdw pipe interrupt enable lists
drm/i915: Optimize pipe irq handling on bdw
drm/i915/bdw: Take render error interrupt out of the mask
drm/i915/bdw: Add BDW PCH check first
drm/i915: Use hsw_crt_get_config on BDW
drm/i915/bdw: Change dp aux timeout to 600us on DDIA
drm/i915/bdw: Enable trickle feed on Broadwell
drm/i915/bdw: WaSingleSubspanDispatchOnAALinesAndPoints
drm/i915/bdw: conservative SBE VUE cache mode
drm/i915/bdw: Limit SDE poly depth FIFO to 2
drm/i915/bdw: Sampler power bypass disable
ddrm/i915/bdw: Disable centroid pixel perf optimization
drm/i915/bdw: BWGTLB clock gate disable
drm/i915/bdw: Implement edp PSR workarounds
...
All the BARs have the ability to grow.
v2: Pulled out the simulator workaround to a separate patch.
Rebased.
v3: Rebase onto latest vlv patches from Jesse.
v4: Rebased on top of the early stolen quirk patch from Jesse.
v5: Use the new macro names.
s/INTEL_BDW_PCI_IDS_D/INTEL_BDW_D_IDS
s/INTEL_BDW_PCI_IDS_M/INTEL_BDW_M_IDS
It's Jesse's fault for not following the convention I originally set.
Cc: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Squash in "drm/i915/bdw: Add BDW to the HAS_DDI check" as
suggested by Damien.
v3: Squash in VEBOX enabling from Zhao Yakui <yakui.zhao@intel.com>
v4: Rebase on top of Jesse's patch to extract all pci ids to
include/drm/i915_pciids.h.
v4: Replace Halo by its marketing moniker Iris. Requested by Ben.
v5: Switch from info->has*ring to info->ring_mask.
v6: Add 0x16X2 variant (which is newer than this patch)
Rename to use new naming scheme (Chris)
Remove Simulator PCI ids. These snuck in during rebase (Chris)
v7: Fix poor sed job from v6
Make the desktop variants use the desktop macro (Rebase error). Notice
that this makes no functional difference - it's just confusing.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Used by the vmwgfx driver
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
drm_get_minor() is only used in one file. Make it static and add a
kernel-doc comment which documents the current semantics.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Allow passing NULL as minor to simplify DRM destruction paths. Also remove
the double-pointer reset as it is no longer needed. drm_put_minor() is
only called when the underlying object is destroyed. Hence, resetting
minors to NULL is not necessary.
As drm_put_minor() is no longer used by other DRM files, we can make it
static, too.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Replace the sparse array of booleans with a bitfield.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When a second process opens the device and master transferrence is
complete, we walk the list of open devices and remove their
authentication. This also revokes our root privilege. Instead of simply
dropping the authentication, this patch reverts the authenticated state
back to its original value.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
New helper function to set the preferred video mode. Can be called
after drm_add_modes_noedid if you don't want the largest supported
video mode be used by default.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Those structures are not used anywhere.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Those functions are just reading data from those pointers.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A change in locking of some kms drivers (currently intel-kms) make
the old approach too inaccurate and also incompatible with the
PREEMPT_RT realtime kernel patchset.
The driver->get_scanout_position() method of intel-kms now needs
to aquire a spinlock, which clashes badly with the former
preempt_disable() calls in the drm, and it also introduces larger
delays and timing uncertainty on a contended lock than acceptable.
This patch changes the prototype of driver->get_scanout_position()
to require/allow kms drivers to perform the ktime_get() system time
queries which go along with actual scanout position readout in a way
that provides maximum precision and to return those timestamps to
the drm. kms drivers implementations of get_scanout_position() are
asked to implement timestamping and scanoutpos readout in a way
that is as precise as possible and compatible with preempt_disable()
on a PREMPT_RT kernel. A driver should follow this pattern in
get_scanout_position() for precision and compatibility:
spin_lock...(...);
preempt_disable_rt(); // On a PREEMPT_RT kernel, otherwise omit.
if (stime) *stime = ktime_get();
... Minimum amount of MMIO register reads to get scanout position ...
... no taking of locks allowed here! ...
if (etime) *etime = ktime_get();
preempt_enable_rt(); // On PREEMPT_RT kernel, otherwise omit.
spin_unlock...(...);
v2: Fix formatting of new multi-line code comments.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The biggest part of the changes is the decoupling of the host1x and DRM
drivers followed by the move of Tegra DRM back to drivers/gpu/drm/tegra
from whence it came. There is a lot of cleanup as well, and the drivers
can now be properly unloaded and reloaded.
HDMI support for the Tegra114 SoC was contributed by Mikko Perttunen.
gr2d support was extended to Tegra114 and the gr3d driver that has been
in the works for quite some time finally made it in. All pieces to run
an OpenGL driver on top of an upstream kernel are now available.
Support for syncpoint bases was added by Arto Merilainen. This is useful
for synchronizing between command streams from different engines such as
gr2d and gr3d.
Erik Faye-Lund and Wei Yongjun contributed various small fixes. Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSch6LAAoJEN0jrNd/PrOhvYwP/ir8/pK0kWLdowfArmZqs1T7
YhFy3zOCDkf2FKwNshsU8gwc8qeaCkP07LUBtjg+BvPdaHBQShLmwkNLKeV6tfLn
A6gtCMkJG3l52PxoM9NtRIyq9Xot8Sv1H+PNSYjKgUDrIYNYkMhgG90+Aj409Qkw
bbons3/CH58ufxY47wpGTFxhsiHX/9CSOlWl2RVfyzeyi5sVG+e+it3jsCl3ma9X
lmCBJuZlaZsB1xy9kQaYobpL0BiNwhTOVeh0YmUQDBxFtIcY9j2h1dOCsh4o1sPp
Aht/r8OaBxCu4ykAoGByaO/Bz6PQEaX1nW776edR1dusUBOupRjmyHcz1unq1Qpo
PUI0zs823WrWX863FQcG+i71wdZDmRReGPduv+94H0IT6NtQEC2fT1eJdn2DtI0L
GD3d8NR92hGdYVH01tEILlrT4Rrlemb0CWr+Vf6T3LwU44Jns/9X3UnG+GVE7IwT
GreK0FjCTKeNZeMKGCJ0aKwjwEd7VMiFRiuEZfoemik8X3ib8f8oCeXIX1gD1ksz
vGSaSjhx//X7/hco+1DSqdPOJnXd/ZUC0AkFQ0lIJ2mQvZfwHx55uE/AFjD1WE4/
BNsTP+8C97IA/zAK241Ow+f1cLhRp1ZlgOVbFZp+EttKZ2vxRik/jV8MsBfhWJBX
gIAXabh1MvhxagGaiFmb
=qc03
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.13-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v3.13-rc1
The biggest part of the changes is the decoupling of the host1x and DRM
drivers followed by the move of Tegra DRM back to drivers/gpu/drm/tegra
from whence it came. There is a lot of cleanup as well, and the drivers
can now be properly unloaded and reloaded.
HDMI support for the Tegra114 SoC was contributed by Mikko Perttunen.
gr2d support was extended to Tegra114 and the gr3d driver that has been
in the works for quite some time finally made it in. All pieces to run
an OpenGL driver on top of an upstream kernel are now available.
Support for syncpoint bases was added by Arto Merilainen. This is useful
for synchronizing between command streams from different engines such as
gr2d and gr3d.
Erik Faye-Lund and Wei Yongjun contributed various small fixes. Thanks!
* tag 'drm/for-3.13-rc1' of git://anongit.freedesktop.org/tegra/linux: (45 commits)
drm/tegra: Reserve syncpoint base for gr3d
drm/tegra: Reserve base for gr2d
drm/tegra: Deliver syncpoint base to user space
gpu: host1x: Add syncpoint base support
gpu: host1x: Add 'flags' field to syncpt request
drm/tegra: Disable clock on probe failure
gpu: host1x: Disable clock on probe failure
drm/tegra: Support bottom-up buffer objects
drm/tegra: Add support for tiled buffer objects
drm/tegra: Add 3D support
drm/tegra: Introduce tegra_drm_submit()
drm/tegra: Use symbolic names for gr2d registers
drm/tegra: Start connectors with correct DPMS mode
drm/tegra: hdmi: Enable VDD earlier for hotplug/DDC
drm/tegra: hdmi: Fix build warnings
drm/tegra: hdmi: Detect DVI-only displays
drm/tegra: Add Tegra114 HDMI support
drm/tegra: hdmi: Parameterize based on compatible property
drm/tegra: hdmi: Rename tegra{2,3} to tegra{20,30}
gpu: host1x: Add support for Tegra114
...
The Tegra DRM driver currently uses some infrastructure to defer the DRM
core initialization until all required devices have registered. The same
infrastructure can potentially be used by any other driver that requires
more than a single sub-device of the host1x module.
Make the infrastructure more generic and keep only the DRM specific code
in the DRM part of the driver. Eventually this will make it easy to move
the DRM driver part back to the DRM subsystem.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The caller may want to know whether the configuration was changed, and
if an hotplug event was sent.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds support for the Armada 510 display subsystem found on the
Marvell Dove devices. This IP is re-used across several different Marvell
SoCs with various tweaks, and this driver has been structured to allow
the other IPs to re-use the bulk of this code; further work in this area
is expected from interested parties.
This has been extensively tested on the SolidRun Cubox platform and
appears to work well there.
[airlied: update for api changes merged previous to this]
So drm was abusing device lifetimes, by having embedded device structures
in the minor and connector it meant that the lifetime of the internal drm
objects (drm_minor and drm_connector) were tied to the lifetime of the device
files in sysfs, so if something kept those files opened the current code
would kfree the objects and things would go downhill from there.
Now in reality there is no need for these lifetimes to be so intertwined,
especailly with hotplugging of devices where we wish to remove the sysfs
and userspace facing pieces before we can unwind the internal objects due
to open userspace files or mmaps, so split the objects out so the struct
device is no longer embedded and do what fbdev does and just allocate
and remove the sysfs inodes separately.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs. This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
acceleration
- dual lcd0 and lcd1 crt operation
- video overlay on each LCD crt via DRM planes
- page flipping of the main scanout buffers
- DRM prime for buffer export/import
This driver is trivial to extend to other Armada SoCs.
Included in this commit is the core driver with no output support; output
support is platform and encoder driver dependent.
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The conflict in intel_drv.h tripped me up a bit since a patch in dinq
moves all the functions around, but another one in drm-next removes a
single function. So I'ev figured backing this into a backmerge would
be good.
i915_dma.c is just adjacent lines changed, nothing nefarious there.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_drv.h
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The user of these counters was killed in
commit d79cdc8312
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Aug 8 15:41:32 2013 +0200
drm: no-op out GET_STATS ioctl
so clean up the leftovers as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We can get the PCI vendor and device IDs via dev->pdev. So we can drop
the duplicated information.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The only user of ctx_count is the via driver, and we can replace that
use with list_is_singular().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
'map_count' and 'work' are never used. Kill them both.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
irq_enabled is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_vblank_init() is too ugly. Make it a bit easier on the eye by
collecting all the per-crtc vblank counters, timestamps etc. to
a structure and just allocate an array of those.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
vblank_enabled is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
vblank_inmodeset is a bitmask, with only two bits mind you, but better
make it unsigned anyway.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
vblank_disable_allowed is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Analog to drm_dev_register(), we now provide drm_dev_unregister() which
does the reverse. drm_dev_put() is still in place and combines the calls
to drm_dev_unregister() and drm_dev_free() so buses don't have to change.
*_get() and *_put() are used for reference-counting in the kernel.
However, drm_dev_put() definitely does not do any kind of ref-counting.
Hence, use the more appropriate *_register(), *_unregister(), *_alloc()
and *_free() names.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The error paths in DRM bus drivers currently leak memory as they don't
correctly revert drm_dev_alloc(). Introduce drm_dev_free() to free DRM
devices which haven't been registered, yet.
We must be careful not to introduce any side-effects with cleanups done in
drm_dev_free(). drm_ht_remove(), drm_ctxbitmap_cleanup() and
drm_gem_destroy() are all fine in that regard.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All bus drivers do device setup themselves. This requires us to adjust all
of them if we introduce new core features. Thus, merge all these into a
uniform drm_dev_register() helper.
Note that this removes the drm_lastclose() error path for AGP as it is
horribly broken. Moreover, no bus driver called this in any other error
path either. Instead, we use the recently introduced AGP cleanup helpers.
We also keep a DRIVER_MODESET condition around pci_set_drvdata() to keep
semantics.
[airlied: keep passing flags through so drivers don't oops on load]
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead of managing device allocation+initialization in each bus-driver,
we should do that in a central place. drm_fill_in_dev() already does most
of it, but also requires the global drm lock for partial AGP device
registration.
Split both apart so we have a clean device initialization/allocation
phase, and a registration phase.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The kernel shouldn't accept invalid modes, just say No.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows us to use fewer bits in the mode structure, leaving room for
future work while allowing more stereo layouts types than we could have
ever dreamt of.
I also exposed the previously private DRM_MODE_FLAG_3D_MASK to set in
stone that we are using 5 bits for the stereo layout enum, reserving 32
values.
Even with that reservation, we gain 3 bits from the previous encoding.
The code adding the mandatory stereo modes needeed to be adapted as it was
relying or being able to or stereo layouts together.
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.
v2: Use crtc_vtotal and multiply the clock by 2 instead of
reconstructing it (Ville Syrjälä)
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like the various timings, make it possible to have a clock field
what we can tweak before giving it to hardware.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This field is unused. Garbage collect it.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This field was only accessed by the nouveau driver, but never set. So
concluded we can rid of this one.
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like with interlaced or double scan modes, make stereo modes a
per-connector opt-in to give a chance to driver authors to make it work
before enabling it.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This capability allows user space to control the delivery of modes with
the 3D flags set. This is to not play games with current user space
users not knowing anything about stereo 3D flags and that could try
to set a mode with one or several of those bits set.
So, the plan is to remove the stereo modes from the list of modes we
give to DRM clients by default, and let them through if we are being
told otherwise.
stereo_allowed is bound to the drm_file structure to make it a
per-client setting, not a global one.
v2: Replace clearing 3D flags by discarding the stereo modes now that
they are regular modes.
v3: SET_CAP -> SET_CLIENT_CAP rename (Chris Wilson)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HDMI 1.4a defines a few layouts that we'd like to expose. This commits
add new modeinfo flags that can be used to list the supported stereo
layouts (when querying the list of modes) and to set a given stereo 3D
mode (when setting a mode).
v2: Add a drm_mode_is_stereo() helper
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This ioctl can be used to turn some knobs in a DRM driver. The client
can ask the DRM core for an alternate view of the reality: it can be
useful to be able to instruct the core that the DRM client can handle
new functionnality that would otherwise break current ABI.
v2: Rename to ioctl from SET_CAP to SET_CLIENT_CAP (Chris Wilson)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
None of the DP DPCD helpers need to modify the DPCD.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have some code duplication related to EDID duplication. Add a helper.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Detailed cap info at address 80h is not available with DPCD ver
1.0. Whether such devices exist in the wild I don't know, but there
should be no harm done in having the defines for downstream port 0 in
address 05h.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 7c510133d9.
Well looks like not enough digging was done, libdrm_nouveau before 2.4.33
used contexts,
292da616fe1f936ca78a3fa8e1b1b19883e343b6 nouveau: pull in major libdrm rewrite
got rid of them,
Reported-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Reported-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Early stolen mem reservation from Jesse in x86 boot code. Acked by Ingo
and hpa. This was ready much earlier but somehow I've thought it'd go
in through x86 trees, hence why this is late. Avoids the pci resource
code to plant mmiobars in the middle of stolen mem and other ugliness.
- vgaarb improvements from Alex Williamson plus the fix from Ville for the
vgacon->fbcon smooth transition "feature".
- Render pageflips on ivb/hsw to avoid stalls due to the ring switching
when only flipping on the blitter (Chris).
- Deadlock fixes around our flush_workqueue which crept back in - lockdep
isn't clever enough :(
- Shrinker recursion fix from Chris - this is the thing that blew the vma
patches from Ben I've taken out of 3.12.
- Fixup for the relocation refactoring. Also an igt testcase to make sure
we don't break this again.
- Pile of smaller fixups all over, shortlog has full details.
* tag 'drm-intel-fixes-2013-09-06' of git://people.freedesktop.org/~danvet/drm-intel: (29 commits)
drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done
drm/i915: try not to lose backlight CBLV precision
drm/i915: Confine page flips to BCS on Valleyview
drm/i915: Skip stolen region initialisation if none is reserved
drm/i915: fix gpu hang vs. flip stall deadlocks
drm/i915: Hold an object reference whilst we shrink it
drm/i915: fix i9xx_crtc_clock_get for multiplied pixels
drm/i915: handle sdvo input pixel multiplier correctly again
drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock
drm/i915: fix up the relocate_entry refactoring
drm/i915: Fix pipe config warnings when dealing with LVDS fixed mode
drm/i915: Don't call sg_free_table() if sg_alloc_table() fails
i915: Update VGA arbiter support for newer devices
vgaarb: Fix VGA decodes changes
vgaarb: Don't disable resources that are not owned
drm/i915: Pin pages whilst mapping the dma-buf
drm/i915: enable trickle feed on Haswell
x86: add early quirk for reserving Intel graphics stolen memory v5
drm/i915: split PCI IDs out into i915_drm.h v4
i915_gem: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc
...
The patch replaces all occurrences of struct fb_videomode by
more accurate struct videomode. The change allows to remove
mode conversion function and simplifies clock divider calculation.
Clock configuration is moved to separate function.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not always marked in the E820 as
reserved or as RAM, and so is subject to overlap from E820 manipulation
later in the boot process. On some systems, MMIO space is allocated on
top, despite the efforts of the "RAM buffer" approach, which simply
rounds memory boundaries up to 64M to try to catch space that may decode
as RAM and so is not suitable for MMIO.
v2: use read_pci_config for 32 bit reads instead of adding a new one
(Chris)
add gen6 stolen size function (Chris)
v3: use a function pointer (Chris)
drop gen2 bits (Daniel)
v4: call e820_sanitize_map after adding the region
v5: fixup comments (Peter)
simplify loop (Chris)
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66726
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66844
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
v4: fix up PCI match structure init for easier use by userspace (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, and dpms (via the enable/disable hooks).
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex writes:
This is the radeon drm-next request. Big changes include:
- support for dpm on CIK parts
- support for ASPM on CIK parts
- support for berlin GPUs
- major ring handling cleanup
- remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
- lots of bug fixes
[airlied: fix up a bunch of conflicts from drm_order removal]
* 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux: (898 commits)
drm/radeon/dpm: make sure dc performance level limits are valid (CI)
drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2)
drm/radeon: gcc fixes for extended dpm tables
drm/radeon: gcc fixes for kb/kv dpm
drm/radeon: gcc fixes for ci dpm
drm/radeon: gcc fixes for si dpm
drm/radeon: gcc fixes for ni dpm
drm/radeon: gcc fixes for trinity dpm
drm/radeon: gcc fixes for sumo dpm
drm/radeonn: gcc fixes for rv7xx/eg/btc dpm
drm/radeon: gcc fixes for rv6xx dpm
drm/radeon: gcc fixes for radeon_atombios.c
drm/radeon: enable UVD interrupts on CIK
drm/radeon: fix init ordering for r600+
drm/radeon/dpm: only need to reprogram uvd if uvd pg is enabled
drm/radeon: check the return value of uvd_v1_0_start in uvd_v1_0_init
drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume
radeon kms: fix uninitialised hotplug work usage in r100_irq_process()
drm/radeon/audio: set up the sads on DCE3.2 asics
drm/radeon: fix handling of variable sized arrays for router objects
...
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_gem_dmabuf.c
drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/radeon/cik.c
drivers/gpu/drm/radeon/ni.c
drivers/gpu/drm/radeon/r600.c
This adds a helper function to extract the speaker allocation
data block from the EDID. This data block describes what speakers
are present on the display device.
v2: update per Ville Syrjälä's comments
v3: fix copy/paste typo in memory allocation
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
Let applications know whether the kernel supports asynchronous page
flipping.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
This lets drivers see the flags requested by the application
[airlied: fixup for rcar/imx/msm]
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Unfortunately, I haven't been thorough enough in:
commit ddecb10cf4
Author: Lespiau, Damien <damien.lespiau@intel.com>
Date: Tue Aug 20 00:53:04 2013 +0100
drm: Remove drm_mode_create_dithering_property()
And forgot to remove the dithering_mode_property member of struct
drm_mode_config.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.
Compared to legacy clients, render clients no longer need any
authentication to perform client ioctls. Instead, user-space controls
render/client access to GPUs via filesystem access-modes on the
render-node. Once a render-node was opened, a client has full access to
the client/render operations on the GPU. However, no modesetting or ioctls
that affect global state are allowed on render nodes.
To prevent privilege-escalation, drivers must explicitly state that they
support render nodes. They must mark their render-only ioctls as
DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must
support clients without any attached master.
If filesystem access-modes are not enough for fine-grained access control
to render nodes (very unlikely, considering the versaitlity of FS-ACLs),
you may still fall-back to fd-passing from server to client (which allows
arbitrary access-control). However, note that revoking access is
currently impossible and unlikely to get implemented.
Note: Render clients no longer have any associated DRM-Master as they are
supposed to be independent of any server state. DRM core highly depends on
file_priv->master to be non-NULL for modesetting/ctx/etc. commands.
Therefore, drivers must be very careful to not require DRM-Master if they
support DRIVER_RENDER.
So far render-nodes are protected by "drm_rnodes". As long as this
module-parameter is not set to 1, a driver will not create render nodes.
This allows us to experiment with the API a bit before we stabilize it.
v2: drop insecure GEM_FLINK to force use of dmabuf
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This can then be used by DRM drivers to setup their vendor infoframes.
v2: Fix hmdi typo (Simon Farnsworth)
v3: Adapt to the hdmi_vendor_infoframe rename
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
This function is only used inside drm_edid.c.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn't really scale, we implement access management in the VMA
manager itself.
We use an rb-tree to store open-files for each VMA node. On each mmap
call, GEM, TTM or the drivers must check whether the current user is
allowed to map this file.
We add a separate lock for each node as there is no generic lock available
for the caller to protect the node easily.
As we currently don't know whether an object may be used for mmap(), we
have to do access management for all objects. If it turns out to slow down
handle creation/deletion significantly, we can optimize it in several
ways:
- Most times only a single filp is added per bo so we could use a static
"struct file *main_filp" which is checked/added/removed first before we
fall back to the rbtree+drm_vma_offset_file.
This could be even done lockless with rcu.
- Let user-space pass a hint whether mmap() should be supported on the
bo and avoid access-management if not.
- .. there are probably more ideas once we have benchmarks ..
v2: add drm_vma_node_verify_access() helper
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
... not only when the dma-buf is freshly created. In contrived
examples someone else could have exported/imported the dma-buf already
and handed us the gem object with a flink name. If such on object gets
reexported as a dma_buf we won't have it in the handle cache already,
which breaks the guarantee that for dma-buf imports we always hand
back an existing handle if there is one.
This is exercised by igt/prime_self_import/with_one_bo_two_files
Now if we extend the locked sections just a notch more we can also
plug th racy buf/handle cache setup in handle_to_fd:
If evil userspace races a concurrent gem close against a prime export
operation we can end up tearing down the gem handle before the dma buf
handle cache is set up. When handle_to_fd gets around to adding the
handle to the cache there will be no one left to clean it up,
effectily leaking the bo (and the dma-buf, since the handle cache
holds a ref on the dma-buf):
Thread A Thread B
handle_to_fd:
lookup gem object from handle
creates new dma_buf
gem_close on the same handle
obj->dma_buf is set, but file priv buf
handle cache has no entry
obj->handle_count drops to 0
drm_prime_add_buf_handle sets up the handle cache
-> We have a dma-buf reference in the handle cache, but since the
handle_count of the gem object already dropped to 0 no on will clean
it up. When closing the drm device fd we'll hit the WARN_ON in
drm_prime_destroy_file_private.
The important change is to extend the critical section of the
filp->prime.lock to cover the gem handle lookup. This serializes with
a concurrent gem handle close.
This leak is exercised by igt/prime_self_import/export-vs-gem_close-race
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
... and move it to the top of the function to avoid a forward
declaration.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
with the reworking semantics and locking of the obj->dma_buf pointer
this pointer is always set as long as there's still a gem handle
around and a dma_buf associated with this gem object.
Also, the per file-priv lookup-cache for dma-buf importing is also
unified between foreign and native objects.
Hence we don't need to special case the clean any more and can simply
drop the clause which only runs for foreing objects, i.e. with
obj->import_attach set.
Note that with this change (actually with the previous one to always
set up obj->dma_buf even for foreign objects) it is no longer required
to set obj->import_attach when importing a foreing object. So update
comments accordingly, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The export dma-buf cache is semantically similar to an flink name. So
semantically it makes sense to treat it the same and remove the name
(i.e. the dma_buf pointer) and its references when the last gem handle
disappears.
Again we need to be careful, but double so: Not just could someone
race and export with a gem close ioctl (so we need to recheck
obj->handle_count again when assigning the new name), but multiple
exports can also race against each another. This is prevented by
holding the dev->object_name_lock across the entire section which
touches obj->dma_buf.
With the new scheme we also need to reinstate the obj->dma_buf link at
import time (in case the only reference userspace has held in-between
was through the dma-buf fd and not through any native gem handle). For
simplicity we don't check whether it's a native object but
unconditionally set up that link - with the new scheme of removing the
obj->dma_buf reference when the last handle disappears we can do that.
To make it clear that this is not just for exported buffers anymore
als rename it from export_dma_buf to dma_buf.
To make sure that now one can race a fd_to_handle or handle_to_fd with
gem_close we use the same tricks as in flink of extending the
dev->object_name_locking critical section. With this change we finally
have a guaranteed 1:1 relationship (at least for native objects)
between gem objects and dma-bufs, even accounting for races (which can
happen since the dma-buf itself holds a reference while in-flight).
This prevent igt/prime_self_import/export-vs-gem_close-race from
Oopsing the kernel. There is still a leak though since the per-file
priv dma-buf/handle cache handling is racy. That will be fixed in a
later patch.
v2: Remove the bogus dma_buf_put from the export_and_register_object
failure path if we've raced with the handle count dropping to 0.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The gem flink name holds a reference onto the object itself, and this
self-reference would prevent an flink'ed object from every being
freed. To break that loop we remove the flink name when the last
userspace handle disappears, i.e. when obj->handle_count reaches 0.
Now in gem_open we drop the dev->object_name_lock between the flink
name lookup and actually adding the handle. This means a concurrent
gem_close of the last handle could result in the flink name getting
reaped right inbetween, i.e.
Thread 1 Thread 2
gem_open gem_close
flink -> obj lookup
handle_count drops to 0
remove flink name
create_handle
handle_count++
If someone now flinks this object again, we'll get a new flink name.
We can close this race by removing the lock dropping and making the
entire lookup+handle_create sequence atomic. Unfortunately to still be
able to share the handle_create logic this requires a
handle_create_tail function which drops the lock - we can't hold the
object_name_lock while calling into a driver's ->gem_open callback.
Note that for flink fixing this race isn't really important, since
racing gem_open against gem_close is clearly a userspace bug. And no
matter how the race ends, we won't leak any references.
But with dma-buf where the userspace dma-buf fd itself is refcounted
this is a valid sequence and hence we should fix it. Therefore this
patch here is just a warm-up exercise (and for consistency between
flink buffer sharing and dma-buf buffer sharing with self-imports).
Also note that this extension of the critical section in gem_open
protected by dev->object_name_lock only works because it's now a
mutex: A spinlock would conflict with the potential memory allocation
in idr_preload().
This is exercises by igt/gem_flink_race/flink_name.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I want to wrap the creation of a dma-buf from a gem object in it,
so that the obj->export_dma_buf cache can be atomically filled in.
Instead of creating a new mutex just for that variable I've figured
I can reuse the existing dev->object_name_lock, especially since
the new semantics will exactly mirror the flink obj->name already
protected by that lock.
v2: idr_preload/idr_preload_end is now an atomic section, so need to
move the mutex locking outside.
[airlied: fix up conflict with patch to make debugfs use lock]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No one outside of drm should use this, the official interfaces are
drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
is purely an implementation detail of gem.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the 2nd attempt, I've always been a bit dissatisified with the
tricky nature of the first one:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html
The issue is that the flink ioctl can race with calling gem_close on
the last gem handle. In that case we'll end up with a zero handle
count, but an flink name (and it's corresponding reference). Which
results in a neat space leak.
In my first attempt I've solved this by rechecking the handle count.
But fundamentally the issue is that ->handle_count isn't your usual
refcount - it can be resurrected from 0 among other things.
For those special beasts atomic_t often suggest way more ordering that
it actually guarantees. To prevent being tricked by those hairy
semantics take the easy way out and simply protect the handle with the
existing dev->object_name_lock.
With that change implemented it's dead easy to fix the flink vs. gem
close reace: When we try to create the name we simply have to check
whether there's still officially a gem handle around and if not refuse
to create the flink name. Since the handle count decrement and flink
name destruction is now also protected by that lock the reace is gone
and we can't ever leak the flink reference again.
Outside of the drm core only the exynos driver looks at the handle
count, and tbh I have no idea why (it's just for debug dmesg output
luckily).
I've considered inlining the drm_gem_object_handle_free, but I plan to
add more name-like things (like the exported dma_buf) to this scheme,
so it's clearer to leave the handle freeing in its own function.
This is exercised by the new gem_flink_race i-g-t testcase, which on
my snb leaks gem objects at a rate of roughly 1k objects/s.
v2: Fix up the error path handling in handle_create and make it more
robust by simply calling object_handle_unreference.
v3: Fix up the handle_unreference logic bug - atomic_dec_and_test
retursn 1 for 0. Oops.
v4: Squash in inlining of drm_gem_object_handle_reference as suggested
by Dave Airlie and add a note that we now have a testcase.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's only used in drm_platform.c.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This function is only used in drm_fb_cma_helper.c.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These were introduced in the very first DRM commit:
commit f453ba0460
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Nov 7 14:05:41 2008 -0800
DRM: add mode setting support
Add mode setting support to the DRM layer.
But are unused.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's only used in drm_crtc.c.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The last user was removed in
commit 575dc34ee0
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Sep 7 18:43:26 2009 +1000
drm/kms: remove old std mode fallback code.
The new code adds modes in the helper, which makes more sense
I disliked the non-driver code adding modes.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was last used by nouveau, replaced by a driver-specific property
in:
commit de69185573
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon Oct 17 12:23:41 2011 +1000
drm/nouveau: improve dithering properties, and implement proper auto mode
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A few prototypes have been left in the headers, their function friends
long gone.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging it turned out that the drmstat tool in libdrm is still using
those files (but only when certain options are set). So we've decided
to keep profcs.
But I when I've started to dig around again what exactly this tool
does I've noticed that it tries to read the "mem", "vm", and "vma"
files from procfs. Now as far my git history digging shows "mem" never
did anything useful (at least in the version that first showed up in
upstream history in 2004) and the file was remove in
commit 955b12def4
Author: Ben Gamari <bgamari@gmail.com>
Date: Tue Feb 17 20:08:49 2009 -0500
drm: Convert proc files to seq_file and introduce debugfs
Which means that for over 4 years drmstat has been broken, and no one
cared. In my opinion that's proof enough that no one is actually using
drmstat, and so that we can savely nuke the procfs support from drm.
While at it fix up the error case cleanup for debugfs in drm_get_minor.
v2: Fix dates, libdrm stopped relying on procfs for drm node detection
in 2001.
v3: fixup compilation warning for !CONFIG_DEBUG_FS, reported by
Fengguang Wu.
Cc: kbuild test robot <fengguang.wu@intel.com>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitly check for that in the new ioctl implementation.
v2: Drop the unused variable I've accidentally left in the code,
spotted by David Herrmann.
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected drivers. David helped a lot in that. Quoting our mail
discussion:
On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>>> -#if __OS_HAS_MTRR
>>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>>>> -{
>>>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>>>> -}
>>>> -#else
>>>> -#define drm_core_has_MTRR(dev) (0)
>>>> -#endif
>>>> -
>>>
>>> That was the last user of DRIVER_USE_MTRR (apart from drivers setting
>>> it in .driver_features). Any reason to keep it around?
>>
>> Yeah, I guess we could rip things out. Which will also force me to
>> properly audit drivers for the eventual behaviour change this could
>> entail (in case there's an x86 driver which did not ask for an mtrr,
>> but iirc there isn't).
>
> david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
> test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
> fi ; done
> drivers/gpu/drm/exynos
> drivers/gpu/drm/gma500
> drivers/gpu/drm/i2c
> drivers/gpu/drm/nouveau
> drivers/gpu/drm/omapdrm
> drivers/gpu/drm/qxl
> drivers/gpu/drm/rcar-du
> drivers/gpu/drm/shmobile
> drivers/gpu/drm/tilcdc
> drivers/gpu/drm/ttm
> drivers/gpu/drm/udl
> drivers/gpu/drm/vmwgfx
> david@david-mb ~/dev/kernel/linux $
>
> So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
> But I cannot tell whether they break if we call arch_phys_wc_add/del,
> anyway. At least nouveau seemed to work here, but it doesn't use AGP
> or drm_bufs, I guess.
Cool, thanks a lot for stitching together the list of drivers to look
at. So for real KMS drivers it's the drives responsibility to add an
mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
already. Somehow the savage driver also ends up doing that, I have no
idea why.
Note that gma500 as a pure KMS driver doesn't need MTRR setup since
the platforms that it supports all support PAT. So no MTRRs needed to
get wc iomappings.
The mtrr support in the drm core is all for legacy mappings of garts,
framebuffers and registers. All legacy drivers set the USE_MTRR flag,
so we're good there.
All in all I think we can really just ditch this
/endquote
v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann
v3: Rebase on top of David Herrmann's agp setup/cleanup changes.
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.
Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static (and remove the unused EXPORT_SYMBOL). To
avoid a forward declaration move it (and drm_gem_object_free_bug) up a
bit.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Lifetime rules seem to be solid around ->import_attach. So this patch
just properly documents them.
Note that pointing directly at the attachment might have issues for
devices that have multiple struct device *dev parts constituting the
logical gpu and so might need multiple attachment points. Similarly
for drm devices which don't need a dma attachment at all (like udl).
But fixing that up is material for different patches.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.
To use the release helper we need to export it, too.
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Basically just extracting some code duplicated in gma500, omapdrm, udl,
and upcoming msm driver.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Variant of drm_gem_create_mmap_offset() which doesn't make the
assumption that virtual size and physical size (obj->size) are the same.
This is needed in omapdrm to deal with tiled buffers. And lets us get
rid of a duplicated and slightly modified version of
drm_gem_create_mmap_offset() in omapdrm.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A small helper to queue up work to do, from workqueue context, after a
flip. Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.
v1: original
v2: wire up docbook + couple docbook fixes
Signed-off-by: Rob Clark <robdclark@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This function is unused.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.
No merged drm driver has ever done that.
After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:
commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie <airlied@linux.ie>
Date: Sun Aug 29 12:04:35 2004 +0000
Drop GAMMA DRM from a great height ...
Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.
So stop this particular cargo-cult and rip it all out.
v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.
v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.
v4: Actually git add ... tsk.
Cc: Dave Airlie <airlied@linux.ie>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).
Also add the drm_legacy prefix for functions which are called from
common code. To further reduce the impact on common code also extract
all the ctx release handling into a function (instead of only
releasing individual handles) and make ctxbitmap_cleanup return void -
it can never fail.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We currently rely on gcc dead-code elimination so the drm_agp_* helpers
are not called if drm_core_has_AGP() is false. That's ugly as hell so
provide "static inline" dummies for the case that AGP is disabled.
Fixes a build-regression introduced by:
commit 28ec711cd4
Author: David Herrmann <dh.herrmann@gmail.com>
Date: Sat Jul 27 16:37:00 2013 +0200
drm/agp: move AGP cleanup paths to drm_agpsupport.c
v2: switch #ifdef -> #if (spotted by Stephen)
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Neat that QA (and Ben) keeps on humming along while I'm on vacation, so
you already get the next feature pull request:
- proper eLLC support for HSW from Ben
- more interrupt refactoring
- add w/a tags where we implement them already (Damien)
- hangcheck fixes (Chris) + hangcheck stats (Mika)
- flesh out the new vm structs for ppgtt and ggtt (Ben)
- PSR for Haswell, still disabled by default (Rodrigo et al.)
- pc8+ refclock sequence code from Paulo
- more interrupt refactoring from Paulo, unifying ilk/snb with the ivb/hsw
interrupt code
- full solution for the Haswell concurrent reg access issues (Chris)
- fix racy object accounting, used by some new leak tests
- fix sync polarity settings on ch7xxx dvo encoder
- random bits&pieces, little fixes and better debug output all over
[airlied: fix conflict with drm_mm cleanups]
* tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel: (289 commits)
drm/i915: Do not dereference NULL crtc or fb until after checking
drm/i915: fix pnv display core clock readout out
drm/i915: Replace open-coded offset_in_page()
drm/i915: Retry DP aux_ch communications with a different clock after failure
drm/i915: Add messages useful for HPD storm detection debugging (v2)
drm/i915: dvo_ch7xxx: fix vsync polarity setting
drm/i915: fix the racy object accounting
drm/i915: Convert the register access tracepoint to be conditional
drm/i915: Squash gen lookup through multiple indirections inside GT access
drm/i915: Use the common register access functions for NOTRACE variants
drm/i915: Use a private interface for register access within GT
drm/i915: Colocate all GT access routines in the same file
drm/i915: fix reference counting in i915_gem_create
drm/i915: Use Graphics Base of Stolen Memory on all gen3+
drm/i915: disable stolen mem for OVERLAY_NEEDS_PHYSICAL
drm/i915: add functions to disable and restore LCPLL
drm/i915: disable CLKOUT_DP when it's not needed
drm/i915: extend lpt_enable_clkout_dp
drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
drm/i915: Add some debug breadcrumbs to connector detection
...
We used to pre-allocate drm_mm nodes and save them in a linked list for
later usage so we always have spare ones in atomic contexts. However, this
is really racy if multiple threads are in an atomic context at the same
time and we don't have enough spare nodes. Moreover, all remaining users
run in user-context and just lock drm_mm with a spinlock. So we can easily
preallocate the node, take the spinlock and insert the node.
This may have worked well with BKL in place, however, with today's
infrastructure it really doesn't make any sense. Besides, most users can
easily embed drm_mm_node into their objects so no allocation is needed at
all.
Thus, remove the old pre-alloc API and all the helpers that it provides.
Drivers have already been converted and we should not use the old API for
new code, anymore.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Introduce two new helpers, drm_agp_clear() and drm_agp_destroy() which
clear all AGP mappings and destroy the AGP head. This allows to reduce the
AGP code in core DRM and move it all to drm_agpsupport.c.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Because, there is no reason for it not to be const.
v1: original
v2: fix compile break in vmwgfx, and couple related cleanups suggested
by Ville Syrjälä
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add a "best_match" flag similar to the drm_mm_search_*() helpers so we
can convert TTM to use them in follow up patches. We can also inline the
non-generic helpers and move them into the header to allow compile-time
optimizations.
To make calls to drm_mm_{search,insert}_node() more readable, this
converts the boolean argument to a flagset. There are pending patches that
add additional flags for top-down allocators and more.
v2:
- use flag parameter instead of boolean "best_match"
- convert *_search_free() helpers to also use flags argument
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We can apply the same optimisation tricks as kref_put_mutex() in our
local equivalent function. However, we have a different locking semantic
(we unlock ourselves, in kref_put_mutex() the callee unlocks) so that we
can use the same callbacks for both locked and unlocked kref_put()s and
so can not simply convert to using kref_put_mutex() directly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Acked-by: Inki Dae <inki.dae@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Ben Skeggs <skeggsb@gmail.com>
Reviwed-by: Rob Clark <robdclark@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need BUG_ON(), spinlock_t and standard kernel data-types so include the
right headers.
Subject: [drm-intel:drm-intel-nightly 154/166] include/drm/drm_mm.h:67:2:
error: unknown type name 'spinlock_t'
Message-ID: <51f14693.g5HGdcuw2v3m8FOd%fengguang.wu@intel.com>
In case it didn't link to it correctly. Somehow this bug doesn't occur
here on my machine, hmm. But I think fixing drm_mm.h is better than
changing the include-order in drm_vma_manager.h, so this is what I
did.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sign bit wasn't handled properly and a small typo.
Thanks to Christian for helping me sort this out.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This backmerges Linus' merge commit of the latest drm-fixes pull:
commit 549f3a1218
Merge: 42577ca058ca4a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue Jul 23 15:47:08 2013 -0700
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
We've accrued a few too many conflicts, but the real reason is that I
want to merge the 100% solution for Haswell concurrent registers
writes into drm-intel-next. But that depends upon the 90% bandaid
merged into -fixes:
commit a7cd1b8fea
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 19 20:36:51 2013 +0100
drm/i915: Serialize almost all register access
Also, we can roll up on accrued conflicts.
Usually I'd backmerge a tagged -rc, but I want to get this done before
heading off to vacations next week ;-)
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_gem.c
v2: For added hilarity we have a init sequence conflict around the
gt_lock, so need to move that one, too. Spotted by Jani Nikula.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of unmapping the nodes in TTM and GEM users manually, we provide
a generic wrapper which does the correct thing for all vma-nodes.
v2: remove bdev->dev_mapping test in ttm_bo_unmap_virtual_unlocked() as
ttm_mem_io_free_vm() does nothing in that case (io_reserved_vm is 0).
v4: Fix docbook comments
v5: use drm_vma_node_size()
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Use the new vma-manager infrastructure. This doesn't change any
implementation details as the vma-offset-manager is nearly copied 1-to-1
from TTM.
The vm_lock is moved into the offset manager so we can drop it from TTM.
During lookup, we use the vma locking helpers to take a reference to the
found object.
In all other scenarios, locking stays the same as before. We always
guarantee that drm_vma_offset_remove() is called only during destruction.
Hence, helpers like drm_vma_node_offset_addr() are always safe as long as
the node has a valid offset.
This also drops the addr_space_offset member as it is a copy of vm_start
in vma_node objects. Use the accessor functions instead.
v4:
- remove vm_lock
- use drm_vma_offset_lock_lookup() to protect lookup (instead of vm_lock)
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Martin Peres <martin.peres@labri.fr>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Use the new vma manager instead of the old hashtable. Also convert all
drivers to use the new convenience helpers. This drops all the
(map_list.hash.key << PAGE_SHIFT) non-sense.
Locking and access-management is exactly the same as before with an
additional lock inside of the vma-manager, which strictly wouldn't be
needed for gem.
v2:
- rebase on drm-next
- init nodes via drm_vma_node_reset() in drm_gem.c
v3:
- fix tegra
v4:
- remove duplicate if (drm_vma_node_has_offset()) checks
- inline now trivial drm_vma_node_offset_addr() calls
v5:
- skip node-reset on gem-init due to kzalloc()
- do not allow mapping gem-objects with offsets (backwards compat)
- remove unneccessary casts
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
If we want to map GPU memory into user-space, we need to linearize the
addresses to not confuse mm-core. Currently, GEM and TTM both implement
their own offset-managers to assign a pgoff to each object for user-space
CPU access. GEM uses a hash-table, TTM uses an rbtree.
This patch provides a unified implementation that can be used to replace
both. TTM allows partial mmaps with a given offset, so we cannot use
hashtables as the start address may not be known at mmap time. Hence, we
use the rbtree-implementation of TTM.
We could easily update drm_mm to use an rbtree instead of a linked list
for it's object list and thus drop the rbtree from the vma-manager.
However, this would slow down drm_mm object allocation for all other
use-cases (rbtree insertion) and add another 4-8 bytes to each mm node.
Hence, use the separate tree but allow for later migration.
This is a rewrite of the 2012-proposal by David Airlie <airlied@linux.ie>
v2:
- fix Docbook integration
- drop drm_mm_node_linked() and use drm_mm_node_allocated()
- remove unjustified likely/unlikely usage (but keep for rbtree paths)
- remove BUG_ON() as drm_mm already does that
- clarify page-based vs. byte-based addresses
- use drm_vma_node_reset() for initialization, too
v4:
- allow external locking via drm_vma_offset_un/lock_lookup()
- add locked lookup helper drm_vma_offset_lookup_locked()
v5:
- fix drm_vma_offset_lookup() to correctly validate range-mismatches
(fix (offset > start + pages))
- fix drm_vma_offset_exact_lookup() to actually do what it says
- remove redundant vm_pages member (add drm_vma_node_size() helper)
- remove unneeded goto
- fix documentation
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
All users of it are now gone!
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
It's unused, everyone is using the _unlocked variant only.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.
Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to keep it
around. This simplifies code paths in drivers, too.
Last but not least, fix gma500 to call drm_gem_object_release() before
freeing objects that were allocated via drm_gem_private_object_init().
That isn't actually necessary for now, but might be in the future.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Only ever re-cleared in drm_setup, otherwise completely unused.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
There's no other caller from driver code, so we can fold this in.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Only ever assigned in the context code for real, with no readers
anywhere. Remove it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
No one ever waits on this waitqueue, so the wake_up call is wasted.
Remove it all.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Highlights:
- follow-up refactoring after the shared dpll rework that landed in 3.11
- oddball prep cleanups from Ben for ppgtt
- encoder->get_config state tracking infrastructure from Jesse
- used by the experimental fastboot support from Jesse (disabled by
default)
- make the error state file official and add it to our sysfs interface
(Mika)
- drm_mm prep changes from Ben, prepares to embedd the drm_mm_node (which
will be used by the vma rework later on)
- interrupt handling rework, follow up cleanups to the VECS enabling, hpd
storm handling and fifo underrun reporting.
- Big pile of smaller cleanups, code improvements and related stuff.
* tag 'drm-intel-next-2013-07-12' of git://people.freedesktop.org/~danvet/drm-intel: (72 commits)
drm/i915: clear DPLL reg when disabling i9xx dplls
drm/i915: Fix up cpt pixel multiplier enable sequence
drm/i915: clean up vlv ->pre_pll_enable and pll enable sequence
drm/i915: move error state to own compilation unit
drm/i915: Don't attempt to read an unitialized stack value
drm/i915: Use for_each_pipe() when possible
drm/i915: don't enable PM_VEBOX_CS_ERROR_INTERRUPT
drm/i915: unify ring irq refcounts (again)
drm/i915: kill dev_priv->rps.lock
drm/i915: queue work outside spinlock in hsw_pm_irq_handler
drm/i915: streamline hsw_pm_irq_handler
drm/i915: irq handlers don't need interrupt-safe spinlocks
drm/i915: kill lpt pch transcoder->crtc mapping code for fifo underruns
drm/i915: improve GEN7_ERR_INT clearing for fifo underrun reporting
drm/i915: improve SERR_INT clearing for fifo underrun reporting
drm/i915: extract ibx_display_interrupt_update
drm/i915: remove unused members from drm_i915_private
drm/i915: don't frob mm.suspended when not using ums
drm/i915: Fix VLV DP RBR/HDMI/DAC PLL LPF coefficients
drm/i915: WARN if the bios reserved range is bigger than stolen size
...
Conflicts:
drivers/gpu/drm/i915/i915_gem.c
SDP header and SDP VSC header as per eDP 1.3 spec, section 3.5,
chapter "PSR Secondary Data Package Support".
v2: Modified and corrected the structures to be more in line for
kernel coding guidelines and rebased the code on Paulo's DP patchset
v3: removing unecessary identation at DP_RECEIVER_CAP_SIZE
v4: moving them to include/drm/drm_dp_helper.h and also already
icluding EDP_PSR_RECEIVER_CAP_SIZE to add everything needed
for PSR at once at drm_dp_helper.h
v5: Fix SDP VSC header and identation by (Paulo Zanoni) and
remove i915 from title (Daniel Vetter)
v6: Fix spec version and move comments from code to commit message
since numbers might change in the future (by Paulo Zanoni).
CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Sateesh Kavuri <sateesh.kavuri@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the previous patch we no longer actually create a node, we simply
find the correct hole and occupy it. This very well could have been
squashed with the last patch, but since I already had David's review, I
figured it's easiest to keep it distinct.
Also update the users in i915. Conveniently this is the only user of the
interface.
CC: David Airlie <airlied@linux.ie>
CC: <dri-devel@lists.freedesktop.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: David Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
will break a bunch of code, but amongst them are 2 callers of
drm_mm_create_block(), both related to stolen memory.
It also allows us to embed the drm_mm_node into the object currently
which provides a nice transition over to the new code.
v2: Reordered to do before ripping out obj->gtt_offset.
Some minor cleanups made available because of reordering.
v3: s/continue/break on failed stolen node allocation (David)
Set obj->gtt_space on failed node allocation (David)
Only unref stolen (fix double free) on failed create_stolen (David)
Free node, and NULL it in failed create_stolen (David)
Add back accidentally removed newline (David)
CC: <dri-devel@lists.freedesktop.org>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Acked-by: David Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can use prime helpers instead.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead of using the dma_buf functionality for GEM CMA, we can use prime
helpers if we can provide low-level hook functions for GEM CMA.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds to call low-level mmap() from prime helpers.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/i915 is the only user of the color allocation handling and
switched to insert_node a while ago. So we can ditch this.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There is no reason to return "int" as this function never fails.
Furthermore, several drivers (ast, sis) already depend on this.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 160954b7bc.
This was rearming the workqueue with a 0 timeout, causing
a WARN_ON, and possible loop.
Daniel writes:
"I've looked a bit into this and I think we need to have a separate
work struct for recovering these lost hotplug events since the
continuous self-rearming case is a real risk (e.g. if a connector
flip-flops all the time). At least I don't see a sane way to block out
re-arming with the current code in a simple way. So reverting the
offender seems like the right thing and I'll go back to the drawing
board for 3.12."
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that the code is compatible in semantics, flip the switch.
Use ww_mutex instead of the homegrown implementation.
ww_mutex uses -EDEADLK to signal that the caller has to back off,
and -EALREADY to indicate this buffer is already held by the caller.
ttm used -EAGAIN and -EDEADLK for those, respectively. So some changes
were needed to handle this correctly.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit converts the source of the val_seq counter to
the ww_mutex api. The reservation objects are converted later,
because there is still a lockdep splat in nouveau that has to
resolved first.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the pull request for radeon for 3.11. Highlights include:
- Support for CIK (Sea Islands) asics: 3D, compute, UVD
- DPM (Dynamic Power Management) support for 6xx-SI
- ASPM support for 6xx-SI
- Assorted bug fixes
* 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux: (168 commits)
drm/radeon/SI: fix TDP adjustment in set_power_state
drm/radeon/NI: fix TDP adjustment in set_power_state
drm/radeon: fix endian issues in atombios dpm code
drm/radeon/dpm: fix UVD clock setting on SI
drm/radeon/dpm: fix UVD clock setting on cayman
drm/radeon/dpm: add support for setting UVD clock on rv6xx
drm/radeon/dpm: add support for setting UVD clock on rs780
drm/radeon: fix typo in ni_print_power_state
drm/radeon: fix typo in cik_select_se_sh()
drm/radeon/si: fix typo in function name
drm/radeon/dpm: fix typo in setting uvd clock
drm/radeon/dpm: add dpm_set_power_state failure output (si)
add dpm_set_power_state failure output (7xx-ni)
drm/radeon/dpm: add dpm_set_power_state failure output (7xx-ni)
drm/radeon/dpm: add dpm_enable failure output (si)
drm/radeon/dpm: add dpm_enable failure output (7xx-ni)
drm/radeon/kms: add dpm support for SI (v7)
drm/radeon: switch SI to use radeon_ucode.h
drm/radeon: add SI to r600_is_internal_thermal_sensor()
drm/radeon/dpm/rs780: properly catch errors in dpm setup
...
Last 3.11 feature pull. I have a few odds bits and pieces and fixes in my
queue, I'll sort them out later on to see what's for 3.11-fixes and what's
for 3.12. But nothing to hold this here up imo.
Highlights:
- more hangcheck work from Mika and Chris to prepare for arb robustness
- trickle feed fixes from Ville
- first parts of the shared pch pll rework, with some basic hw state
readout and cross-checking (this shuts up the confused pch pll refcount
WARN that Linus just recently forwarded)
- Haswell audio power well support from Wang Xingchao (alsa bits acked by
Takashi)
- some cleanups and asserts sprinkling around the plane/gamma enabling
sequence from Ville
- more gtt refactoring from Ben
- clear up the adjusted->mode vs. pixel clock vs. port clock confusion
- 30bpp support, this time for real hopefully
* tag 'drm-intel-next-2013-06-18' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits)
drm/i915: remove a superflous semi-colon
drm/i915: Kill useless "Enable panel fitter" comments
drm/i915: Remove extra "ring" from error message
drm/i915: simplify the reduced clock handling for pch plls
drm/i915: stop killing pfit on i9xx
drm/i915: explicitly set up PIPECONF (and gamma table) on haswell
drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
drm/i915: set up PIPECONF explicitly on ilk-ivb
drm/i915: find guilty batch buffer on ring resets
drm/i915: store ring hangcheck action
drm/i915: add batch bo to i915_add_request()
drm/i915: change i915_add_request to macro
drm/i915: add i915_gem_context_get_hang_stats()
drm/i915: add struct i915_ctx_hang_stats
drm/i915: Try harder to disable trickle feed on VLV
drm/i915: fix up pch pll enabling for pixel multipliers
drm/i915: hw state readout and cross-checking for shared dplls
drm/i915: WARN on lack of shared dpll
drm/i915: split up intel_modeset_check_state
drm/i915: extract readout_hw_state from setup_hw_state
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_fb.c
drivers/gpu/drm/i915/intel_sdvo.c
Required for certain driver calculations. Code
was written by Christian König and ported to the
drm by me.
v2: fix 64 bit divides
v3: fix 64 bit for real (math64.h)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
So it looks like for virtual hw cursors on QXL we need to inform
the "hw" device what the cursor hotspot parameters are. This
makes sense if you think the host has to draw the cursor and interpret
clicks from it. However the current modesetting interface doesn't support
passing the hotspot information from userspace.
This implements a new cursor ioctl, that takes the hotspot info as well,
userspace can try calling the new interface and if it gets -ENOSYS it means
its on an older kernel and can just fallback.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).
To avoid this, check whether the connector state changes in all other
->detect calls (in the current helper code that's only probe_single)
and if that's the case, fire off a hotplug event. Note that we can't
directly call the hotplug event handler, since that expects that no
locks are held (due to reentrancy with the fb code to update the kms
console).
Also, this requires that drivers using the probe_single helper
function set up the poll work. All current drivers do that already,
and with the reworked hpd handling there'll be no downside to
unconditionally setting up the poll work any more.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Drivers are allowed (actually have to) disable unrelated crtcs in
their ->set_config callback (when we steal all the connectors from
that crtc). If they do that they'll clear crtc->fb to NULL.
Which results in a refcount leak, since the drm core is keeping track
of that reference.
To fix this track the old fb of all crtcs and adjust references for
all of them. Of course, since we only hold an additional reference for
the fb for the current crtc we need to increase refcounts before we
drop the old one.
This approach has the benefit that it inches us a bit closer to an
atomic modeset world, where we want to update the config of all crtcs
in one step.
This regression has been introduce in the framebuffer refcount
conversion, specifically in
commit b0d1232589
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Dec 11 01:07:12 2012 +0100
drm: refcounting for crtc framebuffers
Reported-by: Russell King <linux@arm.linux.org.uk>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly. Eliminate them.
v2: Remove all of it from kernel-doc too
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm_plane_force_disable() will forcibly disable the plane even if user
had previously requested the plane to be enabled.
This can be used to force planes to be off when restoring the fbdev
mode.
The code was simply pulled from drm_framebuffer_remove(), which now
calls the new function as well.
v2: Check plane->fb in drm_plane_force_disable(), drop bogus comment
about disabling crtc
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Daniel writes:
Another round of drm-intel-next for 3.11. Highlights:
- Haswell IPS support (Paulo Zanoni)
- VECS support on Haswell (Ben Widawsky, Xiang Haihao, ...)
- Haswell watermark fixes (Paulo Zanoni)
- "Make the gun bigger again" multithread fence fix from Chris.
- i915_error_state finnally no longer fails with -ENOMEM! Big thanks to
Mika for tackling this.
- vlv sideband locking fixes from Jani
- Hangcheck prep work for arb_robustness support (Mika&Chris)
- edp vs cpu port confusion clean-up from Imre
- pile of smaller fixes and cleanups all over.
* tag 'drm-intel-next-2013-06-01' of git://people.freedesktop.org/~danvet/drm-intel: (70 commits)
drm/i915: add i915_ips_status debugfs entry
drm/i915: add enable_ips module option
drm/i915: implement IPS feature
drm/i915: fix up the edp power well check
drm/i915: add I915_PARAM_HAS_VEBOX to i915_getparam
drm/i915: add I915_EXEC_VEBOX to i915_gem_do_execbuffer()
drm/i915: add VEBOX into debugfs
drm/i915: Enable vebox interrupts
drm/i915: vebox interrupt get/put
drm/i915: consolidate interrupt naming scheme
drm/i915: Convert irq_refounct to struct
drm/i915: make PM interrupt writes non-destructive
drm/i915: Add PM regs to pre/post install
drm/i915: Create an ivybridge_irq_preinstall
drm/i915: Create a more generic pm handler for hsw+
drm/i915: add support for 5/6 data buffer partitioning on Haswell
drm/i915: properly set HSW WM_LP watermarks
drm/i915: properly set HSW WM_PIPE registers
drm/i915: fix pch_nop support
drm/i915: Vebox ringbuffer init
...
GEM CMA PRIME support from Laurent.
* 'drm/next' of git://linuxtv.org/pinchartl/fbdev:
drm: GEM CMA: Add DRM PRIME support
drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping
drm: GEM CMA: Split object creation into object alloc and DMA memory alloc
drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap
drm/gem: Split drm_gem_mmap() into object search and object mapping
The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
drm_connector_enum_list which does get modified in drm_connector_init().
While at it move the drm_get_connector_status_name() prototype from
drmP.h to drm_crtc.h where it belongs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() produces:
DRM_FORMAT_XRGB8888: "XR24 little-endian (0x34325258)"
DRM_FORMAT_YUYV: "YUYV little-endian (0x56595559)"
DRM_FORMAT_RGB565|DRM_FORMAT_BIG_ENDIAN: "RG16 big-endian (0xb6314752)"
Unprintable characters: "D??? big-endian (0xff7f0244)"
v2: Fix patch author
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Prevents buffers from being pinned forever.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The drm_gem_mmap() function first finds the GEM object to be mapped
based on the fake mmap offset and then maps the object. Split the object
mapping code into a standalone drm_gem_mmap_obj() function that can be
used to implement dma-buf mmap() operations.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao <xingchao.wang@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are no users left in drivers/gpu.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel writes:
Highlights (copy-pasted from my testing cycle mails):
- fbc support for Haswell (Rodrigo)
- streamlined workaround comments, including an igt tool to grep for
them (Damien)
- sdvo and TV out cleanups, including a fixup for sdvo multifunction devices
- refactor our eDP mess a bit (Imre)
- don't register the hdmi connector on haswell when desktop eDP is present
- vlv support is no longer preliminary!
- more vlv fixes from Jesse for stolen and dpll handling
- more flexible power well checking infrastructure from Paulo
- a few gtt patches from Ben
- a bit of OCD cleanups for transcoder #defines and an assorted pile
of smaller things.
- fixes for the gmch modeset sequence
- a bit of OCD around plane/pipe usage (Ville)
- vlv turbo support (Jesse)
- tons of vlv modeset fixes (Jesse et al.)
- vlv pte write fixes (Kenneth Graunke)
- hpd filtering to avoid costly probes on unaffected outputs (Egbert Eich)
- intel dev_info cleanups and refactorings (Damien)
- vlv rc6 support (Jesse)
- random pile of fixes around non-24bpp modes handling
- asle/opregion cleanups and locking fixes (Jani)
- dp dpll refactoring
- improvements for reduced_clock computation on g4x/ilk+
- pfit state refactored to use pipe_config (Jesse)
- lots more computed modeset state moved to pipe_config, including readout
and cross-check support
- fdi auto-dithering for ivb B/C links, using the neat pipe_config
improvements
- drm_rect helpers plus sprite clipping fixes (Ville)
- hw context refcounting (Mika + Ben)
* tag 'drm-intel-next-2013-05-20-merged' of git://people.freedesktop.org/~danvet/drm-intel: (155 commits)
drm/i915: add support for dvo Chrontel 7010B
drm/i915: Use pipe config state to control gmch pfit enable/disable
drm/i915: Use pipe_config state to disable ilk+ pfit
drm/i915: panel fitter hw state readout&check support
drm/i915: implement WADPOClockGatingDisable for LPT
drm/i915: Add missing platform tags to FBC workaround comments
drm/i915: rip out an unused lvds_reg variable
drm/i915: Compute WR PLL dividers dynamically
drm/i915: HSW FBC WaFbcDisableDpfcClockGating
drm/i915: HSW FBC WaFbcAsynchFlipDisableFbcQueue
drm/i915: Enable FBC at Haswell.
drm/i915: IVB FBC WaFbcDisableDpfcClockGating
drm/i915: IVB FBC WaFbcAsynchFlipDisableFbcQueue
drm/i915: Add support for FBC on Ivybridge.
drm/i915: Organize VBT stuff inside drm_i915_private
drm/i915: make SDVO TV-out work for multifunction devices
drm/i915: rip out now unused is_foo tracking from crtc code
drm/i915: rip out TV-out lore ...
drm/i915: drop TVclock special casing on ilk+
drm/i915: move sdvo TV clock computation to intel_sdvo.c
...
The 'struct' keyword was missing so struct drm_rect documentation never
ended up in the generated docs.
Also move the drm_rect documentations to a new section alognside the
various helper functions and add a short description about the intended
purpose of drm_rect.
v2: Move to new section and add general description
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull radeon sun/hainan support from Dave Airlie:
"Since I know its outside the merge window, but since this is new hw I
thought I'd try and provoke the new hw exception, it just fills in the
blanks in the driver for the new AMD sun and hainan chipsets."
* 'drm-radeon-sun-hainan' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: add Hainan pci ids
drm/radeon: add golden register settings for Hainan (v2)
drm/radeon: sun/hainan chips do not have UVD (v2)
drm/radeon: track which asics have UVD
drm/radeon: radeon-asic updates for Hainan
drm/radeon: fill in ucode loading support for Hainan
drm/radeon: don't touch DCE or VGA regs on Hainan (v3)
drm/radeon: fill in GPU init for Hainan (v2)
drm/radeon: add chip family for Hainan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRmpexAAoJEHm+PkMAQRiGrRIH/1uWFW38RvaCV/PXm/ia6Z+x
BfBJfBIvPxGwb4n7aQNQlhU25xkfrPZ6szO4WiBH5/KPH3xYi2I2OZ1AzffkYqMF
BWkPmsPK6EsTdp16zsi6JtH2aXArG4SpYA7ZamPvDkmfigHuiZg7GlL/9eHTRPNV
P7Q8JToOrcnP8RoGgNj0uFiQeQbc62Kmoq7WuPtUhVlpQCCCknXgOJiYgz9w6Xe9
/i79YFS8WRrzAquExT1NbIOh4ZMqB9MvuroaVWy8JDDLUyz7QUvOCe3tCDNguwgi
FdWvU6nfkdQq5SLaWCWXDE9Rp/pL1MvfBn9vCOwFcp42aw0aQ0PgJVIXvsqufd0=
=jgDI
-----END PGP SIGNATURE-----
Merge tag 'v3.10-rc2' into drm-intel-next-queued
Backmerge Linux 3.10-rc2 since the various (rather trivial) conflicts
grew a bit out of hand. intel_dp.c has the only real functional
conflict since the logic changed while dev_priv->edp.bpp was moved
around.
Also squash in a whitespace fixup from Ben Widawsky for
i915_gem_gtt.c, git seems to do something pretty strange in there
(which I don't fully understand tbh).
Conflicts:
drivers/gpu/drm/i915/i915_reg.h
drivers/gpu/drm/i915/intel_dp.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull drm fixes from Dave Airlie:
"Fix for radeon nomodeset regression, old radeon interface cliprects
fix, 2 qxl crasher fixes, and a couple of minor cleanups.
I may have a new AMD hw support branch next week, its one of those
doesn't affect anything existing just adds new support, I'll see how
it shapes up and I might ask you to take it, just thought I'd warn in
advance."
* 'drm-next' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: restore nomodeset operation (v2)
qxl: fix bug with object eviction and update area
drm/qxl: drop active_user_framebuffer as its unneeded
qxl: drop unused variable.
drm/qxl: fix ioport interactions for kernel submitted commands.
drm: remove unused wrapper macros
drm/radeon: check incoming cliprects pointer
Pull drm fixes from Dave Airlie:
"Just a few straggling fixes I hoovered up, and an intel fixes pull
from Daniel which fixes some regressions, and some mgag200 fixes from
Matrox."
* 'drm-next' of git://people.freedesktop.org/~airlied/linux:
drm/mgag200: Fix framebuffer base address programming
drm/mgag200: Convert counter delays to jiffies
drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
drm/mgag200: Don't change unrelated registers during modeset
drm: Only print a debug message when the polled connector has changed
drm: Make the HPD status updates debug logs more readable
drm: Use names of ioctls in debug traces
drm: Remove pointless '-' characters from drm_fb_helper documentation
drm: Add kernel-doc for drm_fb_helper_funcs->initial_config
drm: refactor call to request_module
drm: Don't prune modes loudly when a connector is disconnected
drm: Add missing break in the command line mode parsing code
drm/i915: clear the stolen fb before resuming
Revert "drm/i915: Calculate correct stolen size for GEN7+"
drm/i915: hsw: fix link training for eDP on port-A
Revert "drm/i915: revert eDP bpp clamping code changes"
drm: don't check modeset locks in panic handler
drm/i915: Fix pipe enabled mask for pipe C in WM calculations
drm/mm: fix dump table BUG
drm/i915: Always normalize return timeout for wait_timeout_ioctl
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc01c64ae, nr=0xae, dev 0xe200, auth=1
[drm:drm_mode_addfb], [FB:32]
[drm:drm_ioctl], pid=699, cmd=0xc0106464, nr=0x64, dev 0xe200, auth=1
[drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a00000
[drm:drm_ioctl], pid=699, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc00464af, nr=0xaf, dev 0xe200, auth=1
[drm:intel_crtc_set_config], [CRTC:3] [NOFB]
into:
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_THROTTLE
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_CREATE
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_TILING
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, IOCTL_MODE_ADDFB
[drm:drm_mode_addfb], [FB:32]
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_MMAP_GTT
[drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a00000
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_DOMAIN
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
[drm:intel_crtc_set_config], [CRTC:3] [NOFB]
v2: drm_ioctls is now a constant (Ville Syrjälä)
Signed-off-by: Chris Cummins <christopher.e.cummins@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull drm updates from Dave Airlie:
"This is the main drm pull request for 3.10.
Wierd bits:
- OMAP drm changes required OMAP dss changes, in drivers/video, so I
took them in here.
- one more fbcon fix for font handover
- VT switch avoidance in pm code
- scatterlist helpers for gpu drivers - have acks from akpm
Highlights:
- qxl kms driver - driver for the spice qxl virtual GPU
Nouveau:
- fermi/kepler VRAM compression
- GK110/nvf0 modesetting support.
Tegra:
- host1x core merged with 2D engine support
i915:
- vt switchless resume
- more valleyview support
- vblank fixes
- modesetting pipe config rework
radeon:
- UVD engine support
- SI chip tiling support
- GPU registers initialisation from golden values.
exynos:
- device tree changes
- fimc block support
Otherwise:
- bunches of fixes all over the place."
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (513 commits)
qxl: update to new idr interfaces.
drm/nouveau: fix build with nv50->nvc0
drm/radeon: fix handling of v6 power tables
drm/radeon: clarify family checks in pm table parsing
drm/radeon: consolidate UVD clock programming
drm/radeon: fix UPLL_REF_DIV_MASK definition
radeon: add bo tracking debugfs
drm/radeon: add new richland pci ids
drm/radeon: add some new SI PCI ids
drm/radeon: fix scratch reg handling for UVD fence
drm/radeon: allocate SA bo in the requested domain
drm/radeon: fix possible segfault when parsing pm tables
drm/radeon: fix endian bugs in atom_allocate_fb_scratch()
OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found
OMAPDSS: VENC: Add error handling for venc_probe_pdata
OMAPDSS: HDMI: Add error handling for hdmi_probe_pdata
OMAPDSS: RFBI: Add error handling for rfbi_probe_pdata
OMAPDSS: DSI: Add error handling for dsi_probe_pdata
OMAPDSS: SDI: Add error handling for sdi_probe_pdata
OMAPDSS: DPI: Add error handling for dpi_probe_pdata
...
Use minor->index to label things, not the name field from the proc_dir_entry
of the /proc/dwm/<minor>/ directory.
Also, use "%u" not "%d" to render the value and use a 12-byte buffer in which
to render the integer, not a 16-byte buffer. The longest string an unsigned
int can give you is 10 chars (4294967295) plus a NUL, so round up to 12 as the
stack is likely to be 4- or 8-byte aligned.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: dri-devel@lists.freedesktop.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Constify drm_proc_list[] and related pointers.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: dri-devel@lists.freedesktop.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object
i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close. The reference gets added at step 2,
but at step 6 we don't have enough info to clean it up.
The solution is to take a reference on the dma-buf when we export it,
and drop the reference when the gem handle goes away.
So when we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the reference to the dma_buf, and it gets collected.
This patch isn't meant to fix any other problem or bikesheds, and it doesn't
fix any races with other scenarios.
v1.1: move export symbol line back up.
v2: okay I had to do a bit more, as the first patch showed a leak
on one of my tests, that I found using the dma-buf debugfs support,
the problem case is exporting a buffer twice with the same handle,
we'd add another export handle for it unnecessarily, however
we now fail if we try to export the same object with a different gem handle,
however I'm not sure if that is a case I want to support, and I've
gotten the code to WARN_ON if we hit something like that.
v2.1: rebase this patch, write better commit msg.
v3: cleanup error handling, track import vs export in linked list,
these two patches were separate previously, but seem to work better
like this.
v4: danvet is correct, this code is no longer useful, since the buffer
better exist, so remove it.
v5: always take a reference to the dma buf object, import or export.
(Imre Deak contributed this originally)
v6: square the circle, remove import vs export tracking now
that there is no difference
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_rect_equals() tells whether two drm_rects are equal.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a debug function to print the rectangle in a human readable format.
v2: Renamed drm_region to drm_rect, the function from drm_region_debug
to drm_rect_debug_print(), and use %+d instead of +%d in the format.
v3: Use %d format for width/height in the non fixed point case as well
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions calculate the scaling factor based on the source and
destination rectangles.
There are two version of the functions, the strict ones that will
return an error if the min/max scaling factor is exceeded, and the
relaxed versions that will adjust the src/dst rectangles in order to
keep the scaling factor withing the limits.
v2: Return error instead of adjusting regions, refactor common parts
into one function, and split into strict and relaxed versions.
v3: Renamed drm_region to drm_rect, add "_rect_" to the function
names.
v4: Fix "calculcate" typos
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
struct drm_rect represents a simple rectangle. The utility
functions are there to help driver writers.
v2: Moved the region stuff into its own file, made the smaller funcs
static inline, used 64bit maths in the scaled clipping function to
avoid overflows (instead it will saturate to INT_MIN or INT_MAX).
v3: Renamed drm_region to drm_rect, drm_region_clip to
drm_rect_intersect, and drm_region_subsample to drm_rect_downscale.
v4: Renamed some function parameters, improve kernel-doc comments a bit,
and actually generate documentation for drm_rect.[ch].
v5: s/RETUTRNS/RETURNS/
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no way to use modes added to the user_modes list. We never
look at the contents of said list in the kernel, and the only operations
userspace can do are attach and detach. So the only "benefit" of this
interface is wasting kernel memory.
Fortunately it seems no real user space application ever used these
ioctls. So just kill them.
Also remove the prototypes for the non-existing drm_mode_addmode_ioctl()
and drm_mode_rmmode_ioctl() functions.
v2: Use drm_noop instead of completely removing the ioctls
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drivers/gpu/drm/drm_pci.c:155:5: warning: symbol 'drm_pci_set_busid' was not declared. Should it be static?
drivers/gpu/drm/drm_pci.c:197:5: warning: symbol 'drm_pci_set_unique' was not declared. Should it be static?
drivers/gpu/drm/drm_pci.c:269:5: warning: symbol 'drm_pci_agp_init' was not declared. Should it be static?
drivers/gpu/drm/drm_crtc.c:181:1: warning: symbol 'drm_get_dirty_info_name' was not declared. Should it be static?
drivers/gpu/drm/drm_crtc.c:1123:5: warning: symbol 'drm_mode_group_init' was not declared. Should it be static?
drivers/gpu/drm/drm_modes.c:918:6: warning: symbol 'drm_mode_validate_clocks' was not declared. Should it be static?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't
compare the clock or vrefresh values. drm_mode_equal() is now
implemented by first doing the clock checks, and then calling
drm_mode_equal_no_clocks().
v2: Add missing EXPORT_SYMBOL()
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No need to zero initialize .vrefresh in DRM_MODE() since it's using
desgignated initializers.
This will also avoid some duplicate initialization warnings later.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some devices (ATI/AMD cards) don't support passing ELD struct to the
hardware but just require filling specific registers and then the
hardware/firmware does the rest. In such cases we need to read the info
from SAD blocks and put them in the correct registers.
agd5f: note that the returned pointer needs to be kfreed as per
Christian's suggestion.
v2: fix warning
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Daniel writes:
Since I expect Linus to open the merge window in about a week I guess this
is the last i915 feature pull for 3.10. Highlights:
Updated testing tree for -next. Highlights:
- Corner case fixes discovered with static analyzers (Damien).
- More fixes to combat unclaimed register errors on Haswell (Paulo).
- Some small fixes to the gpu turbo code (Rodrigo+Ben), Ben has more
fixes for overclocking support pending.
- More prep work for fastboot from Chris.
- VT-switchless suspend/resume from Jesse.
- The prep work of Egbert Eich's hpd irq storm handling. Hopefully we can
squeeze in the actual storm handling code for 3.10 ...
- More convenience helpers for Imre's sg iterator. Core parts acked by
Andrew Morton.
- A bit of backlight code cleanup from Jani.
- Fixed ilk gpu reset (Jesse).
- Reduced color range handling fixes for VLV (Ville).
The big item here is though the introduction of pipe_config to properly
pre-compute the desired modeset state before touching the hw. Together
with some very basic support to read out the current config from the hw
and compare the state with the sw tracking. This is all prep work for more
reliable fastboot, atomic modesets and other cool features. Stuff
converted to the new world includes:
- Most simple pipe attributes (reduce color range, pixel multiplier).
- Pipe bpp/dither handling.
- Some convenience flags like ->has_pch_encoder to simplify the code flow.
- (Almost) DP clock handling, had to be reverted since part of a prep
patch was lost in rebasing ...
Expect a lot of patches for this throughout 3.11, there's tons of work
till we have all state properly tracked for fastbooting to woExpect a lot
of patches for this throughout 3.11, there's tons of work till we have all
state properly tracked for fastbooting to work.
For 3.10 I have a bunch of fixes queued up and I plan to send them all out
at the end of this week. I need to shuffle patches in my -next queue a bit
so that we don't but feature-y stuff in there, too. The main thing I'd
like to sneak in is Egbert's hpd irq storm handling, which should be
pretty low-risk since all the infrastructure work has landed already. I
also have the oops fix pending, but that only mustered review before the
w/e and giving how hairy that part of our modeset code is, I want to give
it some more testing before forwarding.
Note: annarchy.fd.o seems to run out of disk space, so couldn't push the
usual for-airlied branch. Tag should work though.
Note 2: I've had to do a backmerge since conflicts grew too ugly, but the
upstream -rc I've backmerged is already in your drm-next.
* tag 'drm-intel-next-2013-04-06' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits)
drm/i915: info level for simulated gpu hang dmesg notice
drm/i915: revert eDP bpp clamping code changes
Revert "drm/i915: fix DP get_hw_state return value"
drm/i915: Don't use the HDMI port color range bit on Valleyview
drm/i915: Set PIPECONF color range bit on Valleyview
drm/i915: extract i9xx_set_pipeconf
drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900
drm/i915: create pipe_config->dpll for clock state
drm/i915: hw readout support for ->has_pch_encoders
drm/i915: add hw state readout/checking for pipe_config
drm/i915: rip out superflous is_dp&is_cpu_edp tracking
drm/i915: remove leaky eDP functions
drm/i915: track dp target_clock in pipe_config
drm/i915: move dp_m_n computation to dp_encoder->compute_config
drm/i915: clear up the fdi/dp set_m_n confusion
drm/i915: Fix sdvo connector get_hw_state function
drm/i915: drop DPFLIPSTAT enables on VLV v3
drm/i915: add Punit read/write routines for VLV v2
drm/i915: panel power sequencing for VLV eDP v2
drm/i915/dp: fix up VLV DP handling v2
...
qxl wants to use io mapping like i915 gem does, for now
just export the symbols so the driver can implement atomic
page maps using io mapping.
Signed-off-by: Dave Airlie <airlied@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRWLTrAAoJEHm+PkMAQRiGe8oH/iMy48mecVWvxVZn74Tx3Cef
xmW/PnAIj28EhSPqK49N/Ow6AfQToFKf7AP0ge20KAf5teTq95AY+tH74DAANt8F
BjKXXTZiR5xwBvRkq7CR5wDcCvEcBAAz8fgTEd6SEDB2d2VXFf5eKdKUqt1avTCh
Z6Hup5kuwX+ddtwY2DCBXtp2n6fL0Rm5yLzY1A3OOBye1E7VyLTF7M5BR603Q44P
4kRLxn8+R7jy3hTuZIhAeoS8TKUoBwVk7DmKxEzrhTHZVOmvwE9lEHybRnIyOpd/
k1JnbRbiPsLsCVFOn10SQkGDAIk00lro3tuWP2C1ljERiD/OOh5Ui9nXYAhMkbI=
=q15K
-----END PGP SIGNATURE-----
Merge tag 'v3.9-rc5' into drm-intel-next-queued
Backmerge Linux 3.9-rc5 since I want to merge a few dp clock cleanups
for -next, but they will conflict all over the place with
commit 9d1a455b0c
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Mar 18 11:25:36 2013 +0100
drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()
from -fixes.
Conflicts:
drivers/gpu/drm/i915/intel_dp.c: Simply adjacent lines changed.
drivers/gpu/drm/i915/intel_panel.c: A field rename in -next
conflicts with a bugfix in -fixes. Take the version from
-fixes and apply the rename.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than building a config which may or may not work, let the driver
build an initial fb config. This allows the driver to use the BIOS boot
configuration for example, displaying kernel messages and the initial fb
console on the same outputs the BIOS lit up at boot time. If that
fails, the driver can still fall back the same way as the core.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a generic helper to fill in an HDMI AVI infoframe with data
extracted from a DRM display mode.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The drm_file and drm_clip_rect structures are used throughout the file
but they are never declared nor pulled in through an include. Add
forward declarations to make them available.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The same function had already been merged with a different name. Remove
the duplicate one but reuse some of its kerneldoc fragments for the
existing implementation.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
So here's my promised pile of fixes for 3.9. I've dropped the core prep
patches for vt-switchless suspend/resume as discussed on irc. Highlights:
- Fix dmar on g4x. Not really gfx related, but I'm fed up with getting
blamed for dmar crapouts.
- Disable wc ptes updates on ilk when dmar is enabled (Chris). So again,
dmar, but this time gfx related :(
- Reduced range support for hsw, using the pipe CSC (Ville).
- Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is
already confirmed to fix 2 bug reports, so added cc: stable on that one.
- Regression fix for 8bit fb console (Ville).
- Preserve lane reversal bits on DDI/FDI ports (Damien).
- Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of
them, need to decide what to do with the currently still in-flight ones.
- Panel fitter regression fix from Mika Kuoppala (was accidentally left on
on some pipes with the new modset code since 3.7). This also improves
the modeset sequence and might help a few other unrelated issues with
lvds.
- Write backlight regs even harder ... another installement in our eternal
fight against the BIOS and backlights.
- Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for
new ACPI stuff, but closing the race itself seems worthwile on its own.
- A few other small fixes and tiny cleanups all over.
Lots of the patches are cc: stable since I've stalled on a few
not-so-important fixes for 3.8 due to the grumpy noise Linus made.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits)
intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
drm/i915: Implement pipe CSC based limited range RGB output
drm/i915: inverted brightness quirk for Acer Aspire 4736Z
drm/i915: Print the hw context status is debugfs
drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap
drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+
drm/i915: Set i9xx sdvo clock limits according to specifications
drm/i915: Set i9xx lvds clock limits according to specifications
drm/i915: Preserve the DDI link reversal configuration
drm/i915: Preserve the FDI line reversal override bit on CPT
drm/i915: add missing \n to UTS_RELEASE in the error_state
drm: Use C8 instead of RGB332 when determining the format from depth/bpp
drm: Fill depth/bits_per_pixel for C8 format
drm/i915: don't clflush gem objects in stolen memory
drm/i915: Don't wait for page flips if there was GPU reset
drm/i915: Kill obj->pending_flip
drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment
drm/i915: remove bogus mutex_unlock from error-path
drm/i915: Print the pipe control page GTT address
...
Simplify life for drivers using an encoder-slave, so that they can make
their drm_encoder_helper_funcs const, rather than needing to dynamically
allocate and populate them.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add helper to display fb's which can be used directly in drm_info_list:
static struct drm_info_list foo_debugfs_list[] = {
...
{ "fb", drm_fb_cma_debugfs_show, 0 },
};
to display information about CMA fb objects, as well as a
drm_gem_cma_describe() which can be used if the driver bothers to keep
a list of CMA GEM objects.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Dave Airlie