[Intel-gfx] [PATCH v2] tests/testdisplay.c Remove an uncomfortable error output
Signed-off-by: Yi Sun yi@intel.com diff --git a/tests/testdisplay.c b/tests/testdisplay.c index 4430d07..14d7da3 100644 --- a/tests/testdisplay.c +++ b/tests/testdisplay.c @@ -358,9 +358,6 @@ static void paint_image(cairo_t *cr, const char *file) cairo_translate(cr, img_x, img_y); - fprintf(stderr, drew %dx%d image at %d,%d\n, img_w, img_h, - img_x, img_y); - img_w_scale = (double)img_w / (double)img_w_o; img_h_scale = (double)img_h / (double)img_h_o; cairo_scale(cr, img_w_scale, img_h_scale); -- 1.7.6.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] Update the image file pass.png with higher correction level
Signed-off-by: Yi Sun yi@intel.com
diff --git a/tests/pass.png b/tests/pass.png
index
5928d5ca109b7db33640851ceb352f9da742ff7b..36a5236be785ef4b2c1da634560c42d508d211bb
100644
GIT binary patch
literal 569
zcmV-90=G`P)h;3K|Lk000e1NJLTq00Gee00Gef09k{+W9a7bBm0017s
z0017s0dCNBJ^%m#q$gGRCt{2+_8~^Fc5{|^;~eFOKSJ4N7wE`iX2=X8G7YT;5
zZ-j94zf49S*^a~_ETKJu#bU8oEEbE!?zRu9@|A~|aFZc~pEyjp*E7yoEVj3`p-xtt
zFQ4q^yIg(71B=BTVYNb6HsecW=F4XEEapT)#0G^t3xan`%xRJ~jr6#eT|K^x)e
zv#vT!IsbnTjKyM`Y!zQaQ^78l)HzrzwzFNO|=vJOKt^=#rCthXy$^Is)1A8%J#7v
z^^3(~_gY;;^VQSbM74g-GheJpT_cNiN#{OT21vrf68E3KTF!JuvqLNwyID)W0O;w
zsN-tWi^XDlSzklrSfm_m8$z|M3Uo@VzJnEn-MWm@BjtYxJGZe?4G#bP^K@7M${
z*vZbhSvgOq++qyLu~1(%4r_veva6!Z0Ow{EEe0R!@uddku^3a#N~Pa9Aw1qg}=O
zIYSzhMRUYru?N{wp|Uv99p=gN;8BFcyp5Zx@rjy%WlJPbt+3i^XEQ+j}lvE7=H
z#zy?AY}GFoi|uMXqZc|{Z~H+i^X=eTEEw2dgR=@4p?!VzEuuvgp|O|3NL@Exz6Z
zW3kvKTcv!1KbE7X;`N*IsuzUCVjFB*uvjbi^XEG*gf_a_Lf0-E8BSr0NkvXX
Hu0mjfwks0m
literal 376
zcmV-;0f+vHP)h;3K|Lk000e1NJLTq007q007r0dK`lq9a7bBm000XT
z000XT0n*)m`~Uy}DoI2^R9J=Wm(dNwAPht;F#sd6IwLUvl53w0P1CgB_W?SQ){l=E
z9mWy;GvvSnd7=1dMSE)a|H2CWIhyfM87+gHaEJ$d4q*v9e2X8NH73LkVH2~nh8{db
z1oH@vt%vi;17nnJKqlmd8Y?m?=SV};d!JC-@c%hEGI?~i|G%bw#%`yn#2zFYS
z+0-7gg|{O}1!wgq~?C}LtVEqB(o|lRCr`J5x)I`I3=`z)d}Rt{K;Mk`1O)KFXWY
z!nic_THZ#ZgI00c~fPDf?c;Hvckz~B`9IOHyYm1SA#|bqn!+nJepLch5kgVzT3%I
zOA6OV+pcX-Uvy+}b(EP0H?%ow8?F4v@mQk8pPG2rCR_!R9VEK^wFvD^r0@l
W))U}2HxaMNUMnLSTY*+nlZd
--
1.7.6.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/testdisplay.c: Add a option '-g' to save images which intended to paint on screen during each mode setting.
-Original Message- From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, August 06, 2012 4:33 PM To: Sun, Yi Cc: intel-gfx@lists.freedesktop.org; Jin, Gordon Subject: Re: [PATCH] tests/testdisplay.c: Add a option '-g' to save images which intended to paint on screen during each mode setting. On Mon, Aug 6, 2012 at 9:47 AM, Sun, Yi yi@intel.com wrote: We want to use the option to save the images which are intended to be painted on the screen. The images will be save in the folder saveimages, and named like 1_1920x1...@60.png, 2_1920x1080@60 . That would be help for our automatic display testing. If some mode can't be lighten up in automatic display testing, we could check the image saved in the folder to see which mode setting failed manually. I still don't see what you need the images for ... adding more output sounds sane, only lighting up a specific mode makes sense, but I have no idea what you need the actual pngs for. Maybe I'm a bit dense. -Daniel -- Oh, it seems that lighting up a specific mode is better than saving the surface into file. I'll try to rewrite it. Thanks --Sun, Yi Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 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 v2] Update the image file pass.png with higher correction level
On Wed, Aug 08, 2012 at 02:35:20PM +0800, Yi Sun wrote: Signed-off-by: Yi Sun yi@intel.com Both patches applied, thanks. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 0/4] Haswell HDMI/DP audio enable
Dear Wang, first is Wang your first name? Am Mittwoch, den 08.08.2012, 11:03 +0800 schrieb Wang Xingchao: This patch series enable HDMI audio on Haswell platform, not DP audio. The DP enablement will come after the DP patches are upstream. I tested this patch on Sharkbay machine and i could hear clear sound from HDMI port. Could you please add if that was a TV or a receiver? V2 patches fixed one warning and some type errors. V3 patches changes: - change some registers definitions - use macro for IBX/CPT/HSW to get registers - remove some unused variable intended to use in TODO list. v4 patches changes: - remove alsa related hack patch v5 patches changes: - change comments stype - split IBX/CTP registers patch into seperate one • sep*a*rate - remove unused register definition Here're some notes useful for you to test the patches on Sharkbay machine: I please make sure your branch include below three commits in Takashi's sound tree, othersiwe there's no proper Haswell ID and HDMI ID. • White space at the end. • other*wise* For the upstream tree, please refer to sound git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git You can just pull for-linus branch. The all commits above are found in 3.6-rc1. e926f2c850c472f813f9bab486c68a3fe0b03ae4 1c76684d2752b3a24bb7da183cc18e5d126dbcc9 bdbe34dece4942f4d8df9865dba7785bb813366a II No sound from HDMI/DP. we found it's not stable in current stage, sometimes you may not heard sound from HDMI or DP port, but most of the time you can heard clear sound. After some investigation, we suspect the HDA verb didnot really make codec did not change,and we regard the GPU register as the right one. (see III explanation) the easy way is to use intel_audio_dump to compare related registers, and make sure the port is enabled and unmute, otherwise there's no sound. intel_audio_tools has no support on Haswell yet, i wrote patches to make that happen, if you need the patches, please feel free to let me know. Here's part of the snapshot about port enable and mute status from intel_audio_dump: AUD_PORT_EN_HD_CFG Port_B_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_C_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_D_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_B_Amp_Mute_Status1 AUD_PORT_EN_HD_CFG Port_C_Amp_Mute_Status0 AUD_PORT_EN_HD_CFG Port_D_Amp_Mute_Status1 you can see from above message, the Port C is enabled and unmute, that's what we expect. III HDA Codec dependency. When you found there's no sound from HDMI, please use intel_audio_dump to check Port enable/mute status in II and also check related Pipe/Transcoder/DDI port status. Sometimes the pipe and transcoder was disabled in dpms and will not work anymore, that results in the HDMI port no sound. HDA codec's three converters are somehow hardwired to audio Pipes and if you choose the pipe, that means the regarding Codec converter should be enabled too, and only one digital Pin's HDA verbs could work, that depends on whehter your Pin select the converter as input. Here's one example about the whe*th*er Pipe/Transcoder/DDI port(Pipe B, DDI Port C): DDI_BUF_CTL_A 0x0080 DDI Buffer Controler A DDI_BUF_CTL_B 0x DDI Buffer Controler B DDI_BUF_CTL_C 0x8000 DDI Buffer Controler C DDI_BUF_CTL_D 0x DDI Buffer Controler D DDI_BUF_CTL_E 0x8002 DDI Buffer Controler E PIPE_CONF_A 0xc000 PIPE Configuration A PIPE_CONF_B 0xc000 PIPE Configuration B PIPE_CONF_C 0x PIPE Configuration C PIPE_CONF_EDP 0x PIPE Configuration EDP PIPE_DDI_FUNC_CTL_A 0xc4034002 PIPE DDI Function Control A PIPE_DDI_FUNC_CTL_B 0xa0035000 PIPE DDI Function Control B PIPE_DDI_FUNC_CTL_C 0x0003 PIPE DDI Function Control C PIPE_DDI_FUNC_CTL_EDP 0x0003 PIPE DDI Function Control EDP Wang Xingchao (3): The line above should be removed. Wang Xingchao (4): drm/i915: HSW audio registers definition drm/i915: write eld info for HDMI audio drm/i915: Haswell HDMI audio enable drm/i915: use _PIPE macro for IBX/CPT register definition drivers/gpu/drm/i915/i915_reg.h | 71 ++ drivers/gpu/drm/i915/intel_ddi.c |6 ++- drivers/gpu/drm/i915/intel_display.c | 52 - 3 files changed, 118 insertions(+), 11 deletions(-) Thanks, Paul 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
Re: [Intel-gfx] [PATCH v5 0/4] Haswell HDMI/DP audio enable
-Original Message- From: Paul Menzel [mailto:paulepan...@users.sourceforge.net] Sent: Wednesday, August 08, 2012 3:15 PM To: Wang, Xingchao Cc: intel-gfx@lists.freedesktop.org; ti...@suse.de; Fu, Michael; Wu, Fengguang Subject: Re: [Intel-gfx] [PATCH v5 0/4] Haswell HDMI/DP audio enable Dear Wang, first is Wang your first name? Yes. :) Am Mittwoch, den 08.08.2012, 11:03 +0800 schrieb Wang Xingchao: This patch series enable HDMI audio on Haswell platform, not DP audio. The DP enablement will come after the DP patches are upstream. I tested this patch on Sharkbay machine and i could hear clear sound from HDMI port. Could you please add if that was a TV or a receiver? I tested the patch on Haswell Based Machine with a monitor hasing HDMI ports, this is the eld information from the monitor: cat /proc/asound/card0/eld#0.* monitor_present 0 eld_valid 0 monitor_present 1 eld_valid 1 monitor_nameDELL 2408WFP connection_type HDMI eld_version [0x2] CEA-861D or below edid_version[0x3] CEA-861-B, C or D manufacture_id 0xac10 product_id 0xa02c port_id 0x0 support_hdcp0 support_ai 1 audio_sync_delay0 speakers[0x1] FL/FR sad_count 1 sad0_coding_type[0x1] LPCM sad0_channels 2 sad0_rates [0xe0] 32000 44100 48000 sad0_bits [0xe] 16 20 24 monitor_present 0 eld_valid 0 V2 patches fixed one warning and some type errors. V3 patches changes: - change some registers definitions - use macro for IBX/CPT/HSW to get registers - remove some unused variable intended to use in TODO list. v4 patches changes: - remove alsa related hack patch v5 patches changes: - change comments stype - split IBX/CTP registers patch into seperate one • sep*a*rate - remove unused register definition Here're some notes useful for you to test the patches on Sharkbay machine: I please make sure your branch include below three commits in I Takashi's sound tree, othersiwe there's no proper Haswell ID and HDMI ID. • White space at the end. • other*wise* For the upstream tree, please refer to sound git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git You can just pull for-linus branch. The all commits above are found in 3.6-rc1. e926f2c850c472f813f9bab486c68a3fe0b03ae4 1c76684d2752b3a24bb7da183cc18e5d126dbcc9 bdbe34dece4942f4d8df9865dba7785bb813366a II No sound from HDMI/DP. we found it's not stable in current stage, sometimes you may not heard sound from HDMI or DP port, but most of the time you can heard clear sound. After some investigation, we suspect the HDA verb didnot really make codec did not change,and we regard the GPU register as the right one. (see III explanation) the easy way is to use intel_audio_dump to compare related registers, and make sure the port is enabled and unmute, otherwise there's no sound. intel_audio_tools has no support on Haswell yet, i wrote patches to make that happen, if you need the patches, please feel free to let me know. Here's part of the snapshot about port enable and mute status from intel_audio_dump: AUD_PORT_EN_HD_CFG Port_B_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_C_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_D_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_B_Amp_Mute_Status 1 AUD_PORT_EN_HD_CFG Port_C_Amp_Mute_Status 0 AUD_PORT_EN_HD_CFG Port_D_Amp_Mute_Status 1 you can see from above message, the Port C is enabled and unmute, that's what we expect. III HDA Codec dependency. When you found there's no sound from HDMI, III please use intel_audio_dump to check Port enable/mute status in II and also check related Pipe/Transcoder/DDI port status. Sometimes the pipe and transcoder was disabled in dpms and will not work anymore, that results in the HDMI port no sound. HDA codec's three converters are somehow hardwired to audio Pipes and if you choose the pipe, that means the regarding Codec converter should be enabled too, and only one digital Pin's HDA verbs could work, that depends on whehter your Pin select the converter as input. Here's one example about the whe*th*er Pipe/Transcoder/DDI port(Pipe B, DDI Port C): DDI_BUF_CTL_A 0x0080 DDI Buffer Controler A DDI_BUF_CTL_B 0x DDI Buffer Controler B DDI_BUF_CTL_C 0x8000 DDI Buffer Controler C DDI_BUF_CTL_D 0x DDI Buffer Controler D DDI_BUF_CTL_E 0x8002 DDI Buffer Controler E PIPE_CONF_A 0xc000 PIPE Configuration A PIPE_CONF_B 0xc000 PIPE Configuration B PIPE_CONF_C 0x PIPE Configuration C
Re: [Intel-gfx] HD audio not working
At Wed, 08 Aug 2012 00:33:56 +0200, Øyvind Kvålsvoll wrote: Ref. to filed bug https://bugs.freedesktop.org/show_bug.cgi?id=49055: DTS-HD and Dolby TrueHD audio is not working in Intel Sandy Bridge. This must have been well known for quite some time now, and I consider this to be a serious error in the Intel driver. Due to this error it is not possible to play DTS-HD or Dolby-TrueHD on Linux. I have waited patiently several months for a fix, as I was confident that Intel knew about the problem and surely would fix this in the next driver release. I also have the understanding that quite many people are waiting for this fix. Seeing as the bug is filed, and someone has actually looked at it and identified the problem, is there a plan for further progress on this? Could you check whether the test patch Xingchao posted in the last week fixes your problem? https://patchwork.kernel.org/patch/1256981/ If this really cures, we can cook up it in a bit better form and merge to the upstream. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only apply the SNB pipe control w/a to gen6
On Fri, Jul 20, 2012 at 06:02:28PM +0100, Chris Wilson wrote: The requirements for the sync flush to be emitted prior to the render cache flush is only true for SandyBridge. On IvyBridge and friends we can just emit the flushes with an inline CS stall. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Since I've seen Ken ditch these w/a for ivb+ in mesa, I've figured that this is ok. Some bspec reading seems to agree. Merged to dinq, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [pull] drm-intel-fixes
On Tue, Aug 07, 2012 at 02:08:18PM +0200, Daniel Vetter wrote: Hi Dave, - Regression fixer for an OOPS at boot when i915.ko is built-in and CONFIG_PM=n, introduce in 3.5 (patch from Hunt Xu) - Regression fixer for occlusion query failures, the required w/a wasn't applied in all cases (thanks to Eric for tracking this on down). - dmar vs. dma_buf imprt fix (Dave Airlie) - 2 patches to fight down forcewake issues on snb. This is the stuff I've talked about 2 weeks ago already, it's a minefield. Investigation still going on, but afaict this is the best we have for now. - a few minor things to keep covertycompiler happy (Alan, Davendra, Stéphane) - tons of hsw pci ids - this one is a bit late because internal approval sometimes takes a while, but ppl in charge finally agreed that world+dog already knows about ult and crw haswell variants ;-) As discussed on irc, one more fix: - fix ring init sequence (only reported by QA afaict). Yours, Daniel The following changes since commit e8aeaee7b012f1cdb382765d17307445385aa87c: drm/i915: unbreak lastclose for failed driver init (2012-07-25 10:40:00 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 0d8957c8a90bbb5d34fab9a304459448a5131e06: drm/i915: correctly order the ring init sequence (2012-08-08 10:23:35 +0200) Alan Cox (3): vlv: it might be wise if we initialised the flag value... i915: fix error path leak in intel_sdvo_write_cmd i915: Remove silly test Chris Wilson (1): drm/i915: Workaround hang with BSD and forcewake on SandyBridge Daniel Vetter (2): drm/i915: fix forcewake related hangs on snb drm/i915: correctly order the ring init sequence Dave Airlie (1): i915: don't map imported dma-bufs for dmar. Devendra Naga (1): drm/i915: remove unused variable Eric Anholt (1): drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround. Hunt Xu (1): drm/i915: make rc6 in sysfs functions conditional Paulo Zanoni (1): drm/i915: add more Haswell PCI IDs Stéphane Marchesin (1): drm/i915: Make intel_panel_get_backlight static. drivers/char/agp/intel-agp.h | 39 +++--- drivers/char/agp/intel-gtt.c | 60 +++- drivers/gpu/drm/i915/i915_drv.c| 31 +- drivers/gpu/drm/i915/i915_gem_context.c|1 - drivers/gpu/drm/i915/i915_gem_execbuffer.c | 20 +- drivers/gpu/drm/i915/i915_gem_gtt.c|3 +- drivers/gpu/drm/i915/i915_sysfs.c | 12 ++ drivers/gpu/drm/i915/intel_display.c |1 + drivers/gpu/drm/i915/intel_drv.h | 20 +- drivers/gpu/drm/i915/intel_i2c.c |3 -- drivers/gpu/drm/i915/intel_panel.c |2 +- drivers/gpu/drm/i915/intel_pm.c|6 ++- drivers/gpu/drm/i915/intel_ringbuffer.c|7 +++- drivers/gpu/drm/i915/intel_sdvo.c |5 ++- 14 files changed, 172 insertions(+), 38 deletions(-) -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add I915_GEM_PARAM_HAS_SEMAPHORES
Userspace tries to estimate the cost of ring switching based on whether
the GPU and GEM supports semaphores. (If we have multiple rings and no
semaphores, userspace assumes that the cost of switching rings between
batches is exorbitant and will endeavour to keep the next batch on the
active ring - as a coarse approximation to tracking both destination and
source surfaces.) Currently userspace has to guess whether semaphores
exist based on the chipset generation and the module parameter,
i915.semaphores. This is a crude and inaccurate guess as the defaults
internally depend upon other chipset features being enabled or disabled,
nor does it extend well into the future. By exporting a HAS_SEMAPHORES
parameter, we can easily query the driver and obtain an accurate answer.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
include/drm/i915_drm.h |1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9cf7dfe..64fd7be 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1009,6 +1009,9 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_HAS_WAIT_TIMEOUT:
value = 1;
break;
+ case I915_PARAM_HAS_SEMAPHORES:
+ value = i915_semaphore_is_enabled(dev);
+ break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
param-param);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 8cc7083..2f0d472 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -305,6 +305,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_LLC 17
#define I915_PARAM_HAS_ALIASING_PPGTT 18
#define I915_PARAM_HAS_WAIT_TIMEOUT 19
+#define I915_PARAM_HAS_SEMAPHORES 20
typedef struct drm_i915_getparam {
int param;
--
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] drm/i915: Add I915_GEM_PARAM_HAS_SEMAPHORES
On Wed, Aug 08, 2012 at 10:23:22AM +0100, Chris Wilson wrote: Userspace tries to estimate the cost of ring switching based on whether the GPU and GEM supports semaphores. (If we have multiple rings and no semaphores, userspace assumes that the cost of switching rings between batches is exorbitant and will endeavour to keep the next batch on the active ring - as a coarse approximation to tracking both destination and source surfaces.) Currently userspace has to guess whether semaphores exist based on the chipset generation and the module parameter, i915.semaphores. This is a crude and inaccurate guess as the defaults internally depend upon other chipset features being enabled or disabled, nor does it extend well into the future. By exporting a HAS_SEMAPHORES parameter, we can easily query the driver and obtain an accurate answer. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Sounds like something useful, applied for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: dump the device info
Handy for lazy people like me, or when people forget to add the output
of lspci -nn.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index d57ea16..dfa2ab2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1428,6 +1428,42 @@ static void i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
kfree(ap);
}
+static void i915_dump_device_info(struct drm_i915_private *dev_priv)
+{
+ const struct intel_device_info *info = dev_priv-info;
+
+#define DEV_FLAG_STR(name) info-name ? #name , :
+ DRM_DEBUG_DRIVER(i915 device info: gen=%i, pciid=0x%04x flags=
+%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s,
+info-gen,
+dev_priv-dev-pdev-device,
+DEV_FLAG_STR(is_mobile),
+DEV_FLAG_STR(is_i85x),
+DEV_FLAG_STR(is_i915g),
+DEV_FLAG_STR(is_i945gm),
+DEV_FLAG_STR(is_g33),
+DEV_FLAG_STR(need_gfx_hws),
+DEV_FLAG_STR(is_g4x),
+DEV_FLAG_STR(is_pineview),
+DEV_FLAG_STR(is_broadwater),
+DEV_FLAG_STR(is_crestline),
+DEV_FLAG_STR(is_ivybridge),
+DEV_FLAG_STR(is_valleyview),
+DEV_FLAG_STR(is_haswell),
+DEV_FLAG_STR(has_force_wake),
+DEV_FLAG_STR(has_fbc),
+DEV_FLAG_STR(has_pipe_cxsr),
+DEV_FLAG_STR(has_hotplug),
+DEV_FLAG_STR(cursor_needs_physical),
+DEV_FLAG_STR(has_overlay),
+DEV_FLAG_STR(overlay_needs_physical),
+DEV_FLAG_STR(supports_tv),
+DEV_FLAG_STR(has_bsd_ring),
+DEV_FLAG_STR(has_blt_ring),
+DEV_FLAG_STR(has_llc));
+#undef DEV_FLAG_STR
+}
+
/**
* i915_driver_load - setup chip and create an initial config
* @dev: DRM device
@@ -1452,7 +1488,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
if (info-gen = 6 !drm_core_check_feature(dev, DRIVER_MODESET))
return -ENODEV;
-
/* i915 has 4 more counters */
dev-counters += 4;
dev-types[6] = _DRM_STAT_IRQ;
@@ -1468,6 +1503,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
dev_priv-dev = dev;
dev_priv-info = info;
+ i915_dump_device_info(dev_priv);
+
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto free_priv;
--
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/8] drm/i915: set the DDI sync polarity bits
From: Paulo Zanoni paulo.r.zan...@intel.com During my tests, everything worked even if the wrong polarity was set. Still, we should try to set the correct values. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_ddi.c | 6 ++ 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 97f00fb..896b279 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4312,6 +4312,8 @@ #define PIPE_DDI_BPC_10 (120) #define PIPE_DDI_BPC_6(220) #define PIPE_DDI_BPC_12 (320) +#define PIPE_DDI_PVSYNC (117) +#define PIPE_DDI_PHSYNC (116) #define PIPE_DDI_BFI_ENABLE (14) #define PIPE_DDI_PORT_WIDTH_X1(01) #define PIPE_DDI_PORT_WIDTH_X2(11) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 0d7acd7..1fbd67c 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -727,6 +727,7 @@ void intel_ddi_mode_set(struct drm_encoder *encoder, temp = ~PIPE_DDI_PORT_MASK; temp = ~PIPE_DDI_BPC_12; temp = ~PIPE_DDI_MODE_SELECT_MASK; + temp = ~(PIPE_DDI_PVSYNC | PIPE_DDI_PHSYNC); temp |= PIPE_DDI_SELECT_PORT(port) | ((intel_crtc-bpp 24) ? PIPE_DDI_BPC_12 : @@ -738,6 +739,11 @@ void intel_ddi_mode_set(struct drm_encoder *encoder, else temp |= PIPE_DDI_MODE_SELECT_DVI; + if (adjusted_mode-flags DRM_MODE_FLAG_PVSYNC) + temp |= PIPE_DDI_PVSYNC; + if (adjusted_mode-flags DRM_MODE_FLAG_PHSYNC) + temp |= PIPE_DDI_PHSYNC; + I915_WRITE(DDI_FUNC_CTL(pipe), temp); intel_hdmi-set_infoframes(encoder, adjusted_mode); -- 1.7.11.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915: correctly set the DDI_FUNC_CTL bpc field
From: Paulo Zanoni paulo.r.zan...@intel.com
Correctly erase the values previously set and also check for 6pbc and
10bpc.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 26 --
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 896b279..f3fafb8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4308,6 +4308,7 @@
#define PIPE_DDI_MODE_SELECT_DP_SST (224)
#define PIPE_DDI_MODE_SELECT_DP_MST (324)
#define PIPE_DDI_MODE_SELECT_FDI (424)
+#define PIPE_DDI_BPC_MASK (720)
#define PIPE_DDI_BPC_8(020)
#define PIPE_DDI_BPC_10 (120)
#define PIPE_DDI_BPC_6(220)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1fbd67c..8b38359 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -725,14 +725,28 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
/* Enable PIPE_DDI_FUNC_CTL for the pipe to work in HDMI mode */
temp = I915_READ(DDI_FUNC_CTL(pipe));
temp = ~PIPE_DDI_PORT_MASK;
- temp = ~PIPE_DDI_BPC_12;
+ temp = ~PIPE_DDI_BPC_MASK;
temp = ~PIPE_DDI_MODE_SELECT_MASK;
temp = ~(PIPE_DDI_PVSYNC | PIPE_DDI_PHSYNC);
- temp |= PIPE_DDI_SELECT_PORT(port) |
- ((intel_crtc-bpp 24) ?
- PIPE_DDI_BPC_12 :
- PIPE_DDI_BPC_8) |
- PIPE_DDI_FUNC_ENABLE;
+ temp |= PIPE_DDI_FUNC_ENABLE | PIPE_DDI_SELECT_PORT(port);
+
+ switch (intel_crtc-bpp) {
+ case 18:
+ temp |= PIPE_DDI_BPC_6;
+ break;
+ case 24:
+ temp |= PIPE_DDI_BPC_8;
+ break;
+ case 30:
+ temp |= PIPE_DDI_BPC_10;
+ break;
+ case 36:
+ temp |= PIPE_DDI_BPC_12;
+ break;
+ default:
+ WARN(1, %d bpp unsupported by pipe DDI function\n,
+intel_crtc-bpp);
+ }
if (intel_hdmi-has_hdmi_sink)
temp |= PIPE_DDI_MODE_SELECT_HDMI;
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915: completely reset the value of DDI_FUNC_CTL
From: Paulo Zanoni paulo.r.zan...@intel.com
Don't rely on previous values already set on the register. Everything
we're not explicitly setting should be zero for now.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8b38359..ff03a3a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -723,12 +723,7 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
}
/* Enable PIPE_DDI_FUNC_CTL for the pipe to work in HDMI mode */
- temp = I915_READ(DDI_FUNC_CTL(pipe));
- temp = ~PIPE_DDI_PORT_MASK;
- temp = ~PIPE_DDI_BPC_MASK;
- temp = ~PIPE_DDI_MODE_SELECT_MASK;
- temp = ~(PIPE_DDI_PVSYNC | PIPE_DDI_PHSYNC);
- temp |= PIPE_DDI_FUNC_ENABLE | PIPE_DDI_SELECT_PORT(port);
+ temp = PIPE_DDI_FUNC_ENABLE | PIPE_DDI_SELECT_PORT(port);
switch (intel_crtc-bpp) {
case 18:
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915: add parentheses around PIXCLK_GATE definitions
From: Paulo Zanoni paulo.r.zan...@intel.com By looking at the current way we're using these definitions I don't think this commit will fix any bug, but programmers from the future are evil and will certainly find ways to combine macro expansion with operator precedence to introduce bugs that are hard to find. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index af41d03..321ae72 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4395,8 +4395,8 @@ /* LPT PIXCLK_GATE */ #define PIXCLK_GATE0xC6020 -#define PIXCLK_GATE_UNGATE10 -#define PIXCLK_GATE_GATE 00 +#define PIXCLK_GATE_UNGATE(10) +#define PIXCLK_GATE_GATE (00) /* SPLL */ #define SPLL_CTL 0x46020 -- 1.7.11.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915: try harder to find WR PLL clock settings
From: Paulo Zanoni paulo.r.zan...@intel.com
If we don't find the exact refresh rate, go with the next one. This
makes some modes work for me. They won't have the best settings, but
will at least have something. Just returning from this function when
we don't find the perfect settings does not help us at all.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ff03a3a..db242cf 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -267,7 +267,8 @@ struct wrpll_tmds_clock {
u16 r2; /* Reference divider */
};
-/* Table of matching values for WRPLL clocks programming for each frequency */
+/* Table of matching values for WRPLL clocks programming for each frequency.
+ * The code assumes this table is sorted. */
static const struct wrpll_tmds_clock wrpll_tmds_clock_table[] = {
{19750, 38, 25, 18},
{2, 48, 32, 18},
@@ -658,7 +659,7 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
int port = intel_hdmi-ddi_port;
int pipe = intel_crtc-pipe;
- int p, n2, r2, valid=0;
+ int p, n2, r2;
u32 temp, i;
/* On Haswell, we need to enable the clocks and prepare DDI function to
@@ -666,26 +667,20 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
*/
DRM_DEBUG_KMS(Preparing HDMI DDI mode for Haswell on port %c, pipe
%c\n, port_name(port), pipe_name(pipe));
- for (i=0; i ARRAY_SIZE(wrpll_tmds_clock_table); i++) {
- if (crtc-mode.clock == wrpll_tmds_clock_table[i].clock) {
- p = wrpll_tmds_clock_table[i].p;
- n2 = wrpll_tmds_clock_table[i].n2;
- r2 = wrpll_tmds_clock_table[i].r2;
+ for (i = 0; i ARRAY_SIZE(wrpll_tmds_clock_table); i++)
+ if (crtc-mode.clock = wrpll_tmds_clock_table[i].clock)
+ break;
- DRM_DEBUG_KMS(WR PLL clock: found settings for %dKHz
refresh rate: p=%d, n2=%d, r2=%d\n,
- crtc-mode.clock,
- p, n2, r2);
+ if (i == ARRAY_SIZE(wrpll_tmds_clock_table))
+ i--;
- valid = 1;
- break;
- }
- }
+ if (wrpll_tmds_clock_table[i].clock != crtc-mode.clock)
+ DRM_INFO(WR PLL: using settings for %dKHz on %dKHz mode\n,
+wrpll_tmds_clock_table[i].clock, crtc-mode.clock);
- if (!valid) {
- DRM_ERROR(Unable to find WR PLL clock settings for %dKHz
refresh rate\n,
- crtc-mode.clock);
- return;
- }
+ p = wrpll_tmds_clock_table[i].p;
+ n2 = wrpll_tmds_clock_table[i].n2;
+ r2 = wrpll_tmds_clock_table[i].r2;
/* Enable LCPLL if disabled */
temp = I915_READ(LCPLL_CTL);
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915: try to use WR PLL 2
From: Paulo Zanoni paulo.r.zan...@intel.com
The current situation is: we use WR PLL1 for everything, so if we have
2 HDMI outputs they will share the same PLL. As a consequence, when
you set a mode on HDMI2, HDMI1 will change its refresh rate. If the
modes are too different, setting a mode on HDMI2 may make the HDMI1
screen blank (with one of those error messages from your monitor).
So now we at least try to use WR PLL 2. This will improve the case
where we have 2 HDMI outputs and don't keep crazily changing ports,
but it's still not the perfect solution:
- We need to select PORT_CLK_SEL_NONE when we stop using a port, so we
will be able to reuse its PLL.
- We need to move the whole DDI PLL selection code to a place where we
can properly fail and return an error code, possibly undoing the
mode set. Right now, instead of failing we're hijacking WR PLL 2.
This patch is not the perfect solution, but it's at least better than
the current one. Future patches will fix the remaining problems.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 41 ++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index db242cf..80b9902 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -659,7 +659,10 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
int port = intel_hdmi-ddi_port;
int pipe = intel_crtc-pipe;
- int p, n2, r2;
+ uint32_t pll_reg[] = {WRPLL_CTL1, WRPLL_CTL2};
+ uint32_t pll_sel[] = {PORT_CLK_SEL_WRPLL1, PORT_CLK_SEL_WRPLL2};
+ int p, n2, r2, pll;
+ bool used;
u32 temp, i;
/* On Haswell, we need to enable the clocks and prepare DDI function to
@@ -667,6 +670,35 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
*/
DRM_DEBUG_KMS(Preparing HDMI DDI mode for Haswell on port %c, pipe
%c\n, port_name(port), pipe_name(pipe));
+ for (pll = 0; pll 2; pll++) {
+ used = false;
+ for (i = PORT_A; i = PORT_E; i++) {
+ if (i == port)
+ continue;
+
+ if (I915_READ(PORT_CLK_SEL(i)) == pll_sel[pll]) {
+ used = true;
+ break;
+ }
+ }
+ if (!used)
+ break;
+ }
+ if (pll == 2) {
+ /* FIXME: just claiming failure and returning from this function
+* won't help us at all. So instead we hijack WR PLL 2 and hope
+* we don't break the other output (if the refresh rates are
+* similar we may survive). We should definitely move the PLL
+* code to somewhere else, where we may be able to properly
+* fail. Also, we should write code to select PORT_CLK_SEL_NONE
+* when we stop using the port, so other ports will be able to
+* reuse the WR PLL. */
+ DRM_ERROR(No WR PLL available\n);
+ pll = 1;
+ }
+
+ DRM_DEBUG_KMS(Using WR PLL %d\n, pll+1);
+
for (i = 0; i ARRAY_SIZE(wrpll_tmds_clock_table); i++)
if (crtc-mode.clock = wrpll_tmds_clock_table[i].clock)
break;
@@ -688,9 +720,7 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
I915_WRITE(LCPLL_CTL,
temp ~LCPLL_PLL_DISABLE);
- /* Configure WR PLL 1, program the correct divider values for
-* the desired frequency and wait for warmup */
- I915_WRITE(WRPLL_CTL1,
+ I915_WRITE(pll_reg[pll],
WRPLL_PLL_ENABLE |
WRPLL_PLL_SELECT_LCPLL_2700 |
WRPLL_DIVIDER_REFERENCE(r2) |
@@ -702,8 +732,7 @@ void intel_ddi_mode_set(struct drm_encoder *encoder,
/* Use WRPLL1 clock to drive the output to the port, and tell the pipe
to use
* this port for connection.
*/
- I915_WRITE(PORT_CLK_SEL(port),
- PORT_CLK_SEL_WRPLL1);
+ I915_WRITE(PORT_CLK_SEL(port), pll_sel[pll]);
I915_WRITE(PIPE_CLK_SEL(pipe),
PIPE_CLK_SEL_PORT(port));
--
1.7.11.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: dump the device info
Handy for lazy people like me, or when people forget to add the output
of lspci -nn.
v2: Chris Wilson noticed that we have this duplicated already in the
i915_capabilites debugfs file. But there \n as separator looks better,
which would be a bit verbose in dmesg. Abuse the preprocessor to
extract this all.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +--
drivers/gpu/drm/i915/i915_dma.c | 18 +-
drivers/gpu/drm/i915/i915_drv.h | 26 ++
3 files changed, 48 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1312b79..2e07cdd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -61,28 +61,11 @@ static int i915_capabilities(struct seq_file *m, void *data)
seq_printf(m, gen: %d\n, info-gen);
seq_printf(m, pch: %d\n, INTEL_PCH_TYPE(dev));
-#define B(x) seq_printf(m, #x : %s\n, yesno(info-x))
- B(is_mobile);
- B(is_i85x);
- B(is_i915g);
- B(is_i945gm);
- B(is_g33);
- B(need_gfx_hws);
- B(is_g4x);
- B(is_pineview);
- B(is_broadwater);
- B(is_crestline);
- B(has_fbc);
- B(has_pipe_cxsr);
- B(has_hotplug);
- B(cursor_needs_physical);
- B(has_overlay);
- B(overlay_needs_physical);
- B(supports_tv);
- B(has_bsd_ring);
- B(has_blt_ring);
- B(has_llc);
-#undef B
+#define DEV_INFO_FLAG(x) seq_printf(m, #x : %s\n, yesno(info-x))
+#define DEV_INFO_SEP ;
+ DEV_INFO_FLAGS;
+#undef DEV_INFO_FLAG
+#undef DEV_INFO_SEP
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index d57ea16..a7a213c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1428,6 +1428,21 @@ static void i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
kfree(ap);
}
+static void i915_dump_device_info(struct drm_i915_private *dev_priv)
+{
+ const struct intel_device_info *info = dev_priv-info;
+
+#define DEV_INFO_FLAG(name) info-name ? #name , :
+#define DEV_INFO_SEP ,
+ DRM_DEBUG_DRIVER(i915 device info: gen=%i, pciid=0x%04x flags=
+%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s,
+info-gen,
+dev_priv-dev-pdev-device,
+DEV_INFO_FLAGS);
+#undef DEV_INFO_FLAG
+#undef DEV_INFO_SEP
+}
+
/**
* i915_driver_load - setup chip and create an initial config
* @dev: DRM device
@@ -1452,7 +1467,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
if (info-gen = 6 !drm_core_check_feature(dev, DRIVER_MODESET))
return -ENODEV;
-
/* i915 has 4 more counters */
dev-counters += 4;
dev-types[6] = _DRM_STAT_IRQ;
@@ -1468,6 +1482,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
dev_priv-dev = dev;
dev_priv-info = info;
+ i915_dump_device_info(dev_priv);
+
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto free_priv;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0b2eb17..26a2cf6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -279,6 +279,32 @@ struct drm_i915_gt_funcs {
void (*force_wake_put)(struct drm_i915_private *dev_priv);
};
+#define DEV_INFO_FLAGS \
+ DEV_INFO_FLAG(is_mobile) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_i85x) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_i915g) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_i945gm) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_g33) DEV_INFO_SEP \
+ DEV_INFO_FLAG(need_gfx_hws) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_g4x) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_pineview) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_broadwater) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_crestline) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_ivybridge) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_valleyview) DEV_INFO_SEP \
+ DEV_INFO_FLAG(is_haswell) DEV_INFO_SEP \
+ DEV_INFO_FLAG(has_force_wake) DEV_INFO_SEP \
+ DEV_INFO_FLAG(has_fbc) DEV_INFO_SEP \
+ DEV_INFO_FLAG(has_pipe_cxsr) DEV_INFO_SEP \
+ DEV_INFO_FLAG(has_hotplug) DEV_INFO_SEP \
+ DEV_INFO_FLAG(cursor_needs_physical) DEV_INFO_SEP \
+ DEV_INFO_FLAG(has_overlay) DEV_INFO_SEP \
+ DEV_INFO_FLAG(overlay_needs_physical) DEV_INFO_SEP \
+ DEV_INFO_FLAG(supports_tv) DEV_INFO_SEP \
+ DEV_INFO_FLAG(has_bsd_ring) DEV_INFO_SEP \
+ DEV_INFO_FLAG(has_blt_ring) DEV_INFO_SEP \
+ DEV_INFO_FLAG(has_llc)
+
struct intel_device_info {
u8 gen;
u8 is_mobile:1;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH] drm/i915: fixup desired rps frequency computation
On Wed, 8 Aug 2012 17:42:52 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: In commit commit 20b46e59dd102665ce7168baa215e5b1ee66b69b Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Thu Jul 26 11:16:14 2012 +0200 drm/i915: Only set the down rps limit when at the loweset frequency The computation for the new desired frequency was extracted, but since the desired frequency was passed-by value, the adjustments didn't propgate back. Fix this. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Ouch, how embarrassing - for the reviewer. :( Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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] drm/i915: fixup desired rps frequency computation
On Wed, Aug 08, 2012 at 09:12:21PM +0100, Chris Wilson wrote: On Wed, 8 Aug 2012 17:42:52 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: In commit commit 20b46e59dd102665ce7168baa215e5b1ee66b69b Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Thu Jul 26 11:16:14 2012 +0200 drm/i915: Only set the down rps limit when at the loweset frequency The computation for the new desired frequency was extracted, but since the desired frequency was passed-by value, the adjustments didn't propgate back. Fix this. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Ouch, how embarrassing - for the reviewer. :( Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] rps locking fixes v2
Hi all, Essentially just rebase, with Ben's review comments taking into account and one WARN_ON(mutex_is_locked) moved around a bit. Reviewtesting highly welcome. Cheers, Daniel Daniel Vetter (8): drm/i915: properly guard ilk ips state drm/i915: fixup up debugfs rps state handling drm/i915: move all rps state into dev_priv-rps drm/i915: kill dev_priv-mchdev_lock drm/i915: DE_PCU_EVENT irq is ilk-only drm/i915: fix up ilk drps/ips locking drm/ips: move drps/ips/ilk related variables into dev_priv-ips drm/i915: enable rc6 on ilk again drivers/gpu/drm/i915/i915_debugfs.c | 38 +- drivers/gpu/drm/i915/i915_dma.c |2 +- drivers/gpu/drm/i915/i915_drv.h | 55 +--- drivers/gpu/drm/i915/i915_irq.c | 72 +- drivers/gpu/drm/i915/intel_display.c |2 +- drivers/gpu/drm/i915/intel_pm.c | 248 ++ 6 files changed, 245 insertions(+), 172 deletions(-) -- 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: properly guard ilk ips state
The update_gfx_val function called from mark_busy wasn't taking the
mchdev_lock, as it should have. Also sprinkle a few spinlock asserts
over the code to document things better.
Things are still rather confusing, especially since a few variables
in dev_priv are used by both the gen6+ rps code and the ilk ips code.
But protected by totally different locks. Follow-on patches will clean
that up.
v2: Don't add a deadlock ... hence split up update_gfx_val into a
wrapper that grabs the lock and an internal __ variant for callsites
within intel_pm.c that already have taken the lock.
v3: Mark the internal helper as static, noticed by Ben Widawsky.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 50 ++-
1 file changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5050bb8..ad90579 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2710,6 +2710,21 @@ static const struct cparams {
{ 0, 800, 231, 23784 },
};
+/**
+ * Lock protecting IPS related data structures
+ * - i915_mch_dev
+ * - dev_priv-max_delay
+ * - dev_priv-min_delay
+ * - dev_priv-fmax
+ * - dev_priv-gpu_busy
+ * - dev_priv-gfx_power
+ */
+static DEFINE_SPINLOCK(mchdev_lock);
+
+/* Global for IPS driver to get at the current i915 device. Protected by
+ * mchdev_lock. */
+static struct drm_i915_private *i915_mch_dev;
+
unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
{
u64 total_count, diff, ret;
@@ -2717,6 +2732,8 @@ unsigned long i915_chipset_val(struct drm_i915_private
*dev_priv)
unsigned long now = jiffies_to_msecs(jiffies), diff1;
int i;
+ assert_spin_locked(mchdev_lock);
+
diff1 = now - dev_priv-last_time1;
/* Prevent division-by-zero if we are asking too fast.
@@ -2918,15 +2935,14 @@ static u16 pvid_to_extvid(struct drm_i915_private
*dev_priv, u8 pxvid)
return v_table[pxvid].vd;
}
-void i915_update_gfx_val(struct drm_i915_private *dev_priv)
+static void __i915_update_gfx_val(struct drm_i915_private *dev_priv)
{
struct timespec now, diff1;
u64 diff;
unsigned long diffms;
u32 count;
- if (dev_priv-info-gen != 5)
- return;
+ assert_spin_locked(mchdev_lock);
getrawmonotonic(now);
diff1 = timespec_sub(now, dev_priv-last_time2);
@@ -2954,11 +2970,25 @@ void i915_update_gfx_val(struct drm_i915_private
*dev_priv)
dev_priv-gfx_power = diff;
}
+void i915_update_gfx_val(struct drm_i915_private *dev_priv)
+{
+ if (dev_priv-info-gen != 5)
+ return;
+
+ spin_lock(mchdev_lock);
+
+ __i915_update_gfx_val(dev_priv);
+
+ spin_unlock(mchdev_lock);
+}
+
unsigned long i915_gfx_val(struct drm_i915_private *dev_priv)
{
unsigned long t, corr, state1, corr2, state2;
u32 pxvid, ext_v;
+ assert_spin_locked(mchdev_lock);
+
pxvid = I915_READ(PXVFREQ_BASE + (dev_priv-cur_delay * 4));
pxvid = (pxvid 24) 0x7f;
ext_v = pvid_to_extvid(dev_priv, pxvid);
@@ -2984,23 +3014,11 @@ unsigned long i915_gfx_val(struct drm_i915_private
*dev_priv)
state2 = (corr2 * state1) / 1;
state2 /= 100; /* convert to mW */
- i915_update_gfx_val(dev_priv);
+ __i915_update_gfx_val(dev_priv);
return dev_priv-gfx_power + state2;
}
-/* Global for IPS driver to get at the current i915 device */
-static struct drm_i915_private *i915_mch_dev;
-/*
- * Lock protecting IPS related data structures
- * - i915_mch_dev
- * - dev_priv-max_delay
- * - dev_priv-min_delay
- * - dev_priv-fmax
- * - dev_priv-gpu_busy
- */
-static DEFINE_SPINLOCK(mchdev_lock);
-
/**
* i915_read_mch_val - return value for IPS use
*
--
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/8] drm/i915: fixup up debugfs rps state handling
- Take the dev-struct_mutex around access the corresponding state
(and adjusting the rps hw state).
- Add an assert to gen6_set_rps to ensure we don't forget about this
in the future.
- Don't set up the min/max_freq files if it doesn't apply to the hw.
And do the same for the gen6+ cache sharing file while at it.
v2: Move the gen6+ checks into the read/write callbacks. Thanks to the
awesome drm midlayer we can't check that when registering the debugfs
files, because the driver is not yet fully set up, specifically the
-load callback hasn't run yet.
Oh how I despise this disaster ...
v3: Also add a WARN_ON(mutex_is_locked) in set_rps to check the
locking.
Reviewed-by: Ben Widawsky b...@bwidawsk.net (for v2)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +++
drivers/gpu/drm/i915/intel_pm.c |2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1312b79..2499610 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1710,8 +1710,13 @@ i915_max_freq_read(struct file *filp,
char buf[80];
int len;
+ if (!(IS_GEN6(dev) || IS_GEN7(dev)))
+ return -ENODEV;
+
+ mutex_lock(dev-struct_mutex);
len = snprintf(buf, sizeof(buf),
max freq: %d\n, dev_priv-max_delay * 50);
+ mutex_unlock(dev-struct_mutex);
if (len sizeof(buf))
len = sizeof(buf);
@@ -1730,6 +1735,9 @@ i915_max_freq_write(struct file *filp,
char buf[20];
int val = 1;
+ if (!(IS_GEN6(dev) || IS_GEN7(dev)))
+ return -ENODEV;
+
if (cnt 0) {
if (cnt sizeof(buf) - 1)
return -EINVAL;
@@ -1743,12 +1751,14 @@ i915_max_freq_write(struct file *filp,
DRM_DEBUG_DRIVER(Manually setting max freq to %d\n, val);
+ mutex_lock(dev-struct_mutex);
/*
* Turbo will still be enabled, but won't go above the set value.
*/
dev_priv-max_delay = val / 50;
gen6_set_rps(dev, val / 50);
+ mutex_unlock(dev-struct_mutex);
return cnt;
}
@@ -1770,8 +1780,13 @@ i915_min_freq_read(struct file *filp, char __user *ubuf,
size_t max,
char buf[80];
int len;
+ if (!(IS_GEN6(dev) || IS_GEN7(dev)))
+ return -ENODEV;
+
+ mutex_lock(dev-struct_mutex);
len = snprintf(buf, sizeof(buf),
min freq: %d\n, dev_priv-min_delay * 50);
+ mutex_unlock(dev-struct_mutex);
if (len sizeof(buf))
len = sizeof(buf);
@@ -1788,6 +1803,9 @@ i915_min_freq_write(struct file *filp, const char __user
*ubuf, size_t cnt,
char buf[20];
int val = 1;
+ if (!(IS_GEN6(dev) || IS_GEN7(dev)))
+ return -ENODEV;
+
if (cnt 0) {
if (cnt sizeof(buf) - 1)
return -EINVAL;
@@ -1801,12 +1819,14 @@ i915_min_freq_write(struct file *filp, const char
__user *ubuf, size_t cnt,
DRM_DEBUG_DRIVER(Manually setting min freq to %d\n, val);
+ mutex_lock(dev-struct_mutex);
/*
* Turbo will still be enabled, but won't go below the set value.
*/
dev_priv-min_delay = val / 50;
gen6_set_rps(dev, val / 50);
+ mutex_unlock(dev-struct_mutex);
return cnt;
}
@@ -1831,6 +1851,9 @@ i915_cache_sharing_read(struct file *filp,
u32 snpcr;
int len;
+ if (!(IS_GEN6(dev) || IS_GEN7(dev)))
+ return -ENODEV;
+
mutex_lock(dev_priv-dev-struct_mutex);
snpcr = I915_READ(GEN6_MBCUNIT_SNPCR);
mutex_unlock(dev_priv-dev-struct_mutex);
@@ -1857,6 +1880,9 @@ i915_cache_sharing_write(struct file *filp,
u32 snpcr;
int val = 1;
+ if (!(IS_GEN6(dev) || IS_GEN7(dev)))
+ return -ENODEV;
+
if (cnt 0) {
if (cnt sizeof(buf) - 1)
return -EINVAL;
@@ -2061,6 +2087,7 @@ int i915_debugfs_init(struct drm_minor *minor)
i915_cache_sharing_fops);
if (ret)
return ret;
+
ret = i915_debugfs_create(minor-debugfs_root, minor,
i915_ring_stop,
i915_ring_stop_fops);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ad90579..dece479 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2300,6 +2300,8 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 limits = gen6_rps_limits(dev_priv, val);
+ WARN_ON(!mutex_is_locked(dev-struct_mutex));
+
if (val == dev_priv-cur_delay)
return;
--
1.7.10.4
[Intel-gfx] [PATCH 3/8] drm/i915: move all rps state into dev_priv-rps
This way it's easier so see what belongs together, and what is used
by the ilk ips code. Also add some comments that explain the locking.
Note that (cur|min|max)_delay need to be duplicated, because
they're also used by the ips code.
v2: Missed one place that the dev_priv-ips change caught ...
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 11
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_drv.h | 18 ++---
drivers/gpu/drm/i915/i915_irq.c | 32 +++
drivers/gpu/drm/i915/intel_display.c |2 +-
drivers/gpu/drm/i915/intel_pm.c | 47 +-
6 files changed, 63 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2499610..05087fa 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1287,7 +1287,8 @@ static int i915_ring_freq_table(struct seq_file *m, void
*unused)
seq_printf(m, GPU freq (MHz)\tEffective CPU freq (MHz)\n);
- for (gpu_freq = dev_priv-min_delay; gpu_freq = dev_priv-max_delay;
+ for (gpu_freq = dev_priv-rps.min_delay;
+gpu_freq = dev_priv-rps.max_delay;
gpu_freq++) {
I915_WRITE(GEN6_PCODE_DATA, gpu_freq);
I915_WRITE(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY |
@@ -1715,7 +1716,7 @@ i915_max_freq_read(struct file *filp,
mutex_lock(dev-struct_mutex);
len = snprintf(buf, sizeof(buf),
- max freq: %d\n, dev_priv-max_delay * 50);
+ max freq: %d\n, dev_priv-rps.max_delay * 50);
mutex_unlock(dev-struct_mutex);
if (len sizeof(buf))
@@ -1755,7 +1756,7 @@ i915_max_freq_write(struct file *filp,
/*
* Turbo will still be enabled, but won't go above the set value.
*/
- dev_priv-max_delay = val / 50;
+ dev_priv-rps.max_delay = val / 50;
gen6_set_rps(dev, val / 50);
mutex_unlock(dev-struct_mutex);
@@ -1785,7 +1786,7 @@ i915_min_freq_read(struct file *filp, char __user *ubuf,
size_t max,
mutex_lock(dev-struct_mutex);
len = snprintf(buf, sizeof(buf),
- min freq: %d\n, dev_priv-min_delay * 50);
+ min freq: %d\n, dev_priv-rps.min_delay * 50);
mutex_unlock(dev-struct_mutex);
if (len sizeof(buf))
@@ -1823,7 +1824,7 @@ i915_min_freq_write(struct file *filp, const char __user
*ubuf, size_t cnt,
/*
* Turbo will still be enabled, but won't go below the set value.
*/
- dev_priv-min_delay = val / 50;
+ dev_priv-rps.min_delay = val / 50;
gen6_set_rps(dev, val / 50);
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index d57ea16..54dc8d1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1589,7 +1589,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
spin_lock_init(dev_priv-irq_lock);
spin_lock_init(dev_priv-error_lock);
- spin_lock_init(dev_priv-rps_lock);
+ spin_lock_init(dev_priv-rps.lock);
if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
dev_priv-num_pipe = 3;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0b2eb17..2d354e4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -793,9 +793,21 @@ typedef struct drm_i915_private {
bool mchbar_need_disable;
- struct work_struct rps_work;
- spinlock_t rps_lock;
- u32 pm_iir;
+ /* gen6+ rps state */
+ struct {
+ struct work_struct work;
+ u32 pm_iir;
+ /* lock - irqsave spinlock that protectects the work_struct and
+* pm_iir. */
+ spinlock_t lock;
+
+ /* The below variables an all the rps hw state are protected by
+* dev-struct mutext. */
+ u8 cur_delay;
+ u8 min_delay;
+ u8 max_delay;
+ } rps;
+
u8 cur_delay;
u8 min_delay;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 440c905..74c9a0e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -349,16 +349,16 @@ static void notify_ring(struct drm_device *dev,
static void gen6_pm_rps_work(struct work_struct *work)
{
drm_i915_private_t *dev_priv = container_of(work, drm_i915_private_t,
- rps_work);
+ rps.work);
u32 pm_iir, pm_imr;
u8 new_delay;
- spin_lock_irq(dev_priv-rps_lock);
- pm_iir = dev_priv-pm_iir;
-
[Intel-gfx] [PATCH 4/8] drm/i915: kill dev_priv-mchdev_lock
It's only ever a pointer to the global mchdev_lock, and we don't use
it at all.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_pm.c |1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2d354e4..d6072c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -824,7 +824,6 @@ typedef struct drm_i915_private {
int c_m;
int r_t;
u8 corr;
- spinlock_t *mchdev_lock;
enum no_fbc_reason no_fbc_reason;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3ab86bd..44d58e7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3186,7 +3186,6 @@ void intel_gpu_ips_init(struct drm_i915_private *dev_priv)
{
spin_lock(mchdev_lock);
i915_mch_dev = dev_priv;
- dev_priv-mchdev_lock = mchdev_lock;
spin_unlock(mchdev_lock);
ips_ping_for_i915_load();
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915: DE_PCU_EVENT irq is ilk-only
Like all the other drps/ips stuff. Hence add the corresponding check,
give the function a preciser prefix and move the single reg clearing into
the rps handling function, too.
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 74c9a0e..3e203da 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -296,12 +296,14 @@ static void i915_hotplug_work_func(struct work_struct
*work)
drm_helper_hpd_irq_event(dev);
}
-static void i915_handle_rps_change(struct drm_device *dev)
+static void ironlake_handle_rps_change(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
u32 busy_up, busy_down, max_avg, min_avg;
u8 new_delay = dev_priv-cur_delay;
+ I915_WRITE16(MEMINTRSTS, I915_READ(MEMINTRSTS));
+
I915_WRITE16(MEMINTRSTS, MEMINT_EVAL_CHG);
busy_up = I915_READ(RCPREVBSYTUPAVG);
busy_down = I915_READ(RCPREVBSYTDNAVG);
@@ -794,10 +796,8 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
ibx_irq_handler(dev, pch_iir);
}
- if (de_iir DE_PCU_EVENT) {
- I915_WRITE16(MEMINTRSTS, I915_READ(MEMINTRSTS));
- i915_handle_rps_change(dev);
- }
+ if (IS_GEN5(dev) de_iir DE_PCU_EVENT)
+ ironlake_handle_rps_change(dev);
if (IS_GEN6(dev) pm_iir GEN6_PM_DEFERRED_EVENTS)
gen6_queue_rps_work(dev_priv, pm_iir);
--
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/ips: move drps/ips/ilk related variables into dev_priv-ips
Like with the equivalent change for gen6+ rps state, this helps in
clarifying the code (and in fixing a few places that have fallen through
the cracks in the locking review).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 36
drivers/gpu/drm/i915/i915_irq.c | 20 -
drivers/gpu/drm/i915/intel_pm.c | 86 ++-
3 files changed, 70 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d6072c0..5225784 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -808,22 +808,26 @@ typedef struct drm_i915_private {
u8 max_delay;
} rps;
-
- u8 cur_delay;
- u8 min_delay;
- u8 max_delay;
- u8 fmax;
- u8 fstart;
-
- u64 last_count1;
- unsigned long last_time1;
- unsigned long chipset_power;
- u64 last_count2;
- struct timespec last_time2;
- unsigned long gfx_power;
- int c_m;
- int r_t;
- u8 corr;
+ /* ilk-only ips/rps state. Everything in here is protected by the global
+* mchdev_lock in intel_pm.c */
+ struct {
+ u8 cur_delay;
+ u8 min_delay;
+ u8 max_delay;
+ u8 fmax;
+ u8 fstart;
+
+ u64 last_count1;
+ unsigned long last_time1;
+ unsigned long chipset_power;
+ u64 last_count2;
+ struct timespec last_time2;
+ unsigned long gfx_power;
+ u8 corr;
+
+ int c_m;
+ int r_t;
+ } ips;
enum no_fbc_reason no_fbc_reason;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d15ea50..135a84d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -310,7 +310,7 @@ static void ironlake_handle_rps_change(struct drm_device
*dev)
I915_WRITE16(MEMINTRSTS, I915_READ(MEMINTRSTS));
- new_delay = dev_priv-cur_delay;
+ new_delay = dev_priv-ips.cur_delay;
I915_WRITE16(MEMINTRSTS, MEMINT_EVAL_CHG);
busy_up = I915_READ(RCPREVBSYTUPAVG);
@@ -320,19 +320,19 @@ static void ironlake_handle_rps_change(struct drm_device
*dev)
/* Handle RCS change request from hw */
if (busy_up max_avg) {
- if (dev_priv-cur_delay != dev_priv-max_delay)
- new_delay = dev_priv-cur_delay - 1;
- if (new_delay dev_priv-max_delay)
- new_delay = dev_priv-max_delay;
+ if (dev_priv-ips.cur_delay != dev_priv-ips.max_delay)
+ new_delay = dev_priv-ips.cur_delay - 1;
+ if (new_delay dev_priv-ips.max_delay)
+ new_delay = dev_priv-ips.max_delay;
} else if (busy_down min_avg) {
- if (dev_priv-cur_delay != dev_priv-min_delay)
- new_delay = dev_priv-cur_delay + 1;
- if (new_delay dev_priv-min_delay)
- new_delay = dev_priv-min_delay;
+ if (dev_priv-ips.cur_delay != dev_priv-ips.min_delay)
+ new_delay = dev_priv-ips.cur_delay + 1;
+ if (new_delay dev_priv-ips.min_delay)
+ new_delay = dev_priv-ips.min_delay;
}
if (ironlake_set_drps(dev, new_delay))
- dev_priv-cur_delay = new_delay;
+ dev_priv-ips.cur_delay = new_delay;
spin_unlock_irqrestore(mchdev_lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5f9f93e..eff0753 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -593,7 +593,7 @@ static void i915_ironlake_get_mem_freq(struct drm_device
*dev)
break;
}
- dev_priv-r_t = dev_priv-mem_freq;
+ dev_priv-ips.r_t = dev_priv-mem_freq;
switch (csipll 0x3ff) {
case 0x00c:
@@ -625,11 +625,11 @@ static void i915_ironlake_get_mem_freq(struct drm_device
*dev)
}
if (dev_priv-fsb_freq == 3200) {
- dev_priv-c_m = 0;
+ dev_priv-ips.c_m = 0;
} else if (dev_priv-fsb_freq 3200 dev_priv-fsb_freq = 4800) {
- dev_priv-c_m = 1;
+ dev_priv-ips.c_m = 1;
} else {
- dev_priv-c_m = 2;
+ dev_priv-ips.c_m = 2;
}
}
@@ -2162,12 +2162,6 @@ err_unref:
/**
* Lock protecting IPS related data structures
- * - i915_mch_dev
- * - dev_priv-max_delay
- * - dev_priv-min_delay
- * - dev_priv-fmax
- * - dev_priv-gpu_busy
- * - dev_priv-gfx_power
*/
DEFINE_SPINLOCK(mchdev_lock);
@@ -2230,12 +2224,12 @@ static void ironlake_enable_drps(struct drm_device *dev)
vstart = (I915_READ(PXVFREQ_BASE + (fstart * 4)) PXVFREQ_PX_MASK)
[Intel-gfx] [PATCH 8/8] drm/i915: enable rc6 on ilk again
I have the faint hope that the total absence of any locking for the
rps code wasn't too good an idea and could very well have caused some
rc6 related regressions.
Unfortunately we've never managed to reproduce these issues on any of
our own machines, so the only way to go about this is to enable it and
see what happens.
While at it, kill some stale comments and improve the logging.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index eff0753..a87c625 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2361,31 +2361,26 @@ static void gen6_disable_rps(struct drm_device *dev)
int intel_enable_rc6(const struct drm_device *dev)
{
- /*
-* Respect the kernel parameter if it is set
-*/
+ /* Respect the kernel parameter if it is set */
if (i915_enable_rc6 = 0)
return i915_enable_rc6;
- /*
-* Disable RC6 on Ironlake
-*/
- if (INTEL_INFO(dev)-gen == 5)
- return 0;
+ if (INTEL_INFO(dev)-gen == 5) {
+ DRM_DEBUG_DRIVER(Ironlake: only RC6 available\n);
+ return INTEL_RC6_ENABLE;
+ }
- /* On Haswell, only RC6 is available. So let's enable it by default to
-* provide better testing and coverage since the beginning.
-*/
- if (IS_HASWELL(dev))
+ if (IS_HASWELL(dev)) {
+ DRM_DEBUG_DRIVER(Haswell: only RC6 available\n);
return INTEL_RC6_ENABLE;
+ }
- /*
-* Disable rc6 on Sandybridge
-*/
+ /* snb/ivb have more than one rc6 state. */
if (INTEL_INFO(dev)-gen == 6) {
DRM_DEBUG_DRIVER(Sandybridge: deep RC6 disabled\n);
return INTEL_RC6_ENABLE;
}
+
DRM_DEBUG_DRIVER(RC6 and deep RC6 enabled\n);
return (INTEL_RC6_ENABLE | INTEL_RC6p_ENABLE);
}
--
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] drm/i915: dump the device info
On Wed, 8 Aug 2012 22:01:51 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: Handy for lazy people like me, or when people forget to add the output of lspci -nn. v2: Chris Wilson noticed that we have this duplicated already in the i915_capabilites debugfs file. But there \n as separator looks better, which would be a bit verbose in dmesg. Abuse the preprocessor to extract this all. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch I like the placement of the cpp magic next to the struct, that should make it easier to update both at the same time. I think I'd prefer the struct first, magic cpp second. And given the alternatives, I think this is the cleanest way to minimise the code duplication. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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
