From 14f0458a41e033dee31ba605137419385c03fc78 Mon Sep 17 00:00:00 2001 From: Ben Skeggs Date: Mon, 27 Aug 2012 16:22:49 +1000 Subject: drm/nvc0/copy: check PUNITS to determine which copy engines are disabled On some Fermi chipsets (NVCE particularly) PCOPY1 doesn't exist. And if what I've seen on Kepler is true of Fermi too, chipsets of the same type can have different PCOPY units available. This should fix a v3.5 regression reported by a number of people effecting suspend/resume on NVC8/NVCE chipsets. Cc: stable@vger.kernel.org [3.5] Signed-off-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_state.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'drivers/gpu/drm/nouveau') diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 1866dbb49979..c61014442aa9 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -736,9 +736,11 @@ nouveau_card_init(struct drm_device *dev) } break; case NV_C0: - nvc0_copy_create(dev, 1); + if (!(nv_rd32(dev, 0x022500) & 0x00000200)) + nvc0_copy_create(dev, 1); case NV_D0: - nvc0_copy_create(dev, 0); + if (!(nv_rd32(dev, 0x022500) & 0x00000100)) + nvc0_copy_create(dev, 0); break; default: break; -- cgit v1.2.3 From a348cd5fd85dbca7260ef865c5def85929932861 Mon Sep 17 00:00:00 2001 From: Ben Skeggs Date: Fri, 31 Aug 2012 09:56:25 +1000 Subject: drm/nvd0/disp: hopefully fix selection of 6/8bpc mode on DP outputs I have a very limited number of traces available for DP on NVD9+, but, these values produce the same as the binary driver on a confirmed 18-bit eDP panel and a confirmed 24-bit eDP panel (Retina MBP). It's interesting that the bitfield values also match the MODE_CTRL values that control the same thing on nv50:nvd9. Signed-off-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nvd0_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/gpu/drm/nouveau') diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c b/drivers/gpu/drm/nouveau/nvd0_display.c index dac525b2994e..8a2fc89b7763 100644 --- a/drivers/gpu/drm/nouveau/nvd0_display.c +++ b/drivers/gpu/drm/nouveau/nvd0_display.c @@ -1510,10 +1510,10 @@ nvd0_sor_mode_set(struct drm_encoder *encoder, struct drm_display_mode *umode, case OUTPUT_DP: if (nv_connector->base.display_info.bpc == 6) { nv_encoder->dp.datarate = mode->clock * 18 / 8; - syncs |= 0x00000140; + syncs |= 0x00000002 << 6; } else { nv_encoder->dp.datarate = mode->clock * 24 / 8; - syncs |= 0x00000180; + syncs |= 0x00000005 << 6; } if (nv_encoder->dcb->sorconf.link & 1) -- cgit v1.2.3 From 991083ba60f89e717e3a4175be96d48a810e9eae Mon Sep 17 00:00:00 2001 From: Ben Skeggs Date: Fri, 31 Aug 2012 10:51:20 +1000 Subject: drm/nv50-/gpio: initialise to vbios defaults during init This is required to fix an issue on the Retina MBP where the eDP panel's AUX channel isn't wired up to the HPD pin for the panel, causing our aux code to bail out early. From looking at various traces of the binary driver, it appears NVIDIA do something very similar on at least all nv50+ chipsets during their initialisation sequence. So, hopefully this is safe. Issue and fix initially tracked down by Ryan Bourgeois on fdo#51971. Backported fix from reworked nouveau kernel module. Signed-off-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nv50_gpio.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/gpu/drm/nouveau') diff --git a/drivers/gpu/drm/nouveau/nv50_gpio.c b/drivers/gpu/drm/nouveau/nv50_gpio.c index f429e6a8ca7a..f03490534893 100644 --- a/drivers/gpu/drm/nouveau/nv50_gpio.c +++ b/drivers/gpu/drm/nouveau/nv50_gpio.c @@ -115,6 +115,9 @@ nv50_gpio_init(struct drm_device *dev) { struct drm_nouveau_private *dev_priv = dev->dev_private; + /* initialise gpios and routing to vbios defaults */ + nouveau_gpio_reset(dev); + /* disable, and ack any pending gpio interrupts */ nv_wr32(dev, 0xe050, 0x00000000); nv_wr32(dev, 0xe054, 0xffffffff); -- cgit v1.2.3 From 610bd7da160f76f1644ecb4cd7f39511b49a22cc Mon Sep 17 00:00:00 2001 From: Dave Airlie Date: Fri, 14 Sep 2012 13:28:23 +1000 Subject: drm/nouveau: fix booting with plymouth + dumb support We noticed a plymouth bug on Fedora 18, and I then noticed this stupid thinko, fixing it fixed the problem with plymouth. Cc: stable@vger.kernel.org Acked-by: Ben Skeggs Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/gpu/drm/nouveau') diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 69688ef5cf46..7e16dc5e6467 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -598,7 +598,7 @@ nouveau_display_dumb_create(struct drm_file *file_priv, struct drm_device *dev, args->size = args->pitch * args->height; args->size = roundup(args->size, PAGE_SIZE); - ret = nouveau_gem_new(dev, args->size, 0, TTM_PL_FLAG_VRAM, 0, 0, &bo); + ret = nouveau_gem_new(dev, args->size, 0, NOUVEAU_GEM_DOMAIN_VRAM, 0, 0, &bo); if (ret) return ret; -- cgit v1.2.3