gma500: SDVO DDC bus guessing isn't working so hardcode it instead

We currently don't have support for parsing SDVO mappings from BIOS so we're
guessing the bus switch parameter. This isn't working so hardcode it to a
configuration known to work on most poulsbo hardware.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Convert Oaktrail to work with new output handling

Replace psb_intel_output with psb_intel_encoder and psb_intel_connector

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
[Changed Moorestown reference to Oaktrail]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Convert Cedarview to work with new output handling

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: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Replace SDVO code with slightly modified version from i915

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: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add support for Intel GMBUS

Before we integrate the new SDVO code we need GMBUS support

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Convert PSB LVDS to new output handling

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: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Fix encoder type checking for connectors

Fix cases where we need to know what encoder type is behind a given connector.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Remove psb_intel_output from ddc_probe and ddc_get_modes

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Initial support for our encoder and connector structs

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: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

staging/gma500: fixup staging code to build following core changes.

This just fixes up the staging code to keep building.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Replace pitch with pitches[] in drm_framebuffer

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Check that the requested pixel format is valid

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: plane: Check that the fb pixel format is supported by the plane

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: plane: Make 'formats' parameter to drm_plane_init() const

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: plane: Check crtc coordinates against integer overflows in setplane ioctl

Help drivers a little by guaranteeing that crtc_x+crtc_w and
crtc_y+crtc_h don't overflow.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: plane: Check source coordinates

Make sure the source coordinates stay within the buffer.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: plane: Clear plane.crtc and plane.fb after disable_plane()

These are the only indication to user space that the plane was disabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Fix __user sparse warnings

Several pointers and casts were missing __user annotations.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: plane: mutex_unlock() was missing

Unlock the mode_config mutex if drm_plane_init() fails.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: fourcc: Use __u32 instead of u32

drm_fourcc.h can be included from user space so use the appropriate types.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Install drm_fourcc.h

Userspace needs this header.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Add a missing ')'

The code happened to compile because the flag wasn't actually used yet.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/intel: Fix initialization if startup happens in interlaced mode [v2]

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: Christian Schmidt <schmidt@digadd.de>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Fix wrong assumptions in cea_for_each_detailed_block v2

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: Christian Schmidt <schmidt@digadd.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm_edid_to_eld: check for CEA data blocks only from structure revision 3 on

CEA datablocks are only defined from revision 3 onwards. Only check for
them if the revision says so.

Signed-of-by: Christian Schmidt <schmidt@digadd.de>
Tested-by: James Cloos <cloos@jhcloos.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/edid: support CEA video modes.

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: Christian Schmidt <schmidt@digadd.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/Merge branch 'drm-ttm-glisse' of ../drm-radeon-next into drm-core-next

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

drm/ttm: callback move_notify any time bo placement change v4

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: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: simplify memory accounting for ttm user v2

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: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: isolate dma data from ttm_tt V4

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: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/nouveau: enable the ttm dma pool when swiotlb is active V3

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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>

drm/radeon/kms: enable the ttm dma pool if swiotlb is on V4

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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>

drm/ttm: provide dma aware ttm page pool code V9

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: Michel 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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Acked-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: introduce callback for ttm_tt populate & unpopulate V4

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: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: merge ttm_backend and ttm_tt V5

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: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: page allocation use page array instead of list

Use the ttm_tt pages array for pages allocations, move the list
unwinding into the page allocation functions.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>

drm/ttm: test for dma_address array allocation failure

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: use ttm put pages function to properly restore cache attribute

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: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: remove unused backend flags field

This field is not use by any of the driver just drop it.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: remove split btw highmen and lowmem page

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: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

drm/ttm: remove userspace backed ttm object support

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: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

swiotlb: Expose swiotlb_nr_tlb function to modules

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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

drm: Merge branch 'drm-cleanups-jbarnes' into drm-core-next

Merge topic branch with some of Jesse's cleanups, the save/restore hooks
were being used by GMA500 so we can't just drop them.

* drm-cleanups-jbarnes:
  drm: remove some potentially dangerous DRM_ERRORs
  drm: document the drm_mode_config structure
  drm: document the drm_mode_group structure
  drm: document and cleanup drm_mode_config_funcs
  drm: document drm_mode_set structure
  drm: remove unused fields in drm_connector and document the rest
  drm: add drm_encoder comments
  drm: add comments for drm_encoder_funcs
  drm: fix comments for drm_crtc struct
  drm: remove unused connector_count field from drm_display_mode

drm: remove some potentially dangerous DRM_ERRORs

Each of these error messages can be caused by a broken or malicious
userspace wanting to spam the dmesg with useless info.  They're really
not worthy of DRM_DEBUG statements either; those are generally only
useful during bringup of new hardware or versions, and ought to be
removed before going upstream anyway.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: document the drm_mode_config structure

Including a comment about what the locks are for.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: document the drm_mode_group structure

This is actually a core structure with a big future ahead of it.  Make
it a little less mysterious.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: document and cleanup drm_mode_config_funcs

Just fix the wrapping mostly.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: document drm_mode_set structure

This is a core mode setting structure that deserves a little verbiage.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: remove unused fields in drm_connector and document the rest

We never used initial_x/y or the force_encoder_id, so drop those fields
and proide a basic description of the others.

Really, the ELD bits belong in drm_display_info rather than directly in
the connector, but that's a separate cleanup.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add drm_encoder comments

Just some basic comments about the place and function of the structure
and fields.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add comments for drm_encoder_funcs

Just basic verbiage.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: fix comments for drm_crtc struct

Remove stale entries and update with the latest stuff.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: remove unused connector_count field from drm_display_mode

Doesn't really belong here anyway.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Merge branch 'drm-gma500-alancox' into drm-core-next

This merges a topic branch containing patches from Alan for the GMA500 driver.

* drm-gma500-alancox:
  gma500: Oaktrail BIOS handling
  gma500: Fix oaktrail probing part 1
  gma500: Be smarter about layout
  gma500: gtt based hardware scrolling console
  gma500: frame buffer locking
  gma500: Fix backlight crash
  gma500: kill bogus code
  gma500: Convert spaces to tabs in accel_2d.c.
  gma500: do a pass over the FIXME tags
  gma500: Add VBLANK support for Poulsbo hardware
  gma500: Don't enable MSI on Poulsbo
  gma500: Only register interrupt handler for poulsbo hardware
  gma500: kill virtual mapping support
  gma500: Move the API
  gma500: kill off NUM_PIPE define
  gma500: Rename the ioctls to avoid clashing with the legacy drivers
  drm/gma500: begin pruning dead bits of API

gma500: Oaktrail BIOS handling

Now that we pull the right BIOS data out of the hat we need to use it when
doing our panel setup.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Fix oaktrail probing part 1

The Oaktrail platform does not use the GCT/VBT format that is used by the
Moorestowm (non PC legacy) equivalent device. It uses the BIOS tables which
means an opregion and the like.

The current code uses the wrong table which breaks things like the Fujitsu
q550 tablets. Fix the table usage as a first step.

The problem was found and diagnosed by Chia-I Wu

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Be smarter about layout

If we can't fit a page aligned display stride then it's not the end of the
world for a normal font, so try half a page and work down sizes.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: gtt based hardware scrolling console

Add support for GTT based scrolling. Instead of pushing bits around we simply
use the GTT to change the mappings. This provides us with a very fast way to
scroll the display providing we have enough memory to allocate on 4K line
boundaries. In practice this seems to be the case except for very big displays
such as HDMI, and the usual configurations are netbooks/tablets.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: frame buffer locking

If we are the console then a printk can hit us with a spin lock held (and
in fact the kernel will do its best to take the console printing lock).

In that case we cannot politely sleep when synching after an accelerated op
but must behave obnoxiously to be sure of getting the bits out.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Fix backlight crash

Initial changes to get backlight behaviour we want and to fix backlight crashes
on suspend/resume paths.

[Note: on some boxes this will now produce a warning about the backlight, this
 isn't a regression it's an unfixed but non harmful case I still need to nail]

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: kill bogus code

During the power split ups and work a chunk of code escaped into the
Poulsbo code path which it isn't for. On some devices such as the Dell
mini-10 this causes problems.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Convert spaces to tabs in accel_2d.c.

Convert the spaces within the accel_2d.c file to tabs in order to comply
with the coding style of the kernel.

Signed-off-by: Akshay Joshi <me@akshayjoshi.com>
[Trimmed to subset relevant to current tree]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: do a pass over the FIXME tags

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add VBLANK support for Poulsbo hardware

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Don't enable MSI on Poulsbo

Chipset reports MSI capabilities for Poulsbo even though it isn't really there.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Only register interrupt handler for poulsbo hardware

First step in adding proper irq handling. We'll start with poulsbo support so
make sure other chips don't touch drm_irq_install().

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: kill virtual mapping support

This isn't actually usable - we simply don't have the vmap space on a 32bit
system to do this stunt. Instead we will rely on the low level drivers
limiting the console resolution as before.

The real fix is for someone to write a page table aware version of the
framebuffer console blit functions. Good university student project
perhaps..

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Move the API

Finally move the API where it can be seen

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: kill off NUM_PIPE define

We don't want this external in case someone adds more to the hardware. We
want it out of the ABI.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Rename the ioctls to avoid clashing with the legacy drivers

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gma500: begin pruning dead bits of API

At this point we won't add an external set of definitions. We want to get
everything out before we admit to a public API beyond the standardised
ones.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Redefine pixel formats

Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
names, especially for the RGB formats. Component order and byte order are
now strictly specified for each format.

The RGB format naming follows a convention where the components names
and sizes are listed from left to right, matching the order within a
single pixel from most significant bit to least significant bit.

The YUV format names vary more. For the 4:2:2 packed formats and 2
plane formats use the fourcc. For the three plane formats the
name includes the plane order and subsampling information using the
standard subsampling notation. Some of those also happen to match
the official fourcc definition.

The fourccs for for all the RGB formats and some of the YUV formats
I invented myself. The idea was that looking at just the fourcc you
get some idea what the format is about without having to decode it
using some external reference.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: move the fb bpp/depth helper into the core.

This is used by nearly everyone including vmwgfx which doesn't generally
use the fb helper.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon/kms: fix up for BIG ENDIAN breakage

Commit 308e5bcbdb10 ("drm: add an fb creation ioctl that takes a pixel
format v5") missed one spot needing to be fixed up in the __BIG_ENDIAN
case.

Fixes build error:

drivers/gpu/drm/radeon/radeon_fb.c: In function
'radeonfb_create_pinned_object':
drivers/gpu/drm/radeon/radeon_fb.c:144:18: error: 'struct drm_mode_fb_cmd2'
has no member named 'bpp'

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gma500: fix compile error

fops field in drm_driver is a pointer to file_operations
struct, not embedded structure

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gma500: remove genrated file

psb_gfx.mod.c is a generated file and should not be
revision controlled

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gma500: port framebuffer to new plane interface.

This takes over the staging change into the mainline driver.

Fixes -next part one.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/staging/gma500: fix linux-next build

Here's a patch to move things over to the new addfb2 interfaces at
least.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-gma500-alanc' into drm-core-next

* drm-gma500-alanc:
  gma500: Now connect up to the DRM build to finish the job
  gma500: fixup build versus latest header changes.
  gma500: Add support for Cedarview
  gma500: Add Oaktrail support
  gma500: Add Poulsbo support
  gma500: Add the core DRM files and headers
  gma500: Add the i2c bus support
  gma500: Add the glue to the various BIOS and firmware interfaces
  gma500: Add device framework
  gma500: introduce the framebuffer support code
  gma500: introduce the GTT and MMU handling logic
  gma500: GEM and GEM glue
  gma500: Move the basic driver out of staging

gma500: Now connect up to the DRM build to finish the job

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: fixup build versus latest header changes.

Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add support for Cedarview

Again this is similar but has some differences so we have a set of plug in
support. This does make the driver bigger than is needed in some respects
but the tradeoff for maintainability is huge.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add Oaktrail support

Oaktrail (GMA600) is found on some tablet/slate PC type systems. It's a bit
different to the GMA500 but similar enough it makes sense to plug it into
the same driver.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add Poulsbo support

This provides the specific code for Poulsbo, some of which is also used for
the later chipsets. We support the GTT, the 2D engine (for console), and
the display setup/management. We do not support 3D or the video overlays.

In theory enough public info is available to do the video overlay work
but that represents a large task.

Framebuffer X will run nicely with this but do *NOT* use the VESA X
server at the same time as KMS. With a Dell mini 10 things like Xfce4 are
nice and usable even when compositing as the CPU has a good path to the
memory.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add the core DRM files and headers

Not really a nice way to split this up further for submission. This
provides all the DRM interfacing logic, the headers and relevant glue.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add the i2c bus support

Again this might be a candidate for sharing later.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add the glue to the various BIOS and firmware interfaces

Some of this should one day become a library shared by i915 and gma500 I
suspct. Best however to deal with that later once it is all nice and
stably merged.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Add device framework

The devices have various internal differences so we have some abstractions
to hide the ugly differences and we then wrap them up in standard
interfaces. Add these bits

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: introduce the framebuffer support code

We support 2D acceleration on some devices but we try and do tricks with
the GTT as a starting point as this is far faster. The GTT logic could be
improved further but for most display sizes it already makes a pretty good
decision.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: introduce the GTT and MMU handling logic

This fits alongside the GEM support to manage our resources on the card
itself. It's not actually clear we need to configure the MMU at all.
Further research is needed before removing it entirely. For now we suck it
in (slightly abused) from the old semi-free driver.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: GEM and GEM glue

The driver uses GEM along with a couple of small bits of wrapping of its
own. The only real oddity here is the support for using the 'stolen' memory
rather than wasting several MB.

We use a simple resource manager as we don't need to manage our space
intensively at all as we only do 2D work. We also have a GTT which is
entirely GPU facing so in the Cedarview case are not even allocating from
host address space.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gma500: Move the basic driver out of staging

This driver supports unaccelerated KMS display, and accelerated console
handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware.

For the initial merge Medfield will be left out as it needs considerable
further work to reach a decent standard

Begin by adding the Makefiles and Kconfig. These are not yet plumbed into
the DRM layer so will have no effect on their own

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-plane-jbarnes' into drm-core-next

* drm-plane-jbarnes:
  drm: add an fb creation ioctl that takes a pixel format v5
  drm: add plane support v3

drm: add an fb creation ioctl that takes a pixel format v5

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
    update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
    pull in Ville's fix for the memcpy in drm_plane_init
    apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add plane support v3

Planes are a bit like half-CRTCs.  They have a location and fb, but
don't drive outputs directly.  Add support for handling them to the core
KMS code.

v2: fix ABI of get_plane - move format_type_ptr to the end
v3: add 'flags' field for interlaced support (from Ville)

Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Make the per-driver file_operations struct const

From fdf1fdebaa00f81de18c227f32f8074c8b352d50 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sun, 30 Oct 2011 19:06:07 -0700
Subject: [PATCH] drm: Make the per-driver file_operations struct const

The DRM layer keeps a copy of struct file_operations inside its
big driver struct... which prevents it from being consistent and static.
For consistency (and the general security objective of having such things
static), it's desirable to get this fixed.

This patch splits out the file_operations field to its own struct,
which is then "static const", and just stick a pointer to this into
the driver struct, making it more consistent with how the rest of the
kernel does this.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: avoid switching to text console if there is no panic timeout

Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
we're going to reboot immediately, the user will not be able to see the
messages anyway, and messing with the video mode may display artifacts,
and certainly get into several layers of complexity (including mutexes and
memory allocations) which we shall be much safer to avoid.

Signed-off-by: Hugh Dickins <hughd@google.com>
[ Edited commit message and modified to short-circuit panic_timeout < 0
  instead of testing panic_timeout >= 0.  -Mandeep ]
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Linux 3.2-rc1

.. with new name.  Because nothing says "really solid kernel release"
like naming it after an extinct animal that just happened to be in the
news lately.

Merge branch 'fixes' of git://git./linux/kernel/git/tmlind/linux-omap

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (31 commits)
  ARM: OMAP: Fix export.h or module.h includes
  ARM: OMAP: omap_device: Include linux/export.h
  ARM: OMAP2: Fix H4 matrix keyboard warning
  ARM: OMAP1: Remove unused omap-alsa.h
  ARM: OMAP1: Fix warnings about enabling 32 KiHz timer
  ARM: OMAP2+: timer: Remove omap_device_pm_latency
  ARM: OMAP2+: clock data: Remove redundant timer clkdev
  ARM: OMAP: Devkit8000: Remove double omap_mux_init_gpio
  ARM: OMAP: usb: musb: OMAP: Delete unused function
  MAINTAINERS: Update linux-omap git repository
  ARM: OMAP: change get_context_loss_count ret value to int
  ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properly
  ARM: OMAP4: hsmmc: Fix Pbias configuration on regulator OFF
  ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list
  ARM: OMAP: I2C: Fix omap_register_i2c_bus() return value on success
  ARM: OMAP: dmtimer: Include linux/module.h
  ARM: OMAP2+: l3-noc: Include linux/module.h
  ARM: OMAP2+: devices: Fixes for McPDM
  ARM: OMAP: Fix errors and warnings when building for one board
  ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only
  ...

VFS: we need to set LOOKUP_JUMPED on mountpoint crossing

Mountpoint crossing is similar to following procfs symlinks - we do
not get ->d_revalidate() called for dentry we have arrived at, with
unpleasant consequences for NFS4.

Simple way to reproduce the problem in mainline:

    cat >/tmp/a.c <<'EOF'
    #include <unistd.h>
    #include <fcntl.h>
    #include <stdio.h>
    main()
    {
            struct flock fl = {.l_type = F_RDLCK, .l_whence = SEEK_SET, .l_len = 1};
            if (fcntl(0, F_SETLK, &fl))
                    perror("setlk");
    }
    EOF
    cc /tmp/a.c -o /tmp/test

then on nfs4:

    mount --bind file1 file2
    /tmp/test < file1 # ok
    /tmp/test < file2 # spews "setlk: No locks available"...

What happens is the missing call of ->d_revalidate() after mountpoint
crossing and that's where NFS4 would issue OPEN request to server.

The fix is simple - treat mountpoint crossing the same way we deal with
following procfs-style symlinks.  I.e.  set LOOKUP_JUMPED...

Cc: stable@kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>