- 13 Jul, 2010 39 commits
-
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Previously only done on nv50+ This commit also switches unknown NV2x/NV3x chipsets to noaccel mode. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This was always really a developer option, and if it's really necessary we can hack this in ourselves. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Nouveau will no longer load at all if card initialisation fails, so all these checks are unnecessary. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
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>
-
Francisco Jerez authored
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>
-
Francisco Jerez authored
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>
-
Francisco Jerez authored
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Francisco Jerez authored
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>
-
Francisco Jerez authored
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Francisco Jerez authored
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>
-
Francisco Jerez authored
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Francisco Jerez authored
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
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>
-
Albert Damen authored
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>
-
Francisco Jerez authored
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/569505Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Francisco Jerez authored
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>
-
Francisco Jerez authored
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>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Luckily this had absolutely no effect whatsoever :) Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
It's far preferable to have the driver do nothing at all for "nomodeset". Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- 12 Jul, 2010 1 commit
-
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-