- 20 5月, 2011 17 次提交
-
-
由 Alex Deucher 提交于
In the hotplug handler, just use the drm dpms functions. If the monitor is plugged in, turn it on, if it's not, turn it off. This also reduces power usage by turning off the encoder and crtc when the monitor is unplugged. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
- reorganize the functions based on use - clean up function naming - rework link training to better match what we use internally - add initial support for DP 1.2 (no MST yet) Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Required for proper operation with DP bridges. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Fusion hardware often has DP to VGA/LVDS/TMDS bridges to handle non-DP encoders. Internally we treat them mostly like DP. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Used for dp1.2 support and for dp bridges. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
need to wait for the panel to power up. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
eDP is usually used as an LVDS replacement, so treat it more like LVDS from the user perspective. v2: encoder mode is always DP for eDP. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
In DP mode, the DP ref clock can come from PPLL, DCPLL, or ext clock, depending on the asic. The crtc virtual pixel clock is derived from the DP ref clock. - DCE4: PPLL or ext clock - DCE5: DCPLL or ext clock Setting ATOM_PPLL_INVALID will cause SetPixelClock to skip PPLL/DCPLL programming and only program the DP DTO for the crtc virtual pixel clock. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
- properly mask the ss type - don't enable ss if type is external or percentage is 0 - if ss enabled and type is external, set ref_div_src to ext clock - prefer ASIC_INTERNAL_SS_ON_DP to LCD_Info SS_Id for eDP - fix ss amount calculation Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
* 'keithp/drm-intel-next' of ../drm-next: drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge drm/i915/sdvo: Reorder i2c initialisation before ddc proxy drm/i915: FDI link training broken on Ironlake by Ivybridge integration drm/i915: enable rc6 by default drm/i915: add fbc enable flag, but disable by default drm/i915: clean up unused ring_get_irq/ring_put_irq functions drm/i915: fix user irq miss in BSD ring on g4x
-
- 19 5月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
It's not used on Ironlake, but is used on later generations, so make sure it exists before we try to use it in the interrupt handlers. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 18 5月, 2011 4 次提交
-
-
由 Chris Wilson 提交于
The ddc proxy depends upon the underlying i2c bus being selected. Under certain configurations, the i2c-adapter functionality is queried during initialisation and so may trigger an OOPS during boot. Hence, we need to reorder the initialisation of the ddc proxy until after we hook up the i2c adapter for the SDVO device. The condition under which it fails is when the i2c_add_adapter calls into i2c_detect which will attempt to probe all valid addresses on the adapter iff there is a pre-existing i2c_driver with the same class as the freshly added i2c_adapter. So it appears to depend upon having compiled in (or loaded such a module before i915.ko) an i2c-driver that likes to futz over the i2c_adapters claiming DDC support. Reported-by: NMihai Moldovan <ionic@ionic.de> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Commit 357555c0 split out IVB-specific register definitions for FDI link training, but a piece of that commit stopped executing some critical code on Ironlake systems while leaving it running on Sandybridge. Turn that code back on both Ironlake and Sandybridge Signed-off-by: NKeith Packard <keithp@keithp.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Jesse Barnes 提交于
With FBC disabled by default, it should be safe to enable RC6. So let's give it a try. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
FBC has too many corner cases that we don't currently deal with, so disable it by default so we can enable more important features like RC6, which conflicts in some configurations. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31742Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 17 5月, 2011 2 次提交
-
-
由 Feng, Boqun 提交于
This patch depends on patch "drm/i915: fix user irq miss in BSD ring on g4x". Once the previous patch apply, ring_get_irq/ring_put_irq become unused. So simply remove them. Signed-off-by: NFeng, Boqun <boqun.feng@intel.com> Reviewed-by: NXiang, Haihao <haihao.xiang@intel.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Feng, Boqun 提交于
On g4x, user interrupt in BSD ring is missed. This is because though g4x and ironlake share the same bsd_ring, their interrupt control interfaces have _two_ differences. 1.different irq enable/disable functions: On g4x are i915_enable_irq and i915_disable_irq. On ironlake are ironlake_enable_irq and ironlake_disable_irq. 2.different irq flag: On g4x user interrupt flag in BSD ring on is I915_BSD_USER_INTERRUPT. On ironlake is GT_BSD_USER_INTERRUPT Old bsd_ring_get/put_irq call ring_get_irq and ring_get_irq. ring_get_irq and ring_put_irq only call ironlake_enable/disable_irq. So comes the irq miss on g4x. To fix this, as other rings' code do, conditionally call different functions(i915_enable/disable_irq and ironlake_enable/disable_irq) and use different interrupt flags in bsd_ring_get/put_irq. Signed-off-by: NFeng, Boqun <boqun.feng@intel.com> Reviewed-by: NXiang, Haihao <haihao.xiang@intel.com> Cc: stable@kernel.org Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 16 5月, 2011 16 次提交
-
-
由 Randy Dunlap 提交于
Fix build errors when CONFIG_ACPI is enabled but MXM_WMI is not enabled by selecting both MXM_WMI and ACPI_WMI (the latter just for kconfig dependencies): nouveau_acpi.c:(.text+0x2400c8): undefined reference to `mxm_wmi_call_mxmx' nouveau_acpi.c:(.text+0x2400cf): undefined reference to `mxm_wmi_call_mxds' nouveau_acpi.c:(.text+0x2400fe): undefined reference to `mxm_wmi_call_mxmx' nouveau_acpi.c:(.text+0x2402ba): undefined reference to `mxm_wmi_supported Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next: (55 commits) drm/nouveau: make cursor_set implementation consistent with other drivers drm/nva3/clk: better pll calculation when no fractional fb div available drm/nouveau/pm: translate ramcfg strap through ram restrict table drm/nva3/pm: allow use of divisor 16 drm/nvc0/pm: parse clock for pll 0x0a (0x137020) from perf table drm/nvc0/pm: correct core/mem/shader perflvl parsing drm/nouveau/pm: remove memtiming support check when assigning to perflvl drm/nva3: support for memory timing map table drm/nouveau: Associate memtimings with performance levels on cards <= nv98 drm/nva3/pm: initial pass at set_clock() hook drm/nvc0/gr: calculate some more of our magic numbers drm/nv50: respect LVDS link count from EDID on SPWG panels drm/nouveau: recognise DCB connector type 0x41 as LVDS drm/nouveau: fix uninitialised variable warning drm/nouveau: Fix a crash at card takedown for NV40 and older cards drm/nouveau: Free nv04 instmem ramin heap at card takedown drm/nva3: somewhat improve clock reporting drm/nouveau: pull refclk from vbios on limits 0x40 boards drm/nv40/gr: oops, fix random bits getting set in engine obj drm/nv50: improve nv50_pm_get_clock() ...
-
由 Marcin Slusarz 提交于
When xorg state tracker wants to hide the cursor it calls set_cursor with NULL buffer_handle and size=0x0, but nouveau refuses to hide it because size is not 64x64... which is a bit odd. Both radeon and intel check buffer_handle before validating size of cursor, so make nouveau implementation consistent with them. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
The core/mem/shader clocks don't support the fractional feedback divider, causing our calculated clocks to be off by quite a lot in some cases. To solve this we will switch to a search-based algorithm when fN is NULL. For my NVA8 at PL3, this actually generates identical cooefficients to the binary driver. Hopefully that's a good sign, and that does not break VPLL calculation for someone.. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Hopefully this is how we're supposed to correctly handle when the RAMCFG strap is above the number of entries in timing-related tables. It's rather difficult to confirm without finding a configuration where the ram restrict table doesn't map 8-15 back onto 0-7 anyway. There's not a single vbios in the repo which is configured differently.. In any case, this is probably still better than potentially reading outside of the bounds of various tables.. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
We need to parse some of these other entries still, but I've yet to determine exactly which PLLs the rest map to. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Really not necessary here, we want to be able to see if/how we managed to match a timingset to a performance level, even if we can't currently program it. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
v2 (Ben Skeggs): fix ramcfg strap, and remove bogus handling of perf 0x40 Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
I still discourage anyone from actually doing this yet. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Again, doesn't quite match NVIDIA's, but not sure it really matters. This will however, match the same rules we use to calculate the other related grctx magics. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
After looking at a number of different logs, it appears 0x41 likely indicates the presense of an LVDS panel following the SPWG spec (http://www.spwg.org/) Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Looks like a false positive to me, but, anyways! Reported-by: NJimmy Rentz <jb17bsome@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-