In some situations it's possible we can receive a spurious hotplug IRQ
before we're ready to handle it, leading to an oops.
Calling the display init before enabling interrupts should clear any
pending IRQs on the GPU and prevent this from happening.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It seems on some chipsets that doing this from the 0x20 handler causes the
display engine to not ever signal the final 0x40 stage.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This removes the previous prepare_access() and finish_access() hooks, and
replaces it with a much simpler flush() hook.
All the chipset-specific code before nv50 has its use removed completely,
as it's not required there at all.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The previous handler basically worked correctly for a full-blown mode
change. However, it did nothing at all when a partial (encoder only)
reconfiguation was necessary, leading to the display hanging on certain
types of mode switch.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It turns out that the display engine signals an interrupt for disconnects
too. In order to make it easier to process the display interrupts
correctly, we want to ensure we only get one operation per interrupt
sequence - this is what this commit achieves.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The blob seems to have the same problem so it's probably a hardware
issue (bug 28810).
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Avoids an oops in the fence wait failure path (bug 26521).
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
No need to spam the logs when they're found, they're equivalent to
INIT_DONE.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Load detection needs the connector wired to a CRTC, when there are no
inactive CRTCs left that means we need to cut some other head off for
a while, causing intermittent flickering.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Allows us to remove a driver hack that used to be necessary to disable
encoders in certain situations before setting up a mode. The DRM has
better knowledge of when this is needed than the driver does.
This fixes a number of display switching issues.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Uncertain if this is a weirdo configuration, or a BIOS bug. If it's not
a BIOS bug, we still don't know how to make it work anyway so ignore a
"conflicting" DCB entry to prevent a display hang.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
As long as we know the length of the opcode, we're probably better off
trying to parse the remainder of an init table rather than aborting in
the middle of it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Create connectors before encoders to avoid having to do another loop across
encoder list whenever we create a new connector. This allows us to pass
the connector to the encoder creation functions, and avoid using a
create_resources() callback since we can now call it directly.
This can also potentially modify the connector ordering on nv50. On cards
where the DCB connector and encoder tables are in the same order, things
will be unchanged. However, there's some cards where the ordering between
the tables differ, and in one case, leads us to naming the connectors
"wrongly".
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
fixes oops in nouveau_connector_get_modes with nv_encoder is NULL
Signed-off-by: Albert Damen <albrt@gmx.net>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The nv05 card in the bug report [1] doesn't have usable I2C port
register offsets (they're all filled with zeros). Ignore them and use
the defaults.
[1] http://bugs.launchpad.net/bugs/569505
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We just need to clear the SBA and ENABLE bits to reset the AGP
controller: If the AGP bridge was configured to use "fast writes",
clearing the FW bit would break the subsequent MMIO writes and
eventually end with a lockup.
Note that all the BIOSes I've seen do the same as we did (it works for
them because they don't use MMIO), OTOH the blob leaves FW untouched.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
a7b9f9e5adef dropped it by accident.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Thibaut Girka <thib@sitedethib.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Luckily this had absolutely no effect whatsoever :)
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Original behaviour will be preserved for drivers that don't implement
disable() hooks for an encoder.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that highlevel DRM no longer requires PCI, we can move the requirement
into the lowlevel drivers.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
More explicit than dpms. Same as the encoder disable function.
Need this to explicity disconnect plls from crtcs for reuse when you
plls:crtcs ratio isn't 1:1.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm-intel-lru:
drm: implement helper functions for scanning lru list
drm_mm: extract check_free_mm_node
drm: sane naming for drm_mm.c
drm: kill dead code in drm_mm.c
drm: kill drm_mm_node->private
drm: use list_for_each_entry in drm_mm.c
* drm-platform:
drm: Make sure the DRM offset matches the CPU
drm: Add __arm defines to DRM
drm: Add support for platform devices to register as DRM devices
drm: Remove drm_resource wrappers
We don't currently update the DPMS status of the connector (both in the
connector itself and the connector's DPMS property) in the fb helper
code. This means that if the kernel FB core has blanked the screen,
sysfs will still show a DPMS status of "on". It also means that when X
starts, it will try to light up the connectors, but the drm_crtc_helper
code will ignore the DPMS change since according to the connector, the
DPMS status is already on.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28436 (the annoying
"my screen was blanked when I started X and now it won't light up" bug).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
