v2: fix rebase onto drm-fixes
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplug_event()
helper is used by a driver, then the poll helper requires some parts of
the FB helper to be initialized to prevent a crash.

At the same time, drm_fb_helper_init() requires information that is not
necessarily available at such an early stage (number of CRTCs and
connectors), so it cannot be used yet.

Add a new helper, drm_fb_helper_prepare(), that initializes the bare
minimum needed to allow drm_kms_helper_poll_init() to execute and any
subsequent hotplug events to be processed properly.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Correct spelling typo in various part of drivers
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should be done in the drivers for two reasons:
- it gets in the way of fastboot efforts
- it links the fb helpers with the crtc helpers instead of going
  through the real interface vfuncs, forcing i915 to fake all the
  ->disable callbacks used by the crtc helper to avoid ugly Oopsen

v2: Resolve conflicts since drivers still call
drm_fb_helper_single_add_all_connectors.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have two classes of framebuffer
- Created by the driver (atm only for fbdev), and the driver holds
  onto the last reference count until destruction.
- Created by userspace and associated with a given fd. These
  framebuffers will be reaped when their assoiciated fb is closed.

Now these two cases are set up differently, the framebuffers are on
different lists and hence destruction needs to clean up different
things. Also, for userspace framebuffers we remove them from any
current usage, whereas for internal framebuffers it is assumed that
the driver has done this already.

Long story short, we need two different ways to cleanup such drivers.
Three functions are involved in total:
- drm_framebuffer_remove: Convenience function which removes the fb
  from all active usage and then drops the passed-in reference.
- drm_framebuffer_unregister_private: Will remove driver-private
  framebuffers from relevant lists and drop the corresponding
  references. Should be called for driver-private framebuffers before
  dropping the last reference (or like for a lot of the drivers where
  the fbdev is embedded someplace else, before doing the cleanup
  manually).
- drm_framebuffer_cleanup: Final cleanup for both classes of fbs,
  should be called by the driver's ->destroy callback once the last
  reference is gone.

This patch just rolls out the new interfaces and updates all drivers
(by adding calls to drm_framebuffer_unregister_private at all the
right places)- no functional changes yet. Follow-on patches will move
drm core code around and update the lifetime management for
framebuffers, so that we are no longer required to keep framebuffers
alive by locking mode_config.mutex.

I've also updated the kerneldoc already.

vmwgfx seems to again be a bit special, at least I haven't figured out
how the fbdev support in that driver works. It smells like it's
external though.

v2: The i915 driver creates another private framebuffer in the
load-detect code. Adjust its cleanup code, too.
Reviewed-by: NRob Clark <rob@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Remove redundant DRM UAPI header #inclusions from drivers/gpu/.

Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and
drm_sarea.h).  They are now #included via drmP.h and drm_crtc.h via a preceding
patch.

Without this patch and the patch to make include the UAPI headers from the core
headers, after the UAPI split, the DRM C sources cannot find these UAPI headers
because the DRM code relies on specific -I flags to make #include "..."  work
on headers in include/drm/ - but that does not work after the UAPI split without
adding more -I flags.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

This applies on top of drm/radeon: Mark all possible functions / structs as static.
Signed-off-by: NLauri Kasanen <cand@gmx.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Let's allow GCC to optimize better.

This exposed some five unused functions, but this patch doesn't remove them.
Signed-off-by: NLauri Kasanen <cand@gmx.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the display shows random bits other than the intended ones.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We've been getting occasional oops running a 32-bit kernel on a certain
system in our RHEL test hw. It appears that we fail to get sufficent ioremap
space for the framebuffer, and this leads to an oops.

This patch should fix the oops and leave a message in the logs we can
check for.

A future fix would probably to resize the console to a size that we can
ioremap.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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>

This is used by nearly everyone including vmwgfx which doesn't generally
use the fb helper.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 308e5bcb ("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: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

... and switch it to container_of upcasting.

v2: converted new pageflip code-paths.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this aligns the height of the fb allocation so it doesn't trip
over the size checks later when we use this from userspace to
copy the buffer at X start.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.

It looks to me like it would be useful in the following cases:
a) in development drivers - we can always provide a shadowfb fallback.
b) libkms users - we can clean up libkms a lot and avoid linking
to libdrm_*.
c) plymouth via libkms is a lot easier.

Userspace bits would be just calls + mmaps. We could probably
mark these handles somehow as not being suitable for acceleartion
so as top stop people who are dumber than dumb.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit dfe63bb0.

This commit was causing nouveau not to work properly, for -rc1 I'd
prefer it worked and we can look if this is useful for 2.6.39.

Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If you change the color depth via fbset or some other framebuffer aware
userland application struct fb_fix_screeninfo is not updated to this new
information. This patch fixes this issue. Also the function is changed to
just pass in struct drm_framebuffer so in the future we could use more
fields. I'm hoping some day fix->smem* could be set here :-)
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For the fbdev api if the struct fb_var_screeninfo accel_flags field is set
to FB_ACCELF_TEXT then userland applications can not mmap the mmio region.
Since it is a bad idea for DRM drivers to expose the mmio region via the
fbdev layer we always set the accel_flags to prevent this. Please apply.
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes a problem where the wrong card conflicts with vesafb in my
x2 system.
Signed-off-by: NDave Airlie <airlied@redhat.com>

since the handle references are all tied to a file_priv, and when it disappears
all the handle refs go with it.

The fbcon ones we'd only notice on unload, but the nouveau notifier one
would would happen on reboot.

nouveau: Reported-by: Marc Dionne <marc.c.dionne@gmail.com>
nouveau: Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
i915 unload: Reported-by: Keith Packard <keithp@keithp.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NChris Ball <cjb@laptop.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

There were lots of places being inconsistent since handle count
looked like a kref but it really wasn't.

Fix this my just making handle count an atomic on the object,
and have it increase the normal object kref.

Now i915/radeon/nouveau drivers can drop the normal reference on
userspace object creation, and have the handle hold it.

This patch fixes a memory leak or corruption on unload, because
the driver had no way of knowing if a handle had been actually
added for this object, and the fbcon object needed to know this
to clean itself up properly.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We are passing a ttm type when we want to pass true/false.
Reported-by: NDr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Jesse's initial patch commit said:

"At panic time (i.e.  when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.

So make sure we try to unblank and update the display if called from a
panic context."

I've enhanced this to add a flag to the vc that console layer can set to
indicate they want this behaviour to occur.  This also adds support to
fbcon for that flag and adds an fb flag for drivers to indicate they want
to use the support.  It enables this for KMS drivers.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NJames Simmons <jsimmons@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The previous commit fixes the problem, these commits make sure we actually
fail properly if it happens again.

I've squashed the commits from Chris since they are all fixing one issue.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.

v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings.

v3: add config lock take inside polling, add intel/nouveau poll init/fini calls

v4: config lock was a bit agressive, only needed around connector list reading.
otherwise it could re-enter.

glisse: discard drm_helper_hpd_irq_event

v3: Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It removes a hack from nouveau code which had to detect which
region to pass to kick vesafb/efifb.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch is against the drm-fbdevfix1 branch. It removes the
drm_fb_helper_setcolreg function. The reason is that fb_setcolreg is only
used in the case where fb_setcmap is called and no fb_ops->fb_setcmap is
used. In the drm case we always need a fb_setcmap hook to handle multiple
crtcs so we don't need a fb_setcolreg hook. Please apply.
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

a) slow work is always used now for any fbcon hotplug, as its not
   a fast task and is more suited to being ran under slow work.

b) attempt to not do any fbdev changes when X is running as we'll
   just mess it up. This hooks set_par to hopefully do the changes
   once X hands control to fbdev.

This also adds the nouveau/intel hotplug support.
Signed-off-by: NDave Airlie <airlied@redhat.com>

When we are running in a headless environment we have no idea what
output the user might plug in later, we only have hotplug detect
from the digital outputs. So if we detect no connected outputs at
initialisation, start a slow work operation to poll every 5 seconds
for an output.

this is only hooked up for radeon so far, on hw where we have full
hotplug detection there is no need for this.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This breaks the connection between the core drm connector list
and the fbdev connector usage, and allows them to become disjoint
in the future. It also removes the untype void* that was in the
connector struct to support this.

All connectors are added to the fbdev now but this could be
changed in the future.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This move to using the list of crtcs in the fb helper and cleans up the
whole picking code, now we store the crtc/connectors we want directly
into the modeset and we use the modeset directly to set the mode.

Fixes from James Simmons and Ben Skeggs.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The fbdev layer in the kms code should act like a consumer of the kms services and avoid having relying on information being store in the kms core structures in order for it to work.

This patch

a) removes the info pointer/psuedo palette from the core drm_framebuffer structure and moves it to the fbdev helper layer, it also removes the core drm keeping a list of kernel kms fbdevs.
b) migrated all the fb helper functions out of the crtc helper file into the fb helper file.
c) pushed the fb probing/hotplug control into the driver
d) makes the surface sizes into a structure for ease of passing
This changes the intel/radeon/nouveau drivers to use the new helper.
Signed-off-by: NDave Airlie <airlied@redhat.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>