aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_display.c
Commit message (Collapse)AuthorAge
* drm/i915: Do not enable package C8 on unsupported hardwareChris Wilson2013-11-19
| | | | | | | | | | | If the hardware does not support package C8, then do not even schedule work to enable it. Thereby we can eliminate a bunch of dangerous work. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Hold pc8 lock around toggling pc8.gpu_idleChris Wilson2013-11-19
| | | | | | | | | | We need to hold the pc8 lock around toggling the value of gpu_idle. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: encoder->get_config is no longer optionalDaniel Vetter2013-11-18
| | | | | | | | | | We must have one to fill out the adjusted_mode.crtc_clock. And with the tv encoder fixed up every encoder we have has a ->get_config callback. So we can drop the checks. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: flush cursors harderDaniel Vetter2013-11-15
| | | | | | | | | | | | | | | | | Apparently they need the same treatment as primary planes. This fixes modesetting failures because of stuck cursors (!) on Thomas' i830M machine. I've figured while at it I'll also roll it out for the ivb 3 pipe version of this function. I didn't do this for i845/i865 since Bspec says the update mechanism works differently, and there's some additional rules about what can be updated in which order. Tested-by: Thomas Richter <thor@math.tu-berlin.de> Cc: stable@vger.kernel.org Cc: Thomas Richter <thor@math.tu-berlin.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'bdw-stage1-2013-11-08-v2' of ↵Dave Airlie2013-11-10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next So here's the Broadwell pull request. From a kernel driver pov there's two areas with big changes in Broadwell: - Completely new enumerated interrupt bits. On the plus side it now looks fairly unform and sane. - Completely new pagetable layout. To ensure minimal impact on existing platforms we've refactored both the irq and low-level gtt handling code a lot in anticipation of the bdw push. So now bdw enabling in these areas just plugs in a bunch of vfuncs. Otherwise it's all fairly harmless adjusting of switch cases and if-ladders to shovel bdw into the right blocks. So minimized impact on existing platforms. I've also merged the bdw-stage1 branch into our -nightly integration branch for the past week to make sure we don't break anything. Note that there's still quite a flurry or patches floating around, but I've figured I'll push this out. I plan to keep the bdw fixes separate from my usual -fixes stream so that you can reject them easily in case it still looks like too much churn. Also, bdw is for now hidden behind the preliminary hw enabling module option. So there's no real pressure to get follow-up patches all into 3.13. * tag 'bdw-stage1-2013-11-08-v2' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits) drm/i915: Mask the vblank interrupt on bdw by default drm/i915: Wire up cpu fifo underrun reporting support for bdw drm/i915: Optimize gen8_enable|disable_vblank functions drm/i915: Wire up pipe CRC support for bdw drm/i915: Wire up PCH interrupts for bdw drm/i915: Wire up port A aux channel drm/i915: Fix up the bdw pipe interrupt enable lists drm/i915: Optimize pipe irq handling on bdw drm/i915/bdw: Take render error interrupt out of the mask drm/i915/bdw: Add BDW PCH check first drm/i915: Use hsw_crt_get_config on BDW drm/i915/bdw: Change dp aux timeout to 600us on DDIA drm/i915/bdw: Enable trickle feed on Broadwell drm/i915/bdw: WaSingleSubspanDispatchOnAALinesAndPoints drm/i915/bdw: conservative SBE VUE cache mode drm/i915/bdw: Limit SDE poly depth FIFO to 2 drm/i915/bdw: Sampler power bypass disable ddrm/i915/bdw: Disable centroid pixel perf optimization drm/i915/bdw: BWGTLB clock gate disable drm/i915/bdw: Implement edp PSR workarounds ...
| * drm/i915/bdw: Enable trickle feed on BroadwellVille Syrjälä2013-11-08
| | | | | | | | | | | | | | Like on HSW, trickle feed should always be enabled on BDW. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Use The GT mailbox for IPS enable/disableBen Widawsky2013-11-08
| | | | | | | | | | | | | | | | | | | | v2: Squash in fixup from Ben to synchronize the GT mailbox commands. CC: Art Runyan <arthur.j.runyan@intel.com> Reviewed-by: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: BDW also has only 2 FDI lanesPaulo Zanoni2013-11-08
| | | | | | | | | | | | | | | | | | So treat it like Haswell. Reviewed-by: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Use pipe CSC on BroadwellVille Syrjälä2013-11-08
| | | | | | | | | | | | | | | | | | Route cursor and sprite data through the pipe CSC unit on BDW. Primary plane data is already sent through the pipe CSC. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Broadwell has PIPEMISCPaulo Zanoni2013-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And it inherits some bits from the previous TRANS_CONF (aka PIPE_CONF on previous gens). v2: Rebase on to of the pipe config bpp handling rework. v3: Rebased on top of the pipe_config->dither refactoring. v4: Drop the read-modify-write cycle for PIPEMISC, similarly to how we now also build up PIPECONF completely ourselves - keeping around random stuff set by the BIOS just isn't a good idea. I've checked BDW BSpec and we already set all relevant bits. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: add Broadwell sprite/plane/cursor checksPaulo Zanoni2013-11-08
| | | | | | | | | | | | | | | | | | | | | | Just make Broadwell follow the same code paths as Haswell here, instead of running code for the even-older platforms. v2: Shuffle around Ben's vma prep work. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: display stuffBen Widawsky2013-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | Just enough to make the code not barf... Init BDW display to look like HSW. For the simulator this should be fine, but this will probably require more work. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add a FIXME comment about RCS flips being untested on bdw. Also add a note that hblank events are reserved on bdw+ in DERRMR.] Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge tag 'drm-intel-fixes-2013-11-07' of ↵Dave Airlie2013-11-08
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Bit a bit -fixes pull request in the merge window than usual dua to two feauture-y things: - Display CRCs are now enabled on all platforms, including the odd DP case on gm45/vlv. Since this is a testing-only feature it should ever hurt, but I figured it'll help with regression-testing -fixes. So I left it in and didn't postpone it to 3.14. - Display power well refactoring from Imre. Would have caused major pain conflict with the bdw stage 1 patches if I'd postpone this to -next. It's only an relatively small interface rework, so shouldn't cause pain. It's also been in my tree since almost 3 weeks already. That accounts for about two thirds of the pull, otherwise just bugfixes: - vlv backlight fix from Jesse/Jani - vlv vblank timestamp fix from Jesse - improved edp detection through vbt from Ville (fixes a vlv issue) - eDP vdd fix from Paulo - fixes for dvo lvds on i830M - a few smaller things all over Note: This contains a backmerge of v3.12. Since the -internal branch always applied on top of -nightly I need that unified base to merge bdw patches. So you'll get a conflict with radeon connector props when pulling this (and nouveau/master will also conflict a bit when Ben doesn't rebase). The backmerge itself only had conflicts in drm/i915. There's also a tiny conflict between Jani's backlight fix and your sysfs lifetime fix in drm-next. * tag 'drm-intel-fixes-2013-11-07' of git://people.freedesktop.org/~danvet/drm-intel: (940 commits) drm/i915/vlv: use per-pipe backlight controls v2 drm/i915: make backlight functions take a connector drm/i915: move opregion asle request handling to a work queue drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV drm/i915: Make intel_dp_is_edp() less specific drm/i915: Give names to the VBT child device type bits drm/i915/vlv: enable HDA display audio for Valleyview2 drm/i915/dvo: call ->mode_set callback only when the port is running drm/i915: avoid unclaimed registers when capturing the error state drm/i915: Enable DP port CRC for the "auto" source on g4x/vlv drm/i915: scramble reset support for DP port CRC on vlv drm/i915: scramble reset support for DP port CRC on g4x drm/i916: add "auto" pipe CRC source ... Conflicts: MAINTAINERS drivers/gpu/drm/i915/intel_panel.c drivers/gpu/drm/nouveau/core/subdev/mc/base.c drivers/gpu/drm/radeon/atombios_encoders.c drivers/gpu/drm/radeon/radeon_connectors.c
| * | drm/i915: make backlight functions take a connectorJesse Barnes2013-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VLV/BYT, backlight controls a per-pipe, so when adjusting the backlight we need to pass the correct info. So make the externally visible backlight functions take a connector argument, which can be used internally to figure out the pipe backlight to adjust. v2: make connector pipe lookup check for NULL crtc (Jani) fixup connector check in ASLE code (Jani) v3: make sure we take the mode config lock around lookups (Daniel) v4: fix double unlock in panel_get_brightness (Daniel) v5: push ASLE work into a work queue (Daniel) v6: separate ASLE work to a prep patch, rebase (Jani) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/vlv: enable HDA display audio for Valleyview2Mengdong Lin2013-11-05
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch defines HD-Audio configuration registers and enables display audio from HDA controller for Valleyview2. v2: fix missing offset VLV_DISPLAY_BASE v3: rename patch from 'enable HDMI audio' to 'enable HDA display audio', since it's for both HDMI and DP audio v4: use enc_to_dig_port() to get port number, instead of using Haswell specific function intel_ddi_get_encoder_port() Signed-off-by: Mengdong Lin <mengdong.lin@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge tag 'v3.12' into drm-intel-nextDaniel Vetter2013-11-04
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I want to merge in the new Broadwell support as a late hw enabling pull request. But since the internal branch was based upon our drm-intel-nightly integration branch I need to resolve all the oustanding conflicts in drm/i915 with a backmerge to make the 60+ patches apply properly. We'll propably have some fun because Linus will come up with a slightly different merge solution. Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_crt.c drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c drivers/gpu/drm/i915/intel_drv.h All rather simple adjacent lines changed or partial backports from -next to -fixes, with the exception of the thaw code in i915_dma.c. That one needed a bit of shuffling to restore the intent. Oh and the massive header file reordering in intel_drv.h is a bit trouble. But not much. v2: Also don't forget the fixup for the silent conflict that results in compile fail ... Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Fix the PPT fdi lane bifurcate state handling on ivbDaniel Vetter2013-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally I've thought that this is leftover hw state dirt from the BIOS. But after way too much helpless flailing around on my part I've noticed that the actual bug is when we change the state of an already active pipe. For example when we change the fdi lines from 2 to 3 without switching off outputs in-between we'll never see the crucial on->off transition in the ->modeset_global_resources hook the current logic relies on. Patch version 2 got this right by instead also checking whether the pipe is indeed active. But that in turn broke things when pipes have been turned off through dpms since the bifurcate enabling is done in the ->crtc_mode_set callback. To address this issues discussed with Ville in the patch review move the setting of the bifurcate bit into the ->crtc_enable hook. That way we won't wreak havoc with this state when userspace puts all other outputs into dpms off state. This also moves us forward with our overall goal to unify the modeset and dpms on paths (which we need to have to allow runtime pm in the dpms off state). Unfortunately this requires us to move the bifurcate helpers around a bit. Also update the commit message, I've misanalyzed the bug rather badly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507 Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Add support for pipe_bpp readoutVille Syrjälä2013-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On CTG+ read out the pipe bpp setting from hardware and fill it into pipe config. Also check it appropriately. v2: Don't do the pipe_bpp extraction inside the PCH only code block on ILK+. Avoid the PIPECONF read as we already have read it for the PIPECONF_EANBLE check. Note: This is already in drm-intel-next-queued as commit 42571aefafb1d330ef84eb29418832f72e7dfb4c Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 6 23:29:00 2013 +0300 drm/i915: Add support for pipe_bpp readout but is needed for the following bugfix. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * Revert "i915: Update VGA arbiter support for newer devices"Dave Airlie2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 81b5c7bc8de3e6f63419139c2fc91bf81dea8a7d. Adding drm/i915 into the vga arbiter chain means that X (in a piece of well-meant paranoia) will do a get/put on the vga decoding around _every_ accel call down into the ddx. Which results in some nice performance disasters [1]. This really breaks userspace, by disabling DRI for everyone, and stops OpenGL from working, this isn't limited to just the i915 but both the integrated and discrete GPUs on multi-gpu systems, in other words this causes untold worlds of pain, Ville tried to come up with a Great Hack to fiddle the required VGA I/O ops behind everyone's back using stop_machine, but that didn't really work out [2]. Given that we're fairly late in the -rc stage for such games let's just revert this all. One thing we might want to keep is to delay the disabling of the vga decoding until the fbdev emulation and the fbcon screen is set up. If we kill vga mem decoding beforehand fbcon can end up with a white square in the top-left corner it tried to save from the vga memory for a seamless transition. And we have bug reports on older platforms which seem to match these symptoms. But again that's something to play around with in -next. References: [1] http://lists.x.org/archives/xorg-devel/2013-September/037763.html References: [2] http://www.spinics.net/lists/intel-gfx/msg34062.html Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
| | * Revert "drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff ↵Dave Airlie2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | is done" This reverts commit 6e1b4fdad5157bb9e88777d525704aba24389bee. This is part of a revert due to a userspace breakage, better explained in the revert of 1a1a4cbf4906a13c0c377f708df5d94168e7b582. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
| | * drm/i915: Only apply DPMS to the encoder if enabledChris Wilson2013-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current test for an attached enabled encoder fails if we have multiple connectors aliased to the same encoder - both connectors believe they own the enabled encoder and so we attempt to both enable and disable DPMS on the encoder, leading to hilarity and an OOPs: [ 354.803064] WARNING: CPU: 0 PID: 482 at /usr/src/linux/dist/3.11.2/drivers/gpu/drm/i915/intel_display.c:3869 intel_modeset_check_state+0x764/0x770 [i915]() [ 354.803064] wrong connector dpms state [ 354.803084] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_intel coretemp kvm_intel snd_hda_codec i915 kvm snd_hwdep snd_pcm_oss snd_mixer_oss crc32_pclmul snd_pcm crc32c_intel e1000e intel_agp igb ghash_clmulni_intel intel_gtt aesni_intel cfbfillrect aes_x86_64 cfbimgblt lrw cfbcopyarea drm_kms_helper ptp video thermal processor gf128mul snd_page_alloc drm snd_timer glue_helper 8250_pci snd pps_core ablk_helper agpgart cryptd sg soundcore fan i2c_algo_bit sr_mod thermal_sys 8250 i2c_i801 serial_core hwmon cdrom i2c_core evdev button [ 354.803086] CPU: 0 PID: 482 Comm: kworker/0:1 Not tainted 3.11.2 #1 [ 354.803087] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.00 05/03/2013 [ 354.803091] Workqueue: events console_callback [ 354.803092] 0000000000000009 ffff88023611db48 ffffffff814048ac ffff88023611db90 [ 354.803093] ffff88023611db80 ffffffff8103d4e3 ffff880230d82800 ffff880230f9b800 [ 354.803094] ffff880230f99000 ffff880230f99448 ffff8802351c0e00 ffff88023611dbe0 [ 354.803094] Call Trace: [ 354.803098] [<ffffffff814048ac>] dump_stack+0x54/0x8d [ 354.803101] [<ffffffff8103d4e3>] warn_slowpath_common+0x73/0x90 [ 354.803103] [<ffffffff8103d547>] warn_slowpath_fmt+0x47/0x50 [ 354.803109] [<ffffffffa089f1be>] ? intel_ddi_connector_get_hw_state+0x5e/0x110 [i915] [ 354.803114] [<ffffffffa0896974>] intel_modeset_check_state+0x764/0x770 [i915] [ 354.803117] [<ffffffffa08969bb>] intel_connector_dpms+0x3b/0x60 [i915] [ 354.803120] [<ffffffffa037e1d0>] drm_fb_helper_dpms.isra.11+0x120/0x160 [drm_kms_helper] [ 354.803122] [<ffffffffa037e24e>] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper] [ 354.803123] [<ffffffff812116c2>] fb_blank+0x52/0xc0 [ 354.803125] [<ffffffff8121e04b>] fbcon_blank+0x21b/0x2d0 [ 354.803127] [<ffffffff81062243>] ? update_rq_clock.part.74+0x13/0x30 [ 354.803129] [<ffffffff81047486>] ? lock_timer_base.isra.30+0x26/0x50 [ 354.803130] [<ffffffff810472b2>] ? internal_add_timer+0x12/0x40 [ 354.803131] [<ffffffff81047f48>] ? mod_timer+0xf8/0x1c0 [ 354.803133] [<ffffffff81266d61>] do_unblank_screen+0xa1/0x1c0 [ 354.803134] [<ffffffff81268087>] poke_blanked_console+0xc7/0xd0 [ 354.803136] [<ffffffff812681cf>] console_callback+0x13f/0x160 [ 354.803137] [<ffffffff81053258>] process_one_work+0x148/0x3d0 [ 354.803138] [<ffffffff81053f19>] worker_thread+0x119/0x3a0 [ 354.803140] [<ffffffff81053e00>] ? manage_workers.isra.30+0x2a0/0x2a0 [ 354.803141] [<ffffffff8105994b>] kthread+0xbb/0xc0 [ 354.803142] [<ffffffff81059890>] ? kthread_create_on_node+0x120/0x120 [ 354.803144] [<ffffffff8140b32c>] ret_from_fork+0x7c/0xb0 [ 354.803145] [<ffffffff81059890>] ? kthread_create_on_node+0x120/0x120 This regression goes back to the big modeset rework and the conversion to the new dpms helpers which started with: commit 5ab432ef4997ce32c9406721b37ef6e97e57dae1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jun 30 08:59:56 2012 +0200 drm/i915/hdmi: convert to encoder->disable/enable Fixes: igt/kms_flip/dpms-off-confusion Reported-and-tested-by: Wakko Warner <wakko@animx.eu.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030 Link: http://lkml.kernel.org/r/20130928185023.GA21672@animx.eu.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [danvet: Add regression citation, mention the igt testcase this fixes and slap a cc: stable on the patch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: avoid unclaimed registers when capturing the error statePaulo Zanoni2013-11-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though we only check for unclaimed registers while we're writing registers, if we read a bad register we'll still trigger a CPU error interrupt, and we'll print an "Unclaimed register" DRM_ERROR due to that. To avoid this error, just avoid touching power domains that are not enabled. Use kzalloc so we're sure all the disabled domains will be zeroed on the error state file. We already print the information that is enough to discover if the power well is enabled on the error state file, so this should not be a problem. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69747 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Clamp cursor coordinates to int16_t rangeVille Syrjälä2013-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We store cursor_x/y as int16_t internally, but the user provided coordinates are int32_t. Clamp the coordinates so that they don't overflow the int16_t. Since the cursor is only 64x64 in size, the clamping can't cause any visual changes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: use power get/put instead of set for power on after initImre Deak2013-10-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we make sure that all power domains are enabled during driver init and turn off unneded ones only after the first modeset. Similarly during suspend we enable all power domains, which will remain on through the following resume until the first modeset. This logic is supported by intel_set_power_well() in the power domain framework. It would be nice to simplify the API, so that we only have get/put functions and make it more explicit on the higher level how this "power well on during init" logic works. This will make it also easier if in the future we want to shorten the time the power wells are on. For this add a new device private flag tracking whether we have the power wells on because of init/suspend and use only intel_display_power_get()/put(). As nothing else uses intel_set_power_well() we can remove it. This also fixes commit 6efdf354ddb186c6604d1692075421e8d2c740e9 Author: Imre Deak <imre.deak@intel.com> Date: Wed Oct 16 17:25:52 2013 +0300 drm/i915: enable only the needed power domains during modeset where removing intel_set_power_well() resulted in not releasing the reference on the power well that was taken during init and thus leaving the power well on all the time. Regression reported by Paulo. v2: - move the init_power_on flag to the power_domains struct (Daniel) v3: - add note about this being a regression fix too (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: enable only the needed power domains during modesetImre Deak2013-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far the modeset code enabled all power domains if it needed any. It wasn't a problem since HW generations so far only had one always-on power well and one dynamic power well that can be enabled/disabled. For domains powered by always-on power wells (panel fitter on pipe A and the eDP transcoder) we didn't do anything, for all other domains we just enabled the single dynamic power well. Future HW generations will change this, as they add multiple dynamic power wells. Support for these will be added later, this patch prepares for those by making sure we only enable the required domains. Note that after this change on HSW we'll enable all power domains even if it was the domain for the panel fitter on pipe A or the eDP transcoder. This isn't a problem since the power domain framework already checks if the domain is on an always-on power well and doesn't do anything in this case. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: factor out modeset_update_power_wellsImre Deak2013-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | We'll need the same functionality for other HW generations. The support for these will be added by upcoming patches. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Whitespace alignment fix for block header in display error stateChris Wilson2013-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current output looks like: Num Pipes: 2 Pipe [0]: SRC: 027f01df Plane [0]: CNTR: d9000000 STRIDE: 00001400 SIZE: 031f04ff POS: 00000000 ADDR: 00020000 Cursor [0]: CNTR: 00000000 POS: 00000000 BASE: 00000000 Pipe [1]: SRC: 04ff031f Plane [1]: CNTR: 01000000 STRIDE: 00000000 SIZE: 018f02cf POS: 00000000 ADDR: 00000000 Cursor [1]: CNTR: 00000000 POS: 00000000 BASE: 00000000 CPU transcoder: A CONF: 00000000 HTOTAL: 031f027f HBLANK: 03170287 HSYNC: 02ef028f VTOTAL: 020c01df VBLANK: 020401e7 VSYNC: 01eb01e9 CPU transcoder: B CONF: 80000000 HTOTAL: 059f04ff HBLANK: 059f04ff HSYNC: 054f052f VTOTAL: 0336031f VBLANK: 0336031f VSYNC: 03280322 which lacks the important visual clue to demarque the transcoder blocks from the last cursor. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Return -ENOENT when a mode object can't be foundVille Syrjälä2013-11-05
|/ / | | | | | | | | | | | | Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/i915: remove dead code in ironlake_crtc_mode_setDaniel Vetter2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 5 13:34:23 2013 +0200 drm/i915: consolidate pch pll enable sequence I've removed all the code from this if block, but somehow forgotten to kill the block itself. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: set HDMI pixel clock in audio configurationJani Nikula2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HDMI audio expects HDMI pixel clock to be set in the audio configuration. We've currently just set 0, using 25.2 / 1.001 kHz frequency, which fails with some modes. v2: Now with a commit message. Reference: http://mid.gmane.org/CAGpEb3Ep1LRZETPxHGRfBDqr5Ts2tAc8gCukWwugUf1U5NYv1g@mail.gmail.com Reference: http://mid.gmane.org/20130206213533.GA16367@hardeman.nu Reported-by: David Härdeman <david@hardeman.nu> Reported-by: Jasper Smet <josbeir@gmail.com> Tested-by: Jasper Smet <josbeir@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: pass mode to ELD write vfuncsJani Nikula2013-10-18
| | | | | | | | | | | | | | | | | | | | | | This will be needed for setting the HDMI pixel clock for audio config. No functional changes. v2: Now with a commit message. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: check gem bo size when creating framebuffersDaniel Vetter2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's better to catch such fallout early, and this way we can rely on the checking done by the drm core on fb->heigh/width at modeset time. If we ever support planar formats on intel we might want to look into a common helper to do all this, but for now this is good enough. v2: Take tiling into account, requested by Ville. v3: Fix tile height on gen2, spotted by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Requested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: prevent tiling changes on framebuffer backing storageDaniel Vetter2013-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assuming that all framebuffer related metadata is invariant simplifies our userspace input data checking. And current userspace always first updates the tiling of an object before creating a framebuffer with it. This allows us to upconvert a check in pin_and_fence to a WARN. In the future it should also be helpful to know which buffer objects are potential scanout targets for e.g. frontbuffer rendering tracking and similar things. Note that SNA shipped for one prerelease with code which will be broken through this patch. But users shouldn't notice since it's purely an optimization and will transparently fall back to allocating a new fb. i-g-t also had offending code (now fixed), but we don't really care about breaking the test-suite. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Grumpily-reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: grab dev->struct_mutex around framebuffer_initDaniel Vetter2013-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | We look at gem state (like obj->tiling/obj->stride), we better have the relevant locks. Right now this doesn't matter much since most of these checks are a curtesy to safe buggy userspace, but I'd like to freeze the tiling once we have framebuffer objects attached. And then locking matters. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: preserve dispaly init order on ByTArtem Bityutskiy2013-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes HDMI port registration order for the BayTrail platform. The story is that in kernel version 3.11 i915 supported only one HDMI port - the HDMIB port. So this port ended up being HDMI-1 in user-space. But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT' introduced HDMIC port support. And added HDMIC registration prior to HDMIB, so HDMIB became HDMI-2 and HDMIC became HDMI-1. Well, this is fine as far as the kernel is concerned. i915 does not give any guarantees to the numbering, and has never given them. However, this breaks wayland setup in Tizen IVI. We have only one single HDMI port on our hardware, and it is connected to HDMIB. Our configuration relies on the fact that it is HDMI-1. Well, certainly this is user-space problem which was exposed with Jesse's patch. However, there is a reason why we have to do this assumption - we use touchscreen monitors and we have to associate event devices with the monitors, and this is not easy to do dynamically, so we just have a static setup. Anyway, while the user-space setup will have to be fixed regardless, let's chane the HDMI port registration order so that HDMIB stays HDMI-1, just like it was in 3.11. Simply because there is no strong reason for changing the order in the kernel, and it'll help setups like ours in sense that we'll have more time for fixing the issue properly. Also amend the commentary which looks a bit out-of-date. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> [danvet: Drop the commment, SDVOC is gone and we have a proper HDMIC define now.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Use pipe_name() instead of the pipe numberDamien Lespiau2013-10-16
| | | | | | | | | | | | | | | | | | | | | | Yet other direct usages of the pipe number instead of pipe_name(). We've been tracking them lately but managed to miss these last ones. v2: Catch them all! (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()Ville Syrjälä2013-10-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fill out the HSW watermark s/w tracking structures with the current hardware state in intel_modeset_setup_hw_state(). This allows us to skip the HW state readback during watermark programming and just use the values we keep around in dev_priv->wm. Reduces the overhead of the watermark programming quite a bit. v2: s/init_wm/wm_get_hw_state Remove stale comment about sprites Make DDB partitioning readout safer Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix whitespace fail.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Use vlv_clock() in vlv_crtc_clock_get()Ville Syrjälä2013-10-14
| | | | | | | | | | | | | | | | Avoid some code duplication. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Use DIV_ROUND_CLOSEST() to calculate dot/vcoVille Syrjälä2013-10-14
| | | | | | | | | | | | | | | | | | Rounding down when calculating the dot/vco frequencies doesn't make much sense. Round to closest should give slightly nicer answers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: rename intel_fb.c to intel_fbdev.cDaniel Vetter2013-10-11
| | | | | | | | | | | | | | | | | | | | | | This file is all about the legacy fbdev support. If we want to extract framebuffer functions, we better put those into a separate file. Also rename functions accordingly, only two have used the intel_fb_ prefix anyway. Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Kconfig option to disable the legacy fbdev supportDaniel Vetter2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarring. Also, I'm unsure whether we don't need to somehow kick out vgacon, now that nothing else gets in the way. But stuff seems to work, so I don't care. Also everything still works as well with VGA_CONSOLE=n Also the #ifdef mess needs a bit of a cleanup, follow-up patches will do just that. To keep the Kconfig tidy, extract all the i915 options into its own file. v2: - Rebase on top of the preliminary hw support option and the intel_drv.h cleanup. - Shut up warnings in i915_debugfs.c v3: Use the right CONFIG variable, spotted by Chon Ming. Cc: Lee, Chon Ming <chon.ming.lee@intel.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Fix pipe off timeout handling for pre-gen4Ville Syrjälä2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current pre-gen4 pipe off code might break out of the loop due to the timeout, but then the fail to print the warning. Refactor the code a bit to use wait_for() to avoid the problem, and that we also re-check the condition after the timeout has expired. v2: Use wait_for() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Rename primary_disabled to primary_enabledVille Syrjälä2013-10-10
| | | | | | | | | | | | | | | | Let's try to avoid these confusing negated booleans. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Populate primary_disabled in intel_modeset_readout_hw_state()Ville Syrjälä2013-10-10
| | | | | | | | | | | | | | | | | | | | | | | | Make sure our primary_disabled matches our expectations after driver init. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70270 Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: shui yangwei <yangweix.shui@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: wait for IPS_ENABLE when enabling IPSPaulo Zanoni2013-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the end of haswell_crtc_enable we have an intel_wait_for_vblank with a big comment, and the message suggests it's a workaround for something we don't really understand. So I removed that wait and started getting HW state readout error messages saying that the IPS state is not what we expected. I investigated and concluded that after you write IPS_ENABLE to IPS_CTL, the bit will only actually become 1 on the next vblank. So add code to wait for the IPS_ENABLE bit. We don't really need this wait right now due to the wait I already mentioned, but at least this one has a reason to be there, while the other one is just to workaround some problem: we may remove it in the future. The wait also acts as a POSTING_READ which we missed. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Undo the PIPEA quirk for i845Chris Wilson2013-10-10
| | | | | | | | | | | | | | | | | | | | The PIPEA quirk is specifically for the issue with the PIPEB PLL on 830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA running. i845 doesn't even have the second PLL or pipe, and enabling the quirk results in a blank DVO LVDS. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: WARN if primary plane state doesn't match expectationsVille Syrjälä2013-10-10
| | | | | | | | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Rename intel_{enable, disable}_plane to intel_{enable, ↵Ville Syrjälä2013-10-10
| | | | | | | | | | | | | | | | | | | | | | | | disable}_primary_plane The new names make it clearer which plane we're talking about. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Resolve small conflict with the haswell_crtc_disable_planes extraction.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Rename intel_flush_display_plane to intel_flush_primary_planeVille Syrjälä2013-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | The intel_flush_primary_plane name actually tells us which plane we're talking about. Also reorganize the internals a bit and add a missing POSTING_READ() to make sure the hardware has seen the changes by the time we return from the function. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Enable/disable IPS when primary is enabled/disabledVille Syrjälä2013-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | IPS should be OK as long as one plane is enabled on the pipe, but it does seem to cause problems when going between primary only and sprite only. This needs more investigations, but for now just disable IPS whenever the primary plane is disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-14 03:00:06 -0400