- 13 Feb, 2012 8 commits
-
-
Thomas Hellstrom authored
And assign the initial width and height to the minimum in that case. Strange values (-1) from these registers have been reported by users. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Jakob Bornecrantz authored
Signed-off-by:
-
Jakob Bornecrantz authored
Signed-off-by:
-
Jakob Bornecrantz authored
Signed-off-by:
-
Jakob Bornecrantz authored
Signed-off-by:
-
Thomas Hellstrom authored
Pending events may have stale pointer references to struct drm_file objects after a file has been closed, but before the event is supposed to be attached to the drm file. Remove such events on file close. Tested with "modetest". Signed-off-by:
-
Jakob Bornecrantz authored
Signed-off-by:
-
Daniel Vetter authored
CEA actually specifies an interlaced mode with even vtotal and supplies a diagram showing how this is supposed to work. Note that interlaced modes with an even vtotal seem to be a fairly recent invention. All modelines lore I could dig up with googling says that vtotal for interlaced modes _needs_ to be odd. But the even modelines in CEA are not a spec-bug, there's a figure in CEA-861-E called "Figure 5 Special Interlaced Video Format Timing (Even Vtotal)" that explains how it's supposed to work. Furthermore intel Bspec explicitly mentions that both odd and even interlaced vtotal are supported (VTOTAL register in the south display engine of PCH split chips). Acked-by:
Adam Jackson <ajax@redhat.com> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 09 Feb, 2012 3 commits
-
-
Sascha Hauer authored
The drm drivers set the fb_info->pixmap fields without setting fb_info->pixmap.addr. If this is not set the fb core will overwrite these all fb_info->pixmap fields anyway, so there is not much point in setting them in the first place. [airlied: dropped nvidiafb piece - not mine] Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Sascha Hauer authored
Creating a range property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by:
-
Sascha Hauer authored
Creating an enum property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by:
-
- 07 Feb, 2012 1 commit
-
-
git://people.freedesktop.org/~danvet/drm-intelDave Airlie authored
* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: add a LLC feature flag in device description drm/i915: kill i915_mem.c drm/i915: Use kcalloc instead of kzalloc to allocate array drm/i915/dp: Check for AUXCH error before checking for success drm/i915/dp: Use auxch precharge value of 5 everywhere drm/i915/dp: Tweak auxch clock divider for PCH drm/i915: Remove a comment about PCH from the non-PCH path drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP) drm/i915: Implement plane-disabled assertion for PCH too drivers: i915: Fix BLC PWM register setup drm/i915: Check that plane/pipe is disabled before removing the fb drm/i915: fix typo in function name drm/i915: split out pll divider code drm/i915: split 9xx refclk & sdvo tv code out agp/intel: Add pci id for hostbridge from has/qemu drm/i915: there is no pipe CxSR on ironlake drm/i915: Only look for matching clocks for LVDS downclock drm/i915: Silence _DSM errors
-
- 03 Feb, 2012 20 commits
-
-
Sascha Hauer authored
info->fix.visual already is correctly set from drm_fb_helper_fill_fix. info->fix.line_length is also set from drm_fb_helper_fill_fix, so drm_fb_helper_set_par directly instead of a custom exynos_drm_fbdev_set_par. Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
Sascha Hauer authored
list_for_each_entry_safe is for walking a list safe against removal of entries. Here, no entries are removed, so use list_for_each_entry. Signed-off-by:
-
Sascha Hauer authored
Several comments above functions say that the caller must hold the mode_config lock, but the functions take the lock themselves. Fix the comments. Signed-off-by:
-
Sascha Hauer authored
crtc_id is set but never used, so remove it from struct drm_fb_helper_crtc. Signed-off-by:
-
Sascha Hauer authored
conn_limit is set but never used. Remove it from struct drm_fb_helper. Signed-off-by:
-
Sascha Hauer authored
drm_fb_helper_on|off currently manually searches for encoders to turn on/off. Make this simpler by using the helper function. Signed-off-by:
-
Sascha Hauer authored
drm_mode_crtc_set_gamma_size returns boolean true for success and false for failure. This is not very kernel conform, so change it to return 0 for success and a propert error code otherwise. Noone checks the return value, so no users have to be fixed. Signed-off-by:
-
Sascha Hauer authored
drm_setup_crtcs allocated modes using drm_mode_duplicate. Free them in drm_fb_helper_crtc_free. Signed-off-by:
-
Sascha Hauer authored
Modes are created using drm_mode_create which does a drm_mode_object_get, so use drm_mode_destroy in drm_mode_remove which does a drm_mode_object_put. Signed-off-by:
-
Sascha Hauer authored
to add the missing drm_mode_object_put for that mode. Signed-off-by:
-
Sascha Hauer authored
drm_mode_config_init initializes the idr with idr_init, so add the missing counterparts in drm_mode_config_cleanup. Signed-off-by:
-
Alex Deucher authored
Not likely this will be implemented anytime soon, but for completeness... Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
Previous patch only updates r3xx+. It's not likely anyone will use this on r1xx/r2xx, but add it for consistency. Signed-off-by:
-
Eugeni Dodonov authored
This allows to avoid talking to a non-responding bus repeatedly until we finally timeout after 15 attempts. We can do this by catching the -ENXIO error, provided by i2c_algo_bit:bit_doAddress call. Within the bit_doAddress we already try 3 times to get the edid data, so if the routine tells us that bus is not responding, it is mostly pointless to keep re-trying those attempts over and over again until we reach final number of retries. This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall edid detection timing by 10-30% in most cases, and by a much larger margin in case of phantom outputs (up to 30x in one worst case). Timing results for i915-powered machines for 'time xrandr' command: Machine 1: from 0.840s to 0.290s Machine 2: from 0.315s to 0.280s Machine 3: from +/- 4s to 0.184s Timing results for HD5770 with 'time xrandr' command: Machine 4: from 3.210s to 1.060s Reviewed-by:
Chris Wilson <chris@hchris-wilson.co.uk> Reviewed-by:
Keith Packard <keithp@keithp.com> Tested-by:
Sean Finney <seanius@seanius.net> Tested-by:
Soren Hansen <soren@linux2go.dk> Tested-by:
Hernando Torque <sirius@sonnenkinder.org> Tested-by:
Mike Lothian <mike@fireburn.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
-
Alex Deucher authored
Starting with DCE3 hardware, atom contains a general purpose ProcessI2cChannelTransaction similar to ProcessAuxChannelTransaction. Add an implementation using the atom tables for DCE3+ hardware. This should be a little less CPU intensive than bit banging and may work better in certain cases. Enable it by setting the radeon hw_i2c module parameter to 1. E.g., radeon.hw_i2c=1 on the kernel command line in grub. Signed-off-by:
-
Jean Delvare authored
The VESA specification suggests a 2.2 ms timeout on DDC channels. Use exactly that (as the i915 driver does) instead of hard-coding a jiffy count. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Reviewed-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Jean Delvare authored
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C devices can typically operate faster than this, 50 kbps should be fine for all devices (and compliant devices can always stretch the clock if needed.) FWIW, the vast majority of framebuffer drivers set udelay to 10 already. So set it to 10 in DRM drivers too, this will make EDID block reads faster. We might even lower the udelay value later if no problem is reported. Signed-off-by:
-
Ilija Hadzic authored
copy_blit operation works only on integral number of pages so benchmarks shorter than one page size (4K) do not make sense v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and sweep sizes between 1 * <page_size> to 16K * <page_size> doubling the size in each iteration; we get the same coverage, as in the original benchmark, but guarantee integer multiples of page size v3: add whitespace between '*' operator per review received from zajec5@gmail.com Signed-off-by:Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by:
-
Ilija Hadzic authored
R600/700 and Evergreen/NI blit code have a few redundant definitions in respective .c file. Move common definitions into a separate (new) .h file. Signed-off-by:
-
Mandeep Singh Baines authored
Its useful to be able to call the mode setting getter ioctls. Not requiring master fd, enables writing a simple program which can query the state of the video system. Since these ioctls are only "getters" there is no security or synchronization issues which would require master fd. Opening an new fd is already protected by the file permissions on the device file. Signed-off-by:
Mandeep Singh Baines <msb@chromium.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ilija Hadzic <ihadzic@research.bell-labs.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Stephane Marchesin <marcheu@chromium.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
- 02 Feb, 2012 8 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-clientLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: rbd: fix safety of rbd_put_client() rbd: fix a memory leak in rbd_get_client() ceph: create a new session lock to avoid lock inversion ceph: fix length validation in parse_reply_info() ceph: initialize client debugfs outside of monc->mutex ceph: change "ceph.layout" xattr to be "ceph.file.layout"
-
Josh Triplett authored
Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alex Elder authored
The rbd_client structure uses a kref to arrange for cleaning up and freeing an instance when its last reference is dropped. The cleanup routine is rbd_client_release(), and one of the things it does is delete the rbd_client from rbd_client_list. It acquires node_lock to do so, but the way it is done is still not safe. The problem is that when attempting to reuse an existing rbd_client, the structure found might already be in the process of getting destroyed and cleaned up. Here's the scenario, with "CLIENT" representing an existing rbd_client that's involved in the race: Thread on CPU A | Thread on CPU B --------------- | --------------- rbd_put_client(CLIENT) | rbd_get_client() kref_put() | (acquires node_lock) kref->refcount becomes 0 | __rbd_client_find() returns CLIENT calls rbd_client_release() | kref_get(&CLIENT->kref); | (releases node_lock) (acquires node_lock) | deletes CLIENT from list | ...and starts using CLIENT... (releases node_lock) | and frees CLIENT | <-- but CLIENT gets freed here Fix this by having rbd_put_client() acquire node_lock. The result could still be improved, but at least it avoids this problem. Signed-off-by:Alex Elder <elder@dreamhost.com> Signed-off-by:
Sage Weil <sage@newdream.net>
-
Christopher Yeoh authored
This fixes the race in process_vm_core found by Oleg (see http://article.gmane.org/gmane.linux.kernel/1235667/ for details). This has been updated since I last sent it as the creation of the new mm_access() function did almost exactly the same thing as parts of the previous version of this patch did. In order to use mm_access() even when /proc isn't enabled, we move it to kernel/fork.c where other related process mm access functions already are. Signed-off-by:
Chris Yeoh <yeohc@au1.ibm.com> Signed-off-by:
-
Alex Elder authored
If an existing rbd client is found to be suitable for use in rbd_get_client(), the rbd_options structure is not being freed as it should. Fix that. Signed-off-by:
-
Alex Elder authored
Lockdep was reporting a possible circular lock dependency in dentry_lease_is_valid(). That function needs to sample the session's s_cap_gen and and s_cap_ttl fields coherently, but needs to do so while holding a dentry lock. The s_cap_lock field was being used to protect the two fields, but that can't be taken while holding a lock on a dentry within the session. In most cases, the s_cap_gen and s_cap_ttl fields only get operated on separately. But in three cases they need to be updated together. Implement a new lock to protect the spots updating both fields atomically is required. Signed-off-by:
-
Xi Wang authored
"len" is read from network and thus needs validation. Otherwise, given a bogus "len" value, p+len could be an out-of-bounds pointer, which is used in further parsing. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
-
Sage Weil authored
Initializing debufs under monc->mutex introduces a lock dependency for sb->s_type->i_mutex_key, which (combined with several other dependencies) leads to an annoying lockdep warning. There's no particular reason to do the debugfs setup under this lock, so move it out. It used to be the case that our first monmap could come from the OSD; that is no longer the case with recent servers, so we will reliably set up the client entry during the initial authentication. We don't have to worry about racing with debugfs teardown by ceph_debugfs_client_cleanup() because ceph_destroy_client() calls ceph_msgr_flush() first, which will wait for the message dispatch work to complete (and the debugfs init to complete). Fixes: #1940 Signed-off-by:
-
