- 20 12月, 2011 23 次提交
-
-
由 Patrik Jakobsson 提交于
Replace psb_intel_output with psb_intel_encoder and psb_intel_connector. Things will need to be cleaned up and tested so consider this an initial patch for Cedarview. Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Patrik Jakobsson 提交于
Our current SDVO implementation is not working properly, so replace it with a modified version of the i915. Further testing and debugging is needed to make sure we can handle the different SDVO setups and wiring. Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Patrik Jakobsson 提交于
Before we integrate the new SDVO code we need GMBUS support Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Patrik Jakobsson 提交于
LVDS for PSB now uses psb_intel_encoder and psb_intel_connectors instead of psb_intel_output. i2c_bus and ddc_bus are moved to lvds_priv. There was also a pointer to mode_dev (for no obvious reason) that we now get directly from dev_priv. Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Patrik Jakobsson 提交于
Fix cases where we need to know what encoder type is behind a given connector. Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Patrik Jakobsson 提交于
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Patrik Jakobsson 提交于
First step towards adding i915 alike encoder and connector abstractions. This will make life easier when adding i915 output code into our driver. It also removes the old psb_intel_output struct. Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This just fixes up the staging code to keep building. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Otherwise each driver would need to keep the information inside their own framebuffer object structure. Also add offsets[]. BOs on the other hand are driver specific, so those can be kept in driver specific structures. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Help drivers a little by guaranteeing that crtc_x+crtc_w and crtc_y+crtc_h don't overflow. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Make sure the source coordinates stay within the buffer. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
These are the only indication to user space that the plane was disabled. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Several pointers and casts were missing __user annotations. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Unlock the mode_config mutex if drm_plane_init() fails. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
drm_fourcc.h can be included from user space so use the appropriate types. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Userspace needs this header. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
The code happened to compile because the flag wasn't actually used yet. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Christian Schmidt 提交于
My EFI BIOS starts the graphics card up in my projector's preferred EDID mode, 1080@60i. The Intel driver does not clear all the interlaced bits. This patch introduces a new PIPECONF_INTERLACE_MASK define and uses it to restore progressive mode. Signed-of-by: NChristian Schmidt <schmidt@digadd.de> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Christian Schmidt 提交于
The current logic misunderstands the spec about CEA 18byte descriptors. First, the spec doesn't state "detailed timing descriptors" but "18 byte descriptors", so any data record could be stored, mixed timings and other data, just as in the standard EDID. Second, the lower four bit of byte 3 of the CEA record do not contain the number of descriptors, but "the total number of DTDs defining native formats in the whole EDID [...], starting with the first DTD in the DTD list (which starts in the base EDID block)." A device can of course support non-native formats. As such the number can't be used to determine n, and the existing code will filter non-timing 18byte descriptors anyway. Signed-off-by: NChristian Schmidt <schmidt@digadd.de> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Christian Schmidt 提交于
CEA datablocks are only defined from revision 3 onwards. Only check for them if the revision says so. Signed-of-by: NChristian Schmidt <schmidt@digadd.de> Tested-by: NJames Cloos <cloos@jhcloos.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 12月, 2011 1 次提交
-
-
由 Christian Schmidt 提交于
TFT/plasma televisions and projectors have become commonplace, and so has the use of PCs to drive them. Add the video modes specified by an EDID's CEA extension to the mode database for a connector. Before: [ 1.158869] [drm:drm_mode_debug_printmodeline], Modeline 19:"1920x1080i" 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 [ 1.158875] [drm:drm_mode_debug_printmodeline], Modeline 18:"1920x1080i" 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15 [ 1.158882] [drm:drm_mode_debug_printmodeline], Modeline 20:"1920x1080" 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5 After: [ 1.144175] [drm:drm_mode_debug_printmodeline], Modeline 22:"1920x1080" 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 [ 1.144179] [drm:drm_mode_debug_printmodeline], Modeline 21:"1920x1080" 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15 [ 1.144187] [drm:drm_mode_debug_printmodeline], Modeline 30:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 [ 1.144190] [drm:drm_mode_debug_printmodeline], Modeline 29:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 [ 1.144192] [drm:drm_mode_debug_printmodeline], Modeline 25:"1920x1080" 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5 [ 1.144195] [drm:drm_mode_debug_printmodeline], Modeline 24:"1280x720" 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5 [ 1.144198] [drm:drm_mode_debug_printmodeline], Modeline 23:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 [ 1.144201] [drm:drm_mode_debug_printmodeline], Modeline 27:"720x576" 50 27000 720 732 796 864 576 581 586 625 0x40 0xa [ 1.144203] [drm:drm_mode_debug_printmodeline], Modeline 26:"720x480" 60 27000 720 736 798 858 480 489 495 525 0x40 0xa [ 1.144206] [drm:drm_mode_debug_printmodeline], Modeline 28:"640x480" 60 25175 640 656 752 800 480 490 492 525 0x40 0xa Signed-off-by: NChristian Schmidt <schmidt@digadd.de> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 06 12月, 2011 16 次提交
-
-
由 Dave Airlie 提交于
Merge topic branch containing Jerome's TTM changes, contains one change from Konrad to swiotlb export. * 'drm-ttm-glisse' of ../drm-radeon-next: drm/ttm: callback move_notify any time bo placement change v4 drm/ttm: simplify memory accounting for ttm user v2 drm/ttm: isolate dma data from ttm_tt V4 drm/nouveau: enable the ttm dma pool when swiotlb is active V3 drm/radeon/kms: enable the ttm dma pool if swiotlb is on V4 drm/ttm: provide dma aware ttm page pool code V9 drm/ttm: introduce callback for ttm_tt populate & unpopulate V4 drm/ttm: merge ttm_backend and ttm_tt V5 drm/ttm: page allocation use page array instead of list drm/ttm: test for dma_address array allocation failure drm/ttm: use ttm put pages function to properly restore cache attribute drm/ttm: remove unused backend flags field drm/ttm: remove split btw highmen and lowmem page drm/ttm: remove userspace backed ttm object support swiotlb: Expose swiotlb_nr_tlb function to modules
-
由 Jerome Glisse 提交于
Previously we were calling back move_notify in error path when the bo is returned to it's original position or when destroy the bo. When destroying the bo set the new mem placement as NULL when calling back in the driver. Updating nouveau to deal with NULL placement properly. v2: reserve the object before calling move_notify in bo destroy path at that point ttm should be the only piece of code interacting with the object so atomic_set is safe here. v3: callback move notify only once the bo is in its new position call move notify want swaping out the buffer v4:- don't call move_notify when swapin out bo, assume driver should do what is appropriate in swap notify - move move_notify call back to ttm_bo_cleanup_memtype_use for destroy path Reviewed-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
Provide helper function to compute the kernel memory size needed for each buffer object. Move all the accounting inside ttm, simplifying driver and avoiding code duplication accross them. v2 fix accounting of ghost object, one would have thought that i would have run into the issue since a longtime but it seems ghost object are rare when you have plenty of vram ;) Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
Move dma data to a superset ttm_dma_tt structure which herit from ttm_tt. This allow driver that don't use dma functionalities to not have to waste memory for it. V2 Rebase on top of no memory account changes (where/when is my delorean when i need it ?) V3 Make sure page list is initialized empty V4 typo/syntax fixes Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Konrad Rzeszutek Wilk 提交于
If the card is capable of more than 32-bit, then use the default TTM page pool code which allocates from anywhere in the memory. Note: If the 'ttm.no_dma' parameter is set, the override is ignored and the default TTM pool is used. V2 use pci_set_consistent_dma_mask V3 Rebase on top of no memory account changes (where/when is my delorean when i need it ?) CC: Ben Skeggs <bskeggs@redhat.com> CC: Francisco Jerez <currojerez@riseup.net> CC: Dave Airlie <airlied@redhat.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com>
-
由 Konrad Rzeszutek Wilk 提交于
With the exception that we do not handle the AGP case. We only deal with PCIe cards such as ATI ES1000 or HD3200 that have been detected to only do DMA up to 32-bits. V2 force dma32 if we fail to set bigger dma mask V3 Rebase on top of no memory account changes (where/when is my delorean when i need it ?) V4 add debugfs entry is swiotlb is active not only if we are on dma 32bits only gpu CC: Dave Airlie <airlied@redhat.com> CC: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com>
-
由 Konrad Rzeszutek Wilk 提交于
In TTM world the pages for the graphic drivers are kept in three different pools: write combined, uncached, and cached (write-back). When the pages are used by the graphic driver the graphic adapter via its built in MMU (or AGP) programs these pages in. The programming requires the virtual address (from the graphic adapter perspective) and the physical address (either System RAM or the memory on the card) which is obtained using the pci_map_* calls (which does the virtual to physical - or bus address translation). During the graphic application's "life" those pages can be shuffled around, swapped out to disk, moved from the VRAM to System RAM or vice-versa. This all works with the existing TTM pool code - except when we want to use the software IOTLB (SWIOTLB) code to "map" the physical addresses to the graphic adapter MMU. We end up programming the bounce buffer's physical address instead of the TTM pool memory's and get a non-worky driver. There are two solutions: 1) using the DMA API to allocate pages that are screened by the DMA API, or 2) using the pci_sync_* calls to copy the pages from the bounce-buffer and back. This patch fixes the issue by allocating pages using the DMA API. The second is a viable option - but it has performance drawbacks and potential correctness issues - think of the write cache page being bounced (SWIOTLB->TTM), the WC is set on the TTM page and the copy from SWIOTLB not making it to the TTM page until the page has been recycled in the pool (and used by another application). The bounce buffer does not get activated often - only in cases where we have a 32-bit capable card and we want to use a page that is allocated above the 4GB limit. The bounce buffer offers the solution of copying the contents of that 4GB page to an location below 4GB and then back when the operation has been completed (or vice-versa). This is done by using the 'pci_sync_*' calls. Note: If you look carefully enough in the existing TTM page pool code you will notice the GFP_DMA32 flag is used - which should guarantee that the provided page is under 4GB. It certainly is the case, except this gets ignored in two cases: - If user specifies 'swiotlb=force' which bounces _every_ page. - If user is using a Xen's PV Linux guest (which uses the SWIOTLB and the underlaying PFN's aren't necessarily under 4GB). To not have this extra copying done the other option is to allocate the pages using the DMA API so that there is not need to map the page and perform the expensive 'pci_sync_*' calls. This DMA API capable TTM pool requires for this the 'struct device' to properly call the DMA API. It also has to track the virtual and bus address of the page being handed out in case it ends up being swapped out or de-allocated - to make sure it is de-allocated using the proper's 'struct device'. Implementation wise the code keeps two lists: one that is attached to the 'struct device' (via the dev->dma_pools list) and a global one to be used when the 'struct device' is unavailable (think shrinker code). The global list can iterate over all of the 'struct device' and its associated dma_pool. The list in dev->dma_pools can only iterate the device's dma_pool. /[struct device_pool]\ /---------------------------------------------------| dev | / +-------| dma_pool | /-----+------\ / \--------------------/ |struct device| /-->[struct dma_pool for WC]</ /[struct device_pool]\ | dma_pools +----+ /-| dev | | ... | \--->[struct dma_pool for uncached]<-/--| dma_pool | \-----+------/ / \--------------------/ \----------------------------------------------/ [Two pools associated with the device (WC and UC), and the parallel list containing the 'struct dev' and 'struct dma_pool' entries] The maximum amount of dma pools a device can have is six: write-combined, uncached, and cached; then there are the DMA32 variants which are: write-combined dma32, uncached dma32, and cached dma32. Currently this code only gets activated when any variant of the SWIOTLB IOMMU code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xen PV with PCI devices). Tested-by: NMichel Dänzer <michel@daenzer.net> [v1: Using swiotlb_nr_tbl instead of swiotlb_enabled] [v2: Major overhaul - added 'inuse_list' to seperate used from inuse and reorder the order of lists to get better performance.] [v3: Added comments/and some logic based on review, Added Jerome tag] [v4: rebase on top of ttm_tt & ttm_backend merge] [v5: rebase on top of ttm memory accounting overhaul] [v6: New rebase on top of more memory accouting changes] [v7: well rebase on top of no memory accounting changes] [v8: make sure pages list is initialized empty] [v9: calll ttm_mem_global_free_page in unpopulate for accurate accountg] Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Acked-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
Move the page allocation and freeing to driver callback and provide ttm code helper function for those. Most intrusive change, is the fact that we now only fully populate an object this simplify some of code designed around the page fault design. V2 Rebase on top of memory accounting overhaul V3 New rebase on top of more memory accouting changes V4 Rebase on top of no memory account changes (where/when is my delorean when i need it ?) Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
ttm_backend will only exist with a ttm_tt, and ttm_tt will only be of interest when bound to a backend. Merge them to avoid code and data duplication. V2 Rebase on top of memory accounting overhaul V3 Rebase on top of more memory accounting changes V4 Rebase on top of no memory account changes (where/when is my delorean when i need it ?) V5 make sure ttm is unbound before destroying, change commit message on suggestion from Tormod Volden Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
Use the ttm_tt pages array for pages allocations, move the list unwinding into the page allocation functions. Signed-off-by: NJerome Glisse <jglisse@redhat.com>
-
由 Jerome Glisse 提交于
Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
On failure we need to make sure the page we free has wb cache attribute. Do this pas call the proper ttm page helper function. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
This field is not use by any of the driver just drop it. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
Split btw highmem and lowmem page was rendered useless by the pool code. Remove it. Note further cleanup would change the ttm page allocation helper to actualy take an array instead of relying on list this could drasticly reduce the number of function call in the common case of allocation whole buffer. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Jerome Glisse 提交于
This was never use in none of the driver, properly using userspace page for bo would need more code (vma interaction mostly). Removing this dead code in preparation of ttm_tt & backend merge. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Konrad Rzeszutek Wilk 提交于
As a mechanism to detect whether SWIOTLB is enabled or not. We also fix the spelling - it was swioltb instead of swiotlb. CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> [v1: Ripped out swiotlb_enabled] Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-