- 14 Nov, 2013 5 commits
-
-
Daniel Vetter authored
We don't init the lock nor set up all the other state. And it doesn't make sense anyway. This appeases lockdep when running the igt/drv_debugfs_reader test. Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We have a nice macro, so use it. Reviewed-by:
-
Daniel Vetter authored
It's been 5 years since kms support was merged and roughly 4 years since UMS support was ripped out from userspace drivers. Thus far it's not been a big burden to keep the ums paths alive, and we've made some good progress in better separating it from the kms code by sprinkling DRIVER_MODESET checks all over the place. But now that the drm demidlayering is within reach this changes. I want to make the driver loading code more robust using devres.c and other cool tricks. But that doesn't work with ums due to the shadow-attach trick. Which means we either a) need to split out a complete ums codebase like radeon has b) kill it for good. The 2nd option is obviously much less work than the first, so I think it's time to test the waters and see how many people out there still use ums. I've decided that silently failing to initialize the driver (and not e.g. failing to load the module) is the right thing. That way we should only get reports from users that actually care about some ums features (like accelerated gl or support for secondary outputs). Everyone else will just fall back to the vesa X driver. For developers there's a small info level dmesg output. The plan is to drop this Kconfig option after 3.16 (so gives us 2 full releases) and then start killing code for real 2-3 releases afterwards. That should be more than enough time for users to pipe up. Of course if anyone does we need to revisit this plan and maybe go with option a) above. Also enable the KMS support by default in Kconfig and polish the help texts a bit. v2: Add the missing hunk of actual code changes. Oops. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Acked-by:
Dave Airlie <airlied@gmail.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
Thus far we've tried to carefully work around the fact that old userspace relied on the AGP-backed legacy buffer mapping ioctls for a bit too long. But it's really horribly, and now some new users for it started to show up again: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg45547.html This uses drmAgpSize to figure out the GTT size, which is both the wrong thing to inquire and also might force us to keep this crap around for another few years. So I want to stop this particular zombie from raising ever again. Now it's only been 4 years since XvMC was fixed for gen3, so a bit early by the usual rules. But since Linus explicitly said that an ABI breakage only counts if someone actually observes it I want to tempt fate an accelarate the demise of AGP. We probably need to wait 2-3 kernel releases with this shipping until we go on a killing spree code-wise. v2: Remove intel_agp_enabled since it's unused (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Acked-by:
-
Daniel Vetter authored
Most platforms din't hit this condition, but if we want to allow building without agp we should also make this allowed on gen3. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 13 Nov, 2013 2 commits
-
-
Mika Kuoppala authored
Insist that flags and pad fields are zero, so that we can safely extend the interface in future. Testcase: igt/gem_reset_stats/params Suggested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Jesse Barnes authored
Preallocated objects will already have been added to the vma_list when creating their ggtt vma entry, and coincidentally also marked as holding a ggtt mapping. Repeating the vma_list manipulation when setting up the ggtt after preallocation is a recipe for an unhappy kernel. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Use the improve commit message suggest by Chris.] Signed-off-by:
-
- 12 Nov, 2013 2 commits
-
-
Mika Kuoppala authored
This ioctl returns reset stats for specified context. The struct returned contains context loss counters. reset_count: all resets across all contexts batch_active: active batches lost on resets batch_pending: pending batches lost on resets v2: get rid of state tracking completely and deliver only counts. Idea from Chris Wilson. v3: fix commit message v4: default context handled inside i915_gem_context_get_hang_stats v5: reset_count only for priviledged process v6: ctx=0 needs CAP_SYS_ADMIN for batch_* counters (Chris Wilson) v7: context hang stats never returns NULL v8: rebased on top of reworked context hang stats DRM_RENDER_ALLOW for ioctl v9: use DEFAULT_CONTEXT_ID. Improve comments for ioctl struct members Signed-off-by:Ian Romanick <ian.d.romanick@intel.com> Signed-off-by:
-
Mika Kuoppala authored
reset_counter will be incremented twice per successful reset. Odd values mean reset is in progress and even values mean that reset has completed. Reset status ioctl introduced in following commit needs to deliver global reset count to userspace so use reset_counter to derive the actual reset count for the gpu Note that reset in progress is enough to increment the counter. v2: wedged equals reset in progress (Daniel Vetter) v3: Fixed stale comments (Damien Lespiau) Signed-off-by:
-
- 11 Nov, 2013 2 commits
-
-
Daniel Vetter authored
We don't want any ERROR for simulated gpu hangs, otoh printing the error code when the reset failed for real should be interesting. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71333 lu hua <huax.lu@intel.com> Signed-off-by:
-
Chon Ming Lee authored
vlv_dpio_read/write should be describe more in PHY centric instead of display controller centric. Create a enum dpio_channel for channel index and enum dpio_phy for PHY index. This should better to gather for upcoming platform. v2: Rebase the code based on drm/i915/vlv: Fix typo in the DPIO register define. v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro DPIO_PHY, and remove unrelated change. (Ville) Suggested-by:
Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by:
-
- 08 Nov, 2013 2 commits
-
-
Ville Syrjälä authored
We only depend on the intel-gtt module for GTT frobbign on older gens. The intel_agp module is optional, except for UMS and some old XvMC userland on gen3. So make AGP support optional. As before, we will fail the i915 init for UMS and gen3 KMS the same as before if intel_agp isn't around. intel-gtt.c is left with a somewhat ugly ifdef mess, but I'm going to save that for a later cleaning. At least my gen2 still works with the patch and CONFIG_AGP=n. v2: Make i915 depend on X86 and PCI, and intel-gtt depend on PCI Signed-off-by:
-
Chon Ming Lee authored
Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current DPIO register definition doesn't have a structure way to break them down. As a result it is not easy to match the PHY/PLL registers with the configdb document. Rename those registers based on the configdb for easy cross references, and without the need to check the offset in the header file. New format is as following. <platform name>_<DPIO component><optional lane #>_DW<dword # in the doc>_<optional channel #> For example, VLV_PCS_DW0 - Group access to PCS for lane 0 to 3 for PCS DWORD 0. VLV_PCS01_DW0_CH0 - PCS access to lane 0/1, channel 0 for PCS DWORD 0. Another example is VLV_TX_DW0 - Group access to TX lane 0 to 3 for TX DWORD 0 VLV_TX0_DW0 - Refer to TX Lane 0 access only for TX DWORD 0. There is no functional change on this patch. v2: Rebase based on previous patch change. v3: There may be configdb different version that document the start DW differently. Add a comment to clarify. Fix up some mismatch start DW for second PLL block. (Ville) Suggested-by:
-
- 07 Nov, 2013 8 commits
-
-
Ville Syrjälä authored
Make the cur_delay limiting code a bit less prone to typo errors by using clamp_t(). Signed-off-by:
-
Ville Syrjälä authored
Polling to make sure the current GPU frequency matches the last requested frequency should not be necessay, and if there's some throttling involved, the two might not match anyway. Since we're still seeing this trigger occasionally, and it just introduces a rather pointless 10 ms delay, it seems like better to kill it off. Signed-off-by:
-
Chris Wilson authored
The RPS register writing routines use the current value of min/max to set certain limits and interrupt gating. If we set those afterwards, we risk setting up the hw incorrectly and losing power management events, and worse, trigger some internal assertions. Reorder the calling sequences to be correct, and remove the then unrequired clamping from inside set_rps(). And for a bonus, fix the bug of calling gen6_set_rps() from Valleyview. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Chon Ming Lee authored
The max frequency reporting is not correct. But there is already an existing valleyview_rps_max_freq and valleyview_rps_min_freq to get the frequency. Use that for i915_cur_delayinfo. Signed-off-by:
-
Ville Syrjälä authored
Use the same wait_for_vblank code for CTG that we use for ILK+. Also fix the name of the frame counter register while at it. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
When the hardware frame counter reads 0xffffff and we're already past vblank start, we'd return 0x1000000 as the vblank counter value. Once we'd cross into the next frame's active portion, the vblank counter would wrap to 0. So we're reporting two different vblank counter values for the same frame. Fix the problem by masking the cooked value by 0xffffff to make sure the counter wraps already after vblank start. Signed-off-by:
-
Chon Ming Lee authored
For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333. Some premium VLV sku will get the DDR_DATA_RATE set as 11. As a result, the turbo frequency reporting will be incorrect without this workaround. Signed-off-by:
-
Ben Widawsky authored
v2: Fixed the botched locking on init_hw failure in i915_reset (Ville) Call cleanup_ringbuffer on failed context create in init_hw (Ville) v3: Add dev argument ti clean_ringbuffer Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
- 06 Nov, 2013 3 commits
-
-
Ville Syrjälä authored
We'll be looking at more than just mem_freq from dev_priv, so just pass the whole thing. Signed-off-by:
-
Ville Syrjälä authored
We're currently miscalculating the VLV graphics clock a little bit. This is caused by rounding the step to integer MHz, which does not match reality. Change the formula to match the GUnit HAS to give more accurate answers. Signed-off-by:
-
Ville Syrjälä authored
valleyview_modeset_global_pipes() may add pipes that are getting fully disabled to prepare_pipes bitmask. The rest of the code doesn't expect this, so clear out any such pipes from the prepare_pipes bitmask. Signed-off-by:
-
- 05 Nov, 2013 5 commits
-
-
Jesse Barnes authored
Either the docs were wrong or the values have changed since the old days before we had wheels. Reported-by:
-
Jesse Barnes authored
It's possible that the CCK clock could run at a different rate than the DDR clock, so use the same method to get CCK as the GMBUS code does when calculating the new CDclk divider in the VLV display code. Reported-by:
-
Jesse Barnes authored
On VLV/BYT, we can adjust the CDclk frequency up or down based on the max pixel clock we need to drive. Lowering it can save power, while raising it is necessary to support high resolution. Add a new callback in modeset_affected_pipes and a modeset_global_resources function to perform this adjustment as necessary. v2: use punit interface for 320 and 266 MHz CDclk adjustments (Ville) v3: reset GMBUS dividers too, since we changed CDclk (Ville) v4: jump to highest voltage when going to 400MHz CDclk (Jesse) v5: drop duplicate define (Ville) use shifts by 1 for fixed point (Ville) drop new callback (Daniel) v6: fixup adjusted_mode.clock -> adjusted_mode.crtc_clock again (Ville) document Bunit reg access better (Ville) v7: pass modeset_pipes and pipe_config to global_pipes so we get the right clock data (Ville) Signed-off-by: -
Jesse Barnes authored
We don't want it delayed with the RPS work. Signed-off-by:
-
Jesse Barnes authored
For modifying self-refresh exit latency. Reviewed-by:
-
- 04 Nov, 2013 3 commits
-
-
Daniel Vetter authored
With the change in the modeset sequence this shouldn't be required any more since the ->mode_set callback now gets called when the dvo port is fully up and running. Also limit the retry loop to 10 tries to avoid hanging the machine while holding important modeset locks. Cc: Thomas Richter <thor@math.tu-berlin.de> Tested-by:
Thomas Richter <thor@math.tu-berlin.de> Signed-off-by:
-
Daniel Vetter authored
The ns2501 controller seems to need the dpll and dvo port to accept the timing update commands. Quick testing on my x30 here seems to indicate that other dvo controllers don't mind. So let's move the ->mode_set callback to a place where we have the port up and running already. Tested-by:
-
Daniel Vetter authored
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:
-
- 03 Nov, 2013 3 commits
-
-
Linus Torvalds authored
-
git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds authored
Pull MIPS fixes from Ralf Baechle: "Three fixes across arch/mips with the most complex one being the GIC interrupt fix - at nine lines still not monster. I'm confident this are the final MIPS patches even if there should go for an rc8" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: ralink: fix return value check in rt_timer_probe() MIPS: malta: Fix GIC interrupt offsets MIPS: Perf: Fix 74K cache map
-
Mathias Krause authored
Negative message lengths make no sense -- so don't do negative queue lenghts or identifier counts. Prevent them from getting negative. Also change the underlying data types to be unsigned to avoid hairy surprises with sign extensions in cases where those variables get evaluated in unsigned expressions with bigger data types, e.g size_t. In case a user still wants to have "unlimited" sizes she could just use INT_MAX instead. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 02 Nov, 2013 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linuxLinus Torvalds authored
Pull ARM kallsyms fix from Rusty Russell: "Last minute perf unbreakage for ARM modules; spent a day in linux-next" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: scripts/kallsyms: filter symbols not in kernel address space
-
Vineet Gupta authored
A vmalloc fault needs to sync up PGD/PTE entry from init_mm to current task's "active_mm". ARC vmalloc fault handler however was using mm. A vmalloc fault for non user task context (actually pre-userland, from init thread's open for /dev/console) caused the handler to deref NULL mm (for mm->pgd) The reasons it worked so far is amazing: 1. By default (!SMP), vmalloc fault handler uses a cached value of PGD. In SMP that MMU register is repurposed hence need for mm pointer deref. 2. In pre-3.12 SMP kernel, the problem triggering vmalloc didn't exist in pre-userland code path - it was introduced with commit 20bafb3d "n_tty: Move buffers into n_tty_data" Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Cc: Gilad Ben-Yossef <gilad@benyossef.com> Cc: Noam Camus <noamc@ezchip.com> Cc: stable@vger.kernel.org #3.10 and 3.11 Cc: Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
- 01 Nov, 2013 3 commits
-
-
Ming Lei authored
This patch uses CONFIG_PAGE_OFFSET to filter symbols which are not in kernel address space because these symbols are generally for generating code purpose and can't be run at kernel mode, so we needn't keep them in /proc/kallsyms. For example, on ARM there are some symbols which may be linked in relocatable code section, then perf can't parse symbols any more from /proc/kallsyms, this patch fixes the problem (introduced b9b32bf7) Cc: Russell King <linux@arm.linux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Cc: Michal Marek <mmarek@suse.cz> Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Cc: stable@vger.kernel.org
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Ingo Molnar: "Two fixes: - Fix 'NMI handler took too long to run' false positives [ Genuine NMI overhead speedups will come for v3.13, this commit only fixes a measurement bug ] - Fix perf ring-buffer missed barrier causing (rare) ring-buffer data corruption on ppc64" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86: Fix NMI measurements perf: Fix perf ring buffer memory ordering -
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here is a set of patches that revert all of the changes done to the pl2303 USB serial driver in the 3.12-rc timeframe, as it turns out they break some devices that work just fine on 3.11. As it's not a good idea to break working systems, drop them all and they will be reworked for future kernel versions such that there is no breakage. I've also included a MAINTAINERS update for the USB serial subsystem and a new device id for the ftdi_sio driver as well" * tag 'usb-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: serial: ftdi_sio: add id for Z3X Box device USB: Maintainers change for usb serial drivers Revert "USB: pl2303: restrict the divisor based baud rate encoding method to the "HX" chip type" Revert "usb: pl2303: fix+improve the divsor based baud rate encoding method" Revert "usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method" Revert "usb: pl2303: remove 500000 baud from the list of standard baud rates" Revert "usb: pl2303: move the two baud rate encoding methods to separate functions" Revert "usb: pl2303: increase the allowed baud rate range for the divisor based encoding method" Revert "usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips" Revert "usb: pl2303: add two comments concerning the supported baud rates with HX chips" Revert "pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup()" Revert "pl2303: improve the chip type information output on startup" Revert "pl2303: improve the chip type detection/distinction" Revert "USB: pl2303: distinguish between original and cloned HX chips"
-
