Re: [Intel-gfx] [PATCH 2/8] drm/i915: Introduce i915_gem_object_create_stolen_for_preallocated
On Wed, Feb 06, 2013 at 11:10:22AM +, Chris Wilson wrote: > Wrap a preallocated region of stolen memory within an ordinary GEM > object, for example the BIOS framebuffer. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_drv.h|5 +++ > drivers/gpu/drm/i915/i915_gem_stolen.c | 65 > > 2 files changed, 70 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 08c5def..fd8a495 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1720,6 +1720,11 @@ void i915_gem_stolen_cleanup_compression(struct > drm_device *dev); > void i915_gem_cleanup_stolen(struct drm_device *dev); > struct drm_i915_gem_object * > i915_gem_object_create_stolen(struct drm_device *dev, u32 size); > +struct drm_i915_gem_object * > +i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev, > +u32 stolen_offset, > +u32 gtt_offset, > +u32 size); Can we default to u64 for things from now on. Not that I know anything, or anything. At least gtt_offset. > void i915_gem_object_release_stolen(struct drm_i915_gem_object *obj); > > /* i915_gem_tiling.c */ > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c > b/drivers/gpu/drm/i915/i915_gem_stolen.c > index 69d97cb..130d1db 100644 > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c > @@ -312,6 +312,71 @@ i915_gem_object_create_stolen(struct drm_device *dev, > u32 size) > return NULL; > } > > +struct drm_i915_gem_object * > +i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev, > +u32 stolen_offset, > +u32 gtt_offset, > +u32 size) > +{ > + struct drm_i915_private *dev_priv = dev->dev_private; > + struct drm_i915_gem_object *obj; > + struct drm_mm_node *stolen; > + > + if (dev_priv->mm.stolen_base == 0) > + return NULL; > + > + DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, > gtt_offset=%x, size=%x\n", > + stolen_offset, gtt_offset, size); > + > + /* KISS and expect everything to be page-aligned */ > + BUG_ON(stolen_offset & 4095); > + BUG_ON(gtt_offset & 4095); > + BUG_ON(size & 4095); > + > + if (WARN_ON(size == 0)) > + return NULL; > + > + stolen = drm_mm_create_block(&dev_priv->mm.stolen, > + stolen_offset, size, > + false); > + if (stolen == NULL) { > + DRM_DEBUG_KMS("failed to allocate stolen space\n"); > + return NULL; > + } > + > + obj = _i915_gem_object_create_stolen(dev, stolen); > + if (obj == NULL) { > + DRM_DEBUG_KMS("failed to allocate stolen object\n"); > + drm_mm_put_block(stolen); > + return NULL; > + } > + > + /* To simplify the initialisation sequence between KMS and GTT, > + * we allow construction of the stolen object prior to > + * setting up the GTT space. The actual reservation will occur > + * later. > + */ > + if (drm_mm_initialized(&dev_priv->mm.gtt_space)) { > + obj->gtt_space = drm_mm_create_block(&dev_priv->mm.gtt_space, > + gtt_offset, size, > + false); > + if (obj->gtt_space == NULL) { > + DRM_DEBUG_KMS("failed to allocate stolen GTT space\n"); > + drm_gem_object_unreference(&obj->base); > + return NULL; > + } > + } else > + obj->gtt_space = I915_GTT_RESERVED; Could you explain how/why we'd do this before the mm is initialized. > + > + obj->gtt_offset = gtt_offset; > + obj->has_global_gtt_mapping = 1; > + > + list_add_tail(&obj->gtt_list, &dev_priv->mm.bound_list); > + list_add_tail(&obj->mm_list, &dev_priv->mm.inactive_list); > + > + return obj; > +} > + > void > i915_gem_object_release_stolen(struct drm_i915_gem_object *obj) > { > -- > 1.7.10.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
Sorry Chris, I spoke too soon. The working config was single screen/monitor config, as attached here. Commenting of SNA line made it work. The dual screen configuration is still failing as before. And if I comment out the SNA lines I get this in the X log. [3056612.622] Requested Entity already in use! [3056612.622] (EE) Screen 1 deleted because of no matching config section. [3056612.622] (EE) [3056612.622] (EE) Backtrace: [3056612.623] (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x5726f6] [3056612.623] (EE) 1: /usr/bin/Xorg (0x40+0x1761c9) [0x5761c9] [3056612.623] (EE) 2: /lib/libpthread.so.0 (0x7f893e206000+0xfb20) [0x7f893e215b20] [3056612.623] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f893bcf4000+0xed20) [0x7f893bd02d20] [3056612.623] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f893bcf4000+0xff85) [0x7f893bd03f85] [3056612.623] (EE) 5: /usr/bin/Xorg (xf86DeleteScreen+0x84) [0x47dd04] [3056612.623] (EE) 6: /usr/bin/Xorg (xf86BusConfig+0x216) [0x469336] [3056612.623] (EE) 7: /usr/bin/Xorg (InitOutput+0x956) [0x476e96] [3056612.623] (EE) 8: /usr/bin/Xorg (0x40+0x25b26) [0x425b26] [3056612.623] (EE) 9: /lib/libc.so.6 (__libc_start_main+0xf5) [0x7f893d09a755] [3056612.623] (EE) 10: /usr/bin/Xorg (0x40+0x26001) [0x426001] [3056612.624] (EE) [3056612.624] (EE) Segmentation fault at address 0x0 [3056612.624] Fatal server error: [3056612.624] Caught signal 11 (Segmentation fault). Server aborting [3056612.624] [3056612.624] (EE) Thanks, Nitin > -Original Message- > From: Kamble, Nitin A > Sent: Wednesday, February 06, 2013 4:07 PM > To: 'ch...@chris-wilson.co.uk' > Cc: intel-gfx@lists.freedesktop.org > Subject: RE: ZaphodHeads with intel X driver > > > > > The ZaphodHead connector name should match the name given by xrandr, > > which would appear to be HDMI1. Getting closer... > > -Chris > > > > -- > > Chris Wilson, Intel Open Source Technology Centre > > Thanks Chris, Yes, it got me closer. The X is not failing now as seen in the > attached log with the attached config. > But now the issue is I am seeing the screen getting duplicated on the 2 > monitors. The following config should create 2 separate screens. > > Section "ServerLayout" > Identifier "Default Layout" > Screen "Screen0" 0 0 > Screen "Screen1" LeftOf "Screen0" > EndSection > > > Thanks, > Nitin xorg.conf.working Description: xorg.conf.working ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
> > The ZaphodHead connector name should match the name given by xrandr, > which would appear to be HDMI1. Getting closer... > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre Thanks Chris, Yes, it got me closer. The X is not failing now as seen in the attached log with the attached config. But now the issue is I am seeing the screen getting duplicated on the 2 monitors. The following config should create 2 separate screens. Section "ServerLayout" Identifier "Default Layout" Screen "Screen0" 0 0 Screen "Screen1" LeftOf "Screen0" EndSection Thanks, Nitin Xorg.0.log Description: Xorg.0.log xorg.conf Description: xorg.conf ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
On Wed, Feb 06, 2013 at 11:43:51PM +, Kamble, Nitin A wrote: > Chris, > > X is failing even with this reduced 1 screen config. > > Section "Device" > Identifier "Intel0" > Driver "intel" > BusID "PCI:00:02:0" > Option "ZaphodHeads" "HDMI-A-1" The ZaphodHead connector name should match the name given by xrandr, which would appear to be HDMI1. Getting closer... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
Chris, X is failing even with this reduced 1 screen config. Section "Device" Identifier "Intel0" Driver "intel" BusID "PCI:00:02:0" Option "ZaphodHeads" "HDMI-A-1" Option "AccelMethod" "SNA" Screen 0 EndSection Section "Monitor" Identifier"HDMI1" Option"DPMS" "true" Option"PrefferedMode" "1920x1080" EndSection Section "Screen" Identifier"Screen0" Device"Intel0" Monitor "HDMI1" DefaultDepth 24 EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Screen0" 0 0 EndSection Section "ServerFlags" Option"DontZap" "0" Option"AutoAddDevices" "False" EndSection The x log is: [3054115.081] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (GT2), Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Server, Ivybridge Server (GT2), Haswell Desktop (GT1), Haswell Desktop (GT2), Haswell Desktop (GT2+), Haswell Mobile (GT1), Haswell Mobile (GT2), Haswell Mobile (GT2+), Haswell Server (GT1), Haswell Server (GT2), Haswell Server (GT2+), Haswell SDV Desktop (GT1), Haswell SDV Desktop (GT2), Haswell SDV Desktop (GT2+), Haswell SDV Mobile (GT1), Haswell SDV Mobile (GT2), Haswell SDV Mobile (GT2+), Haswell SDV Server (GT1), Haswell SDV Server (GT2), Haswell SDV Server (GT2+), Haswell ULT Desktop (GT1), Haswell ULT Desktop (GT2), Haswell ULT Desktop (GT2+), Haswell ULT Mobile (GT1), Haswell ULT Mobile (GT2), Haswell ULT Mobile (GT2+), Haswell ULT Server (GT1), Haswell ULT Server (GT2), Haswell ULT Server (GT2+), Haswell CRW Desktop (GT1), Haswell CRW Desktop (GT2), Haswell CRW Desktop (GT2+), Haswell CRW Mobile (GT1), Haswell CRW Mobile (GT2), Haswell CRW Mobile (GT2+), Haswell CRW Server (GT1), Haswell CRW Server (GT2), Haswell CRW Server (GT2+), ValleyView PO board [3054115.081] (--) using VT number 3 [3054115.088] (EE) Screen 0 deleted because of no matching config section. [3054115.088] (II) UnloadModule: "intel" [3054115.088] (II) UnloadModule: "intel" [3054115.088] (EE) Screen(s) found, but none have a usable configuration. [3054115.088] Fatal server error: [3054115.088] no screens found [3054115.088] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [3054115.088] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [3054115.088] (EE) [3054115.111] Server terminated with error (1). Closing log file. Let me know if you need any more information. Thanks, Nitin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
On Wed, Feb 06, 2013 at 11:00:49PM +, Kamble, Nitin A wrote: > Thanks Chris for the reply. Attached are all the relevant log files. Both screen stanzas are pointing to the same device. It should be: Screen0 -> Device0, Screen1 -> Device1 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
> -Original Message- > From: ch...@chris-wilson.co.uk [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, February 06, 2013 2:12 PM > To: Kamble, Nitin A > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: ZaphodHeads with intel X driver > > On Wed, Feb 06, 2013 at 06:43:53PM +, Kamble, Nitin A wrote: > > > > On a Intel core i3 (ivybridge) system (NUC) with 2 HDMI ports, I am > > trying to get two independent screens by following this method. > > http://en.gentoo-wiki.com/wiki/X.Org/ > > > Dual_Monitors#Single_graphics_card.2C_Multiple_X_screens_with_Zaphod > He > > ads > > > > And X is failing to start complaining about no usable screens. > > > > I also came across this commit. > > http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/ > > ?id=265d94e0aa46b30a3198893544dd3619cc9145de > > > > So Looks like the config with ZaphodHeads should work. Is there > > anything wrong in this config? How can I get it to work? > > That's quite difficult to tell since you did not attach the xorg.conf you > experimented with, or the resultant Xorg.log. > > Quite probably you simply missed the Option "AccelMethod" "SNA", but > since you got an error message about no screens detected, the error is > actually likely to be something else. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre Thanks Chris for the reply. Attached are all the relevant log files. Nitin lspci Description: lspci sys Description: sys Xorg.0.log Description: Xorg.0.log xorg.conf Description: xorg.conf ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ZaphodHeads with intel X driver
On Wed, Feb 06, 2013 at 06:43:53PM +, Kamble, Nitin A wrote: > > On a Intel core i3 (ivybridge) system (NUC) with 2 HDMI ports, I am trying to > get two independent screens by following this method. > http://en.gentoo-wiki.com/wiki/X.Org/ > Dual_Monitors#Single_graphics_card.2C_Multiple_X_screens_with_ZaphodHeads > > And X is failing to start complaining about no usable screens. > > I also came across this commit. > http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/ > ?id=265d94e0aa46b30a3198893544dd3619cc9145de > > So Looks like the config with ZaphodHeads should work. Is there anything wrong > in this config? How can I get it to work? That's quite difficult to tell since you did not attach the xorg.conf you experimented with, or the resultant Xorg.log. Quite probably you simply missed the Option "AccelMethod" "SNA", but since you got an error message about no screens detected, the error is actually likely to be something else. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes
I'll break etiquette here and include the entire original message below (and top-post!) since I'm sending this to intel-gfx as well. Since the previous mail I've tested a more recent kernel (3.8-rc6), swapping HDMI cables and a firmware update on the receiver, none of it helped. I've also noticed that: a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make the sound go away (higher frame rates) or work (1080p30). So, it has nothing to do with interlacing. The only difference between the output of all the intel*dump tools when running 1080p30 and 1080p60 is included below. It's interesting to note that all the modes that don't work have fdi_lanes = 2 while the working ones have fdi_lanes = 1 (port width in intel_reg_dumper-speak). I'm CC:ing the intel-gfx list as well as the ALSA list since I'm not su sure where the problem lies anymore...suggestions? //David difference between intel reg dump: diff -Nur 1080p60/intel_reg_dumper.log 1080p30/intel_reg_dumper.log --- 1080p60/intel_reg_dumper.log2013-02-06 21:50:35.307560443 +0100 +++ 1080p30/intel_reg_dumper.log2013-02-06 21:52:46.579566050 +0100 @@ -20,11 +20,11 @@ VSYNC_A: 0x0440043b (1084 start, 1089 end) VSYNCSHIFT_A: 0x PIPEASRC: 0x077f0437 (1920, 1080) - PIPEA_DATA_M1: 0x7e3661e0 (TU 64, val 0x3661e0 3564000) - PIPEA_DATA_N1: 0x0041eb00 (val 0x41eb00 432) + PIPEA_DATA_M1: 0x7e1b30f0 (TU 64, val 0x1b30f0 1782000) + PIPEA_DATA_N1: 0x0020f580 (val 0x20f580 216) PIPEA_DATA_M2: 0x (TU 1, val 0x0 0) PIPEA_DATA_N2: 0x (val 0x0 0) - PIPEA_LINK_M1: 0x00024414 (val 0x24414 148500) + PIPEA_LINK_M1: 0x0001220a (val 0x1220a 74250) PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 27) PIPEA_LINK_M2: 0x (val 0x0 0) PIPEA_LINK_N2: 0x (val 0x0 0) @@ -102,7 +102,7 @@ PCH_SSC4_AUX_PARMS: 0x29c5 PCH_DPLL_SEL: 0x0008 (TransA DPLL enable (DPLL A), TransB DPLL disable (DPLL (null))) PCH_DPLL_ANALOG_CTL: 0x8000 -PCH_DPLL_A: 0xc4020002 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 2, FPA1 P1 2, refclk default 120Mhz, sdvo/hdmi mul 1) +PCH_DPLL_A: 0xc4080008 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 4, FPA1 P1 4, refclk default 120Mhz, sdvo/hdmi mul 1) PCH_DPLL_B: 0x04800080 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 8, FPA1 P1 8, refclk default 120Mhz, sdvo/hdmi mul 1) PCH_FPA0: 0x00021007 (n = 2, m1 = 16, m2 = 7) PCH_FPA1: 0x00021007 (n = 2, m1 = 16, m2 = 7) @@ -156,10 +156,10 @@ TRANSACONF: 0xc000 (enable, active, progressive) TRANSBCONF: 0x (disable, inactive, progressive) TRANSCCONF: 0x (disable, inactive, progressive) - FDI_TXA_CTL: 0x800c4b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X2, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable) + FDI_TXA_CTL: 0x80044b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable) FDI_TXB_CTL: 0x0004 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable) FDI_TXC_CTL: 0x0004 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable) - FDI_RXA_CTL: 0x8c082b50 (enable, train pattern not train, port width X2, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk) + FDI_RXA_CTL: 0x8c002b50 (enable, train pattern not train, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk) FDI_RXB_CTL: 0x0040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk) FDI_RXC_CTL: 0x0040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disab
[Intel-gfx] ZaphodHeads with intel X driver
On a Intel core i3 (ivybridge) system (NUC) with 2 HDMI ports, I am trying to get two independent screens by following this method. http://en.gentoo-wiki.com/wiki/X.Org/Dual_Monitors#Single_graphics_card.2C_Multiple_X_screens_with_ZaphodHeads And X is failing to start complaining about no usable screens. I also came across this commit. http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=265d94e0aa46b30a3198893544dd3619cc9145de So Looks like the config with ZaphodHeads should work. Is there anything wrong in this config? How can I get it to work? Thanks, Nitin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/22] drm/i915: don't init LVDS on VLV
On Wed, Feb 6, 2013 at 2:19 PM, Jani Nikula wrote: > On Sat, 02 Feb 2013, Jesse Barnes wrote: >> Signed-off-by: Jesse Barnes > > Reviewed-by: Jani Nikula Up to now all the platform output setup selection has happened in, I'm not sure whether we should sprinkle this out like that. In any case, we seem to miss the check for Haswell, too. It probably works out since the lvds present pin doesn't work, either. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/22] drm/i915: don't init LVDS on VLV
On Sat, 02 Feb 2013, Jesse Barnes wrote: > Signed-off-by: Jesse Barnes Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_lvds.c |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_lvds.c > b/drivers/gpu/drm/i915/intel_lvds.c > index 8c61876..feef18c 100644 > --- a/drivers/gpu/drm/i915/intel_lvds.c > +++ b/drivers/gpu/drm/i915/intel_lvds.c > @@ -1024,6 +1024,9 @@ static bool intel_lvds_supported(struct drm_device *dev) > if (HAS_PCH_SPLIT(dev)) > return true; > > + if (IS_VALLEYVIEW(dev)) > + return false; > + > /* Otherwise LVDS was only attached to mobile products, >* except for the inglorious 830gm */ > return IS_MOBILE(dev) && !IS_I830(dev); > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/22] drm/i915: new register for IS_DISPLAYREG
On Sat, 02 Feb 2013, Jesse Barnes wrote: > From: Ben Widawsky > > Signed-off-by: Ben Widawsky > --- > drivers/gpu/drm/i915/i915_drv.c |7 +++ > drivers/gpu/drm/i915/i915_reg.h |1 + > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index b35b479..28d5992 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1193,10 +1193,6 @@ static bool IS_DISPLAYREG(u32 reg) > reg <= VLV_ISR) > return false; > > - if (reg == FORCEWAKE_VLV || > - reg == FORCEWAKE_ACK_VLV) > - return false; > - > if (reg == GEN6_GDRST) > return false; > > @@ -1213,6 +1209,9 @@ static bool IS_DISPLAYREG(u32 reg) > case GEN6_MBCTL: > case GEN6_UCGCTL2: > case GEN7_UCGCTL4: > + case FORCEWAKE_VLV: > + case FORCEWAKE_ACK_VLV: > + case VLV_GTLC_WAKE_CTRL: Obviously the IS_DISPLAYREG bits can be dropped now. BR, Jani. > return false; > default: > break; > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index c785750..7e13f34 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -4212,6 +4212,7 @@ > #define FORCEWAKE_ACK_VLV 0x1300b4 > #define FORCEWAKE_ACK_HSW 0x130044 > #define FORCEWAKE_ACK 0x130090 > +#define VLV_GTLC_WAKE_CTRL 0x130090 > #define FORCEWAKE_MT0xa188 /* > multi-threaded */ > #define FORCEWAKE_KERNEL 0x1 > #define FORCEWAKE_USER 0x2 > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/22] drm/i915: add UCGCTL4 to display reg check on VLV
On Wed, 06 Feb 2013, Jani Nikula wrote: > On Sat, 02 Feb 2013, Jesse Barnes wrote: >> Add a few regs needed for various clock gating init purposes and make >> sure they don't fall into the display offset range on VLV. > > GEN7_UCGCTL4 needs to be fixed in i915_reg.h after IS_DISPLAYREG > removal. Strike that. The whole patch can be dropped since it's not a display reg. > >> >> Signed-off-by: Jesse Barnes >> --- >> drivers/gpu/drm/i915/i915_drv.c |1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c >> b/drivers/gpu/drm/i915/i915_drv.c >> index 69d0637..13b9b4f 100644 >> --- a/drivers/gpu/drm/i915/i915_drv.c >> +++ b/drivers/gpu/drm/i915/i915_drv.c >> @@ -1208,6 +1208,7 @@ static bool IS_DISPLAYREG(u32 reg) >> case GEN7_HALF_SLICE_CHICKEN1: >> case GEN6_MBCTL: >> case GEN6_UCGCTL2: >> +case GEN7_UCGCTL4: >> return false; >> default: >> break; >> -- >> 1.7.9.5 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/22] drm/i915: add power context allocation and setup on VLV
On Sat, 02 Feb 2013, Jesse Barnes wrote: > The Gunit has a separate reg for this, so allocate some stolen space for > the power context and initialize the reg. > > Signed-off-by: Jesse Barnes > --- > drivers/gpu/drm/i915/i915_drv.h|2 ++ > drivers/gpu/drm/i915/i915_gem_stolen.c | 41 > > drivers/gpu/drm/i915/i915_reg.h|1 + > 3 files changed, 44 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index f4ae73d..34f01a9 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -928,6 +928,8 @@ typedef struct drm_i915_private { > struct drm_mm_node *compressed_fb; > struct drm_mm_node *compressed_llb; > > + struct drm_mm_node *vlv_pctx; > + > unsigned long last_gpu_reset; > > /* list of fbdev register on this device */ > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c > b/drivers/gpu/drm/i915/i915_gem_stolen.c > index f21ae17..ac11a41 100644 > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c > @@ -171,11 +171,49 @@ void i915_gem_stolen_cleanup_compression(struct > drm_device *dev) > dev_priv->cfb_size = 0; > } > > +static void i915_setup_pctx(struct drm_device *dev) > +{ > + struct drm_i915_private *dev_priv = dev->dev_private; > + struct drm_mm_node *pctx; > + unsigned long pctx_paddr; > + int pctx_size = 24*1024; > + > + pctx = drm_mm_search_free(&dev_priv->mm.stolen, pctx_size, 4096, 0); > + if (pctx) > + pctx = drm_mm_get_block(pctx, pctx_size, 4096); > + if (!pctx) > + goto err; > + > + pctx_paddr = dev_priv->mm.stolen_base + pctx->start; > + if (!pctx_paddr) > + goto err_free_pctx; > + > + dev_priv->vlv_pctx = pctx; > + I915_WRITE(VLV_PCBR, pctx_paddr); > + > + return; > + > +err_free_pctx: > + drm_mm_put_block(pctx); > +err: > + DRM_DEBUG("not enough stolen space for PCTX, disabling\n"); > +} > + > +static void i915_cleanup_pctx(struct drm_device *dev) > +{ > + struct drm_i915_private *dev_priv = dev->dev_private; > + > + I915_WRITE(VLV_PCBR, 0); > + drm_mm_put_block(dev_priv->vlv_pctx); > +} > + > void i915_gem_cleanup_stolen(struct drm_device *dev) > { > struct drm_i915_private *dev_priv = dev->dev_private; > > i915_gem_stolen_cleanup_compression(dev); > + if (IS_VALLEYVIEW(dev) && i915_powersave) > + i915_cleanup_pctx(dev); At least in theory dev_priv->vlv_pctx could be NULL here. Maybe make dev_priv->vlv_pctx != NULL the condition here? BR, Jani. > drm_mm_takedown(&dev_priv->mm.stolen); > } > > @@ -193,6 +231,9 @@ int i915_gem_init_stolen(struct drm_device *dev) > /* Basic memrange allocator for stolen space */ > drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->mm.gtt->stolen_size); > > + if (IS_VALLEYVIEW(dev) && i915_powersave) > + i915_setup_pctx(dev); > + > return 0; > } > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 286bab3..c785750 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -561,6 +561,7 @@ > #define ISR 0x020ac > #define VLV_GUNIT_CLOCK_GATE 0x182060 > #define GCFG_DIS (1<<8) > +#define VLV_PCBR 0x182120 > #define VLV_IIR_RW 0x182084 > #define VLV_IER 0x1820a0 > #define VLV_IIR 0x1820a4 > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/22] drm/i915: add UCGCTL4 to display reg check on VLV
On Sat, 02 Feb 2013, Jesse Barnes wrote: > Add a few regs needed for various clock gating init purposes and make > sure they don't fall into the display offset range on VLV. GEN7_UCGCTL4 needs to be fixed in i915_reg.h after IS_DISPLAYREG removal. > > Signed-off-by: Jesse Barnes > --- > drivers/gpu/drm/i915/i915_drv.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 69d0637..13b9b4f 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1208,6 +1208,7 @@ static bool IS_DISPLAYREG(u32 reg) > case GEN7_HALF_SLICE_CHICKEN1: > case GEN6_MBCTL: > case GEN6_UCGCTL2: > + case GEN7_UCGCTL4: > return false; > default: > break; > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Skip modifying PCH DREF if not changing clock sources
On Wed, Feb 06, 2013 at 11:10:21AM +, Chris Wilson wrote: > Modifying the clock sources (via the DREF control on the PCH) is a slow > multi-stage process as we need to let the clocks stabilise between each > stage. If we are not actually changing the clock sources, then we can > return early. > > Signed-off-by: Chris Wilson One idea I've been pondering for the refclock stuff is to simply shovel this into the ->modeset_global_resources callback. That way no clever tricks are required, and we'd avoid this for all cases where fastboot works complety. Presumably ofc that the bios didn't set up a config which does not work. As a bonus, we could only set up the refclocks the new configuration actually needs, i.e. filter for encoder->crtc != NULL ... A bit a risky patch, but might uncover some subtle bugs if we do the refclock adjusting more often. Too insane? -Daniel > --- > drivers/gpu/drm/i915/intel_display.c | 83 > +- > 1 file changed, 61 insertions(+), 22 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index d75c6a0..f1dbd01 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -4749,7 +4749,7 @@ static void ironlake_init_pch_refclk(struct drm_device > *dev) > struct drm_i915_private *dev_priv = dev->dev_private; > struct drm_mode_config *mode_config = &dev->mode_config; > struct intel_encoder *encoder; > - u32 temp; > + u32 val, final; > bool has_lvds = false; > bool has_cpu_edp = false; > bool has_pch_edp = false; > @@ -4792,70 +4792,109 @@ static void ironlake_init_pch_refclk(struct > drm_device *dev) >* PCH B stepping, previous chipset stepping should be >* ignoring this setting. >*/ > - temp = I915_READ(PCH_DREF_CONTROL); > + val = I915_READ(PCH_DREF_CONTROL); > + > + /* As we must carefully and slowly disable/enable each source in turn, > + * compute the final state we want first and check if we need to > + * make any changes at all. > + */ > + final = val; > + final &= ~DREF_NONSPREAD_SOURCE_MASK; > + if (has_ck505) > + final |= DREF_NONSPREAD_CK505_ENABLE; > + else > + final |= DREF_NONSPREAD_SOURCE_ENABLE; > + > + final &= ~DREF_SSC_SOURCE_MASK; > + final &= ~DREF_CPU_SOURCE_OUTPUT_MASK; > + final &= ~DREF_SSC1_ENABLE; > + > + if (has_panel) { > + final |= DREF_SSC_SOURCE_ENABLE; > + > + if (intel_panel_use_ssc(dev_priv) && can_ssc) > + final |= DREF_SSC1_ENABLE; > + > + if (has_cpu_edp) { > + if (intel_panel_use_ssc(dev_priv) && can_ssc) > + final |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD; > + else > + final |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD; > + } else > + final |= DREF_CPU_SOURCE_OUTPUT_DISABLE; > + } else { > + final |= DREF_SSC_SOURCE_DISABLE; > + final |= DREF_CPU_SOURCE_OUTPUT_DISABLE; > + } > + > + if (final == val) > + return; > + > /* Always enable nonspread source */ > - temp &= ~DREF_NONSPREAD_SOURCE_MASK; > + val &= ~DREF_NONSPREAD_SOURCE_MASK; > > if (has_ck505) > - temp |= DREF_NONSPREAD_CK505_ENABLE; > + val |= DREF_NONSPREAD_CK505_ENABLE; > else > - temp |= DREF_NONSPREAD_SOURCE_ENABLE; > + val |= DREF_NONSPREAD_SOURCE_ENABLE; > > if (has_panel) { > - temp &= ~DREF_SSC_SOURCE_MASK; > - temp |= DREF_SSC_SOURCE_ENABLE; > + val &= ~DREF_SSC_SOURCE_MASK; > + val |= DREF_SSC_SOURCE_ENABLE; > > /* SSC must be turned on before enabling the CPU output */ > if (intel_panel_use_ssc(dev_priv) && can_ssc) { > DRM_DEBUG_KMS("Using SSC on panel\n"); > - temp |= DREF_SSC1_ENABLE; > + val |= DREF_SSC1_ENABLE; > } else > - temp &= ~DREF_SSC1_ENABLE; > + val &= ~DREF_SSC1_ENABLE; > > /* Get SSC going before enabling the outputs */ > - I915_WRITE(PCH_DREF_CONTROL, temp); > + I915_WRITE(PCH_DREF_CONTROL, val); > POSTING_READ(PCH_DREF_CONTROL); > udelay(200); > > - temp &= ~DREF_CPU_SOURCE_OUTPUT_MASK; > + val &= ~DREF_CPU_SOURCE_OUTPUT_MASK; > > /* Enable CPU source on CPU attached eDP */ > if (has_cpu_edp) { > if (intel_panel_use_ssc(dev_priv) && can_ssc) { > DRM_DEBUG_KMS("Using SSC on eDP\n"); > - temp |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD; > + val |= DREF_CPU_SOURCE_OU
Re: [Intel-gfx] [PATCH] drm/i915: write backlight harder
On Wed, Feb 6, 2013 at 1:29 PM, Jani Nikula wrote: > Given how much pain the backlight keeps giving us, do you think we would > benefit from sticking a DRM_DEBUG_DRIVER in the if block there? > > Either way, with a heavy *sigh*, > Reviewed-by: Jani Nikula Merged to dinq, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: write backlight harder
On Wed, 06 Feb 2013, Daniel Vetter wrote: > 770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit > commit 770c12312ad617172b1a65b911d3e6564fc5aca8 > Author: Takashi Iwai > Date: Sat Aug 11 08:56:42 2012 +0200 > > drm/i915: Fix blank panel at reopening lid > > changed the register write sequence for restoring the backlight, which > helped prevent non-working backlights on some machines. Turns out that > the original sequence was the right thing to do for a different set of > machines. Worse, setting the backlight level _after_ enabling it seems > to reset it somehow. So we need to make that one conditional upon the > backlight having been reset to zero, and add the old one back. > > Cargo-culting at it's best, but it seems to work. > > Cc: sta...@vger.kernel.org > Cc: Takashi Iwai > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_panel.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index bee8cb6..a3730e0 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev, > if (dev_priv->backlight_level == 0) > dev_priv->backlight_level = intel_panel_get_max_backlight(dev); > > + dev_priv->backlight_enabled = true; > + intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); > + > if (INTEL_INFO(dev)->gen >= 4) { > uint32_t reg, tmp; > > @@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device > *dev, > } > > set_level: > - /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1. > - * BLC_PWM_CPU_CTL may be cleared to zero automatically when these > - * registers are set. > + /* Check the current backlight level and try to set again if it's zero. > + * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically > + * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written. >*/ > - dev_priv->backlight_enabled = true; > - intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); > + if (!intel_panel_get_backlight(dev)) > + intel_panel_actually_set_backlight(dev, > dev_priv->backlight_level); Given how much pain the backlight keeps giving us, do you think we would benefit from sticking a DRM_DEBUG_DRIVER in the if block there? Either way, with a heavy *sigh*, Reviewed-by: Jani Nikula > } > > static void intel_panel_init_backlight(struct drm_device *dev) > -- > 1.7.10.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Build: Add --disable-tests configure flag to avoid tests build - v2
On Wed, Feb 06, 2013 at 12:25:16PM +0100, Takashi Iwai wrote: > At Tue, 5 Feb 2013 16:17:54 -0200, > Rodrigo Vivi wrote: > > > > Tests are still being built by default. However this request > > came from OSVs in order to allow them to include i-g-t in their > > distributions by default avoiding adding more and more dependencies > > since we are improving and adding more and more tests. > > > > v2: wait for Ben's spacin fixes and adjusted for new space rules. > > /spacin/spacing/ ? > > Reviewed-by: Takashi Iwai Merged, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/22] drm/i915: enable force wake, disable LLC on VLV
This has been discussed elsewhere, but I summarize here for transparency: This makes some of the display registers take the NEEDS_FORCE_WAKE path in reg reads and writes, breaking things. Rebased on top of recent drm-intel-next-queued with Ville's IS_DISPLAYREG nuking commits this works all right, though. BR, Jani. On Sat, 02 Feb 2013, Jesse Barnes wrote: > Signed-off-by: Jesse Barnes > --- > drivers/gpu/drm/i915/i915_drv.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 13b9b4f..b35b479 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -276,6 +276,8 @@ static const struct intel_device_info > intel_valleyview_m_info = { > .has_bsd_ring = 1, > .has_blt_ring = 1, > .is_valleyview = 1, > + .has_force_wake = 1, > + .has_llc = 0, > }; > > static const struct intel_device_info intel_valleyview_d_info = { > @@ -285,6 +287,8 @@ static const struct intel_device_info > intel_valleyview_d_info = { > .has_bsd_ring = 1, > .has_blt_ring = 1, > .is_valleyview = 1, > + .has_force_wake = 1, > + .has_llc = 0, > }; > > static const struct intel_device_info intel_haswell_d_info = { > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Build: Add --disable-tests configure flag to avoid tests build - v2
At Tue, 5 Feb 2013 16:17:54 -0200, Rodrigo Vivi wrote: > > Tests are still being built by default. However this request > came from OSVs in order to allow them to include i-g-t in their > distributions by default avoiding adding more and more dependencies > since we are improving and adding more and more tests. > > v2: wait for Ben's spacin fixes and adjusted for new space rules. /spacin/spacing/ ? Reviewed-by: Takashi Iwai Thanks! We can drop one more patch from SLE package now ;) Takashi > > Signed-off-by: Rodrigo Vivi > > Conflicts: > configure.ac > --- > Makefile.am | 6 +- > configure.ac | 11 ++- > 2 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/Makefile.am b/Makefile.am > index 5ea0fd8..0dd615b 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -21,12 +21,16 @@ > > ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} > > -SUBDIRS = lib man tools scripts tests benchmarks demos > +SUBDIRS = lib man tools scripts benchmarks demos > > if BUILD_SHADER_DEBUGGER > SUBDIRS += debugger > endif > > +if BUILD_TESTS > +SUBDIRS += tests > +endif > + > test: > ${MAKE} -C tests test > > diff --git a/configure.ac b/configure.ac > index 1c56fa4..e66876c 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -122,6 +122,16 @@ AM_CONDITIONAL(BUILD_SHADER_DEBUGGER, [test > "x$BUILD_SHADER_DEBUGGER" != xno]) > XORG_TESTSET_CFLAG([THREAD_CFLAGS], [-pthread], [-mt]) > AC_SUBST([THREAD_CFLAGS]) > > +AC_ARG_ENABLE(tests, > + AS_HELP_STRING([--disable-tests], > + [Disable tests build (default: enabled)]), > + [BUILD_TESTS=$enableval], [BUILD_TESTS="yes"]) > +if test "x$BUILD_TESTS" = xyes; then > + AC_DEFINE(BUILD_TESTS, 1, [Build tests]) > + AC_CONFIG_FILES([tests/Makefile]) > +fi > +AM_CONDITIONAL(BUILD_TESTS, [test "x$BUILD_TESTS" = xyes]) > + > AC_CONFIG_FILES([ >Makefile >benchmarks/Makefile > @@ -129,7 +139,6 @@ AC_CONFIG_FILES([ >lib/Makefile >man/Makefile >scripts/Makefile > - tests/Makefile >tools/Makefile >debugger/Makefile >debugger/system_routine/Makefile > -- > 1.7.11.7 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: write backlight harder
At Wed, 6 Feb 2013 11:24:41 +0100, Daniel Vetter wrote: > > 770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit > commit 770c12312ad617172b1a65b911d3e6564fc5aca8 > Author: Takashi Iwai > Date: Sat Aug 11 08:56:42 2012 +0200 > > drm/i915: Fix blank panel at reopening lid > > changed the register write sequence for restoring the backlight, which > helped prevent non-working backlights on some machines. Turns out that > the original sequence was the right thing to do for a different set of > machines. Worse, setting the backlight level _after_ enabling it seems > to reset it somehow. So we need to make that one conditional upon the > backlight having been reset to zero, and add the old one back. > > Cargo-culting at it's best, but it seems to work. > > Cc: sta...@vger.kernel.org > Cc: Takashi Iwai > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 > Signed-off-by: Daniel Vetter Feel free to take: Acked-by: Takashi Iwai thanks, Takashi > --- > drivers/gpu/drm/i915/intel_panel.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index bee8cb6..a3730e0 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev, > if (dev_priv->backlight_level == 0) > dev_priv->backlight_level = intel_panel_get_max_backlight(dev); > > + dev_priv->backlight_enabled = true; > + intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); > + > if (INTEL_INFO(dev)->gen >= 4) { > uint32_t reg, tmp; > > @@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device > *dev, > } > > set_level: > - /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1. > - * BLC_PWM_CPU_CTL may be cleared to zero automatically when these > - * registers are set. > + /* Check the current backlight level and try to set again if it's zero. > + * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically > + * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written. >*/ > - dev_priv->backlight_enabled = true; > - intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); > + if (!intel_panel_get_backlight(dev)) > + intel_panel_actually_set_backlight(dev, > dev_priv->backlight_level); > } > > static void intel_panel_init_backlight(struct drm_device *dev) > -- > 1.7.10.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915: Validate that the framebuffer accommodates the current mode
As we retrieve the mode from the BIOS it may be constructed using different assumptions for its configuration, such as utilizing the panel fitter in a conflicting manner. As such the associated framebuffer may be insufficient for our setup, and so we need to reject the current mode and install our own. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 38 +- 1 file changed, 28 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c1d8200..f5d4d88 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6441,27 +6441,40 @@ intel_framebuffer_create_for_mode(struct drm_device *dev, return intel_framebuffer_create(dev, &mode_cmd, obj); } +static bool +mode_fits_in_fb(struct drm_display_mode *mode, + struct drm_framebuffer *fb) +{ + struct drm_i915_gem_object *obj; + int min_pitch; + + min_pitch = intel_framebuffer_pitch_for_width(mode->hdisplay, + fb->bits_per_pixel); + if (fb->pitches[0] < min_pitch) + return false; + + obj = to_intel_framebuffer(fb)->obj; + if (obj == NULL) + return false; + + if (obj->base.size < mode->vdisplay * fb->pitches[0]) + return false; + + return true; +} + static struct drm_framebuffer * mode_fits_in_fbdev(struct drm_device *dev, struct drm_display_mode *mode) { struct drm_i915_private *dev_priv = dev->dev_private; - struct drm_i915_gem_object *obj; struct drm_framebuffer *fb; if (dev_priv->fbdev == NULL) return NULL; - obj = dev_priv->fbdev->ifb.obj; - if (obj == NULL) - return NULL; - fb = &dev_priv->fbdev->ifb.base; - if (fb->pitches[0] < intel_framebuffer_pitch_for_width(mode->hdisplay, - fb->bits_per_pixel)) - return NULL; - - if (obj->base.size < mode->vdisplay * fb->pitches[0]) + if (!mode_fits_in_fb(mode, fb)) return NULL; return fb; @@ -9090,6 +9103,11 @@ void intel_modeset_setup_hw_state(struct drm_device *dev, if (crtc->base.enabled) crtc->mode_valid = intel_crtc_get_mode(&crtc->base, &crtc->base.mode); + + if (crtc->base.fb && + !mode_fits_in_fb(&crtc->base.mode, crtc->base.fb)) + crtc->mode_valid = false; + if (crtc->mode_valid) { DRM_DEBUG_KMS("found active mode: "); drm_mode_debug_printmodeline(&crtc->base.mode); -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915: Only preserve the BIOS modes if they are the preferred ones
Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c |9 + drivers/gpu/drm/i915/intel_dp.c |1 + drivers/gpu/drm/i915/intel_drv.h |8 drivers/gpu/drm/i915/intel_fb.c |9 + drivers/gpu/drm/i915/intel_lvds.c|1 + drivers/gpu/drm/i915/intel_panel.c | 10 ++ 6 files changed, 38 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 43e226d..c1d8200 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9233,6 +9233,15 @@ void intel_connector_attach_encoder(struct intel_connector *connector, &encoder->base); } +bool intel_connector_get_preferred_mode(struct intel_connector *connector, + struct drm_display_mode *mode) +{ + if (!connector->get_preferred_mode) + return false; + + return connector->get_preferred_mode(connector, mode); +} + /* * set vga decode state - true == enable VGA decode */ diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index c82aed3..c8597d9 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2922,6 +2922,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, } if (is_edp(intel_dp)) { + intel_connector->get_preferred_mode = intel_connector_get_panel_fixed_mode; intel_panel_init(&intel_connector->panel, fixed_mode); intel_panel_setup_backlight(connector); } diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a6c0b25..8bd9bf0 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -204,6 +204,9 @@ struct intel_connector { * and active (i.e. dpms ON state). */ bool (*get_hw_state)(struct intel_connector *); + bool (*get_preferred_mode)(struct intel_connector *, + struct drm_display_mode *); + /* Panel info for eDP and LVDS */ struct intel_panel panel; @@ -505,6 +508,9 @@ extern int intel_panel_init(struct intel_panel *panel, struct drm_display_mode *fixed_mode); extern void intel_panel_fini(struct intel_panel *panel); +extern bool intel_connector_get_panel_fixed_mode(struct intel_connector *connector, +struct drm_display_mode *mode); + extern void intel_fixed_panel_mode(struct drm_display_mode *fixed_mode, struct drm_display_mode *adjusted_mode); extern void intel_pch_panel_fitting(struct drm_device *dev, @@ -576,6 +582,8 @@ hdmi_to_dig_port(struct intel_hdmi *intel_hdmi) bool ibx_digital_port_connected(struct drm_i915_private *dev_priv, struct intel_digital_port *port); +extern bool intel_connector_get_preferred_mode(struct intel_connector *connector, + struct drm_display_mode *mode); extern void intel_connector_attach_encoder(struct intel_connector *connector, struct intel_encoder *encoder); extern struct drm_encoder *intel_best_encoder(struct drm_connector *connector); diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c index ca6c8e6..32bc904 100644 --- a/drivers/gpu/drm/i915/intel_fb.c +++ b/drivers/gpu/drm/i915/intel_fb.c @@ -237,6 +237,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper *fb_helper, for (i = 0; i < fb_helper->connector_count; i++) { struct drm_connector *connector; struct drm_encoder *encoder; + struct drm_display_mode mode; connector = fb_helper->connector_info[i]->connector; if (!enabled[i]) { @@ -266,6 +267,14 @@ static bool intel_fb_initial_config(struct drm_fb_helper *fb_helper, return false; } + if (intel_connector_get_preferred_mode(to_intel_connector(connector), &mode) && + !drm_mode_equal(&mode, &encoder->crtc->mode)) { + DRM_DEBUG_KMS("connector %s on crtc %d has an non-native mode, aborting\n", + drm_get_connector_name(connector), + encoder->crtc->base.id); + return false; + } + modes[i] = &encoder->crtc->mode; crtcs[i] = intel_fb_helper_crtc(fb_helper, encoder->crtc); diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 3da1b2a..9f4381e 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -1134,6 +1134,7 @@ bool intel_lvds_init(struct drm_device *dev) intel_encoder->get_hw_state = intel_l
[Intel-gfx] [PATCH 6/8] drm/i915: Retrieve the current mode upon KMS takeover
Read the current hardware state to retrieve the active mode and populate our CRTC config if that mode matches our presumptions. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h |2 + drivers/gpu/drm/i915/intel_crt.c | 27 +++- drivers/gpu/drm/i915/intel_display.c | 119 ++ drivers/gpu/drm/i915/intel_dp.c | 22 +++ drivers/gpu/drm/i915/intel_drv.h |7 +- drivers/gpu/drm/i915/intel_dvo.c | 36 ++ drivers/gpu/drm/i915/intel_hdmi.c| 22 +++ drivers/gpu/drm/i915/intel_lvds.c| 27 +++- drivers/gpu/drm/i915/intel_sdvo.c| 23 +++ 9 files changed, 242 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 6f4afbf..aff1436 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -280,6 +280,8 @@ struct drm_i915_display_funcs { void (*update_linetime_wm)(struct drm_device *dev, int pipe, struct drm_display_mode *mode); void (*modeset_global_resources)(struct drm_device *dev); + bool (*crtc_get_mode)(struct drm_crtc *crtc, +struct drm_display_mode *mode); int (*crtc_mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode, diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 68e79f3..aa3001a 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -81,6 +81,27 @@ static bool intel_crt_get_hw_state(struct intel_encoder *encoder, return true; } +static unsigned intel_crt_get_mode_flags(struct intel_encoder *encoder) +{ + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private; + struct intel_crt *crt = intel_encoder_to_crt(encoder); + u32 tmp, flags = 0; + + tmp = I915_READ(crt->adpa_reg); + + if (tmp & ADPA_HSYNC_ACTIVE_HIGH) + flags |= DRM_MODE_FLAG_PHSYNC; + else + flags |= DRM_MODE_FLAG_NHSYNC; + + if (tmp & ADPA_VSYNC_ACTIVE_HIGH) + flags |= DRM_MODE_FLAG_PVSYNC; + else + flags |= DRM_MODE_FLAG_NVSYNC; + + return flags; +} + static void intel_disable_crt(struct intel_encoder *encoder) { struct drm_i915_private *dev_priv = encoder->base.dev->dev_private; @@ -777,10 +798,12 @@ void intel_crt_init(struct drm_device *dev) crt->base.disable = intel_disable_crt; crt->base.enable = intel_enable_crt; - if (HAS_DDI(dev)) + if (HAS_DDI(dev)) { crt->base.get_hw_state = intel_ddi_get_hw_state; - else + } else { crt->base.get_hw_state = intel_crt_get_hw_state; + crt->base.get_mode_flags = intel_crt_get_mode_flags; + } intel_connector->get_hw_state = intel_connector_get_hw_state; drm_encoder_helper_add(&crt->base.base, &crt_encoder_funcs); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7c4c7d5..43e226d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6600,11 +6600,12 @@ void intel_release_load_detect_pipe(struct drm_connector *connector, } /* Returns the clock of the currently programmed mode of the given pipe. */ -static int intel_crtc_clock_get(struct drm_device *dev, struct drm_crtc *crtc) +static int i9xx_crtc_clock_get(struct drm_crtc *crtc) { + struct drm_device *dev = crtc->dev; struct drm_i915_private *dev_priv = dev->dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int pipe = intel_crtc->pipe; + enum pipe pipe = intel_crtc->pipe; u32 dpll = I915_READ(DPLL(pipe)); u32 fp; intel_clock_t clock; @@ -6687,35 +6688,84 @@ static int intel_crtc_clock_get(struct drm_device *dev, struct drm_crtc *crtc) } /** Returns the currently programmed mode of the given pipe. */ -struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev, -struct drm_crtc *crtc) +static bool i9xx_crtc_get_mode(struct drm_crtc *crtc, + struct drm_display_mode *mode) { - struct drm_i915_private *dev_priv = dev->dev_private; + struct drm_i915_private *dev_priv = crtc->dev->dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); enum transcoder cpu_transcoder = intel_crtc->cpu_transcoder; - struct drm_display_mode *mode; - int htot = I915_READ(HTOTAL(cpu_transcoder)); - int hsync = I915_READ(HSYNC(cpu_transcoder)); - int vtot = I915_READ(VTOTAL(cpu_transcoder)); - int vsync = I915_READ(VSYNC(cpu_transcoder)); + u32 tmp; - mode = kzalloc(sizeof(*mode), GFP_KERNEL); - if (!mode) -
[Intel-gfx] [PATCH 5/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon
Signed-off-by: Chris Wilson Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_dma.c |8 +- drivers/gpu/drm/i915/i915_drv.h |2 +- drivers/gpu/drm/i915/intel_display.c | 14 +- drivers/gpu/drm/i915/intel_drv.h |4 + drivers/gpu/drm/i915/intel_fb.c | 305 +++--- 5 files changed, 306 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 4fa6beb..f2b7db7 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1273,6 +1273,7 @@ static const struct vga_switcheroo_client_ops i915_switcheroo_ops = { static int i915_load_modeset_init(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; + bool was_vga_enabled; int ret; ret = intel_parse_bios(dev); @@ -1309,7 +1310,11 @@ static int i915_load_modeset_init(struct drm_device *dev) /* Important: The output setup functions called by modeset_init need * working irqs for e.g. gmbus and dp aux transfers. */ - intel_modeset_init(dev); + intel_modeset_init(dev, &was_vga_enabled); + + /* Wrap existing BIOS mode configuration prior to GEM takeover */ + if (!was_vga_enabled) + intel_fbdev_init_bios(dev); ret = i915_gem_init(dev); if (ret) @@ -1323,6 +1328,7 @@ static int i915_load_modeset_init(struct drm_device *dev) /* FIXME: do pre/post-mode set stuff in core KMS code */ dev->vblank_disable_allowed = 1; + /* Install a default KMS/GEM fbcon if we failed to wrap the BIOS fb */ ret = intel_fbdev_init(dev); if (ret) goto cleanup_gem; diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index fd8a495..6f4afbf 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1814,7 +1814,7 @@ static inline void intel_unregister_dsm_handler(void) { return; } /* modesetting */ extern void intel_modeset_init_hw(struct drm_device *dev); -extern void intel_modeset_init(struct drm_device *dev); +extern void intel_modeset_init(struct drm_device *dev, bool *was_vga_enabled); extern void intel_modeset_gem_init(struct drm_device *dev); extern void intel_modeset_cleanup(struct drm_device *dev); extern int intel_modeset_vga_set_state(struct drm_device *dev, bool state); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8f9cdd7..7c4c7d5 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8698,12 +8698,17 @@ static void intel_init_quirks(struct drm_device *dev) } /* Disable the VGA plane that we never use */ -static void i915_disable_vga(struct drm_device *dev) +static bool i915_disable_vga(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; + bool was_enabled; u8 sr1; u32 vga_reg = i915_vgacntrl_reg(dev); + was_enabled = !(I915_READ(vga_reg) & VGA_DISP_DISABLE); + DRM_DEBUG_KMS("VGA output is currently %s\n", + was_enabled ? "enabled" : "disabled"); + vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO); outb(SR01, VGA_SR_INDEX); sr1 = inb(VGA_SR_DATA); @@ -8713,6 +8718,8 @@ static void i915_disable_vga(struct drm_device *dev) I915_WRITE(vga_reg, VGA_DISP_DISABLE); POSTING_READ(vga_reg); + + return was_enabled; } void intel_modeset_init_hw(struct drm_device *dev) @@ -8728,7 +8735,8 @@ void intel_modeset_init_hw(struct drm_device *dev) mutex_unlock(&dev->struct_mutex); } -void intel_modeset_init(struct drm_device *dev) +void intel_modeset_init(struct drm_device *dev, + bool *was_vga_enabled) { struct drm_i915_private *dev_priv = dev->dev_private; int i, ret; @@ -8775,7 +8783,7 @@ void intel_modeset_init(struct drm_device *dev) intel_pch_pll_init(dev); /* Just disable it once at startup */ - i915_disable_vga(dev); + *was_vga_enabled = i915_disable_vga(dev); intel_setup_outputs(dev); /* Just in case the BIOS is doing something questionable. */ diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 07d95a1..985e9dd 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -146,6 +146,8 @@ struct intel_fbdev { struct intel_framebuffer ifb; struct list_head fbdev_list; struct drm_display_mode *our_mode; + bool stolen; + int preferred_bpp; }; struct intel_encoder { @@ -212,6 +214,7 @@ struct intel_crtc { enum plane plane; enum transcoder cpu_transcoder; u8 lut_r[256], lut_g[256], lut_b[256]; + bool mode_valid; /* * Whether the crtc and the connected output pipeline is active. Implies * that crtc->enabled is
[Intel-gfx] [PATCH 4/8] drm: add initial_config function to fb helper
From: Jesse Barnes Rather than building a config which may or may not work, let the driver build an initial fb config. This allows the driver to use the BIOS boot configuration for example, displaying kernel messages and the initial fb console on the same outputs the BIOS lit up at boot time. If that fails, the driver can still fall back the same way as the core. Signed-off-by: Jesse Barnes Signed-off-by: Chris Wilson Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/drm_fb_helper.c | 23 +++ include/drm/drm_fb_helper.h |4 2 files changed, 19 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 954d175..924901d 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1247,7 +1247,7 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper) struct drm_mode_set *modeset; bool *enabled; int width, height; - int i, ret; + int i; DRM_DEBUG_KMS("\n"); @@ -1268,16 +1268,23 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper) drm_enable_connectors(fb_helper, enabled); - ret = drm_target_cloned(fb_helper, modes, enabled, width, height); - if (!ret) { - ret = drm_target_preferred(fb_helper, modes, enabled, width, height); - if (!ret) + if (!(fb_helper->funcs->initial_config && + fb_helper->funcs->initial_config(fb_helper, crtcs, modes, + enabled, width, height))) { + memset(modes, 0, dev->mode_config.num_connector*sizeof(modes[0])); + memset(crtcs, 0, dev->mode_config.num_connector*sizeof(crtcs[0])); + + if (!drm_target_cloned(fb_helper, + modes, enabled, width, height) && + !drm_target_preferred(fb_helper, + modes, enabled, width, height)) DRM_ERROR("Unable to find initial modes\n"); - } - DRM_DEBUG_KMS("picking CRTCs for %dx%d config\n", width, height); + DRM_DEBUG_KMS("picking CRTCs for %dx%d config\n", + width, height); - drm_pick_crtcs(fb_helper, crtcs, modes, 0, width, height); + drm_pick_crtcs(fb_helper, crtcs, modes, 0, width, height); + } /* need to set the modesets up here for use later */ /* fill out the connector<->crtc mappings into the modesets */ diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h index 5120b01..40b0c5c 100644 --- a/include/drm/drm_fb_helper.h +++ b/include/drm/drm_fb_helper.h @@ -56,6 +56,10 @@ struct drm_fb_helper_funcs { int (*fb_probe)(struct drm_fb_helper *helper, struct drm_fb_helper_surface_size *sizes); + bool (*initial_config)(struct drm_fb_helper *fb_helper, + struct drm_fb_helper_crtc **crtcs, + struct drm_display_mode **modes, + bool *enabled, int width, int height); }; struct drm_fb_helper_connector { -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915: Split the framebuffer_info creation into a separate routine
This will be shared with wrapping the BIOS framebuffer into the fbdev later. In the meantime, we can tidy the code slightly and improve the error path handling. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c |7 -- drivers/gpu/drm/i915/intel_drv.h |7 ++ drivers/gpu/drm/i915/intel_fb.c | 154 ++ 3 files changed, 91 insertions(+), 77 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f1dbd01..8f9cdd7 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6413,13 +6413,6 @@ intel_framebuffer_create(struct drm_device *dev, } static u32 -intel_framebuffer_pitch_for_width(int width, int bpp) -{ - u32 pitch = DIV_ROUND_UP(width * bpp, 8); - return ALIGN(pitch, 64); -} - -static u32 intel_framebuffer_size_for_mode(struct drm_display_mode *mode, int bpp) { u32 pitch = intel_framebuffer_pitch_for_width(mode->hdisplay, bpp); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 13afb37..07d95a1 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -134,6 +134,13 @@ struct intel_framebuffer { struct drm_i915_gem_object *obj; }; +inline static u32 +intel_framebuffer_pitch_for_width(int width, int bpp) +{ + u32 pitch = DIV_ROUND_UP(width * bpp, 8); + return ALIGN(pitch, 64); +} + struct intel_fbdev { struct drm_fb_helper helper; struct intel_framebuffer ifb; diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c index 6591029..de0ac4c 100644 --- a/drivers/gpu/drm/i915/intel_fb.c +++ b/drivers/gpu/drm/i915/intel_fb.c @@ -57,29 +57,96 @@ static struct fb_ops intelfb_ops = { .fb_debug_leave = drm_fb_helper_debug_leave, }; +static struct fb_info *intelfb_create_info(struct intel_fbdev *ifbdev) +{ + struct drm_framebuffer *fb = &ifbdev->ifb.base; + struct drm_device *dev = fb->dev; + struct drm_i915_private *dev_priv = dev->dev_private; + struct fb_info *info; + u32 gtt_offset, size; + int ret; + + info = framebuffer_alloc(0, &dev->pdev->dev); + if (!info) + return NULL; + + info->par = ifbdev; + ifbdev->helper.fb = fb; + ifbdev->helper.fbdev = info; + + strcpy(info->fix.id, "inteldrmfb"); + + info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT; + info->fbops = &intelfb_ops; + + ret = fb_alloc_cmap(&info->cmap, 256, 0); + if (ret) + goto err_info; + + /* setup aperture base/size for vesafb takeover */ + info->apertures = alloc_apertures(1); + if (!info->apertures) + goto err_cmap; + + info->apertures->ranges[0].base = dev->mode_config.fb_base; + info->apertures->ranges[0].size = dev_priv->gtt.mappable_end; + + gtt_offset = ifbdev->ifb.obj->gtt_offset; + size = ifbdev->ifb.obj->base.size; + + info->fix.smem_start = dev->mode_config.fb_base + gtt_offset; + info->fix.smem_len = size; + + info->screen_size = size; + info->screen_base = ioremap_wc(dev_priv->gtt.mappable_base + gtt_offset, + size); + if (!info->screen_base) + goto err_cmap; + + /* If the object is shmemfs backed, it will have given us zeroed pages. +* If the object is stolen however, it will be full of whatever +* garbage was left in there. +*/ + if (ifbdev->ifb.obj->stolen) + memset_io(info->screen_base, 0, info->screen_size); + + /* Use default scratch pixmap (info->pixmap.flags = FB_PIXMAP_SYSTEM) */ + + drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth); + drm_fb_helper_fill_var(info, &ifbdev->helper, fb->width, fb->height); + + return info; + +err_cmap: + if (info->cmap.len) + fb_dealloc_cmap(&info->cmap); +err_info: + framebuffer_release(info); + return NULL; +} + static int intelfb_create(struct intel_fbdev *ifbdev, struct drm_fb_helper_surface_size *sizes) { struct drm_device *dev = ifbdev->helper.dev; - struct drm_i915_private *dev_priv = dev->dev_private; - struct fb_info *info; - struct drm_framebuffer *fb; - struct drm_mode_fb_cmd2 mode_cmd = {}; + struct drm_mode_fb_cmd2 mode_cmd = { 0 }; struct drm_i915_gem_object *obj; - struct device *device = &dev->pdev->dev; + struct fb_info *info; int size, ret; /* we don't do packed 24bpp */ if (sizes->surface_bpp == 24) sizes->surface_bpp = 32; - mode_cmd.width = sizes->surface_width; + mode_cmd.width = sizes->surface_width; mode_cmd.height = sizes->surface_height; - mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((sizes->surface_bpp + 7) / -
[Intel-gfx] [PATCH 2/8] drm/i915: Introduce i915_gem_object_create_stolen_for_preallocated
Wrap a preallocated region of stolen memory within an ordinary GEM object, for example the BIOS framebuffer. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h|5 +++ drivers/gpu/drm/i915/i915_gem_stolen.c | 65 2 files changed, 70 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 08c5def..fd8a495 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1720,6 +1720,11 @@ void i915_gem_stolen_cleanup_compression(struct drm_device *dev); void i915_gem_cleanup_stolen(struct drm_device *dev); struct drm_i915_gem_object * i915_gem_object_create_stolen(struct drm_device *dev, u32 size); +struct drm_i915_gem_object * +i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev, + u32 stolen_offset, + u32 gtt_offset, + u32 size); void i915_gem_object_release_stolen(struct drm_i915_gem_object *obj); /* i915_gem_tiling.c */ diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index 69d97cb..130d1db 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -312,6 +312,71 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size) return NULL; } +struct drm_i915_gem_object * +i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev, + u32 stolen_offset, + u32 gtt_offset, + u32 size) +{ + struct drm_i915_private *dev_priv = dev->dev_private; + struct drm_i915_gem_object *obj; + struct drm_mm_node *stolen; + + if (dev_priv->mm.stolen_base == 0) + return NULL; + + DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, gtt_offset=%x, size=%x\n", + stolen_offset, gtt_offset, size); + + /* KISS and expect everything to be page-aligned */ + BUG_ON(stolen_offset & 4095); + BUG_ON(gtt_offset & 4095); + BUG_ON(size & 4095); + + if (WARN_ON(size == 0)) + return NULL; + + stolen = drm_mm_create_block(&dev_priv->mm.stolen, +stolen_offset, size, +false); + if (stolen == NULL) { + DRM_DEBUG_KMS("failed to allocate stolen space\n"); + return NULL; + } + + obj = _i915_gem_object_create_stolen(dev, stolen); + if (obj == NULL) { + DRM_DEBUG_KMS("failed to allocate stolen object\n"); + drm_mm_put_block(stolen); + return NULL; + } + + /* To simplify the initialisation sequence between KMS and GTT, +* we allow construction of the stolen object prior to +* setting up the GTT space. The actual reservation will occur +* later. +*/ + if (drm_mm_initialized(&dev_priv->mm.gtt_space)) { + obj->gtt_space = drm_mm_create_block(&dev_priv->mm.gtt_space, +gtt_offset, size, +false); + if (obj->gtt_space == NULL) { + DRM_DEBUG_KMS("failed to allocate stolen GTT space\n"); + drm_gem_object_unreference(&obj->base); + return NULL; + } + } else + obj->gtt_space = I915_GTT_RESERVED; + + obj->gtt_offset = gtt_offset; + obj->has_global_gtt_mapping = 1; + + list_add_tail(&obj->gtt_list, &dev_priv->mm.bound_list); + list_add_tail(&obj->mm_list, &dev_priv->mm.inactive_list); + + return obj; +} + void i915_gem_object_release_stolen(struct drm_i915_gem_object *obj) { -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Skip modifying PCH DREF if not changing clock sources
Modifying the clock sources (via the DREF control on the PCH) is a slow multi-stage process as we need to let the clocks stabilise between each stage. If we are not actually changing the clock sources, then we can return early. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 83 +- 1 file changed, 61 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index d75c6a0..f1dbd01 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4749,7 +4749,7 @@ static void ironlake_init_pch_refclk(struct drm_device *dev) struct drm_i915_private *dev_priv = dev->dev_private; struct drm_mode_config *mode_config = &dev->mode_config; struct intel_encoder *encoder; - u32 temp; + u32 val, final; bool has_lvds = false; bool has_cpu_edp = false; bool has_pch_edp = false; @@ -4792,70 +4792,109 @@ static void ironlake_init_pch_refclk(struct drm_device *dev) * PCH B stepping, previous chipset stepping should be * ignoring this setting. */ - temp = I915_READ(PCH_DREF_CONTROL); + val = I915_READ(PCH_DREF_CONTROL); + + /* As we must carefully and slowly disable/enable each source in turn, +* compute the final state we want first and check if we need to +* make any changes at all. +*/ + final = val; + final &= ~DREF_NONSPREAD_SOURCE_MASK; + if (has_ck505) + final |= DREF_NONSPREAD_CK505_ENABLE; + else + final |= DREF_NONSPREAD_SOURCE_ENABLE; + + final &= ~DREF_SSC_SOURCE_MASK; + final &= ~DREF_CPU_SOURCE_OUTPUT_MASK; + final &= ~DREF_SSC1_ENABLE; + + if (has_panel) { + final |= DREF_SSC_SOURCE_ENABLE; + + if (intel_panel_use_ssc(dev_priv) && can_ssc) + final |= DREF_SSC1_ENABLE; + + if (has_cpu_edp) { + if (intel_panel_use_ssc(dev_priv) && can_ssc) + final |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD; + else + final |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD; + } else + final |= DREF_CPU_SOURCE_OUTPUT_DISABLE; + } else { + final |= DREF_SSC_SOURCE_DISABLE; + final |= DREF_CPU_SOURCE_OUTPUT_DISABLE; + } + + if (final == val) + return; + /* Always enable nonspread source */ - temp &= ~DREF_NONSPREAD_SOURCE_MASK; + val &= ~DREF_NONSPREAD_SOURCE_MASK; if (has_ck505) - temp |= DREF_NONSPREAD_CK505_ENABLE; + val |= DREF_NONSPREAD_CK505_ENABLE; else - temp |= DREF_NONSPREAD_SOURCE_ENABLE; + val |= DREF_NONSPREAD_SOURCE_ENABLE; if (has_panel) { - temp &= ~DREF_SSC_SOURCE_MASK; - temp |= DREF_SSC_SOURCE_ENABLE; + val &= ~DREF_SSC_SOURCE_MASK; + val |= DREF_SSC_SOURCE_ENABLE; /* SSC must be turned on before enabling the CPU output */ if (intel_panel_use_ssc(dev_priv) && can_ssc) { DRM_DEBUG_KMS("Using SSC on panel\n"); - temp |= DREF_SSC1_ENABLE; + val |= DREF_SSC1_ENABLE; } else - temp &= ~DREF_SSC1_ENABLE; + val &= ~DREF_SSC1_ENABLE; /* Get SSC going before enabling the outputs */ - I915_WRITE(PCH_DREF_CONTROL, temp); + I915_WRITE(PCH_DREF_CONTROL, val); POSTING_READ(PCH_DREF_CONTROL); udelay(200); - temp &= ~DREF_CPU_SOURCE_OUTPUT_MASK; + val &= ~DREF_CPU_SOURCE_OUTPUT_MASK; /* Enable CPU source on CPU attached eDP */ if (has_cpu_edp) { if (intel_panel_use_ssc(dev_priv) && can_ssc) { DRM_DEBUG_KMS("Using SSC on eDP\n"); - temp |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD; + val |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD; } else - temp |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD; + val |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD; } else - temp |= DREF_CPU_SOURCE_OUTPUT_DISABLE; + val |= DREF_CPU_SOURCE_OUTPUT_DISABLE; - I915_WRITE(PCH_DREF_CONTROL, temp); + I915_WRITE(PCH_DREF_CONTROL, val); POSTING_READ(PCH_DREF_CONTROL); udelay(200); } else { DRM_DEBUG_KMS("Disabling SSC entirely\n"); - temp &= ~DREF_CPU_SOURCE_OUTPUT_MAS
[Intel-gfx] [PATCH] drm/i915: write backlight harder
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid changed the register write sequence for restoring the backlight, which helped prevent non-working backlights on some machines. Turns out that the original sequence was the right thing to do for a different set of machines. Worse, setting the backlight level _after_ enabling it seems to reset it somehow. So we need to make that one conditional upon the backlight having been reset to zero, and add the old one back. Cargo-culting at it's best, but it seems to work. Cc: sta...@vger.kernel.org Cc: Takashi Iwai Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_panel.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index bee8cb6..a3730e0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev, if (dev_priv->backlight_level == 0) dev_priv->backlight_level = intel_panel_get_max_backlight(dev); + dev_priv->backlight_enabled = true; + intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); + if (INTEL_INFO(dev)->gen >= 4) { uint32_t reg, tmp; @@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device *dev, } set_level: - /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1. -* BLC_PWM_CPU_CTL may be cleared to zero automatically when these -* registers are set. + /* Check the current backlight level and try to set again if it's zero. +* On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically +* when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written. */ - dev_priv->backlight_enabled = true; - intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); + if (!intel_panel_get_backlight(dev)) + intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); } static void intel_panel_init_backlight(struct drm_device *dev) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] NEWS: Fix a typo: a*n* inadvertent
I'm a terrible proof-reader. Thanks for the correction, applied. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] configure.ac: Split out XCB libraries from `XVMCLIB` into `XCB`
On Wed, Feb 06, 2013 at 10:59:53AM +0100, Paul Menzel wrote: > Date: Sun, 3 Feb 2013 13:33:08 +0100 > > Building the package under Debian Sid/unstable, `dh_shlibdeps` informs > that `libI810XvMC.so.1.0.0` does not need to be linked against > `libX11-xcb.so.1`, `libxcb-dri2.so.0`, `libxcb-util.so.0` or > `libxcb.so.1` [1]. [snip] Thanks for the patch, applied. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] NEWS: Fix a typo: a*n* inadvertent
Date: Tue, 22 Jan 2013 10:47:22 +0100 --- NEWS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index a1fcf66..bc384e7 100644 --- a/NEWS +++ b/NEWS @@ -47,7 +47,7 @@ As usual we have a large number of bug fixes since the last release: Release 2.20.19 (2013-01-20) A quick release as the last broke USB DisplayLink slave outputs badly. The -performance of those displays was unusable due to a inadvertent change that +performance of those displays was unusable due to an inadvertent change that caused us to flush the entire scanout over the USB for every drawing operation. -- 1.7.10.4 signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] configure.ac: Split out XCB libraries from `XVMCLIB` into `XCB`
Date: Sun, 3 Feb 2013 13:33:08 +0100 Building the package under Debian Sid/unstable, `dh_shlibdeps` informs that `libI810XvMC.so.1.0.0` does not need to be linked against `libX11-xcb.so.1`, `libxcb-dri2.so.0`, `libxcb-util.so.0` or `libxcb.so.1` [1]. $ debuild -b -us -uc […] make[1]: Entering directory `/src/xserver-xorg-video-intel' dh_shlibdeps -- --warnings=6 dpkg-shlibdeps: Warnung: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen libX11-xcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole) dpkg-shlibdeps: Warnung: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen libxcb-dri2.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole) dpkg-shlibdeps: Warnung: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen libxcb-util.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole) dpkg-shlibdeps: Warnung: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen libxcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole) make[1]: Leaving directory `/src/xserver-xorg-video-intel' […] Moving `x11-xcb`, `xcb-dri2` and `xcb-aux` from `XVMCLIBS` into `XCB` and adding `XCB_LIBS` only to the `LIBADD` variables of `libIntelXvMC` makes the warnings go away and the libraries are still built without any issues. make[1]: Entering directory `/src/xserver-xorg-video-intel' dh_shlibdeps -- --warnings=6 make[1]: Leaving directory `/src/xserver-xorg-video-intel' dh_installdeb -O--builddirectory=build/ dh_xsf_substvars -O--builddirectory=build/ dh_gencontrol -O--builddirectory=build/ dpkg-gencontrol: Warnung: Feld Depends von Paket xserver-xorg-video-intel-dbg: unbekannte Substitutionsvariable ${shlibs:Depends} dh_md5sums -O--builddirectory=build/ dh_builddeb -O--builddirectory=build/ dpkg-deb: Paket »xserver-xorg-video-intel« wird in »../xserver-xorg-video-intel_2.19.0-6.1_i386.deb« gebaut. dpkg-deb: Paket »xserver-xorg-video-intel-dbg« wird in »../xserver-xorg-video-intel-dbg_2.19.0-6.1_i386.deb« gebaut. dpkg-genchanges -b >../xserver-xorg-video-intel_2.19.0-6.1_i386.changes dpkg-genchanges: rein binärer Upload - es ist kein Quellcode hinzugefügt dpkg-source --after-build xserver-xorg-video-intel dpkg-buildpackage: Binärpaket(e) hochzuladen (keine Quellen enthalten) Now running lintian... W: xserver-xorg-video-intel: hardening-no-relro usr/lib/libI810XvMC.so.1.0.0 W: xserver-xorg-video-intel: hardening-no-fortify-functions usr/lib/libI810XvMC.so.1.0.0 W: xserver-xorg-video-intel: hardening-no-relro usr/lib/libIntelXvMC.so.1.0.0 W: xserver-xorg-video-intel: hardening-no-fortify-functions usr/lib/libIntelXvMC.so.1.0.0 W: xserver-xorg-video-intel: hardening-no-relro usr/lib/xorg/modules/drivers/intel_drv.so W: xserver-xorg-video-intel: hardening-no-fortify-functions usr/lib/xorg/modules/drivers/intel_drv.so N: 1 tag overridden (1 warning) Finished running lintian. The modules were originally added with the following commit present since tag 2.10.0. commit 3e8f2eae3a586aa29be4858698e666e0ec778cea Author: Eric Anholt Date: Thu Oct 15 13:48:56 2009 -0700 XVMC: Use XCB DRI2 instead of cargo-culting our own copy of Xlib stuff. (v2) [1] https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-intel&arch=i386&ver=2%3A2.19.0-6&stamp=1347825458 Signed-off-by: Paul Menzel --- configure.ac |3 ++- src/xvmc/Makefile.am |2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index e6ab9d0..5ae4208 100644 --- a/configure.ac +++ b/configure.ac @@ -404,8 +404,9 @@ AC_MSG_RESULT([$DRI2]) if test "$XVMC" = yes; then PKG_CHECK_MODULES(XVMCLIB, - [xvmc dri2proto x11-xcb xcb-dri2 xcb-aux], + [xvmc dri2proto], [XVMC=yes], [XVMC=no]) + PKG_CHECK_MODULES(XCB, [x11-xcb xcb-dri2 xcb-aux]) fi AC_MSG_CHECKING([whether to include XvMC support]) AC_MSG_RESULT([$XVMC]) diff --git a/src/xvmc/Makefile.am b/src/xvmc/Makefile.am index 36a939b..85e6a89 100644 --- a/src/xvmc/Makefile.am +++ b/src/xvmc/Makefile.am @@ -20,4 +20,4 @@ AM_CFLAGS = @XORG_CFLAGS@ @DRM_CFLAGS@ @DRI_CFLAGS@ \ @XVMCLIB_CFLAGS@ -I$(top_srcdir)/src -DTRUE=1 -DFALSE=0 libIntelXvMC_la_LDFLAGS = -version-number 1:0:0 -libIntelXvMC_la_LIBADD = @DRI_LIBS@ @DRM_LIBS@ @XVMCLIB_LIBS@ @DRMINTEL_LIBS@ -lpthread +libIntelXvMC_la_LIBADD = @DRI_LIBS@ @DRM_LIBS@ @XVMCLIB_LIBS@ @XCB_LIBS@ @DRMINTEL_LIBS@ -lpthread -- 1.7.10.4 signature.asc Description: This is a digitally signed message part ___
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Discard the unbound list when suspending
On Wed, Feb 06, 2013 at 09:31:21AM +, Chris Wilson wrote: > The unbound tracking of objects is an optimisation to avoid costly > domain transfers whilst the system is rendering. Across suspend, the > objects will be involuntarily moved out of the GTT domain and will > require fixup upon resume. Rather than perform those clflushes for all > objects immediately upon resume, just move them out of the unbound > tracking list on suspend and lazily reload them from the CPU domain as > and when they are used afterwards. > > Signed-off-by: Chris Wilson Similar comment about fast resume performance: I think we should only do these when freezing for hibernation. Otherwise browser performance with cool new stuff like the fast S1x suspend (or whatever it's called again) will be a horrible experience. Every time you just read for a few seconds and the system suspend in the background we'll drop all gem bo's on the floor ... -Daniel > --- > drivers/gpu/drm/i915/i915_gem.c | 24 > 1 file changed, 24 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index f6ef53f..db14c73 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3912,6 +3912,17 @@ void i915_gem_free_object(struct drm_gem_object > *gem_obj) > i915_gem_object_free(obj); > } > > +static void > +i915_gem_discard_unbound(struct drm_i915_private *dev_priv) > +{ > + struct drm_i915_gem_object *obj, *next; > + > + list_for_each_entry_safe(obj, next, > + &dev_priv->mm.unbound_list, > + gtt_list) > + (void)i915_gem_object_put_pages(obj); > +} > + > int > i915_gem_idle(struct drm_device *dev) > { > @@ -3936,6 +3947,19 @@ i915_gem_idle(struct drm_device *dev) > if (!drm_core_check_feature(dev, DRIVER_MODESET)) > i915_gem_evict_everything(dev); > > + /* For KMS we just want to discard the unbound list as it will > + * change domains when thawing - and restoring its domain upon > + * resume seems like a false optimisation. Also note that discarding > + * the unbound list will have the useful side-effect of dropping > + * purgeable objects which it seems pointless to restore as they are > + * merely a userspace cache. > + * However, we may still have some pinned objects (like dma-buf) > + * that cannot simply be discarded and will require domain > + * restoration upon resume. > + */ > + if (drm_core_check_feature(dev, DRIVER_MODESET)) > + i915_gem_discard_unbound(dev_priv); > + > i915_gem_reset_fences(dev); > > /* Hack! Don't let anybody do execbuf while we don't control the chip. > -- > 1.7.10.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Restore GTT domain tracking of unbound objects upon resume
On Wed, Feb 06, 2013 at 09:31:20AM +, Chris Wilson wrote: > In order for the objects to be coherent in uncached memory (as they are > presumed to be on the unbound list) we need to clflush them because > experience dictates that the CPU caches will be dirtied across > hibernation. > > Cc: sta...@vger.kernel.org > Signed-off-by: Chris Wilson I think this change will freak out Jesse, since it'll kill resume time when we clflush a few GB of memory. So could you throw another patch on top of this series (maybe after the unbound dropping) which calls restore_gtt only when thawing from hibernate, but not when resuming? > --- > drivers/gpu/drm/i915/i915_gem_gtt.c |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index bdaca3f..368c821 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -404,6 +404,9 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev) > i915_gem_gtt_bind_object(obj, obj->cache_level); > } > > + list_for_each_entry(obj, &dev_priv->mm.unbound_list, gtt_list) > + i915_gem_clflush_object(obj); > + > i915_gem_chipset_flush(dev); > } > > -- > 1.7.10.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Restore GTT domain tracking of unbound objects upon resume
In order for the objects to be coherent in uncached memory (as they are presumed to be on the unbound list) we need to clflush them because experience dictates that the CPU caches will be dirtied across hibernation. Cc: sta...@vger.kernel.org Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_gtt.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index bdaca3f..368c821 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -404,6 +404,9 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev) i915_gem_gtt_bind_object(obj, obj->cache_level); } + list_for_each_entry(obj, &dev_priv->mm.unbound_list, gtt_list) + i915_gem_clflush_object(obj); + i915_gem_chipset_flush(dev); } -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Discard the unbound list when suspending
The unbound tracking of objects is an optimisation to avoid costly domain transfers whilst the system is rendering. Across suspend, the objects will be involuntarily moved out of the GTT domain and will require fixup upon resume. Rather than perform those clflushes for all objects immediately upon resume, just move them out of the unbound tracking list on suspend and lazily reload them from the CPU domain as and when they are used afterwards. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index f6ef53f..db14c73 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3912,6 +3912,17 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj) i915_gem_object_free(obj); } +static void +i915_gem_discard_unbound(struct drm_i915_private *dev_priv) +{ + struct drm_i915_gem_object *obj, *next; + + list_for_each_entry_safe(obj, next, +&dev_priv->mm.unbound_list, +gtt_list) + (void)i915_gem_object_put_pages(obj); +} + int i915_gem_idle(struct drm_device *dev) { @@ -3936,6 +3947,19 @@ i915_gem_idle(struct drm_device *dev) if (!drm_core_check_feature(dev, DRIVER_MODESET)) i915_gem_evict_everything(dev); + /* For KMS we just want to discard the unbound list as it will +* change domains when thawing - and restoring its domain upon +* resume seems like a false optimisation. Also note that discarding +* the unbound list will have the useful side-effect of dropping +* purgeable objects which it seems pointless to restore as they are +* merely a userspace cache. +* However, we may still have some pinned objects (like dma-buf) +* that cannot simply be discarded and will require domain +* restoration upon resume. +*/ + if (drm_core_check_feature(dev, DRIVER_MODESET)) + i915_gem_discard_unbound(dev_priv); + i915_gem_reset_fences(dev); /* Hack! Don't let anybody do execbuf while we don't control the chip. -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] PM: make VT switching to the suspend console optional v3
On Tue, Feb 05, 2013 at 11:02:17PM +0100, Rafael J. Wysocki wrote: > On Tuesday, February 05, 2013 01:55:44 PM Jesse Barnes wrote: > > On Mon, 04 Feb 2013 21:26:26 +0100 > > "Rafael J. Wysocki" wrote: > > > > > On Monday, February 04, 2013 01:37:20 PM Jesse Barnes wrote: > > > > KMS drivers can potentially restore the display configuration without > > > > userspace help. Such drivers can can call a new funciton, > > > > pm_vt_switch_required(false) if they support this feature. In that > > > > case, the PM layer won't VT switch to the suspend console at suspend > > > > time and then back to the original VT on resume, but rather leave things > > > > alone for a nicer looking suspend and resume sequence. > > > > > > > > v2: make a function so we can handle multiple drivers (Alan) > > > > v3: use a list to track device requests (Rafael) > > > > > > > > Signed-off-by: Jesse Barnes > > > > > > Acked-by: Rafael J. Wysocki > > > > > > for all [1-3/3]. > > > > Any chance for an r-b on the PM one at least? Then Daniel could > > probably push this through drm-intel-next. > > Done. Thanks, I've merged the first two patches to drm-intel-next, the i915 one still needs a bit of care imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: support resume without VT switch v2
On Mon, Feb 04, 2013 at 01:37:22PM +, Jesse Barnes wrote: > Add support for resuming the suspend configuration at resume time to > avoid slow and ugly VT switches during suspend and resume. Also emit a > hotplug event at resume time to make sure any potential configuration > changes (monitors coming and going, dock events) are handled properly. > > v2: use new fb flag to indicate we don't need to VT switch > > Signed-off-by: Jesse Barnes > --- > drivers/gpu/drm/i915/i915_drv.c | 28 +--- > drivers/gpu/drm/i915/i915_drv.h |1 + > drivers/gpu/drm/i915/intel_display.c | 25 + > drivers/gpu/drm/i915/intel_fb.c |3 +++ > 4 files changed, 54 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 1172658..7dbaa01 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -483,8 +483,6 @@ static int i915_drm_freeze(struct drm_device *dev) > > cancel_delayed_work_sync(&dev_priv->rps.delayed_resume_work); > > - intel_modeset_disable(dev); > - You can't just drop this without replacement I think, check git blame for why it's been added. > drm_irq_uninstall(dev); > } > > @@ -544,6 +542,24 @@ void intel_console_resume(struct work_struct *work) > console_unlock(); > } > > +static void intel_resume_hotplug(struct drm_device *dev) > +{ > + struct drm_mode_config *mode_config = &dev->mode_config; > + struct intel_encoder *encoder; > + > + mutex_lock(&mode_config->mutex); > + DRM_DEBUG_KMS("running encoder hotplug functions\n"); > + > + list_for_each_entry(encoder, &mode_config->encoder_list, base.head) > + if (encoder->hot_plug) > + encoder->hot_plug(encoder); > + > + mutex_unlock(&mode_config->mutex); > + > + /* Just fire off a uevent and let userspace tell us what to do */ > + drm_helper_hpd_irq_event(dev); > +} This should imo be in a separate patch, since afaict we don't bother with this right now. And I guess we should figure out how this should be done across drm drivers ... > + > static int __i915_drm_thaw(struct drm_device *dev) > { > struct drm_i915_private *dev_priv = dev->dev_private; > @@ -563,8 +579,14 @@ static int __i915_drm_thaw(struct drm_device *dev) > mutex_unlock(&dev->struct_mutex); > > intel_modeset_init_hw(dev); > - intel_modeset_setup_hw_state(dev, false); Since this doesn't add any delays (besides a few register reads), but adds tons of paranoid checks for our state-handling: Why drop it? Dropping this also explains why you get away with killing intel_modeset_disable without swimming in a see of WARN_ONs ;-) > drm_irq_install(dev); > + > + /* Resume the modeset for every activated CRTC */ > + mutex_lock(&dev->mode_config.mutex); > + intel_resume_force_mode(dev); > + mutex_unlock(&dev->mode_config.mutex); > + > + intel_resume_hotplug(dev); > } > > intel_opregion_init(dev); > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 12ab3bd..c8b1896 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1680,6 +1680,7 @@ extern void gen6_set_rps(struct drm_device *dev, u8 > val); > extern void intel_detect_pch(struct drm_device *dev); > extern int intel_trans_dp_port_sel(struct drm_crtc *crtc); > extern int intel_enable_rc6(const struct drm_device *dev); > +extern int intel_resume_force_mode(struct drm_device *dev); > > extern bool i915_semaphore_is_enabled(struct drm_device *dev); > int i915_reg_read_ioctl(struct drm_device *dev, void *data, > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index da1ad9c..a127877 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -9369,6 +9369,31 @@ void intel_modeset_cleanup(struct drm_device *dev) > drm_mode_config_cleanup(dev); > } > > +int intel_resume_force_mode(struct drm_device *dev) > +{ > + struct drm_crtc *crtc; > + struct drm_encoder *encoder; > + struct drm_encoder_helper_funcs *encoder_funcs; > + struct drm_crtc_helper_funcs *crtc_funcs; > + int ret; > + > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { > + > + if (!crtc->enabled) { > + DRM_ERROR("skipping disabled crtc\n"); > + continue; > + } > + > + ret = intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, > + crtc->fb); > + > + if (ret == false) > + DRM_ERROR("failed to set mode on crtc %p\n", crtc); > + } > + > + return 0; > +} intel_modeset_setup_hw_state(dev, true); should do exactly thi