- 27 4月, 2012 8 次提交
-
-
由 Alan Cox 提交于
Introduce a panel presence check for Cedartrail. Non netbook devices don't necessarily have a panel attached. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alan Cox 提交于
Pull in various i915 bits that we will need to begin tackling the LVDS detect and ACPI events. We try and drift towards the i915 version of the code with the long term goal that at least some of it can one day be unified. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alan Cox 提交于
We don't want them uncached, combining will do nicely and fixes the performance problem with the generic modesetting X server. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alan Cox 提交于
Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alan Cox 提交于
We need to pull more stuff from the VBT in order to configure the clocking correctly in all cases. Add the relevant bits from the other CDV driver work. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alan Cox 提交于
This was reported a long time ago (and I apologize to whoever it was that reported it as I've lost the original report). Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ian Pilcher 提交于
EDID vendor IDs are always 3 characters long (4 with the terminating 0). It doesn't make any sense to have a (possibly 8-byte) pointer to the ID string in the quirk structure. Signed-off-by: NIan Pilcher <arequipeno@gmail.com> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
Requiring the first byte of the EDID base block header to be 0 means we don't fix up as many transfer errors as we could. Instead have the callers specify whether it's meant to be block 0 or not, and conditionally run header fixup based on that. Bugzilla: https://bugzilla.redhat.com/812890Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 24 4月, 2012 9 次提交
-
-
由 Matthew Garrett 提交于
This fixes the build breakage reported by Stephen in -next when merging the drm-next tree. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
The error handling code w.r.t. idr usage looks inconsistent. In the case of drm_mode_object_get() and drm_ctxbitmap_next() the error handling is also incomplete. Unify the code to follow the same pattern always. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Since Matthew's changes we have to select arbitration. Reported-by: devh on #radeon Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Matthew Garrett 提交于
vga-switcheroo currently changes the default VGA device by fiddling with the IORESOURCE_ROM_SHADOW flag on the device. This isn't strictly accurate, since there's no guarantee that switching also changes the ROM decoding. Switch over to using the vgaarb functions for this. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Matthew Garrett 提交于
The default VGA device is a somewhat fluid concept on platforms with multiple GPUs. Add support for setting it so switching code can update things appropriately, and make sure that the sysfs code returns the right device if it's changed. v2: Updated to fix builds when __ARCH_HAS_VGA_DEFAULT_DEVICE is false. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Acked-by: NH. Peter Anvin <hpa@zytor.com> Acked-by: benh@kernel.crashing.org Cc: airlied@redhat.com Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
- add support for rs6xx - add support for DCE4/5 - fixup 6xx/7xx Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
This adds register definitions for HDMI/DP audio on DCE2/3/4/5 hardware. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Improve handling of bpc (bits per color) in radeon. In most cases we want 8 except for HDMI, DP, LVDS, and eDP. v2: handle DP better. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Tested-by: NLennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Takashi Iwai 提交于
HD panel (1366x768) found most commonly on laptops can't be represented exactly in CVT/DMT expression, which leads to 1368x768 instead, because 1366 can't be divided by 8. Add a hack to convert to 1366x768 manually as an exception. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 20 4月, 2012 21 次提交
-
-
由 Jim Cromie 提交于
[airlied: fixed one more new one added since] Signed-off-by: NJim Cromie <jim.cromie@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Takashi Iwai 提交于
Reviewed-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
Some common sizes that don't show up in DMT. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
We want the same type for extra modes inferred from ranges. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is continuous frequency", and moves the set of supported timing formulas into the range descriptor itself. In any event, the range descriptor can act as a filter on the DMT list without regard to a specific timing formula. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
Copied from the list in xserver. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
Slightly more honest naming. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
mode_in_range() handles what this was warning about. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
It won't find any, yet. Fix up callers to match: standard mode codes will look prefer r-b modes for a given size if present, EST3 mode codes will look for exactly the r-b-ness mentioned in the mode code. This might mean fewer modes matched for EST3 mode codes between now and when the DMT mode list regrows the r-b modes, but practically speaking EST3 codes don't exist in the wild. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
No functional change, but will make an upcoming change clearer. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Adam Jackson 提交于
Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Paulo Zanoni 提交于
CEA modes 6, 7, 8, 9, 21, 22, 23, 24, 44, 45, 50, 51, 54, 55, 58 and 59 require sending pixel data 2 times. This doesn't mean the modes will work yet, but now the drivers know they're different. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Paulo Zanoni 提交于
The specification defines a VIC (Video Identification Code) for each mode. When we're browsing drm_edid_modes.h, it really helps to have the number available (otherwise we have to count...). These numbers are also used in the EDID data (by the CEA-EXT extension block). Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lars-Peter Clausen 提交于
The CEA extension block has a field which describes which YCbCr modes are supported by the device, use it to fill the drm_display_info color_formats fields. Also the existence of a CEA extension block is used as indication that the device supports RGB. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lars-Peter Clausen 提交于
The code should obviously check the EDID feature field for EDID feature flags and not the color_formats field of the drm_display_info struct. Also update the color_formats field with new modes instead of overwriting the current mode. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Perform some basic sanity check on some of the parameters in drm_mode_fb_cmd2. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
These functions return the chroma subsampling factors for the specified pixel format. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
This function returns the bytes per pixel value based on the pixel format and plane index. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
There will be a need for this function in drm_crtc.c later. This avoids making drm_crtc.c depend on drm_crtc_helper.c. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 12 4月, 2012 2 次提交
-
-
由 Dave Airlie 提交于
On coherent systems (not-AGP) the IB should be in cached memory so should be just as fast, so we can avoid copying to temporary pages and just use it directly. provides minor speedups on rv530: gears ~1820->1860, ipers: 29.9->30.6, but always good to use less CPU if we can. v3: cleanup unneeded bits. Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This closes a race seen with kexec where we enable PCI bus mastering but the card has been reinitialised fully yet. This was previously fixed by a patch from Jerome, but this should close the race completely. v2: add SI support as suggested by Alex. Reported-and-tested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-