drm_ht_remove_item() does not handle removing an absent item and the hlist
in particular is incorrectly initialised. The easy remedy is simply skip
calling i915_gem_free_mmap_offset() unless we have actually created the
offset and associated ht entry.
This also fixes the mishandling of a partially constructed offset which
leaves pointers initialized after freeing them along the
i915_gem_create_mmap_offset() error paths.
In particular this should fix the oops found here:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/415357/comments/8
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: stable@kernel.org
Ever since we enabled GEM, the pre-9xx chipsets (particularly 865) have had
serious stability issues. Back in May a wbinvd was added to the DRM to
work around much of the problem. Some failure remained -- easily visible
by dragging a window around on an X -retro desktop, or by looking at bugzilla.
The chipset flush was on the right track -- hitting the right amount of
memory, and it appears to be the only way to flush on these chipsets, but the
flush page was mapped uncached. As a result, the writes trying to clear the
writeback cache ended up bypassing the cache, and not flushing anything! The
wbinvd would flush out other writeback data and often cause the data we wanted
to get flushed, but not always. By removing the setting of the page to UC
and instead just clflushing the data we write to try to flush it, we get the
desired behavior with no wbinvd.
This exports clflush_cache_range(), which was laying around and happened to
basically match the code I was otherwise going to copy from the DRM.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Brice Goglin <Brice.Goglin@ens-lyon.org>
Cc: stable@kernel.org
This patch adds framebuffer compression (good for about ~0.5W power
savings in the best case) support for pre-GM45 chips. GM45+ have a new,
more flexible FBC scheme that will be added in a separate patch.
FBC can't always be enabled: the compressed buffer must be physically
contiguous and reside in stolen space. So if you have a large display
and a small amount of stolen memory, you may not be able to take
advantage of FBC. In some cases, a BIOS setting controls how much
stolen space is available. Increasing this to 8 or 16M can help.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
With all the other lid pieces in place, it's easy to generate a uevent
for the LVDS connector just like we do for other outputs. Should make
lid open/close fit in with the rest of a userland based output
reconfiguration scheme.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
We can't load or hotplug detect LVDS like we can other outputs, but if
there's a lid device present we can use it as a proxy. This allows the
LFP state to be determined at ->detect time, making configurations
requiring manual intervention today "just work" assuming the lid device
status is correct.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Some laptop platforms will disable pipes and/or planes at lid close time
and not restore them when the lid is opened again. So catch the lid
event, and if the lid was opened, force a mode restore.
Fixes fdo bug #21230.
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Some drivers need to know when a lid event occurs and get the current
status. This can be useful for when a platform firmware clobbers some
hardware state at lid time, and a driver needs to restore things when
the lid is opened again.
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
When the output device is LVDS, maybe the pixel clock of adjusted_mode will be
less than that in mode. In such case it will set the incorrect multipler factor
in DPLL_MD register.
So the dpll_md_reg will be reset when the output type is non-SDVO
https://bugs.freedesktop.org/show_bug.cgi?id=22761
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewd-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
When the sdvo device is detected as SDVO-LVDS, we will check whether the
brightness is supported by issue SDVO enhancement command.
If it is supported, we will add the brightness property and then brightness
can be adjusted.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
When the sdvo device is detected as SDVO-TV, we will check whether the
sepecific picture enhancement is supported. If it is supported, we will
add the corresponnding property for SDVO-TV. We will add the following
property for the SDVO-TV enhancements if they are supported:
* Contrast/Brightness/Saturation/Hue.
* left/right/top/bottom margin: This is implemented by using the
horizontal/vertical overscan enhancements. When the overscan
enhancements are supported, the above properties will be added. This is
to be compatible with what we have done in integrated-TV.
* horizontal pos/vertical pos.
http://bugs.freedesktop.org/show_bug.cgi?id=22891
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Otherwise, some other userland writing into its buffer may race to land
writes either after the CPU thinks it's got a coherent view, or after its
GTT entries have been redirected to point at the scratch page. Either
result is unpleasant.
Signed-off-by: Eric Anholt <eric@anholt.net>
This was a non-trivial merge with some patches sent to Linus
in drm-fixes.
Conflicts:
drivers/gpu/drm/radeon/r300.c
drivers/gpu/drm/radeon/radeon_asic.h
drivers/gpu/drm/radeon/rs600.c
drivers/gpu/drm/radeon/rs690.c
drivers/gpu/drm/radeon/rv515.c
When an output was disconnected, its mode list would remain. If you later
plugged into a sink with no EDID (projector, etc), you'd inherit the mode
list from the old sink, which is not what you want.
taken from Fedora kernel
Signed-off-by: Dave Airlie <airlied@redhat.com>
The driver gets the bridge device in a number of places, upcoming
vga arb code paths need the bridge device, however they need it in
under a lock, and the pci lookup can allocate memory. So clean
this code up before then and get the bridge once for the driver lifetime.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the r600 KMS + CS support to the Linux kernel.
The r600 TTM support is quite basic and still needs more
work esp around using interrupts, but the polled fencing
should work okay for now.
Also currently TTM is using memcpy to do VRAM moves,
the code is here to use a 3D blit to do this, but
isn't fully debugged yet.
Authors:
Alex Deucher <alexdeucher@gmail.com>
Dave Airlie <airlied@redhat.com>
Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This ports the tv-out code from the DDX to KMS.
adds a radeon.tv module option, radeon.tv=0 to disable tv
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the command stream checker for the RN50, R100 and R200 cards.
It stops any access to 3D registers on RN50, and does checks
on buffer sizes on the r100/r200 cards. It also fixes some texture
sizing checks on r300.
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
agp/intel: support for new chip variant of IGDNG mobile
drm/i915: Unref old_obj on get_fence_reg() error path
drm/i915: increase default latency constant (v2 w/comment)
The new code adds modes in the helper, which makes more sense
I disliked the non-driver code adding modes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add the default mode for every output device when there
is no mode for it.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add a function that can be used to add the default mode for the output device
without EDID.
It will add the default mode that meets with the requirements of given
hdisplay/vdisplay limit.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When we need to add the standard timing mode, we will firstly check whether it
can be found in DMT table by comparing the hdisplay/vdisplay/vfresh_rate.
If it can't be found, then we will use the cvt/gtf to add the required mode.
If it can be found, it will be returned.
At the same time the function of drm_mode_vrefresh is also fixed. It will
return the result of actual refresh_rate plus 0.5.
For example:
When the calculated value is 84.9, then the fresh_rate is 85.
When the calculated value is 70.02, then the fresh_rate is 70.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When we add a standard timing mode in UMS, we will first check whether it can
be found in default mode table. If it can't be found, then we will use cvt/gtf
to add the standard timing mode.
Add the default mode table so that we can check whether the given mode
can be found in the default mode table as what we have done in UMS mode.
If the status of one output device is connected but there is no EDID, it will
have no correct mode. In such case we can add some default modes for it. Of
course we only add the modes in the default modes list that visible part is not
greater than 1024x768.
The default mode is autogenerated from the DMT spec. And it is copied from
xserver/hw/xfree86/modes/xf86EdidModes.c. But the mode with reduced blank
feature is removed.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds some rv350+ register for LTE/GTE discard,
and enables the rv515 two sided stencil register.
It also disables the DEPTHXY_OFFSET register which
can be used to workaround the CS checker.
Moves rs690 to proper place in rs600 and uses correct
table on rs600.
Signed-off-by: Dave Airlie <airlied@redhat.com>
- As ima_counts_put() may be called after the inode has been freed,
verify that the inode is not NULL, before dereferencing it.
- Maintain the IMA file counters in may_open() properly, decrementing
any counter increments on subsequent errors.
Reported-by: Ciprian Docan <docan@eden.rutgers.edu>
Reported-by: J.R. Okajima <hooanon05@yahoo.co.jp>
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com
Signed-off-by: James Morris <jmorris@namei.org>
According to the docs, the ringbuffer is not allowed to wrap in the middle
of an instruction.
G45 PRM, Vol 1b, p101:
While the “free space” wrap may allow commands to be wrapped around the
end of the Ring Buffer, the wrap should only occur between commands.
Padding (with NOP) may be required to follow this restriction.
Do as commanded.
[Having seen bug reports where there is evidence of split commands, but
apparently the GPU has continued on merrily before a bizarre and untimely
death, this may or may not fix a few random hangs.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
CC: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reported by Michael Guntsche <mike@it-loops.com>
--------------------
Commit
38bddf04bc gianfar: gfar_remove needs to call unregister_netdev()
breaks the build of the gianfar driver because "dev" is undefined in
this function. To quickly test rc9 I changed this to priv->ndev but I do
not know if this is the correct one.
--------------------
Signed-off-by: David S. Miller <davem@davemloft.net>
