- 19 May, 2012 1 commit
-
-
Dave Airlie authored
Reported-by: Randy Dunlap Signed-off-by:Dave Airlie <airlied@redhat.com>
-
- 18 May, 2012 1 commit
-
-
Dave Airlie authored
This lets the kernel tell userspace if the device supports prime import/export. This is useful for -modesetting at least, but would be nice for other drivers. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 17 May, 2012 23 commits
-
-
Rafał Miłecki authored
Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Alex Deucher authored
Introduce special struct radeon_afmt for this purpose. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
All radeon_gem_init() does is initialize the gem objects list. radeon_device.c does this explicitly. r600+ calls radeon_gem_init() so the list gets initialized twice. Older asics don't call it at all and rely on the the init in radeon_device.c. Just call radeon_gem_init() in radeon_device.c and remove the explicit calls from all the newer asics. All asics call radeon_gem_fini() in their fini pathes. That could possibly be cleaned up too. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Ilija Hadzic authored
connector_names table is just a repeat of information that already exists in drm_connector_enum_list and the same string can be retrieved using drm_get_connector_name function. Nuke the redundant table and use the proper function to retrieve the connector name. Signed-off-by:
Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by:
-
Michel Dänzer authored
Without this, e.g. egltri_screen looks scrambled after a GPU reset. Signed-off-by:
-
Jerome Glisse authored
It seems imac pannel doesn't like whe we change the hot plug setup and then refuse to work. This help but doesn't fully fix: https://bugzilla.redhat.com/show_bug.cgi?id=726143 v2: fix typo and improve commit message Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Reviewed-by:
-
Dan Carpenter authored
drm_core_ioremap() initializes ->handle. We already know "dev->agp_buffer_map" is a valid pointer. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dave Airlie authored
CC [M] drivers/gpu/drm/i915/i915_gem_evict.o /ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c: In function ‘psb_chip_errata’: /ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:360:1: warning: no return statement in function returning non-void [-Wreturn-type] /ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c: At top level: /ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:379:2: warning: initialization from incompatible pointer type [enabled by default] /ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:379:2: warning: (near initialization for ‘psb_chip_ops.errata’) [enabled by default] Signed-off-by: -
Dan Carpenter authored
If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that: drivers/gpu/drm/gma500/opregion.c:154:6: warning: unused variable ‘max’ [-Wunused-variable] Which give me a chance to use the new config_enabled() macro. :) Signed-off-by:
Paul Menzel <paulepanter@users.sourceforge.net> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Dan Carpenter authored
We can just return -ENOMEM here if the allocation fails. Signed-off-by:
-
Paulo Zanoni authored
The i915 driver needs this for the rotation and overscan compensation properties. Other drivers might need this too. Reviewed-by:
Rob Clark <rob.clark@linaro.org> Tested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
This way, we don't need to count every time, so we're a little bit faster and code is a little bit smaller. Change suggested by Ville Syrjälä. Reviewed-by:
-
Paulo Zanoni authored
In the future, we may want to kill the internal functions: - drm_connector_attach_property - drm_connector_property_set_value - drm_connector_property_get_value It seems the IOCTL drm_mode_connector_property_set_ioctl will have to live, but we may change libdrm to not use it anymore, if we want. Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
-
Paulo Zanoni authored
Useless for connector properties (since they already have their own ioctls), but useful when we add properties to CRTCs, planes and other objects. Reviewed-by:
-
Paulo Zanoni authored
For now, only connectors have it. In the future, all objects that need properties should use it. Since the structure is referenced inside struct drm_mode_object, we will be able to deal with object properties without knowing the real type of the object. Reviewed-by:
-
Paulo Zanoni authored
Also return void instead of int. We have more than 100 callers and no one checks for the return value. If this function fails the property won't be exposed by the get/set ioctls, but we should probably survive. If this starts happening, the solution will be to increase DRM_CONNECTOR_MAX_PROPERTY and recompile the Kernel. Signed-off-by:
-
Paulo Zanoni authored
Move code from drm_mode_connector_property_set_ioctl to a new function, so we can reuse this code when we add crtc properties. Reviewed-by:
-
Alan Cox authored
Debugging the lid problem tested various error paths which were found wanting so start fixing them up. There is a ton of improvement work could be done here so that every bit of functionality agrees if its _fini, _uninit, etc, and they agree who is responsible for deciding if the clean up is needed. That can come later. Signed-off-by:
-
Alan Cox authored
The recent changes led to the lid timer code being run on various devices. It does no harm on most but isn't needed. It also calls unconditionally into the Poulsbo backlight code which goes bang on Cedartrail. Signed-off-by:
-
Dave Airlie authored
This is the initial driver for emulated cirrus GPU found in qemu. This driver only supports the emulated GPU and doesn't attempt to bind to any real cirrus GPUs. This driver is intended to be used with xf86-video-modesetting in userspace. It requires at least version 0.3.0 This follow the same design as ast and mgag200, and is based on work done by Matthew Garrett previously. This GPU has no hw cursor, and it can't scanout 32-bpp, only packed 24-bpp. i.e. it sucks. Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Dave Airlie authored
This is a driver for the G200 server engines chips, it doesn't driver any of the Matrix G series desktop cards. It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards. Its based on previous work done my Matthew Garrett but remodelled to follow the same style and flow as the AST server driver. It also works along the same lines as the AST server driver wrt memory management. There is no userspace driver planned, xf86-video-modesetting should be used. It also appears these GPUs have no ARGB hw cursors. v2: add missing tagfifo reset + G200 SE memory bw setup pieces. Signed-off-by: -
Dave Airlie authored
This is the initial driver for the Aspeed Technologies chips found in servers. This driver supports the AST 2000, 2100, 2200, 2150 and 2300. It doesn't support the AST11xx due to lack of hw to test it on, and them requiring different codepaths. This driver is intended to be used with xf86-video-modesetting in userspace. This driver has a slightly different design than other KMS drivers, but future server chips will probably share similiar setup. As these GPUs commonly have low video RAM, it doesn't make sense to put the kms console in VRAM always. This driver places the kms console into system RAM, and does dirty updates to a copy in video RAM. When userspace sets a new scanout buffer, it forcefully evicts the video RAM console, and X can create a framebuffer that can use all of of video RAM. This driver uses TTM but in a very simple fashion to control the eviction to system RAM of the console, and multiple servers. v2: add s/r support, fix Kconfig. Signed-off-by: -
Dave Airlie authored
Reported by sfr on -next merge. Signed-off-by:
-
- 16 May, 2012 1 commit
-
-
Dave Airlie authored
Since Matthew's efi/vga changes on non-EFI machines we were failing to tell the vgaarb/switcheroo what the default device was, this sets the default device in the quirk if none has been set before. This fixes the switcheroo on my T410s. Cc: Matthew Garrett <mjg@redhat.com> Acked-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
- 13 May, 2012 10 commits
-
-
Dave Airlie authored
Merge branch 'topic/vga-switcheroo' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into drm-core-next * 'topic/vga-switcheroo' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: vga_switcheroo: Add the support for audio clients vga_switcheroo: Introduce struct vga_switcheroo_client_ops vga_switcheroo: Refactor using linked list
-
Rafał Miłecki authored
Use defined macros by the way. Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Takashi Iwai authored
Add the support for audio clients to VGA-switcheroo for handling the HDMI audio controller together with VGA switching. The id of the audio controller should be given explicitly at registration time unlike the video controller. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
This changes the API as a clean-up. Instead of passing multiple function pointers at each time, introduce a new struct holding the whole callback functions and pass it to the registration. The same struct will be used for the upcoming audio client registration, too. Signed-off-by: -
Takashi Iwai authored
Refactor the code base a bit for the further work to adapt more clients. Signed-off-by:
-
- 11 May, 2012 4 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-2012-05-06-merged' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next Daniel says Highlights: - sparse fixes from Ben. - tons of little cleanups from Chris all over: tiling_changed clarification, deferred_free list removal, ... - fix up irq handler on gen2 & gen3 + related cleanups from Chris - prep work for wait_rendering_timeout from Ben with some nice refactorings - first set of infoframe fixes from Paulo for doubleclocked CEA modes - improve pch pll handling from Jesse and Chris - gpu hangman, this also contains the reset fix for gen4 - rps sanity check from Chris - this papers over issues when the gpu fails to clock up on snb/ivb, and it is shockingly easy to hit. The code prints a big WARN backtrace and restores the hw to a sane state. The real fix is still in the works. Atm I'm aware of 2 regressions in -next: - One of the gmbus patches (not gmbus itself) regressed lvds detection on a MacbookPro. I've analyzed the bug already and I think I know what's going on, patch is awaiting test feedback. - Just today QA reported that DP on ilk regressed. That bug is fresh of the press and still awaiting detailed logfiles and the bisect result. The only thing that's clear atm is that -fixes works and -next doesn't.
-
Rob Clark authored
Previously these functions would assume that vma->vm_file was the drm_file. Although if in some cases if the drm driver needs to use something else for the backing file (such as the tmpfs filp) then this assumption is no longer true. But vma->vm_private_data is still the GEM object. With this change, now the drm_device comes from the GEM object rather than the drm_file so the driver is more free to play with vma->vm_file. The scenario where this comes up is for mmap'ing of cached dmabuf's for non-coherent systems, where the driver needs to use fault handling and PTE shootdown to simulate coherency. We can't use the vma->vm_file of the dmabuf, which is using anon_inode's address_space. The most straightforward thing to do is to use the GEM object's obj->filp for vma->vm_file in all cases, for which we need this patch. Signed-off-by:
Rob Clark <rob@ti.com> Signed-off-by:
-
Alan Cox authored
Keep this as a patch of its own in case of bug reports. Signed-off-by:
-
Alan Cox authored
We don't need to check these - they are always going to be the same for any PVR based device. Signed-off-by:
-
