- 07 Jul, 2014 33 commits
-
-
Ben Widawsky authored
As Ville points out, it's possible/probable we don't actually need this. Potentially, this validates the letter of the spec, and not the spirit. Ville: > I discussed this on irc w/ Ben, and I was suggesting we don't need to > poll. Polling apparently can be used as a workaround for certain > hardware issues, but it looks like those issues shouldn't affect us, > for the momemnt at least. So my suggestion was to try w/o polling > first (since there could be some power cost to polling) and add the > poll bit if problems arise. Rodrigo: Spec suggests this as an W/A for GT3. However semaphores didn't worked in my BDW GT2 on Signal Mode. So pool mode is definitely needed. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
Simple debugfs file to display the current state of semaphores. This is useful if you want to see the state without hanging the GPU. NOTE: This patch is optional to the series. NOTE2: Like the GPU error state collection, the reads are currently incoherent. v2 (Rodrigo): * Iterate only on active rings. * s/ring_buffer/engine_cs. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
Since the semaphore information is in an object, just dump it, and let the user parse it later. NOTE: The page being used for the semaphores are incoherent with the CPU. No matter what I do, I cannot figure out a way to read anything but 0s. Note that the semaphore waits are indeed working. v2: Don't print signal, and wait (they should be the same). Instead, print sync_seqno (Chris) v3: Free the semaphore error object (Chris) v4: Fix semaphore offset calculation during error state collection (Ville) v5: VCS2 rebase Make semaphore object error capture coding style consistent (Ville) Do the proper math for the signal offset (Ville) v6: Fix small conflicts on rebase and s/ring_buffer/engine_cs (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
v2: s/ring_buffer/engine_cs (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Ipehr just carries Dword 0 and on Gen 8, offsets are located on Dword 2 and 3 of MI_SEMAPHORE_WAIT. This implementation was based on Ben's work and on Ville's suggestion for Ben Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Fixup format string.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to wait on is all well defined by the table in the previous patch. There is nothing else different from previous GEN's semaphore synchronization code. v2: Update macros to not require the other ring's ring->id (Chris) v3: Add missing VCS2 gen8_ring_wait init besides s/ring_buffer/engine_cs (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
Semaphore signalling works similarly to previous GENs with the exception that the per ring mailboxes no longer exist. Instead you must define your own space, somewhere in the GTT. The comments in the code define the layout I've opted for, which should be fairly future proof. Ie. I tried to define offsets in abstract terms (NUM_RINGS, seqno size, etc). NOTE: If one wanted to move this to the HWSP they could. I've decided one 4k object would be easier to deal with, and provide potential wins with cache locality, but that's all speculative. v2: Update the macro to not need the other ring's ring->id (Chris) Update the comment to use the correct formula (Chris) v3: Move the macros the ringbuffer.h to prevent churn in next patch (Ville) v4: Fixed compilation rebase conflict commit 1ec9e26d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Feb 14 14:01:11 2014 +0100 drm/i915: Consolidate binding parameters into flags v5: VCS2 rebase Replace hweight_long with hweight32 v6 (Rodrigo): * Add missed VC2 gen8 ring signal init * fixing conflicst on rebase * minor fixes on address table * remove WARN_ON Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [danvet: s/BUG_ON/WARN_ON/] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
With the ring mask we now have an easy way to know the number of rings in the system, and therefore can accurately predict the number of dwords to emit for semaphore signalling. This was not possible (easily) previously. There should be no functional impact, simply fewer instructions emitted. While we're here, simply do the round up to 2 instead of the fancier rounding we did before, which rounding up per mbox, ie 4. This also allows us to drop the unnecessary MI_NOOP, so not really 4, 3. v2: Use 3 dwords instead of 4 (Ville) Do the proper calculation to get the number of dwords to emit (Ville) Conditionally set .sync_to when semaphores are enabled (Ville) v3: Rebased on VCS2 Replace hweight_long with hweight32 (Ville) v4: Pull out the accidentally squashed hunk from the next patch after rebase (Daniel). v5: Fix conflict after rebase (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
Gen8 has already had some differentiation with how it handles rings. Semaphores bring yet more differences, and now is as good a time as any to do the split. Also, since gen8 doesn't actually use semaphores up until this point, put the proper "NULL" values in for the mbox info. v2: v1 had a stale commit message v3: Move everything in the is_semaphore_enabled() check v4: VCS2 rebase Remove double assignment of signal in render ring (Ville) v5: Adding missed VCS2 signal init on gen8+ (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
ring index calculation table was out of date after other rings were added, although the formula is flexible and scale when adding new rings. So this patch just update the comments and add a brief explanation why to use sync_seqno[ring index]. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
It just fix a typo. v2: removing underscore to let this like all other ring names (Oscar) Cc: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by (v1): Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
John Harrison authored
The 'i915_driver_preclose()' function has a parameter called 'file_priv'. However, this is misleading as the structure it points to is a 'drm_file' not a 'drm_i915_file_private'. It should be named just 'file' to avoid confusion. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
The always-on power well pixel path on haswell is routed such that it bypasses the panel fitter when we use is. Which means the pfit CRC source won't work in that configuration. Add a new disallow-bypass flags to the pfit pipe config state and set it when we want to use the pf CRC. Results in a bit of flicker, but should get the job done. We'll also undo do it afterwards to make sure other tests arent' negatively affected. Totally untested due to lack of hsw laptops around here. v2: s/disallow_bypass/force_power_well_on/ to avoid a double negative (Damien). v3: force_thru because roadsigns. v4: Don't forget the power wells! Also note that until the runtime pm for DPMS series is fully merged the simple disable/enable trick won't work since the ->crtc_mode_set callback is still required to do nasty things. This stuff is tricky, but I think by both fixing up get_crtc_power_domains and the debugfs wa code we should always grab/drop the additional power well correctly. v5: Wrap in () as suggested by Damien to avoid setting reserved values for the edp transcoder path on bdw+ References: https://bugs.freedesktop.org/show_bug.cgi?id=72864 Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Tested-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Michel Thierry authored
The workaround to limit SDE poly depth FIFO to 2 is not applied because 3D Chicken-3 mask bit is not set. WaLimitSizeOfSDEPolyFifo is only for BDW-A and could be removed. Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Egbert Eich authored
Since the root cause is understood now and with the fix commit 564ed191 Author: Imre Deak <imre.deak@intel.com> Date: Fri Jun 13 14:54:21 2014 +0300 drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode in place the magic for G4x chipsets introduced with commit commit 61bc95c1 Author: Egbert Eich <eich@suse.com> Date: Mon Mar 4 09:24:38 2013 -0500 DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. to avoided occasional screen blanking on mode changes can finally be removed. It's been verified that Imre's fix also resolves the said issue. Signed-off-by: Egbert Eich <eich@suse.de> Tested-by: Stefan Dirsch <sndirsch@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
As pointed out before we don't have a reliable way to read back ips status on BDW without the risk to disable it when reading. However now we are pretending that IPS on BDW is always on and getting people confused about it. So this patch allows people to know if ips was ever attempted to be enabled. Even if the current status is impossible to be ascertain. v2: (spotted by Paulo): * A version that at least compiles * with more clear messages * let Cheryview on the safe side until we aren't sure that checking ips state on ips won't disable it. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
We're forgetting to unpin the last_context from the ggtt at GPU reset time. This leads to the vma pin_count leaking at every reset if the last context wasn't the ring default context. Further use of the same context will trigger the pin_count check in i915_gem_object_pin() and userspace will be faced with EBUSY as a result. This plaques kms_flip rather badly since it performs lots of resets, and every fd has its own default context these days. Fix the problem by properly unpinning the last context at reset. This regression seems to back to commit acce9ffa Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:03 2013 -0800 drm/i915: Better reset handling for contexts Testcase: igt/gem_ctx_exec/reset-pin-leak Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Dave Airlie authored
The digital ports from Ironlake and up have the ability to distinguish between long and short HPD pulses. Displayport 1.1 only uses the short form to request link retraining usually, so we haven't really needed support for it until now. However with DP 1.2 MST we need to handle the short irqs on their own outside the modesetting locking the long hpd's involve. This patch adds the framework to distinguish between short/long to the current code base, to lay the basis for future DP 1.2 MST work. This should mean we get better bisectability in case of regression due to the new irq handling. v2: add GM45 support (untested, due to lack of hw) Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Todd Previte <tprevite@gmail.com> [danvet: Fix conflicts in i915_irq.c with Oscar Mateo's irq handling race fixes and a trivial one in intel_drv.h with the psr code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
Blanking/unblanking the console in a loop on an Asus T100 sometimes leaves the console blank. After some digging I found that applying commit 61bc95c1 Author: Egbert Eich <eich@suse.com> Date: Mon Mar 4 09:24:38 2013 -0500 DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. fixed VLV too. In my case the problem seemed to happen already during the previous crtc disabling and went away if I disabled self-refresh mode before disabling the primary plane. The root cause for this is that updates from the shadow to live plane control register are blocked at vblank time if the memory self-refresh mode (aka max-fifo mode on VLV) is active at that moment. The controller checks at frame start time if the CPU is in C0 and the self-refresh mode enable bit is set and if so activates self-reresh mode, otherwise deactivates it. So to make sure that the plane truly gets disabled before pipe-off we have to: 1. disable memory self-refresh mode 2. disable plane 3. wait for vblank 4. disable pipe 5. wait for pipe-off v2: - add explanation for the root cause from HW team (Cesar Mancini et al) - remove note about the CPU C7S state, in my latest tests disabling it alone didn't make a difference - add vblank between disabling plane and pipe (Ville) - apply the same workaround for all gmch platforms (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
Atm it's possible that we enable the memory self-refresh mode before the watermark levels used by this mode are programmed with valid values. So move the enabling after we programmed the WM levels. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
This functionality will be also needed by an upcoming patch, so factor it out. As a bonus this also makes things a bit more uniform across platforms. Note that this also changes the register read-modify-write to a simple write during disabling. This is what we do during enabling anyway and according to the spec all the relevant bits are reserved-MBZ or reserved with a 0 default value. v2: - unchanged v3: - fix missing cxsr disabling on pineview (Deepak) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Now that the CMNRESET deassert is part of the cmnlane power well, intel_reset_dpio() is called too late to make any difference. We've deasserted CMNRESET by that time, and so the off+on toggle w/a will never kick in. Move the workaround to intel_power_domains_init_hw() where it gets called before we enable the init power domain. 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>
-
Ville Syrjälä authored
Remove the clutter in __vlv_set_power_well() by moving the cmnlane handling into custom enable/disable hooks for the cmnlane. 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>
-
Ville Syrjälä authored
We have a slightly different way of readoing out the cdclk in gmbus_set_freq(). Kill that and just call .get_display_clock_speed(). Also need to remove the GMBUSFREQ update from intel_i2c_reset() since that gets called way too early. Let's do it in intel_modeset_init_hw() instead, and also pull the initial vlv_cdclk_freq update there from init_clock gating. 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>
-
Ville Syrjälä authored
If someone is interested in the current cdclk frquency it should be stable and not in process of changing frquency. Warn if the current and requested cdclk don't match in .get_display_clock_spee() on vlv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
VLV Punit doesn't support the 400MHz cdclk option, so we bypass the Punit and poke at CCK directly. However we forgot to wait for the frequeency change to complete. Poll the CCK clock status to make sure the clock has changed before we fire up any pipes. 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>
-
Ville Syrjälä authored
Drop the cdclk frequency to 200MHz on vlv when all pipes are off. In theory we should be able to use 200MHz also when the pixel clock is at most 90% of 200MHz. However in practice all we seem to get is a solid color picture or an otherwise corrupted display. 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>
-
Ville Syrjälä authored
Depending on the HPLL frequency one of the supported cdclk frquencies is either 320MHz or 333MHz. Figure out which one it is to accurately pick the minimal required cdclk. This would also avoid a warning from the cdclk code where it compares the actual cdclk read out from the hardware with a value that was calculated using valleyview_calc_cdclk(). 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>
-
Ville Syrjälä authored
We have a standard hook for reading out the current cdclk. Move the VLV code from valleyview_cur_cdclk() to .get_display_clock_speed(). 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>
-
Ville Syrjälä authored
Avoid using magic values for CCK frequency bits. Also the mask we were using for the requested frequency was one bit too short. Fix it up. Note: This also fixes the #define for a mask (spotted by Jesse in his review). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Add note about mask change.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Use kHz units in vlv cdclk code since that's more customary. Also replace the precomputed 90% values with *9/10 computation for extra clarity. 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>
-
Daniel Vetter authored
Due to Dave's vacation drm-next hasn't opened yet for 3.17 so I couldn't move my drm-intel-next queue forward yet like I usually do. Just pull in the latest upstream -rc to unblock patch merging - I don't want to needlessly rebase my current patch pile really and void all the testing we've done already. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Jani apparently didn't rebase onto latest drm-intel-next so a merge is in order. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 Jul, 2014 4 commits
-
-
Linus Torvalds authored
-
git://git.secretlab.ca/git/linuxLinus Torvalds authored
Pull devicetree bugfix from Grant Likely: "Important bug fix for parsing 64-bit addresses on 32-bit platforms. Without this patch the kernel will try to use memory ranges that cannot be reached" * tag 'dt-for-linus' of git://git.secretlab.ca/git/linux: of: Check for phys_addr_t overflows in early_init_dt_add_memory_arch
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "This is a set of 13 fixes, a MAINTAINERS update and a sparse update. The fixes are mostly correct value initialisations, avoiding NULL derefs and some uninitialised pointer avoidance. All the patches have been incubated in -next for a few days. The final patch (use the scsi data buffer length to extract transfer size) has been rebased to add a cc to stable, but only the commit message has changed" * tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: [SCSI] use the scsi data buffer length to extract transfer size virtio-scsi: fix various bad behavior on aborted requests virtio-scsi: avoid cancelling uninitialized work items ibmvscsi: Add memory barriers for send / receive ibmvscsi: Abort init sequence during error recovery qla2xxx: Fix sparse warning in qla_target.c. bnx2fc: Improve stats update mechanism bnx2fc: do not scan uninitialized lists in case of error. fc: ensure scan_work isn't active when freeing fc_rport pm8001: Fix potential null pointer dereference and memory leak. MAINTAINERS: Update LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) maintainers Email IDs be2iscsi: remove potential junk pointer free be2iscsi: add an missing goto in error path scsi_error: set DID_TIME_OUT correctly scsi_error: fix invalid setting of host byte
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "i915, tda998x and vmwgfx fixes, The main one is i915 fix for missing VGA connectors, along with some fixes for the tda998x from Russell fixing some modesetting problems. (still on holidays, but got a spare moment to find these)" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/vmwgfx: Fix incorrect write to read-only register v2: drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin drm/i915: only apply crt_present check on VLV drm/i915: Wait for vblank after enabling the primary plane on BDW drm/i2c: tda998x: add some basic mode validation drm/i2c: tda998x: faster polling for edid drm/i2c: tda998x: move drm_i2c_encoder_destroy call
-
- 05 Jul, 2014 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "This week's arm-soc fixes: - A set of of OMAP patches that we had missed Tony's pull request of: * Reset fix for am43xx * Proper OPP table for omap5 * Fix for SoC detection of one of the DRA7 SoCs * hwmod updates to get SATA and OCP to work on omap5 (drivers merged in 3.16) * ... plus a handful of smaller fixes - sunxi needed to re-add machine specific restart code that was removed in anticipation of a watchdog driver being merged for 3.16, and it didn't make it in. - Marvell fixes for PCIe on SMP and a big-endian fix. - A trivial defconfig update to make my capri test board boot with bcm_defconfig again. ... and a couple of MAINTAINERS updates, one to claim new Keystone drivers that have been merged, and one to merge MXS and i.MX (both Freescale platforms). The largest diffs come from the hwmod code for omap5 and the re-add of the restart code on sunxi. The hwmod stuff is quite late at this point but it slipped through cracks repeatedly while coming up the maintainer chain and only affects the one SoC so risk is low" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: MAINTAINERS: Add few more Keystone drivers MAINTAINERS: merge MXS entry into IMX one ARM: sunxi: Reintroduce the restart code for A10/A20 SoCs ARM: mvebu: fix cpuidle implementation to work on big-endian systems ARM: mvebu: update L2/PCIe deadlock workaround after L2CC cleanup ARM: mvebu: move Armada 375 external abort logic as a quirk ARM: bcm: Fix bcm and multi_v7 defconfigs ARM: dts: dra7-evm: remove interrupt binding ARM: OMAP2+: Fix parser-bug in platform muxing code ARM: DTS: dra7/dra7xx-clocks: ATL related changes ARM: OMAP2+: drop unused function ARM: dts: am43x-epos-evm: Add Missing cpsw-phy-sel for am43x-epos-evm ARM: dts: omap5: Update CPU OPP table as per final production Manual ARM: DRA722: add detection of SoC information ARM: dts: Enable twl4030 off-idle configuration for selected omaps ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "A few minor fixlets in ARM SoC irq drivers and a fix for a memory leak which I introduced in the last round of cleanups :(" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq: Fix memory leak when calling irq_free_hwirqs() irqchip: spear_shirq: Fix interrupt offset irqchip: brcmstb-l2: Level-2 interrupts are edge sensitive irqchip: armada-370-xp: Mask all interrupts during initialization.
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Fixes for 3.16-rc3; most importantly Jesse brings back VGA he took away on a bunch of machines. Also a vblank fix for BDW and a power workaround fix for VLV. * tag 'drm-intel-fixes-2014-07-03' of git://anongit.freedesktop.org/drm-intel: drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin drm/i915: only apply crt_present check on VLV drm/i915: Wait for vblank after enabling the primary plane on BDW
-