- 14 2月, 2013 7 次提交
-
-
由 Daniel Vetter 提交于
Now that the driver is in control of whether it needs to disable everything at take-over or not, we can rip this all out. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
This should be done in the drivers for two reasons: - it gets in the way of fastboot efforts - it links the fb helpers with the crtc helpers instead of going through the real interface vfuncs, forcing i915 to fake all the ->disable callbacks used by the crtc helper to avoid ugly Oopsen v2: Resolve conflicts since drivers still call drm_fb_helper_single_add_all_connectors. Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
drm_fbdev_cma_init does the inital fbcon setup by calling down into drm_fb_helper_initial_config, so no need at all to restore the just set up configuration right away ... Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Not called by anyone, and really, shouldn't be. Drivers are supposed either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event. Originally this was done differently, but is now consolidated in the helper functions and no longer done by drivers directly. Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
It doesn't even show up in any header files and only used iternally. Originally it was (ab)used to restore the fbcon on lastclose, but that died with commit e8e7a2b8 Author: Dave Airlie <airlied@redhat.com> Date: Thu Apr 21 22:18:32 2011 +0100 drm/i915: restore only the mode of this driver on lastclose (v2) Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
It's only used internally for the sysrq and panic handlers provided by the drm fb helper implementation. Hence just inline it, kill the export and remove the confusing kerneldoc. Driver's are supposed to call drm_fb_helper_restore_fbdev_mode on lastclose. Note that locking is totally fubar - the sysrq case doesn't take any locks at all. The panic handler probably shouldn't take any locks since it'll only make things worse. Otoh it's probably better to switch things over to the atomic modeset callbacks (and disable the panic handler for those drivers which don't implement it). But that's both better done in separate patches. Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
... it's required. Fix up exynos and the cma helper, and add a corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode. Note that tegra calls the fbdev cma helper restore function also from it's driver-load callback. Which is a bit against current practice, since usually the call is only from ->lastclose, and initial setup is done by drm_fb_helper_initial_config. Also add the relevant drm DocBook entry. v2: Add promised WARN to restore_fbdev_mode. Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 2月, 2013 11 次提交
-
-
由 Daniel Kurtz 提交于
It is a bit more precise to compute the total number of pixels first and then divide, rather than multiplying the line pixel count by the already-rounded line duration. Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Bjorn Helgaas 提交于
Use PCI Express Capability access functions to simplify this code a bit. For non-PCIe devices or pre-PCIe 3.0 devices that don't implement the Link Capabilities 2 register, pcie_capability_read_dword() reads a zero. Since we're only testing whether the bits we care about are set, there's no need to mask out the other bits we *don't* care about. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Bjorn Helgaas 提交于
For devices that conform to PCIe r3.0 and have a Link Capabilities 2 register, we test and report every bit in the Supported Link Speeds Vector field. For a device that supports both 2.5GT/s and 5.0GT/s, we set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in the returned mask. For pre-r3.0 devices, the Link Capabilities 0010b encoding (PCI_EXP_LNKCAP_SLS_5_0GB) means that both 5.0GT/s and 2.5GT/s are supported, so set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in this case as well. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Bjorn Helgaas 提交于
Use the standard #defines rather than bare numbers for the PCIe Link Capabilities speed bits. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thierry Reding 提交于
Drivers that register interrupt handlers without the DRM core helpers don't initialize the .irq_enabled field and drm_dev_to_irq() may fail when called on them. This shouldn't preclude them from implementing the vblank IOCTL. Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Aaron Plattner 提交于
Simplify the Radeon prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. v2: - Rename functions to radeon_gem_prime_get_sg_table and radeon_gem_prime_import_sg_table. - Delete the now-unused vmapping_count variable. Signed-off-by: NAaron Plattner <aplattner@nvidia.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Aaron Plattner 提交于
Simplify the Nouveau prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. v2: Rename functions to nouveau_gem_prime_get_sg_table and nouveau_gem_prime_import_sg_table. Signed-off-by: NAaron Plattner <aplattner@nvidia.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Aaron Plattner 提交于
Instead of reimplementing all of the dma_buf functionality in every driver, create helpers drm_prime_import and drm_prime_export that implement them in terms of new, lower-level hook functions: gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object gem_prime_vmap, gem_prime_vunmap: map and unmap an object These hooks are optional; drivers can opt in by using drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of struct drm_driver. v2: - Drop .begin_cpu_access. None of the drivers this code replaces implemented it. Having it here was a leftover from when I was trying to include i915 in this rework. - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers did. This patch series shouldn't change that behavior. - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table. Rename struct sg_table* variables to 'sgt' for clarity. - Update drm.tmpl for these new hooks. v3: - Pass the vaddr down to the driver. This lets drivers that just call vunmap on the pointer avoid having to store the pointer in their GEM private structures. - Move documentation into a /** DOC */ comment in drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F lines to include documentation of the individual functions from drmP.h, but the docproc / kernel-doc scripts barf on that file, so hopefully this is good enough for now. - apply refcount fix from commit be8a42ae ("drm/prime: drop reference on imported dma-buf come from gem") Signed-off-by: NAaron Plattner <aplattner@nvidia.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Rob Clark 提交于
Move this out of nouveau directory. As we start to add more encoder slaves used by other drivers, it makes sense to put the Kconfig bits in one place. Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
There seems to be a bad interaction between gem/shmem and defio on top, I get list corruption on the page lru in the shmem code. Turn it off for now until we get some more digging done. Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Chris Wilson 提交于
As we use a variable length the compiler does not realise that it is a fixed value of either 2 or 4 bytes. Instead of performing the inline comparison itself, the compiler inserts a function call to the generic memcmp routine which is optimised for long comparisons of variable length. That turns out to be quite expensive... Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 07 2月, 2013 2 次提交
-
-
由 Dave Airlie 提交于
Okay you don't really want to use udl devices as your console, but if you are unlucky enough to do so, you run into a lot of schedule while atomic due to printk being called from all sorts of funky places. So check if we are in an atomic context, and queue the damage for later, the next printk should cause it to appear. This isn't ideal, but it is simple, and seems to work okay in my testing here. (dirty area idea came from xenfb) fixes a bunch of sleeping while atomic issues running fbcon on udl devices. Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
While looking at plymouth on udl I noticed that plymouth was trying to use its fb plugin not its drm one, it was trying to drmOpen a driver called usb not udl, noticed that we actually had out driver pointing at the wrong device. Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 06 2月, 2013 1 次提交
-
-
由 Alex Deucher 提交于
Only enable it when we disable the display rather than at DPMS time since enabling it requires a full modeset to restore the display state. Fixes blank screens in certain cases. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 02 2月, 2013 6 次提交
-
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Oland is a new asic in the SI family. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Now that we have switched to using IBs for page table updates, we can switch back the using the DMA ring. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
For very large page table updates, we can exceed the size of the ring. To avoid this, use an IB to perform the page table update. v2(ck): cleanup the IB infrastructure and the use it instead of filling the struct ourself. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NChristian König <christian.koenig@amd.com>
-
- 01 2月, 2013 13 次提交
-
-
由 Yasuaki Ishimatsu 提交于
acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_FAILURE() to the return value of acpi_bus_get_device(). Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Alex Deucher 提交于
The MC isn't part of the GPU per se. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
fetch the reset mask and check if the relevant ring flags are set to determine whether the ring is hung or not. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
It's better to halt the engines before we disable the MC. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
It's better to halt the engines before we disable the MC. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
It's better to halt the engines before we disable the MC. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
It's better to halt the engines before we disable the MC. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
When we attempt the reset the GPU, look at the status registers to determine what blocks need to be reset. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
When we attempt the reset the GPU, look at the status registers to determine what blocks need to be reset. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
When we attempt the reset the GPU, look at the status registers to determine what blocks need to be reset. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
When we attempt the reset the GPU, look at the status registers to determine what blocks need to be reset. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Update the code to better match the recommended programming sequence for soft reset. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Update the code to better match the recommended programming sequence for soft reset. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-