summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-04-15libnvdimm, pmem: clarify the write+clear_poison+write flowDan Williams
The ACPI specification does not specify the state of data after a clear poison operation. Potential future libnvdimm bus implementations for other architectures also might not specify or disagree on the state of data after clear poison. Clarify why we write twice. Reported-by: Jeff Moyer <jmoyer@redhat.com> Reported-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: Jeff Moyer <jmoyer@redhat.com> Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
2016-04-15ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisationOleksij Rempel
by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move mask_m & mask_p initialisation. This coused a performance regression on ar9281. Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common code in ar9002_hw_spur_mitigate.") Reported-by: Gustav Frederiksen <lkml2017@openmailbox.org> Tested-by: Gustav Frederiksen <lkml2017@openmailbox.org> Cc: <stable@vger.kernel.org> # 4.2+ Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-04-15cxgb4: Set VPD size so we can read both VPD structuresHariprasad Shenai
Chelsio adapters have two VPD structures stored in the VPD: - offset 0x000: an abbreviated VPD, and - offset 0x400: the complete VPD. After 104daa71b396 ("PCI: Determine actual VPD size on first access"), the PCI core computes the valid VPD size by parsing the VPD starting at offset 0x0. That size only includes the abbreviated VPD structure, so reads of the complete VPD at 0x400 fail. Explicitly set the VPD size with pci_set_vpd_size() so the driver can read both VPD structures. [bhelgaas: changelog, split patches, rename to pci_set_vpd_size() and return int (not ssize_t)] Fixes: 104daa71b396 ("PCI: Determine actual VPD size on first access") Tested-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-04-15PCI: Add pci_set_vpd_size() to set VPD sizeHariprasad Shenai
After 104daa71b396 ("PCI: Determine actual VPD size on first access"), the PCI core computes the valid VPD size by parsing the VPD starting at offset 0x0. We don't attempt to read past that valid size because that causes some devices to crash. However, some devices do have data past that valid size. For example, Chelsio adapters contain two VPD structures, and the driver needs both of them. Add pci_set_vpd_size(). If a driver knows it is safe to read past the end of the VPD data structure at offset 0, it can use pci_set_vpd_size() to allow access to as much data as it needs. [bhelgaas: changelog, split patches, rename to pci_set_vpd_size() and return int (not ssize_t)] Fixes: 104daa71b396 ("PCI: Determine actual VPD size on first access") Tested-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-04-15ASoC: wm5102: Free compressed IRQ in CODEC removeCharles Keepax
We request one of the DSP IRQs during CODEC probe, as such we should free it during CODEC remove, this patch does so. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-15ASoC: arizona: Free speaker thermal IRQs in CODEC removeCharles Keepax
The thermal warning IRQs for the speaker are requested in CODEC probe but never freed. This patch frees them in CODEC remove. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-15s390: add CPU_BIG_ENDIAN config optionHeiko Carstens
Make sure that s390 appears to be a big endian machine by defining this config option. Without this s390 appears to be little endian as seen by e.g. the recordmount script: "perl ./scripts/recordmcount.pl "s390" "little" "64"" This has no practical impact within the script since the endian variable is only evaluated for mips. However there are already a couple of common code places which evaluate this config option. None of them is relevant for s390 currently though. To avoid any issues in the future (and fix the recordmcount oddity) add the new config option. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-04-15s390/spinlock: avoid yield to non existent cpuHeiko Carstens
arch_spin_lock_wait_flags() checks if a spinlock is not held before trying a compare and swap instruction. If the lock is unlocked it tries the compare and swap instruction, however if a different cpu grabbed the lock in the meantime the instruction will fail as expected. Subsequently the arch_spin_lock_wait_flags() incorrectly tries to figure out if the cpu that holds the lock is running. However it is using the wrong cpu number for this (-1) and then will also yield the current cpu to the wrong cpu. Fix this by adding a missing continue statement. Fixes: 470ada6b1a1d ("s390/spinlock: refactor arch_spin_lock_wait[_flags]") Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-04-15s390/dcssblk: fix possible deadlock in remove vs. per-device attributesGerald Schaefer
dcssblk_remove_store() holds the dcssblk_devices_sem semaphore while calling device_unregister(), which in turn tries to acquire the kernfs kn->dev_map rwsem for the device sysfs subtree. The same rwsem is also acquired when using the per-device sysfs attributes in the device sub-tree, and the attribute handlers then also acquire the dcssblk_devices_sem. This can lead to a deadlock when removing a DCSS while concurrently reading from / writing to one of its sysfs attributes. The following lockdep warning hinted towards the issue (CPU0 = dcssblk_remove_store, CPU1 = dcssblk_shared_store): [ 76.496047] Possible unsafe locking scenario: [ 76.496054] CPU0 CPU1 [ 76.496059] ---- ---- [ 76.496087] lock(&dcssblk_devices_sem); [ 76.496090] lock(s_active#175); [ 76.496106] lock(&dcssblk_devices_sem); [ 76.496110] lock(s_active#175); [ 76.496115] *** DEADLOCK *** Fix this by releasing the dcssblk_devices_sem semaphore, which only protects internal DCSS data, before calling device_unregister(). Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-04-15thinkpad_acpi: Silence an uninitialized variable warningDan Carpenter
If fan_get_status() fails then "s" is not initialized. Tweak the error handling a bit to silence this warning. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-04-15intel_telemetry_pltdrv: Silence an uninitialized variable warningDan Carpenter
Presumably "pss_period" and "ioss_period" can't both be zero, but this function is never called so we can't infer that using static analysis alone. Silence the warning by setting "ret" to zero. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-04-15hp_accel: Silence an uninitialized variable warningDan Carpenter
If acpi_evaluate_integer() fails then "lret" isn't initialized. I've tweaked the error handling to avoid this issue. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-04-15block: loop: fix filesystem corruption in case of aio/dioMing Lei
Starting from commit e36f620428(block: split bios to max possible length), block core starts to split bio in the middle of bvec. Unfortunately loop dio/aio doesn't consider this situation, and always treat 'iter.iov_offset' as zero. Then filesystem corruption is observed. This patch figures out the offset of the base bvevc via 'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset to iov iterator. Fixes: e36f6204288088f (block: split bios to max possible length) Cc: Keith Busch <keith.busch@intel.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: stable@vger.kernel.org (4.5) Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2016-04-15crypto: ccp - Prevent information leakage on exportTom Lendacky
Prevent information from leaking to userspace by doing a memset to 0 of the export state structure before setting the structure values and copying it. This prevents un-initialized padding areas from being copied into the export area. Cc: <stable@vger.kernel.org> # 3.14.x- Reported-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-15crypto: sha1-mb - use corrcet pointer while completing jobsXiaodong Liu
In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is used when check and complete other jobs. If the memory of first completed req is freed, while still completing other jobs in the func, kernel will crash since NULL pointer is assigned to RIP. Cc: <stable@vger.kernel.org> Signed-off-by: Xiaodong Liu <xiaodong.liu@intel.com> Acked-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-15crypto: rsa-pkcs1pad - fix dst lenTadeusz Struk
The output buffer length has to be at least as big as the key_size. It is then updated to the actual output size by the implementation. Cc: <stable@vger.kernel.org> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-15drm/i915: Show pin mapped counts and sizes in debugfsTvrtko Ursulin
Show a total and purgeable number of pin mapped objects and their total and purgeable size. Example output (new stat prefixed with a star): # cat i915_gem_objects 19920 objects, 289243136 bytes 19920 [18466] objects, 288714752 [267911168] bytes in gtt 0 [0] active objects, 0 [0] bytes 19917 [18466] inactive objects, 288714752 [267911168] bytes 0 unbound objects, 0 bytes 0 purgeable objects, 0 bytes 1 pinned mappable objects, 3145728 bytes 0 fault mappable objects, 0 bytes * 19914 [0] pin mapped objects, 285560832 [0] bytes [purgeable] 4294967296 [268435456] gtt total Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460716493-27826-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-15drm/i915: Show pin mapped status in describe_objTvrtko Ursulin
Reflect the status of obj->mapping as added with the i915_gem_object_pin_map API. 'M' was chosen to designate the pin mapped status. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-15drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platformsVille Syrjälä
We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI, and just trying to frob the display timings to include borders results in a corrupted picture. So reject the 'Center' scaling mode on GMCH platforms for eDP and DSI. TODO: Should really filter out the unsupported modes from the prop, but that would be fairly invasive since the prop is now created and stored by drm core. So leave it for a rainy day. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-6-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Hook up pfit for DSIVille Syrjälä
Add the scaling mode property to DSI connectors, handle changes in the property value, and compute the panel fitter state during .compute_config(). v2: Handle BXT as well Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-5-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Eliminate {vlv,bxt}_configure_dsi_pll()Ville Syrjälä
Fold the DSI PLL configuration functions into the DSI PLL enable functions since they are small and not called from anywhere else. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-4-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Compute DSI PLL parameters during .compute_config()Ville Syrjälä
Compute the DSI PLL parameters during .compute_config() rather than .pre_pll_enable() so that we can fail gracefully if we can't find suitable parameters. In order to do that we need to store the DSI PLL parameters in pipe_config. v2: Handle BXT too Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-3-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHVVille Syrjälä
Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While the DPLL isn't used to provide the clock we still need the refclock, and it appears that the pixel repeat factor also has an effect on DSI output. So set up eveyrhing in DPLL and DPLL_MD as we would do for DP/HDMI/VGA, but don't actually enable the DPLL or configure the dividers via DPIO. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variationsDongwon Kim
This patch is to correct one thing in this commit: commit 25a56705332add0363e47b3a0eca001d6fbd5bec Author: Dongwon Kim <dongwon.kim@intel.com> Date: Wed Mar 16 18:06:13 2016 -0700 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit This reversed bit polarity is actually common for all BXT and APL SoCs. Therefore, revision checking in the original commit should be removed to make the bit set regardless of revision ID of GFX block. Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460673463-14453-1-git-send-email-dongwon.kim@intel.com
2016-04-15drm/dp/mst: Restore primary hub guid on resumeLyude
Some hubs are forgetful, and end up forgetting whatever GUID we set previously after we do a suspend/resume cycle. This can lead to hotplugging breaking (along with probably other things) since the hub will start sending connection notifications with the wrong GUID. As such, we need to check on resume whether or not the GUID the hub is giving us is valid. Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
2016-04-15drm: Release driver references to handle before making it available againChris Wilson
When userspace closes a handle, we remove it from the file->object_idr and then tell the driver to drop its references to that file/handle. However, as the file/handle is already available again for reuse, it may be reallocated back to userspace and active on a new object before the driver has had a chance to drop the old file/handle references. Whilst calling back into the driver, we have to drop the file->table_lock spinlock and so to prevent reusing the closed handle we mark that handle as stale in the idr, perform the callback and then remove the handle. We set the stale handle to point to the NULL object, then any idr_find() whilst the driver is removing the handle will return NULL, just as if the handle is already removed from idr. Note: This will be used to have a direct handle -> vma lookup table, instead of first a handle -> obj lookup, and then an (obj, vm) -> vma lookup. v2: Use NULL rather than an ERR_PTR to avoid having to adjust callers. idr_alloc() tracks existing handles using an internal bitmap, so we are free to use the NULL object as our stale identifier. v3: Needed to update the return value check after changing from using the stale error pointer to NULL. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: dri-devel@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thierry Reding <treding@nvidia.com> [danvet: Add note about the use-case.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460721308-32405-1-git-send-email-chris@chris-wilson.co.uk
2016-04-15drm/i915/dp/mst: Add source port info to debugfs outputJim Bride
Modify the debugfs output for i915_dp_mst_info to list the source port for the DP MST topology in question. v2: rebase v3: rebase v4: rebase cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-3-git-send-email-jim.bride@linux.intel.com
2016-04-15drm/dp/mst: Enhance DP MST debugfs outputJim Bride
Add some additional information (input vs. output port, sink associated with VC, peer device type, max number of VCs supported) and ensure that any embedded '\0' characters in a branch device's devid string are not written to debugfs. v2: Rebase + change drm_edid_get_monitor_name() call to reflect new signature. v3: Minor changes suggested by Jani + rebase. v4: Rebase cc: dri-devel@lists.freedesktop.org cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-2-git-send-email-jim.bride@linux.intel.com
2016-04-15drm/edid: Add drm_edid_get_monitor_name()Jim Bride
In order to include monitor name information in debugfs output we needed to add a function that would extract the monitor name from the EDID, and that function needed to reside in the file where the rest of the EDID helper functions are implemented. v2: Refactor to have drm_edid_get_monitor_name() and drm_edid_to_eld() use a common helper function to extract the monitor name from the edid. [Jani] + rebase. v3: Minor changes suggested by Jani + rebase. v4: Few more minor changes suggested by Jani + rebase. cc: dri-devel@lists.freedesktop.org cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-1-git-send-email-jim.bride@linux.intel.com
2016-04-15drm/i915/bxt: Enable runtime PMImre Deak
With the preceding fixes runtime PM should be functional, I could runtime suspend/resume the device without problems. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-17-git-send-email-imre.deak@intel.com
2016-04-15Revert "drm/i915/bxt: Disable power well support"Imre Deak
With the preceding fixes power well support should be functional on Broxton, I could enter/exit DC5 without problems. This reverts commit 18024199579882265653bfe9e2b1a3dcb5697cd9. CC: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-16-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Add HW state verification for DDI PHY and CDCLKImre Deak
I caught a few errors in our current PHY/CDCLK programming by sanity checking the actual programmed state, so I thought it would be also useful for the future. In addition to verifying the state after programming it also verify it after exiting DC5, to make sure DMC restored/kept intact everything related. v2: - Inlining __phy_reg_verify_state() doesn't make sense and also incorrect, so don't do it (PW/CI gcc) v3: - Rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459780030-15781-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Don't reprogram an already enabled DDI PHYImre Deak
If BIOS has already programmed and enabled a PHY, don't reprogram it as that may interfere with the currently active outputs. A follow-up patch will add state verification, so we can catch any misconfiguration on BIOS's behalf. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-14-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Sanitize the DBUF HW state together with CDCLKImre Deak
When determining whether CDCLK is enabled by BIOS and so we should skip reprogramming it, we didn't check the related DBUF power request and state. In theory BIOS could enable one without the other so check for this case and reprogram things if something is amiss. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-13-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Don't toggle power well 1 on-demandImre Deak
Power well 1 is managed by the DMC firmware so don't toggle it on-demand from the driver. This means we need to follow the BSpec display initialization sequence during driver loading and resuming (both system and runtime) and enable power well 1 only once there. Afterwards DMC will toggle power well 1 whenever entering/exiting DC5. For this to work we also need to do away getting the PLL power domain, since that just kept runtime PM disabled for good. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-12-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Power down DDI PHYs separately during the per PHY uninitImre Deak
The power-down step logically belongs to the individual PHY uninit sequence so move it there. The only functional change is that we will power down now PHY 1 separately before PHY 0 and preserve the other bits in the register which are defined as reserved. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-11-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Pass drm_i915_private to DDI PHY, CDCLK helpersImre Deak
For internal APIs passing dev_priv is preferred to reduce indirections, so convert over a few DDI PHY, CDCLK helpers. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-10-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/skl: Unexport skl_pw1_misc_io_initImre Deak
On Broxton we need to enable/disable power well 1 during the init/unit display sequence similarly to Skylake/Kabylake. The code for this will be added in a follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's a simple function called only from a single place and having it inlined in the Skylake display core init/unit functions will make it easier to compare it with its Broxton counterpart. This also flips the order of Misc IO and power well 1 disabling which matches the enabling order. The specification doesn't prescribe the disabling order, so this should be fine. v2: - Fix incorrect enable vs. disable power well call in skl_display_core_uninit() (Patrik) - Add commit comment about chaning the order of PW1 and Misc IO power well disabling (Patrik) CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459773777-10701-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Suspend power domains during suspend-to-idleImre Deak
On SKL/KBL suspend-to-idle (aka freeze/s0ix) is performed with DMC firmware assistance where the target display power state is DC6. On Broxton on the other hand we don't use the firmware for this, but rely instead on a manual DC9 flow. For this we have to uninitialize the display following the BSpec display uninit sequence, just as during S3/S4, so make sure we follow this sequence. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-8-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Fix DMC/DC state assertsImre Deak
The display power well support and DC state management doesn't depend on runtime PM support, so remove the incorrect asserts about this. Also Broxton does support DC5, so the related assert in assert_can_enable_dc5() is incorrect. There is a more generic and correct assert for this already in gen9_set_dc_state(), so we can remove all the other ones. At the same time convert WARNs to WARN_ONCE for consistency with the other DC state asserts. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-7-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Make power well disabling synchronousImre Deak
So far we only power well enabling was synchronous not disabling. Since we don't exactly know how the firmware (both DMC and PCU) synchronizes against the actual power well state during DC transitions, make the disabling also synchronous. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-6-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMRImre Deak
DMC forces on power well 1 and the misc IO power well by setting the corresponding request bits both in the BIOS and the DEBUG power well request registers. This is somewhat unexpected since the firmware should really just save and restore state but not alter it. We also depend on being able to disable power well 1, and the misc IO power well before entering S3/S4 on BXT and SKL or entering DC9 on BXT. To fix this make sure these request bits are cleared whenever we want to disable the given power wells. On SKL there is another twist where the firmware also clears the power well 1 request bit in HSW_POWER_WELL_DRIVER (but not that of the misc IO power well). This happens to not cause a problem due to the forced-on request bits in the other request registers. I've filed a bug about all this, but fixing that may take a while and having this sanity check in place makes sense even for future firmware versions. At the same time also check the KVMR request bits. I haven't seen this being altered, but we don't expect any request bits in here either, so sanitize this register as well. v2: - Apply the workaround on SKL as well. I noticed the related failure from the CI report, later Patrik also reported seeing it on his machine. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459851965-6137-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-onlyImre Deak
This register is read-only, so we have never actually set OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code comment about this. I filed a specification update request to clarify this there. CC: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-4-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Fix GRC code register field definitionsImre Deak
This has been corrected in BSpec quite some time ago, but we missed it somehow. The wrong field definitions resulted in configuring PHY0 with an incorrect GRC value. v2: - Remove the FIXME comment, we left in the code exactly about this issue. (Ville) CC: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-3-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Reject DMC firmware versions with known bugsImre Deak
DMC version 1.06 has a known bug, where the firmware polls forever for a port PLL to lock, if the PLL was disabled when entering DC5, which locks up the machine. Version 1.07 fixes this, so make that the minimum required version on BXT. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-2-git-send-email-imre.deak@intel.com
2016-04-15objtool: Add workaround for GCC switch jump table bugJosh Poimboeuf
GCC has a rare quirk, currently only seen in three driver functions in the kernel, and only with certain obscure non-distro configs, which can cause objtool to produce "unreachable instruction" false positive warnings. As part of an optimization, GCC makes a copy of an existing switch jump table, modifies it, and then hard-codes the jump (albeit with an indirect jump) to use a single entry in the table. The rest of the jump table and some of its jump targets remain as dead code. In such a case we can just crudely ignore all unreachable instruction warnings for the entire object file. Ideally we would just ignore them for the function, but that would require redesigning the code quite a bit. And honestly that's just not worth doing: unreachable instruction warnings are of questionable value anyway, and this is a very rare issue. kbuild reports: https://lkml.kernel.org/r/201603231906.LWcVUpxm%25fengguang.wu@intel.com https://lkml.kernel.org/r/201603271114.K9i45biy%25fengguang.wu@intel.com https://lkml.kernel.org/r/201603291058.zuJ6ben1%25fengguang.wu@intel.com GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70604 Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/700fa029bbb0feff34f03ffc69d666a3c3b57a61.1460663532.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-15pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffsKeerthy
pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices ranging from 1 to MAX. This leads to a corner case where we try to request the pin number = MAX and fails. bit_pos value is being calculted using ffs. pin_num_from_lsb uses bit_pos value. pins array is populated with: pin + pin_num_from_lsb. The above is 1 more than usual bit indices as bit_pos uses ffs to compute first set bit. Hence the last of the pins array is populated with the MAX value and not MAX - 1 which causes error when we call pin_request. mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1)) Consequently val_pos and submask are correct. Hence use __ffs which gives (ffs(x) - 1) as the first bit set. fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Signed-off-by: Keerthy <j-keerthy@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-04-15ARM: 8551/2: DMA: Fix kzalloc flags in __dma_allocAlexandre Courbot
Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer information") allocates a structure meant for internal buffer management with the GFP flags of the buffer itself. This can trigger the following safeguard in the slab/slub allocator: if (unlikely(flags & GFP_SLAB_BUG_MASK)) { pr_emerg("gfp: %un", flags & GFP_SLAB_BUG_MASK); BUG(); } Fix this by filtering the flags that make the slab allocator unhappy. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-04-15pinctrl: mediatek: correct debounce time unit in mtk_gpio_set_debounceYingjoe Chen
The debounce time unit for gpio_chip.set_debounce is us but mtk_gpio_set_debounce regard it as ms. Fix this by correct debounce time array dbnc_arr so it can find correct debounce setting. Debounce time for first debounce setting is 500us, correct this as well. While I'm at it, also change the debounce time array name to "debounce_time" for readability. Cc: stable@vger.kernel.org Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-04-15drm/i915: use drm_crtc_send_vblank_event()Gustavo Padovan
Replace the legacy drm_send_vblank_event() with the new helper function. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460656118-16766-4-git-send-email-gustavo@padovan.org
generated by cgit (git 2.34.1) at 2025-09-19 15:00:36 +0000