Rather than having a quirk list just always check the EDID header
when probing.  This is the recommended behavior according to the
display team.  This avoids problems with improperly terminated
i2c lines on some boards.  This is also what the proprietary
driver does.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.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>

drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines (here: Asus M2A-VM HDMI)

    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: NThomas Reim <reimth@gmail.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Acked-by: NStephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The most common use of the radeon i2c buses is for ddc.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Sometimes the i2c test in i2c_bit_add_bus fails
if this happens we fail to register the i2c adapter and
eventually fail to add the connector.  If i2c fails,
add the connector to the user can at least force
it on.

Note that some distros set i2c-algo-bit.bit_test to 1 by
default which sometimes fails preventing the ddc i2c adapter
from being added.  The i2c adapter works even if the bit test
fails, probably due to pre/post_xfer not getting called in
the test_bit function.  I have another patch to follow
up on that.

See:
https://bugs.freedesktop.org/show_bug.cgi?id=36221Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Switch some errors to debug output.  These are generally harmless
and tend to confuse users.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

As per advice from Jean Delvare.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This causes the connector to not be added since i2c init fails
for the adapter.  Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=31688

Noticed by Ari Savolainen.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: Ari Savolainen <ari.m.savolainen@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is a follow on to:
2b5b1d7da9583484b3a9e7e375a90ca0e8ca07c2
(drm/radeon/kms: add support for clock/data path routers)

That patch completed mux support for ddc and cd line routing
between connectors.  This patch fixes an indexing typo that was
resulting in the atom bios router objects not always being walked,
ensures the validity entries for the reused router structure are
reset for every connector object walked, and corrects the masking
operations used to update the mux control bits.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=31339Signed-off-by: NTyson Whitehead <twhitehead@gmail.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is a follow on to:
26b5bc98
(drm/radeon/kms: add support for router objects)

That patch added support for systems that use a mux to control
the ddc line routing between the connectors.  This patch adds
support for systems that use a mux to control the encoder
clock and data path routing to the connectors.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=31339Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Rather than calling get_memory_clock and get_engine_clock,
used the tracked values from the pm code.  Calling the tables
adds additional latency in the modesetting and pm paths.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The pins for ddc and aux are shared so you need to switch the
mode when doing ddc.  The ProcessAuxChannel table already sets
the pin mode to DP.  This should fix unreliable ddc issues
on DP ports using non-DP monitors.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

router objects are found on systems that use a mux to control
ddc line to connector routing or to control the actual clock and data
routing from the chip to the connectors.  This patch implements ddc line
routing.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Previously we added i2c buses as needed when enumerating connectors
power management, etc.  This only exposed the actual buses used and
could have lead to the same buse getting created more than once if
one buses was used for more than one purpose.  This patch sets up
all i2c buses on the card in one place and users of the buses just
point back to the one instance.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Turn off hw i2c by default except for mm i2c which
is hw only until we sort out the remaining prescale
issues on older chips.  hw i2c can be enabled with
hw_i2c=1.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This allows us to remove the internal bit algo bus used by
the radeon i2c algo.  We now register a radeon algo adapter
if the gpio line is hw capable and the hw inplementation is
available, otherwise we register a bit algo adapter.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Should fix fdo bug 26430
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

use the i2c pads to drive SDA

Possible fix for fdo bug 26430
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

original evergreen patches we against a kernel tree
without my radeon i2c algo changes.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Pre-pcie chips seem to use the reference clock
rather than the sclk.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

we need a constant sclk for i2c prescale.  Also,
get the current sclk when calculating prescale rather
than using the default sclk.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

wire hw i2c support into radeon i2c algo.

fixes merged:
- handle bus probing correctly
- use meaningful error numbers
- abort if transaction fails
- The line mapping is different depending on the asic.
- protect hw i2c engine with a mutex
- rs300 doesn't have a pin select bit
- r200 has a different pin select setup
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently just a wrapper around bit algo
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- keep the atom i2c id in the i2c rec
- fix gpio regs for GPIO and MDGPIO on pre-avivo chips
- track whether the i2c line is hw capable
- track whether the i2c line uses the multimedia i2c block
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is enough to retrieve EDID and DPCP.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This enables initialization of external tmds chips on pre-atom
and mac systems.  Macs are untested.  Also, some macs have single
link tmds chips while others have dual link tmds chips.  We need
to figure out which ones have which.

This gets external TMDS working on my RS485 and RV380.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- Change reg/mask names to match what we use internally
and in the bios
- Clarify how i2c over gpio on radeon actually works
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need this for supporting things other than ddc on i2c.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It hasn't been used in ages, and having the user tell your how much
memory is being freed at free time is a recipe for disaster even if it
was ever used.
Signed-off-by: NEric Anholt <eric@anholt.net>

Add kernel modesetting support to radeon driver, use the ttm memory
manager to manage memory and DRM/GEM to provide userspace API.
In order to avoid backward compatibility issue and to allow clean
design and code the radeon kernel modesetting use different code path
than old radeon/drm driver.

When kernel modesetting is enabled the IOCTL of radeon/drm
driver are considered as invalid and an error message is printed
in the log and they return failure.

KMS enabled userspace will use new API to talk with the radeon/drm
driver. The new API provide functions to create/destroy/share/mmap
buffer object which are then managed by the kernel memory manager
(here TTM). In order to submit command to the GPU the userspace
provide a buffer holding the command stream, along this buffer
userspace have to provide a list of buffer object used by the
command stream. The kernel radeon driver will then place buffer
in GPU accessible memory and will update command stream to reflect
the position of the different buffers.

The kernel will also perform security check on command stream
provided by the user, we want to catch and forbid any illegal use
of the GPU such as DMA into random system memory or into memory
not owned by the process supplying the command stream. This part
of the code is still incomplete and this why we propose that patch
as a staging driver addition, future security might forbid current
experimental userspace to run.

This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX
(radeon up to X1950). Works is underway to provide support for R6XX,
R7XX and newer hardware (radeon from HD2XXX to HD4XXX).

Authors:
    Jerome Glisse <jglisse@redhat.com>
    Dave Airlie <airlied@redhat.com>
    Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>