Dump some of the audio registers at server startup time.
(II) intel(0): AUD_CONFIG: 0x00000004
(II) intel(0): AUD_HDMIW_STATUS: 0x00000000
(II) intel(0): AUD_CONV_CHCNT: 0x00000000
(II) intel(0): VIDEO_DIP_CTL: 0x20000600
(II) intel(0): AUD_PINW_CNTR: 0x00000040
(II) intel(0): AUD_CNTL_ST: 0x00002000
(II) intel(0): AUD_PIN_CAP: 0x00000094
(II) intel(0): AUD_PINW_CAP: 0x004073bd
(II) intel(0): AUD_PINW_UNSOLRESP: 0x80000008
(II) intel(0): AUD_OUT_DIG_CNVT: 0x00000001
(II) intel(0): AUD_OUT_CWCAP: 0x00006211
(II) intel(0): AUD_GRP_CAP: 0x00000004
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
The 965 docs note, and it's probably the case on 915 as well, that the
2x2 subspans are read as a unit, even if the bottom row isn't used. If
the address in that bottom row extended beyond the end of the GTT, a
fault could occur.
Thanks to Chris Wilson for pointing out the problem.
Only apply on G4X with SR01 bit5 workaround for VGA plane disable, and
restore behavior back for other chips to make sure other modes got disabled
too.
For bug #17235, #19715, #21064, #23178
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
We only set up one sampler, because all of our sampling is the same. By
using a non-zero index for the other two samplers, we'd dereference (likely)
zeroed data, resulting in using NEAREST filtering. This was a regression in
40671132cb which incidentally switched from
having 6 samplers to 1.
Bug #22895, #19856
Now the DVO timing in LVDS data entry is obtained by using the
following step:
a. get the entry size for every LVDS panel data
b. Get the LVDS fp entry for the preferred panel type
c. get the DVO timing by using entry->dvo_timing
In our driver the entry->dvo_timing is related with the size of
lvds_fp_timing. For example: the size is 46.
But it seems that the size of lvds_fp_timing varies on the differnt
platform. In such case we will get the incorrect DVO timing because of
the incorrect DVO offset in LVDS panel data entry.
Calculate the DVO timing offset in LVDS data entry to get the DVO timing
a. get the DVO timing offset in the LVDS fp data entry by using the
pointer definition in LVDS data ptr
b. get the LVDS data entry
c. get the DVO timing by adding the DVO timing offset to data entry
https://bugs.freedesktop.org/show_bug.cgi?id=22787
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
This removes the explicit transform disabling code in drm_set_mode_major.
Without a fixed X server, transforms will still be broken, but even a fixed
X server can't work around this driver bug.
Signed-off-by: Keith Packard <keithp@keithp.com>
This improves aa10text performance from 74k to 569k on my 855 laptop.
This also causes my 865 to hang on aa10text like it does on rgb10text,
thanks to actually hitting render accel.
This lets the driver allocate a nice idle buffer object instead of a
busy one, reducing runtime of firefox-20090601 on my G45 from 50.7 (+/- .41%)
to 48.4 (+/- 1.1%).
This was needed when we were doing the mask computations in this pixmap,
but now they're done in a temporary and then uploaded later.
This reduces runtime of firefox-20090601 from 52.6 (+/- .96%) to 50.7
(+/- .41%) seconds on my G45.
This synchronizes the X EDID data with the kernel EDID data each time the
kernel data may have changed. Otherwise, X ends up stuck with the first EDID
data it sees, failing to accomodate to different monitors.
Signed-off-by: Keith Packard <keithp@keithp.com>
DPMS header was split into dpms.h (client) and dpmsconst.h (server). Drivers
need to include dpmsconst.h if xextproto 7.1 is available.
SHM is now shm.h instead of shmstr. Requires definition of ShmFuncs that's
not exported by the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't do it, treat this the same as every other prepare access call in uxa.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Owain Ainsworth <zerooa@googlemail.com>
The two shared i830_composite.c, so giving i830 atomic batch support
triggered anger about starting i830's atomic area while in i915's atomic
area. Instead, split the emit-a-primitive stuff from the state emission.
scrn->fbOffset may be changed when binding objects to the aperture during
server initialization or VT enter. This was accidentally removed when the
NoAlloc option was eliminated.
Signed-off-by: Keith Packard <keithp@keithp.com>
Without kernel support and explicit knowledge about where in the ring the
last rendering operation for a specific pixmap was, we must synchronize with
any outstanding rendering before accessing a pixmap which does not have a
buffer object.
Signed-off-by: Keith Packard <keithp@keithp.com>
The frame buffer only has a valid address between prepare_access and
finish_access calls, so remove all other attempts to compute an address from
the driver.
Signed-off-by: Keith Packard <keithp@keithp.com>
We only need to get static offsets for objects when not running KMS,
otherwise the kernel will manage those as needed for us.
Binding objects is done in one of two ways. For GEM buffer objects, we use
dri_bo_pin. For GART allocated memory, we bind that to the GART.
Wu Fengguang
Kristian Høgsberg
Eric Anholt
Jesse Barnes
Matthias Hopf
Zhenyu Wang
Adam Jackson
Zou Nan hai
Zhao Yakui
Dave Airlie
Krzysztof Halasa
Keith Packard
Xiang, Haihao
Carl Worth
Peter Hutterer
Owain Ainsworth
Barry Scott