- 06 Nov, 2013 33 commits
-
-
Chris Wilson authored
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>
-
Chris Wilson authored
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>
-
Dave Airlie authored
This causes problems with never going busy due to ptherm polling, and after talking to Ben I can't see it being required. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
drm_connector_sysfs_add() explicitly checks if connector->kdev is already populated and returns success. So it clearly now allows being called multiple times. Remove some stale comments to the contrary. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Christian König authored
Don't block forever if there is nothing to wait for. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Rafa? Mi?ecki <zajec5@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Gerd Hoffmann authored
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Gerd Hoffmann authored
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: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Gerd Hoffmann authored
Explicitly set 1024x768 as default mode, so the display doesn't come up with the largest supported mode. While being at it drop first three drm_add_modes_noedid calls. As drm_add_modes_noedid fills the mode list with modes from the database *up to* the specified size it is pretty pointless to call it multiple times with different sizes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Gerd Hoffmann authored
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>
-
Ville Syrjälä authored
drm_fb_get_bpp_depth() likes to complain about unsupported pixel formats but doesn't bother telling us what the format was. Also format_check() just returns an error when it encouters an invalid format, leaving the user scratching his head trying to figure out why addfb failed. Make life a bit easier by using drm_get_format_name() in both places. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
I got very confused when I tried to compare the EST modes with the spec. Bring over a comment from xf86EdidModes.c that actually describes some of history where these things came from. Signed-off-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>
-
Ville Syrjälä authored
Also check the est3 modes whose presence is indicated by bit 0. Signed-off-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>
-
Ville Syrjälä authored
The correct refresh rate for this mode is 75, not 85. Signed-off-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>
-
Ville Syrjälä authored
Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
Return -ENOENT for framebuffers like we do for other mode objects that can't be found. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
We tend to return -EINVAL for everything. Let's try to help poor userland developers a bit by at least returning -ENONET for missing objects. Signed-off-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>
-
Ben Hutchings authored
Most architectures define virt_to_page() as a macro that casts its argument such that an argument of type unsigned long will be accepted without complaint. However, the proper type is void *, and passing unsigned long results in a warning on MIPS. Compile-tested only. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Ben Hutchings authored
By definition, the page offset will not affect the result. Compile-tested only. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
YoungJun Cho authored
When there are unconsumed pending events, the events are destroyed by calling destroy callback, but the events list are remained, because there is no list_del(). It is possible that the page flip request is handled after drm_events_release() is called and before drm_fb_release(). In this case a drm_pending_event is remained not freed. So exynos driver checks again to remove it in its post close routine. But the file_priv->event_list contains undeleted ones, this can make oops for accessing invalid memory. Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Lespiau, Damien authored
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>
-
Lespiau, Damien authored
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>
-
Lespiau, Damien authored
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>
-
Lespiau, Damien authored
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>
-
Duan Jiong authored
This removes an open coded simple_open() function and replaces file operations references to the function with simple_open() instead. Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Laurent Pinchart authored
The driver registers a backlight device and thus requires BACKLIGHT_CLASS_DEVICE to be selected to avoid compilation breakages. Cc: stable@vger.kernel.org Reported-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Mario Kleiner authored
Move the ktime_get() clock readouts and potential preempt_disable() calls from drm core into kms driver to make it compatible with the api changes in the drm core. The intel-kms driver needs to take the uncore.lock inside i915_get_crtc_scanoutpos() and intel_pipe_in_vblank(). This is incompatible with the preempt_disable() on a PREEMPT_RT patched kernel, as regular spin locks must not be taken within a preempt_disable'd section. Lock contention on the uncore.lock also introduced too much uncertainty in vblank timestamps. Push the ktime_get() timestamping for scanoutpos queries and potential preempt_disable_rt() into i915_get_crtc_scanoutpos(), so these problems can be avoided: 1. First lock the uncore.lock (might sleep on a PREEMPT_RT kernel). 2. preempt_disable_rt() (will be added by the rt-linux folks). 3. ktime_get() a timestamp before scanout pos query. 4. Do all mmio reads as fast as possible without grabbing any new locks! 5. ktime_get() a post-query timestamp. 6. preempt_enable_rt() 7. Unlock the uncore.lock. This reduces timestamp uncertainty on a low-end HP Atom Mini netbook with Intel GMA-950 nicely: Before: 3-8 usecs with spikes > 20 usecs, triggering query retries. After : Typically 1 usec (98% of all samples), occassionally 2 usecs (2% of all samples), with maximum of 3 usecs (a handful). 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>
-
Mario Kleiner authored
Move the ktime_get() clock readouts and potential preempt_disable() calls from drm core into kms driver to make it compatible with the api changes in the drm core. This should not introduce any change in functionality or behaviour in radeon-kms, just a reshuffling of code. 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>
-
Mario Kleiner authored
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>
-
Mario Kleiner authored
Preemption handling will get pushed into the kms drivers in followup patches, to make timestamping more robust and PREEMPT_RT friendly. 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>
-
- 05 Nov, 2013 2 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Initial pull request for radeon drm-next 3.13. Highlights: - Enable DPM on a number of asics by default - Enable audio by default - Dynamically power down dGPUs on PowerXpress systems - Lots of bug fixes * 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux: (36 commits) drm/radeon: don't share PPLLs on DCE4.1 drm/radeon/dpm: fix typo in setting smc flag drm/radeon: fixup locking inversion between, mmap_sem and reservations drm/radeon: clear the page directory using the DMA drm/radeon: initially clear page tables drm/radeon: drop CP page table updates & cleanup v2 drm/radeon: add vm_set_page tracepoint drm/radeon: rework and fix reset detection v2 drm/radeon: don't use PACKET2 on CIK drm/radeon: fix UVD destroy IB size drm/radeon: activate UVD clocks before sending the destroy msg drm/radeon/si: fix define for MC_SEQ_TRAIN_WAKEUP_CNTL drm/radeon: fix endian handling in rlc buffer setup drm/radeon/dpm: retain user selected performance level across state changes drm/radeon: disable force performance state when thermal state is active drm/radeon: enable DPM by default on r7xx asics drm/radeon: enable DPM by default on evergreen asics drm/radeon: enable DPM by default on BTC asics drm/radeon: enable DPM by default on SI asics drm/radeon: enable DPM by default on SUMO/PALM APUs ...
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
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 ...
-
- 04 Nov, 2013 1 commit
-
-
Dave Airlie authored
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: Dave Airlie <airlied@redhat.com>
-
- 01 Nov, 2013 4 commits
-
-
Alex Deucher authored
Sharing PPLLs seems to cause problems on some boards. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45334Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Alex Deucher authored
PPSMC_EXTRAFLAGS_AC2DC_GPIO5_POLARITY_HIGH should be set in extraFlags, not systemFlags. Noticed-by: Sylvain BERTRAND <sylware@legeek.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Maarten Lankhorst authored
op 08-10-13 18:58, Thomas Hellstrom schreef: > On 10/08/2013 06:47 PM, Jerome Glisse wrote: >> On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote: >>> On 10/08/2013 04:55 PM, Jerome Glisse wrote: >>>> On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote: >>>>> Am 08.10.2013 16:33, schrieb Jerome Glisse: >>>>>> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: >>>>>>> Allocate and copy all kernel memory before doing reservations. This prevents a locking >>>>>>> inversion between mmap_sem and reservation_class, and allows us to drop the trylocking >>>>>>> in ttm_bo_vm_fault without upsetting lockdep. >>>>>>> >>>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> >>>>>> I would say NAK. Current code only allocate temporary page in AGP case. >>>>>> So AGP case is userspace -> temp page -> cs checker -> radeon ib. >>>>>> >>>>>> Non AGP is directly memcpy to radeon IB. >>>>>> >>>>>> Your patch allocate memory memcpy userspace to it and it will then be >>>>>> memcpy to IB. Which means you introduce an extra memcpy in the process >>>>>> not something we want. >>>>> Totally agree. Additional to that there is no good reason to provide >>>>> anything else than anonymous system memory to the CS ioctl, so the >>>>> dependency between the mmap_sem and reservations are not really >>>>> clear to me. >>>>> >>>>> Christian. >>>> I think is that in other code path you take mmap_sem first then reserve >>>> bo. But here we reserve bo and then we take mmap_sem because of copy >>> >from user. >>>> Cheers, >>>> Jerome >>>> >>> Actually the log message is a little confusing. I think the mmap_sem >>> locking inversion problem is orthogonal to what's being fixed here. > >>> This patch fixes the possible recursive bo::reserve caused by > >>> malicious user-space handing a pointer to ttm memory so that the ttm > >>> fault handler is called when bos are already reserved. That may > >>> cause a (possibly interruptible) livelock. >>> Once that is fixed, we are free to choose the mmap_sem -> >>> bo::reserve locking order. Currently it's bo::reserve->mmap_sem(), >>> but the hack required in the ttm fault handler is admittedly a bit >>> ugly. The plan is to change the locking order to >>> mmap_sem->bo::reserve > >>> I'm not sure if it applies to this particular case, but it should be > >>> possible to make sure that copy_from_user_inatomic() will always > >>> succeed, by making sure the pages are present using > >>> get_user_pages(), and release the pages after > >>> copy_from_user_inatomic() is done. That way there's no need for a > >>> double memcpy slowpath, but if the copied data is very fragmented I > >>> guess the resulting code may look ugly. The get_user_pages() > >>> function will return an error if it hits TTM pages. >>> /Thomas >> get_user_pages + copy_from_user_inatomic is overkill. We should just >> do get_user_pages which fails with ttm memory and then use copy_highpage >> helper. >> >> Cheers, >> Jerome > Yeah, it may well be that that's the preferred solution. > > /Thomas > I still disagree, and shuffled radeon_ib_get around to be called sooner. How does the patch below look? 8<------- Allocate and copy all kernel memory before doing reservations. This prevents a locking inversion between mmap_sem and reservation_class, and allows us to drop the trylocking in ttm_bo_vm_fault without upsetting lockdep. Changes since v1: - Kill extra memcpy for !AGP case. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Christian König authored
Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-