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: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

blit copy functions deal with GPU pages, not CPU pages,
so rename the variables and parameters accordingly
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave 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: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave 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: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave 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: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave 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: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave 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: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave 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: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave 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: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave 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: NJean Delvare <jdelvare@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave 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: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NDave 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: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Remove bogus inlines in evergreen and r100.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NDave 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: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes

evergreen_cs_parse                          4080   23124  +19044

and others compared to a non force inline kernel.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NDave 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: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave 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: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave 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: NAlex Deucher <alexander.deucher@amd.com>
Cc: Chen Jie <chenj@lemote.com>
Signed-off-by: NDave 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: NMichael Witten <mfwitten@gmail.com>
Signed-off-by: NDave 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=41561Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave 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=41561Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave 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: NJean Delvare <jdelvare@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NTormod Volden <debian.tormod@gmail.com>
Reviewed-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NDave 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: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave 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: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDave 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: NMarek Olšák <maraeo@gmail.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave 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: NMarek Olšák <maraeo@gmail.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave 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: NDave Airlie <airlied@redhat.com>
Cc: stable@kernel.org
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>

Fixes resume on Compaq Presario V5245EU.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=41642Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@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: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave 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/826677Signed-off-by: NThomas Reim <reimth@gmail.com>
Acked-by: NChris Routh <routhy@gmail.com>
Cc: <stable@kernel.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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>

Otherwise these would need to be painstakingly calculated looking at the source
code.
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>

Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave 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: NJay Estabrook <jay.estabrook@gmail.com>
Signed-off-by: NDave 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=39882Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave 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: NMatthew Garrett <mjg@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave 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: NMatthew Garrett <mjg@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>