The mmap_region() code would temporarily set the VM_ACCOUNT flag for
anonymous shared mappings just to inform shmem_zero_setup() that it
should enable accounting for the resulting shm object. It would then
clear the flag after calling ->mmap (for the /dev/zero case) or doing
shmem_zero_setup() (for the MAP_ANON case).
This just resulted in vma merge issues, but also made for just
unnecessary confusion. Use the already-existing VM_NORESERVE flag for
this instead, and let shmem_{zero|file}_setup() just figure it out from
that.
This also happens to make it obvious that the new DRI2 GEM layer uses a
non-reserving backing store for its object allocation - which is quite
possibly not intentional. But since I didn't want to change semantics
in this patch, I left it alone, and just updated the caller to use the
new flag semantics.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Schedule a vblank signal, kill the process, and we'll go walking over freed
memory. Given that no open-source userland exists using this, nor have I
ever heard of a consumer, just let this code die.
Signed-off-by: Eric Anholt <eric@anholt.net>
Requested-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6:
i2c: Warn on deprecated binding model use
eeprom: More consistent symbol names
eeprom: Move 93cx6 eeprom driver to /drivers/misc/eeprom
spi: Move at25 (for SPI eeproms) to /drivers/misc/eeprom
i2c: Move old eeprom driver to /drivers/misc/eeprom
i2c: Move at24 to drivers/misc/eeprom
i2c: Quilt tree has moved
i2c: Delete many unused adapter IDs
i2c: Delete 10 unused driver IDs
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/i915: Fix cursor physical address choice to match the 2D driver.
drm: stash AGP include under the do-we-have-AGP ifdef
drm: don't whine about not reading EDID data
drm/i915: hook up LVDS DPMS property
drm/i915: remove unnecessary debug output in KMS init
i915: fix freeing path for gem phys objects.
drm: create mode_config idr lock
drm: fix leak of device mappings since multi-master changes.
Use '%zu' to print out a size_t variable, not '%d'. Another case of the
"let's keep at least Linus' defconfig compile warningless" rule.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Make this message a little quieter, since it's common and not necessarily
indicative of a problem.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The LVDS output supports DPMS calls, but we never hooked up the property code,
so set property calls didn't actually do anything. Implement a set_property
callback for the LVDS output so that the right thing happens.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Create a separate mode_config IDR lock for simplicity. The core DRM
config structures (connector, mode, etc. lists) are still protected by
the mode_config mutex, but the CRTC IDR (used for the various identifier
IDs) is now protected by the mode_config idr_mutex. Simplifies the
locking a bit and removes a warning.
All objects are protected by the config mutex, we may in the future,
split the object further to have reference counts.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Device maps now contain a link to the master that created them, so
when cleaning up the master, remove any maps that are connected to it.
Also delete any remaining maps at driver unload time.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is an initial patch to do support for objects which needs physical
contiguous main ram, cursors and overlay registers on older chipsets.
These objects are bound on cursor bin, like pinning, and we copy
the data to/from the backing store object into the real one on attach/detach.
notes:
possible over the top in attach/detach operations.
no overlay support yet.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The detected fixed panel mode really is preferred, so mark it as such and
add it to the LVDS connector mode list.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
When mode setting is first initialized, the driver will call into
drm_helper_initial_config() to set up an initial output and framebuffer
configuration. This routine is responsible for probing the available
connectors, encoders, and crtcs, looking for modes and putting together
something reasonable (where reasonable is defined as "allows kernel
messages to be visible on as many displays as possible").
However, the code was a bit too aggressive in setting default modes when
none were found on a given connector. Even if some connectors had modes,
any connectors found lacking modes would have the default 800x600 mode added
to their mode list, which in some cases could cause problems later down the
line. In my case, the LVDS was perfectly available, but the initial config
code added 800x600 modes to both of the detected but unavailable HDMI
connectors (which are on my non-existent docking station). This ended up
preventing later code from setting a mode on my LVDS, which is bad.
This patch fixes that behavior by making the initial config code walk
through the connectors first, counting the available modes, before it decides
to add any default modes to a possibly connected output. It also fixes the
logic in drm_target_preferred() that was causing zeroed out modes to be set
as the preferred mode for a given connector, even if no modes were available.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
If we are running DRI1 userspace, we really need to set the sarea up properly.
thanks to Richard for finding/testing this.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the absence of kernel mode setting, many drivers disable IRQs across VT
switch. The core DRM vblank code is missing a check for this case however;
even after IRQ disable, the vblank code will still have the vblank_enabled
flag set, so unless we track the fact that they're disabled at IRQ uninstall
time, when we VT switch back in we won't actually re-enable them, which means
any apps waiting on vblank before the switch will hang.
This patch does that and also adds a sanity check to the wait condition to
look for the irq_enabled flag in general, as well as adding a wakeup to the
IRQ uninstall path.
Fixes fdo bug #18879 with compiz hangs at VT switch.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
In some cases userland may be confused and try to wait on vblank events from
pipes that aren't actually enabled. We shouldn't allow this, so return
-EINVAL if the pipe isn't on.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
