- 01 9月, 2014 1 次提交
-
-
由 Maarten Lankhorst 提交于
No users are left, kill it off! :D Conversion to the reservation api is next on the list, after that the functionality can be restored with rcu. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
-
- 27 8月, 2014 1 次提交
-
-
由 Christian König 提交于
This allows us to more fine grained specify where to place the buffer object. v2: rebased on drm-next, add bochs changes as well Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 13 8月, 2014 1 次提交
-
-
由 Benoit Taine 提交于
We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. This issue was reported by checkpatch. A simplified version of the semantic patch that makes this change is as follows (http://coccinelle.lip6.fr/): // <smpl> @@ identifier i; declarer name DEFINE_PCI_DEVICE_TABLE; initializer z; @@ - DEFINE_PCI_DEVICE_TABLE(i) + const struct pci_device_id i[] = z; // </smpl> [bhelgaas: add semantic patch] Signed-off-by: NBenoit Taine <benoit.taine@lip6.fr> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 22 7月, 2014 1 次提交
-
-
由 Thierry Reding 提交于
The final parameter to ttm_bo_reserve() is a pointer, therefore callers should use NULL instead of 0. Fixes a bunch of sparse warnings of this type: warning: Using plain integer as NULL pointer Signed-off-by: NThierry Reding <treding@nvidia.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 17 7月, 2014 1 次提交
-
-
由 Jason Wang 提交于
Return IRQ_NONE if it was not our irq. This is necessary for the case when qxl is sharing irq line with a device A in a crash kernel. If qxl is initialized before A and A's irq was raised during this gap, returning IRQ_HANDLED in this case will cause this irq to be raised again after EOI since kernel think it was handled but in fact it was not. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NJason Wang <jasowang@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 08 7月, 2014 2 次提交
-
-
由 Thierry Reding 提交于
To implement hotplug detection in a race-free manner, drivers must call drm_kms_helper_poll_init() before hotplug events can be triggered. Such events can be triggered right after any of the encoders or connectors are initialized. At the same time, if the drm_fb_helper_hotplug_event() helper is used by a driver, then the poll helper requires some parts of the FB helper to be initialized to prevent a crash. At the same time, drm_fb_helper_init() requires information that is not necessarily available at such an early stage (number of CRTCs and connectors), so it cannot be used yet. Add a new helper, drm_fb_helper_prepare(), that initializes the bare minimum needed to allow drm_kms_helper_poll_init() to execute and any subsequent hotplug events to be processed properly. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thierry Reding 提交于
There's no need for this to be modifiable. Make it const so that it can be put into the .rodata section. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NThierry Reding <treding@nvidia.com> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 6月, 2014 1 次提交
-
-
由 Thomas Wood 提交于
Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: NThomas Wood <thomas.wood@intel.com> Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 6月, 2014 1 次提交
-
-
由 Damien Lespiau 提交于
I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used in a few places. I suspect its usage has been spread by copy & paste rather than anything else. Let's just remove it for plain ARRAY_SIZE(). Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 04 6月, 2014 1 次提交
-
-
由 David Mansfield 提交于
spice-server and downstream code expect that the primary surface will always have surface_id = 0, while in reality, once allocated, the surface_id in qxl.ko is NEVER 0. In a dual head environment, all monitors render portions of the primary surface. However, when the monitor config events are generated and sent, the primary surface is only mapped to the correct identifier (i.e. 0) for the primary head (where crtc index is 0). The fix is to look at the "primary" flag in the bo and always use id 0, irrespective of which head is being configured. [airlied: qxl hw really needs to be fixed to scanout surfaces] Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 01 5月, 2014 2 次提交
-
-
由 Christian Engelmayer 提交于
Remove occurrences of unused struct qxl_device pointer in functions qxl_ttm_fault() and qxl_init_mem_type(). Detected by Coverity: CID 1019128, CID 1019129. Signed-off-by: NChristian Engelmayer <cengelma@gmx.at> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
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: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 4月, 2014 2 次提交
-
-
由 Daniel Vetter 提交于
Especially not on modesetting drivers - this is used to size the driver private structure for legacy drm buffers. Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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: NThierry Reding <treding@nvidia.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 4月, 2014 1 次提交
-
-
由 Thomas Hellstrom 提交于
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com>
-
- 02 4月, 2014 2 次提交
-
-
由 Maarten Lankhorst 提交于
This fixes a BUG_ON(bo->sync_obj != NULL); in ttm_bo_release_list. Cc: stable@vger.kernel.org #v3.10+ Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Matt Roper 提交于
Now that CRTC's have a primary plane, there's no need to track the framebuffer in the CRTC. Replace all references to the CRTC fb with the primary plane's fb. This patch was generated by the Coccinelle semantic patching tool using the following rules: @@ struct drm_crtc C; @@ - (C).fb + C.primary->fb @@ struct drm_crtc *C; @@ - (C)->fb + C->primary->fb v3: Generate patch via coccinelle. Actual removal of crtc->fb has been moved to a subsequent patch. v2: Fixup several lingering crtc->fb instances that were missed in the first patch iteration. [Rob Clark] Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NRob Clark <robdclark@gmail.com>
-
- 16 3月, 2014 2 次提交
-
-
由 David Herrmann 提交于
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: NDavid Herrmann <dh.herrmann@gmail.com>
-
由 David Herrmann 提交于
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: NDavid Herrmann <dh.herrmann@gmail.com>
-
- 14 1月, 2014 2 次提交
-
-
由 Randy Dunlap 提交于
Fix build error: qxl uses crc32 functions so it needs to select CRC32. Also use angle quotes around a kernel header file name. drivers/built-in.o: In function `qxl_display_read_client_monitors_config': (.text+0x19d754): undefined reference to `crc32_le' Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Rashika 提交于
Mark function qxl_device_init() as static in drm/qxl/qxl_kms.c because it is not used outside this file. This eliminates the following warning in drm/qxl/qxl_kms.c: drivers/gpu/drm/qxl/qxl_kms.c:118:5: warning: no previous prototype for ‘qxl_device_init’ [-Wmissing-prototypes] Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com> Reviewed-by: NJosh Triplett <josh@joshtriplett.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 12月, 2013 1 次提交
-
-
由 Randy Dunlap 提交于
Fix build error: qxl uses crc32 functions so it needs to select CRC32. Also use angle quotes around a kernel header file name. drivers/built-in.o: In function `qxl_display_read_client_monitors_config': (.text+0x19d754): undefined reference to `crc32_le' Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 12月, 2013 1 次提交
-
-
由 Antonio Ospite 提交于
Reformat the help text to follow the style of the other Kconfig files, and also fix indentation for the "select" lines. Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 18 12月, 2013 3 次提交
-
-
由 Daniel Vetter 提交于
Less yelling ftw! Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
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: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Not all drivers will need take all the modeset locks for dirtyfb, so push the locking down to the drivers. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NJakob Bornecrantz <jakob@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 29 11月, 2013 1 次提交
-
-
由 Dave Airlie 提交于
wow no idea how I got this far without seeing this, leaking the entries in the list makes kmalloc-64 slab grow. References: https://bugzilla.kernel.org/show_bug.cgi?id=65121 Cc: stable@vger.kernel.org Reported-by: NMatthew Stapleton <matthew4196@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 06 11月, 2013 3 次提交
-
-
由 Dave Airlie 提交于
So GNOME userspace has an issue with when it rescans for modes on hotplug events, if the monitor has no EDID it assumes that nothing has changed on EDID as with real hw we'd never have new modes without a new EDID, and they kind off rely on the behaviour now, however with virtual GPUs we would like to rescan the modes and get a new preferred mode on hotplug events to handle dynamic guest resizing (where you resize the host window and the guest resizes with it). This is a simple property we can make userspace watch for to trigger new behaviour based on it, and can be used to replaced EDID hacks in virtual drivers. Acked-by: Marc-André Lureau <marcandre.lureau@gmail.com> (on irc) Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Gerd Hoffmann 提交于
qxl devices can have a 64bit surface bar, which is quite handy if you need a bit more surface memory. So try to use it if it is present. Note that this bar might be mapped above 4g. QEMU command line to check that out: qemu-system-x86_64 -m 4g \ -vga qxl -global qxl-vga.vram64_size_mb=512 \ $otheroptions Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 04 11月, 2013 1 次提交
-
-
由 Dave Airlie 提交于
If we are using deferred io due to plymouth or X.org fbdev driver we will oops in memcpy due to this pointless multiply here, removing it fixes fbdev to start and not oops. Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 10月, 2013 4 次提交
-
-
由 Marc-André Lureau 提交于
To disable a monitor, a Spice client sends a monitor config with the monitor resolution to 0x0. However, before qxl_crtc_disable() is reached after the hotplug event, it can happen that another monitor is reconfigured, and qxl_send_monitors_config() is called with the old config, which will re-enable the monitor on the client. Reset config if monitor is found disconnected, during drm_helper_hpd_irq_event(). Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Marc-André Lureau 提交于
All hard-coded resolutions are passing this check. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Marc-André Lureau 提交于
By default, 1024x768 is the preferred resolution. However, when a monitor config is given, it should be the only preferred resolution. Note that the monitor config resolution is passed to qxl_add_common_modes() to avoid adding a duplicate mode without the preferred resolution. That would discard the previous monitor config preferred bit. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Marc-André Lureau 提交于
drm_helper_hpd_irq_event() only notifies when the connector status changed. However, Spice monitor config can change while the connector is connected, to support arbitrary resolution. Do an hotplug event if it wasn't done by drm_helper_hpd_irq_event(). Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 12 10月, 2013 1 次提交
-
-
由 Daniel Vetter 提交于
For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by adding per-driver options. At least as long as most drivers don't support disabling the fbdev support. v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm driver can already take advantage of this, which allows us to build msm without any fbdev depencies in the kernel! v3: Move the MODULE_* stuff from the fbdev helper file to drm_crtc_helper.c. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Acked-by: NDave Airlie <airlied@linux.ie> Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 10月, 2013 1 次提交
-
-
由 David Herrmann 提交于
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: NDavid Herrmann <dh.herrmann@gmail.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 27 8月, 2013 1 次提交
-
-
由 David Herrmann 提交于
GEM does already a good job in tracking access to gem buffers via handles and drm_vma access management. However, TTM drivers currently do not verify this during mmap(). TTM provides the verify_access() callback to test this. So fix all drivers to actually call into gem+vma to verify access instead of always returning 0. All drivers assume that user-space can only get access to TTM buffers via GEM handles. So whenever the verify_access() callback is called from ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is true for all TTM+GEM drivers. But that's why this patch doesn't touch pure TTM drivers (ie, vmwgfx). v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if access was denied. Cc: Dave Airlie <airlied@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Jerome Glisse <jglisse@redhat.com> Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 8月, 2013 2 次提交
-
-
由 Daniel Vetter 提交于
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: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 David Herrmann 提交于
These two helpers are unused. Remove them. They rely on gem_obj->driver_private, which is set to NULL during setup. As this field isn't used by the driver, anymore, we can remove this assignment as well. Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-