factor out most of evergreen blit code and use the refactored code
from r600 that is now common for both r600 and evergreen
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
blit copy functions deal with GPU pages, not CPU pages,
so rename the variables and parameters accordingly
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
reorganize the code such that only the primitives (i.e., the functions
that load the CP ring) are hardware specific; dynamically link the
primitives in a (new) pointer structure inside r600_blit at
blit initialization time so that the functions that control the blit
operations can be made common for r600 and evergreen parts
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Lots of new (and hopefully useful) benchmark. Load the driver
with radeon_benchmark=<test_number> and enjoy. Among tests
added are VRAM to VRAM blits and blits with buffer size sweeps.
The latter can be from GTT to VRAM, VRAM to GTT, and VRAM to VRAM
and there are two types of sweeps: powers of two and (probably
more interesting) buffers sizes that correspond to common modes.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
factor out repeated code into functions
fix units in which the throughput is reported (megabytes per second
and megabits per second make sense, others are kind of confusing)
make report more amenable to awk and friends (e.g. whitespace is
always the separator, unit is separated from the number, etc)
add #defines for some hard coded constants
besides "beautification" this reorg is done in preparation
for writing more elaborate benchmarks
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
some 3d register bits look like magic in r600 blit functions
use predefined constants to make it more intuitive what they are
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
some bits in 3D registers used by blit functions look like
magic and this is hard to follow; change them to a little bit
more meaningful pre-defined constants
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Covert 4k pages to multiples of 64x64x4 tiles.
This is also more efficient than a scanline based
approach from the MC's perspective.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Covert 4k pages to multiples of 64x64x4 tiles.
This is also more efficient than a scanline based
approach from the MC's perspective.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There is no point in re-doing in post_xfer all the initialization
that was already done by pre_xfer. Instead, only do the work which
differs from pre_xfer.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This shrinks the sizes of a lot of functions in the radeon driver
dramatically.
With a non force inline + -Os kernel this is default anyways.
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With this patch I'm only about 50k larger with DRM debugging
enables (why is that enabled by default?!?), and slightly
smaller without.
[airlied: moved r100.c additions to radeon_ring.c]
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With the dropped inlines gccs starts warning about genuinely unused
functions. Remove r600_bpe_from_format, evergreen_cs_track_validate_cb,
evergreen-cs_packet_next_is_pkt3_nop which are all unused.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes
evergreen_cs_parse 4080 23124 +19044
and others compared to a non force inline kernel.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Looks like the same pcie gen2 speed initialization for
Evergreen also works on Cayman and seems to come up fine,
so enable it if the module parameter says so
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Enabling pcie gen2 speed was skipped for Northern Islands
AISCs, although it looks like it works just fine with the same
initialization sequence used for evergreen.
According to Alex D. gen2 init was skipped to prevent a crash
that has been caused by some other bug that has been
fixed in the meantime; so now it should be safe to enable it.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If a card wasn't PCIE, we always set the DMA mask to 32 bits.
This is only applies to the old rage128/r1xx gart block on
early radeon asics (~r1xx-r4xx). Newer PCI and IGP cards
can handle 40 bits just fine.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Chen Jie <chenj@lemote.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:
struct radeon_debugfs {
struct drm_info_list *files;
unsigned num_files;
};
Consequently, the number of debugfs files may be much greater
than RADEON_DEBUGFS_MAX_NUM_FILES, something that the current
code ignores:
if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
DRM_ERROR("Reached maximum number of debugfs files.\n");
DRM_ERROR("Report so we increase RADEON_DEBUGFS_MAX_NUM_FILES.\n");
return -EINVAL;
}
This commit fixes this make, and accordingly renames:
RADEON_DEBUGFS_MAX_NUM_FILES
to:
RADEON_DEBUGFS_MAX_COMPONENTS
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When force == false, we don't do load detection in the connector
detect functions. Unforunately, we also return the previous
connector state so we never get disconnect events for DVI-I, DVI-A,
or VGA. Save whether we detected the monitor via load detection
previously and use that to determine whether we return the previous
state or not.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
DVI-D and HDMI-A are digital only, so there's no need to
attempt analog load detect. Also, skip bail before the
!force check, or we fail to get a disconnect events.
The next patches in the series attempt to fix disconnect
events for connectors with analog support (DVI-I, HDMI-B,
DVI-A).
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 9b9fe724 accidentally used RADEON_GPIO_EN_* where
RADEON_GPIO_MASK_* was intended. This caused improper initialization
of I2C buses, mostly visible when setting i2c_algo_bit.bit_test=1.
Using the right constants fixes the problem.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6: (353 commits)
drm/nouveau: remove allocations from gart populate() hook
drm/nvc0/fb: slightly improve PMFB intr handling, move out of nvc0_graph.c
drm/nvc0/fifo: avoid touching missing subfifos
drm/nvd9/disp: bail out of mode_set_base if no fb bound to crtc
drm/nvd9/disp: stub some more api hooks so we don't oops on resume
drm/nouveau: fix printk typo in ioremap failure path
drm/nvc0/pm: minor clock readback fixes
drm/nv40/pm: execute memory reset script from vbios
drm/nv50/gr: refactor initialisation
drm/nouveau: if requested, try harder at disabling sysmem pushbufs
drm/nv50/gr: enable ctxprog xfer only when we need it to save power
drm/nouveau/dp: add support for displayport table 0x30
drm/nouveau/dp: return master dp table pointer too when looking up encoder
drm/nouveau/bios: simplify U/d table hash matching func to just match
drm/nouveau/dp: preserve non-pattern bits in DP_TRAINING_PATTERN_SET
drm/nvc0/gr: remove MODULE_FIRMWARE() lines
drm/nouveau/dp: use alternate lane mask for nvaf
drm/nouveau/dp: link rate scripts are selected with a comparison table
drm/nv40/pm: write nv40-specific reclocking routines
drm/nv40/pm: parse geometric delta clock from vbios
...
This was previously done for r300 only. Use %016llX instead of %08X for
printing the table address.
Also fix typos in gart warning messages.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sink type is always DP for DP bridges and EDID fetch on
DP bridges is always i2c over aux rather than plain i2c.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the bios or OS sets the pci max read request size to 0 or an
invalid value (6,7), it can result in a hang or slowdown. Check
and set it to something sane if it's invalid.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=42162
v2: use pci reg defines from include/linux/pci_regs.h
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The new DRM_RADEON_GEM_WAIT ioctl combines GEM_WAIT_IDLE and GEM_BUSY (there
is a NO_WAIT flag to get the latter) with USAGE_READ and USAGE_WRITE flags
to take advantage of the new ttm_bo_wait changes.
Also bump the DRM version.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or written. The point of this is to be able to avoid
unnecessary waiting, e.g. if a GPU has written something to a buffer and is now
reading that buffer, and a CPU wants to map that buffer for read, it needs to
only wait for the last write. If there were no write, there wouldn't be any
waiting needed.
This, or course, requires user space drivers to send read/write flags
with each relocation (like we have read/write domains in radeon, so we can
actually use those for something useful now).
Now how this patch works:
The read/write flags should passed to ttm_validate_buffer. TTM maintains
separate sync objects of the last read and write for each buffer, in addition
to the sync object of the last use of a buffer. ttm_bo_wait then operates
with one the sync objects.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On some Power rv100 cards, we have no ATY OF table, but we have
no combios table either, and hence we refuse all modes on VGA-0
since we end up with a 0 max pixel clock.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: stable@kernel.org
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
For some reason SPI block is in broken state after module
unloading. This lead to broken rendering after reloading
module. Fix this by reseting SPI block in CP resume function
Signed-off-by: Jerome Glisse <jglisse@redhat.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data
to i2c bus for a HDMI connector that is not implemented/existent
on the notebook's board.
Fix by applying extented DDC probing for this connector.
Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
with Improperly Wired DDC Lines
Tested for kernel 2.6.38 on Toshiba Satellite L300D notebook
BugLink: http://bugs.launchpad.net/bugs/826677
Signed-off-by: Thomas Reim <reimth@gmail.com>
Acked-by: Chris Routh <routhy@gmail.com>
Cc: <stable@kernel.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise these would need to be painstakingly calculated looking at the source
code.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Alpha needs to have available the system bus address for the Radeon's
local memory, so that it can be used in ttm_bo_vm_fault(), when building
the PTEs for accessing that VRAM. So, we make bus.addr hold the ioremap()
return, and then we can modify bus.base appropriately for use during page
fault processing.
Signed-off-by: Jay Estabrook <jay.estabrook@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Attempting to try and turn off disconnected display hw in the
hotput handler lead to more problems than it helped. For
now just register an event and only attempt the do something
interesting with DP. Other connectors are just too problematic:
- Some systems have an HPD pin assigned to LVDS, but it's rarely
if ever connected properly and we don't really care about hpd
events on LVDS anyway since it's always connected.
- The HPD pin is wired up correctly for eDP, but we don't really
have to do anything since the events since it's always connected.
- Some HPD pins fire more than once when you connect/disconnect
- etc.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39882
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
At least some Apples program the GPU into a state that wedges the engine
once userspace starts trying to perform accelerated operations. Executing
the Atom init scripts gets the hardware back into a working state. The
same hardware works fine when booted via BIOS emulation, so let's just
execute the init scripts on Apples when we're using EFI.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have two sources of information about panel capabilities on mobile
radeon - the BIOS, which gives us a native mode, and the panel's preferred
mode. In theory these two will always match, but there's some corner cases
where the BIOS hasn't been fully initialised and so the native mode in it
ends up with default values. However, if we get a panel with reasonable
EDID, it's probably the case that the panel's preferred mode does actually
represent the panel capabilities. This patch handles that case by replacing
the native mode with the panel's preferred mode if the resolutions don't
match. Systems without a valid internal panel EDID will still use the BIOS
native mode.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to add support for 4 crtcs when setting the possible crtcs
for the encoders.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we get a hotplug event on an connector that is off, don't
attempt to turn it on or off, it should already be off.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=728228
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
for a DVI connector that is not implemented/existent on the board.
Fix by applying extented DDC probing for this connector.
Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
with Improperly Wired DDC Lines
Tested for kernel 2.6.38 on Asus ECS A740GM-M board
BugLink: http://bugs.launchpad.net/bugs/810926
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Log PCI subsystem vendor and subsystem device ID in addition to
PCI vendor and device ID during kernel mode initialisation. This helps
to better identify radeon devices of third-party vendors, e. g. for
bug analysis.
Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some integrated ATI Radeon chipset implementations with add-on HDMI card
(e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even
when the add-on card is not plugged in or HDMI is disabled in BIOS setup.
In this case, drm_get_edid() and drm_edid_block_valid() periodically
dump data and kernel errors into system log files and onto terminals.
For these connectors DDC probing is extended by a check for a correct
EDID header. Only in case a valid EDID header is also found, the
(HDMI or DVI) connector will be used by the Radeon driver. This prevents
the kernel driver from useless flooding of logs and terminal sessions with
EDID dumps and error messages.
This patch adds a flag 'requires_extended_probe' to the radeon_connector
structure. In function radeon_connector_needs_extended_probe() this flag
can be set on a chipset family/vendor/connector type specific basis.
In addition, function radeon_ddc_probe() has been adapted to perform
extended DDC probing if required by the connector's flag.
Requires function drm_edid_header_is_valid() in DRM module provided by
[PATCH] drm: Separate EDID Header Check from EDID Block Check.
Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196
BugLink: http://bugs.launchpad.net/bugs/7228066
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reg header files are generated so they are not cleaned automagically.
They need to be added to the clean-files list.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The board has an lm63 compatible thermal chip, but no
thermal chip entry in the vbios tables.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39513
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This off by one range check was copy and pasted a couple places.
It's not really harmful, but we should fix it anyway.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Ilija Hadzic