summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-05-11smc_diag.h: fix include from userlandNicolas Dichtel
This patch prepares the uapi export by fixing the following error: .../linux/smc_diag.h:6:27: fatal error: rdma/ib_verbs.h: No such file or directory #include <rdma/ib_verbs.h> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-05-11btrfs_tree.h: fix include from userlandNicolas Dichtel
This patch prepares the uapi export by fixing the following errors: .../linux/btrfs_tree.h:283:2: error: #error "UUID items require BTRFS_UUID_SIZE == 16!" #error "UUID items require BTRFS_UUID_SIZE == 16!" .../linux/btrfs_tree.h:390:12: error: ‘BTRFS_UUID_SIZE’ undeclared here (not in a function) __u8 uuid[BTRFS_UUID_SIZE]; ^ .../linux/btrfs_tree.h:796:16: error: ‘BTRFS_DEV_STAT_VALUES_MAX’ undeclared here (not in a function) __le64 values[BTRFS_DEV_STAT_VALUES_MAX]; Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-05-11uapi: includes linux/types.h before exporting filesNicolas Dichtel
Some files will be exported after a following patch. 0-day tests report the following warning/error: ./usr/include/linux/bcache.h:8: include of <linux/types.h> is preferred over <asm/types.h> ./usr/include/linux/bcache.h:11: found __[us]{8,16,32,64} type without #include <linux/types.h> ./usr/include/linux/qrtr.h:8: found __[us]{8,16,32,64} type without #include <linux/types.h> ./usr/include/linux/cryptouser.h:39: found __[us]{8,16,32,64} type without #include <linux/types.h> ./usr/include/linux/pr.h:14: found __[us]{8,16,32,64} type without #include <linux/types.h> ./usr/include/linux/btrfs_tree.h:337: found __[us]{8,16,32,64} type without #include <linux/types.h> ./usr/include/rdma/bnxt_re-abi.h:45: found __[us]{8,16,32,64} type without #include <linux/types.h> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-05-11Makefile.headersinst: remove destination-y optionNicolas Dichtel
This option was added in commit c7bb349e7c25 ("kbuild: introduce destination-y for exported headers") but never used in-tree. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-05-11Makefile.headersinst: cleanup input filesNicolas Dichtel
After the last three patches, all exported headers are under uapi/, thus input-files2 are not needed anymore. The side effect is that input-files1-name is exactly header-y. Note also that input-files3-name is genhdr-y. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-05-11x86: stop exporting msr-index.h to userlandNicolas Dichtel
Even if this file was not in an uapi directory, it was exported because it was listed in the Kbuild file. Fixes: b72e7464e4cf ("x86/uapi: Do not export <asm/msr-index.h> as part of the user API headers") Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-05-11nios2: put setup.h in uapiNicolas Dichtel
This header file is exported, but from a userland pov, it's just a wrapper to asm-generic/setup.h. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-05-11h8300: put bitsperlong.h in uapiNicolas Dichtel
This header file is exported, thus move it to uapi. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-05-10blk-mq: NVMe 512B/4K+T10 DIF/DIX format returns I/O error on dd with split opWen Xiong
When formatting NVMe to 512B/4K + T10 DIf/DIX, dd with split op returns "Input/output error". Looks block layer split the bio after calling bio_integrity_prep(bio). This patch fixes the issue. Below is how we debug this issue: (1)format nvme to 4K block # size with type 2 DIF (2)dd with block size bigger than 1024k. oflag=direct dd: error writing '/dev/nvme0n1': Input/output error We added some debug code in nvme device driver. It showed us the first op and the second op have the same bi and pi address. This is not correct. 1st op: nvme0n1 Op:Wr slba 0x505 length 0x100, PI ctrl=0x1400, dsmgmt=0x0, AT=0x0 & RT=0x505 Guard 0x00b1, AT 0x0000, RT physical 0x00000505 RT virtual 0x00002828 2nd op: nvme0n1 Op:Wr slba 0x605 length 0x1, PI ctrl=0x1400, dsmgmt=0x0, AT=0x0 & RT=0x605 ==> This op fails and subsequent 5 retires.. Guard 0x00b1, AT 0x0000, RT physical 0x00000605 RT virtual 0x00002828 With the fix, It showed us both of the first op and the second op have correct bi and pi address. 1st op: nvme2n1 Op:Wr slba 0x505 length 0x100, PI ctrl=0x1400, dsmgmt=0x0, AT=0x0 & RT=0x505 Guard 0x5ccb, AT 0x0000, RT physical 0x00000505 RT virtual 0x00002828 2nd op: nvme2n1 Op:Wr slba 0x605 length 0x1, PI ctrl=0x1400, dsmgmt=0x0, AT=0x0 & RT=0x605 Guard 0xab4c, AT 0x0000, RT physical 0x00000605 RT virtual 0x00003028 Signed-off-by: Wen Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2017-05-10drm/i915: Add support for sprites on g4xVille Syrjälä
Now that the watermarks are in order, it should be safe to enable sprite planes on g4x. We alreday have the code in fact, we just call it ilk_. Let's rename to g4x_ and let it loose. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-16-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Add g4x watermark tracepointVille Syrjälä
Add a tracepoint for watermark programming on g4x, similar to what we have on vlv/chv. Should help in debugging watermark programming sequence issues. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-15-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Enable HPLL watermarks on g4xVille Syrjälä
I don't see why we couldn't use the HPLL watermarks on g4x. So let's enable them. Let's assume a 35 usec memory latency for the HPLL mode. That's roughly what PNV uses. Based on the behaviour of the ELK box I have 35 usec is probably overkill. Actually all the current latency values used seem overkill as I can reduce them pretty drastically before I start to see underruns. But let's play things a bit safe for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-14-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Two stage watermarks for g4xVille Syrjälä
Implement proper two stage watermark programming for g4x. As with other pre-SKL platforms, the watermark registers aren't double buffered on g4x. Hence we must sequence the watermark update carefully around plane updates. The code is quite heavily modelled on the VLV/CHV code, with some fairly significant differences due to the different hardware architecture: * g4x doesn't use inverted watermark values * CxSR actually affects the watermarks since it controls memory self refresh in addition to the max FIFO mode * A further HPLL SR mode is possible with higher memory wakeup latency * g4x has FBC2 and so it also has FBC watermarks * max FIFO mode for primary plane only (cursor is allowed, sprite is not) * g4x has no manual FIFO repartitioning * some TLB miss related workarounds are needed for the watermarks Actually the hardware is quite similar to ILK+ in many ways. The most visible differences are in the actual watermakr register layout. ILK revamped that part quite heavily whereas g4x is still using the layout inherited from earlier platforms. Note that we didn't previously enable the HPLL SR on g4x. So in order to not introduce too many functional changes in this patch I've not actually enabled it here either, even though the code is now fully ready for it. We'll enable it separately later on. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-13-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Apply the g4x TLB miss w/a to SR watermarks as wellVille Syrjälä
The documentation I've seen doesn't actually specify which watermarks need the TLB miss w/a. Currently we only apply the w/a to the normal watermarks for both primary and cursor planes. Since the documentation doesn't explicitly say anything I'm going to assume that the w/a should equally apply to the SR/HPLL watermarks. So let's do that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-12-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Refactor wm calculationsVille Syrjälä
All platforms until SKL compute their watermarks essentially using the same method1/small buffer and method2/large buffer formulas. Most just open code it in slightly different ways. Let's pull it all into common helpers. This makes it a little easier to spot the actual differences. While at it try to add some docs explainign what the formulas are trying to do. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-11-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Refactor the g4x TLB miss w/a to a helperVille Syrjälä
Pull the g4x TLB miss w/a calculation into a small helper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-10-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Fix the g4x watermark TLB miss workaroundVille Syrjälä
The g4x watermark TLB miss workaround requires that we bump up the watermark by the difference between 8 full lines and the FIFO size. Unfortunately the way we compute it at the moment ignores the size of the pixels. The code also used the primary plane width as the cursor width when computing the TLB miss w/a for the cursor. Let's fix both problems. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-9-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Fix cursor 'cpp' in watermark calculatins for old platformsVille Syrjälä
The watermark code for the old platforms (g4x and older) uses the primary plane cpp when computing cursor watermarks. To keep the fix simple let's just hardcode cpp=4 for the cursor on those platforms since that's all we support. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-8-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Document CxSRVille Syrjälä
Add some documentation explaining what CxSR actually is. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-7-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Make vlv/chv watermark debug print less crypticVille Syrjälä
The magic numbers 0,1,2 aren't all that interesting for users perhaps. Since we know what these watermark levels mean for VLV/CHV let's print their names. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-6-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Rename bunch of vlv_ watermark structures to g4x_Ville Syrjälä
We'll be wanting to share some of these watermark structures on g4x, so let's rename them to have a g4x_ prefix instead of vlv_. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-5-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: s/vlv_num_wm_levels/intel_wm_num_levels/Ville Syrjälä
Rename the VLV/CHV max_level->num_levels helper to have an intel_ prefix since it's not VLV/CHV specific and I'll want to use it on other platforms as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-4-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: Drop the debug message from vlv_get_fifo_size()Ville Syrjälä
Seeing the display FIFO sizes at driver load time doesn't really provide anything useful for us, so let's just drop the debug message. One can always use eg. intel_watermarks to dump out the hardware settings prior to loading the driver. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-3-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10drm/i915: s/vlv_plane_wm_compute/vlv_raw_plane_wm_compute/ etc.Ville Syrjälä
Rename some of the vlv wm functions to reflect the fact that they operate on the "raw" watermarks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-2-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-05-10blk-stat: don't use this_cpu_ptr() in a preemptable sectionJens Axboe
If PREEMPT_RCU is enabled, rcu_read_lock() isn't strong enough for us to use this_cpu_ptr() in that section. Use the safer get/put_cpu_ptr() variants instead. Reported-by: Mike Galbraith <efault@gmx.de> Fixes: 34dbad5d26e2 ("blk-stat: convert to callback-based statistics reporting") Signed-off-by: Jens Axboe <axboe@fb.com>
2017-05-10elevator: remove redundant warnings on IO scheduler switchJens Axboe
We warn twice for switching to a scheduler, if that switch fails. As we also report the failure in the return value to the sysfs write, remove the dmesg induced failures. Keep the failure print for warning to switch to the kconfig selected IO scheduler, as we can't report errors for that in any other way. Signed-off-by: Jens Axboe <axboe@fb.com>
2017-05-10block, bfq: stress that low_latency must be off to get max throughputPaolo Valente
The introduction of the BFQ and Kyber I/O schedulers has triggered a new wave of I/O benchmarks. Unfortunately, comments and discussions on these benchmarks confirm that there is still little awareness that it is very hard to achieve, at the same time, a low latency and a high throughput. In particular, virtually all benchmarks measure throughput, or throughput-related figures of merit, but, for BFQ, they use the scheduler in its default configuration. This configuration is geared, instead, toward a low latency. This is evidently a sign that BFQ documentation is still too unclear on this important aspect. This commit addresses this issue by stressing how BFQ configuration must be (easily) changed if the only goal is maximum throughput. Signed-off-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@fb.com>
2017-05-10block, bfq: use pointer entity->sched_data only if setPaolo Valente
In the function __bfq_deactivate_entity, the pointer entity->sched_data could happen to be used before being properly initialized. This led to a NULL pointer dereference. This commit fixes this bug by just using this pointer only where it is safe to do so. Reported-by: Tom Harrison <l12436.tw@gmail.com> Tested-by: Tom Harrison <l12436.tw@gmail.com> Signed-off-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@fb.com>
2017-05-10nvme: lightnvm: fix memory leakRakesh Pandit
Free up kmalloc allocated memory if failure happens while handling L2P table transfer in nvme_nvm_get_l2p_tbl. Fixes: 8e79b5cb ("lightnvm: move block provisioning to targets") Signed-off-by: Rakesh Pandit <rakesh@tuxera.com> Reviewed-by: Javier González <javier@cnexlabs.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2017-05-10Merge tag 'mvebu-arm64-4.12-1' of git://git.infradead.org/linux-mvebu into fixesArnd Bergmann
Merge "mvebu arm64 for 4.12" from Gregory CLEMENT: enable the Armada 37xx pinctrl driver * tag 'mvebu-arm64-4.12-1' of git://git.infradead.org/linux-mvebu: arm64: marvell: enable the Armada 37xx pinctrl driver
2017-05-10Merge tag 'mvebu-dt64-4.12-3' of git://git.infradead.org/linux-mvebu into fixesArnd Bergmann
Pull "mvebu dt64 for 4.12 (part 3)" from Gregory CLEMENT: pinctrl and GPIO description for Armada 37xx SoCs * tag 'mvebu-dt64-4.12-3' of git://git.infradead.org/linux-mvebu: ARM64: dts: marvell: armada37xx: add pinctrl definition ARM64: dts: marvell: Add pinctrl nodes for Armada 3700
2017-05-10Merge tag 'renesas-fixes-for-v4.12' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes Pull "Renesas ARM Based SoC Fixes for v4.12" from Simon Horman: * Provide dummy rcar_rst_read_mode_pins() for compile-testing * tag 'renesas-fixes-for-v4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: soc: renesas: Provide dummy rcar_rst_read_mode_pins() for compile-testing
2017-05-10drm/i915/lvds: Remove magic from PLL programmingImre Deak
This looks like a left-over from enabling work. The spec defines CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED as reserved set, so follow this in the programming. v2: - Follow the spec to set CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.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/1494408113-379-7-git-send-email-imre.deak@intel.com
2017-05-10drm/i915: Sanitize stolen memory size calculationImre Deak
On GEN8+ (not counting CHV) the calculation can in theory result in an incorrect sign extension with all upper bits set. In practice this is unlikely to happen since it would require 4GB of stolen memory set aside. For consistency still prevent the sign extension explicitly everywhere. 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/1494408113-379-6-git-send-email-imre.deak@intel.com
2017-05-10drm/i915: Check error return when converting pipe to connectorImre Deak
An error from intel_get_pipe_from_connector() would mean a bug somewhere else, but we still should check for it to prevent some other more obscure bug later. v2: - Fall back to a reasonable default instead of bailing out in case of error. (Jani) v3: - Fix s/PIPE_INVALID/INVALID_PIPE/ typo. (Jani) v4: - Fix bogus bracing around WARN() condition. (Ville) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-5-git-send-email-imre.deak@intel.com
2017-05-10drm/i915: Check error return when setting DMA maskImre Deak
Even though an error from these functions isn't fatal we still want to have a diagnostic message about it. v2: - Don't do assignments in if statements. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-4-git-send-email-imre.deak@intel.com
2017-05-10drm/i915/sdvo: Check error return from intel_sdvo_get_value()Imre Deak
The current code assumes that 'enhancements' won't change in case of an error, but this isn't guaranteed. Fix things by treating any error as a lack of the given capability. v2: - Remove the now redundant init of enhancements. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.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/1494408113-379-3-git-send-email-imre.deak@intel.com
2017-05-10drm/i915/dp: Check error return during DPCD capability queriesImre Deak
The assumptions of these users of drm_dp_dpcd_readb() is that the passed in output buffer won't change in case of error, but this isn't guaranteed. Fix this by treating any error as the lack of the given capability. In case of DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP an error would leave the buffer uninitialized even with the above assumption. 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/1494408113-379-2-git-send-email-imre.deak@intel.com
2017-05-10drm/i915/vlv: Fix port B PLL opamp initializationImre Deak
The current code looks like a typo, the specification calls for setting bits 31:24 to 0x8C, while preserving bits 23:0. Fix things accordingly. I'm not aware of the typo causing a real problem, so the fix is only for consistency. Cc: Ville Syrjälä <ville.syrjala@linux.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/1494408113-379-1-git-send-email-imre.deak@intel.com
2017-05-10drm/vblank: Lock down vblank->hwmode moreDaniel Vetter
In the previous patch we've implemented hwmode tracking a la i915 for the vblank timestamp calculations. But that was just the basic semantics, i915 has some nice sanity checks to make sure we keep getting this right. Move them over too. v2: - WARN_ON_ONCE to avoid excessive spam (Ville) - Really only WARN on atomic drivers. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-5-daniel.vetter@ffwll.ch
2017-05-10drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutposDaniel Vetter
If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence the final timestamps might be a bit off. But since this is an existing bug I'm not going to change it, but just try to be bug-for-bug compatible with the current code. This only applies to radeon&amdgpu. - i915 tries to get it perfect by updating crtc->hwmode when the pipe is off (i.e. vblank->enabled = false). - All other atomic drivers look at crtc->state->adjusted_mode. Those that look at state->requested_mode simply don't adjust their mode, so it's the same. That has two problems: Accessing crtc->state from interrupt handling code is unsafe, and it's updated before we shut down the pipe. For nonblocking modesets it's even worse. For atomic drivers try to implement what i915 does. To do that we add a new hwmode field to the vblank structure, and update it from drm_calc_timestamping_constants(). For atomic drivers that's called from the right spot by the helper library already, so all fine. But for safety let's enforce that. For legacy driver this function is only called at the end (oh the fun), which is broken, so again let's not bother and just stay bug-for-bug compatible. The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos directly to implement ->get_vblank_timestamp in every driver, deleting a lot of code. v2: Completely new approach, trying to mimick the i915 solution. v3: Fixup kerneldoc. v4: Drop the WARN_ON to check that the vblank is off, atomic helpers currently unconditionally call this. Recomputing the same stuff should be harmless. v5: Fix typos and move misplaced hunks to the right patches (Neil). v6: Undo hunk movement (kbuild). Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
2017-05-10drm/vblank: Add FIXME comments about moving the vblank ts hooksDaniel Vetter
This is going to be a bit too much, but good to have at least a small note about where this should all head towards. Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-3-daniel.vetter@ffwll.ch
2017-05-10drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestampDaniel Vetter
It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. v2: Fixup misplaced hunks (Neil). v3: kbuild says v1 was better ... Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch
2017-05-10drm/vblank: Switch drm_driver->get_vblank_timestamp to return a boolDaniel Vetter
There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything else). Again, we DRM_ERROR. - EINVAL is checked at higher levels already, and if we'd use struct drm_crtc * instead of (dev, pipe) it would be real obvious that those are again core bugs. The only valid failure mode is crap hardware that couldn't sample a useful timestamp, to ask the core to just grab a not-so-accurate timestamp. Bool is perfectly fine for that. v2: Also fix up the one caller, I lost that in the shuffling (Jani). v3: Fixup commit message (Neil). Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch
2017-05-10drm/vgem: Convert to a struct drm_device subclassChris Wilson
With Laura's introduction of the fake platform device for importing dmabuf, we add a second static that is logically tied to the vgem_device. Convert vgem over to using the struct drm_device subclassing, so that the platform device is stored inside its owner. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Laura Abbott <labbott@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170508132228.9509-1-chris@chris-wilson.co.uk
2017-05-10gpu: drm: gma500: remove dead codeGustavo A. R. Silva
Local variable use_gct is assigned to a constant value and it is never updated again. Remove this variable and the dead code it guards. Addresses-Coverity-ID: 145690 Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170509152221.GA7618@embeddedgus
2017-05-10ALSA: hda: Fix cpu lockup when stopping the cmd dmasJeeja KP
Using jiffies in hdac_wait_for_cmd_dmas() to determine when to time out when interrupts are off (snd_hdac_bus_stop_cmd_io()/spin_lock_irq()) causes hard lockup so unlock while waiting using jiffies. ---<-snip->--- <0>[ 1211.603046] NMI watchdog: Watchdog detected hard LOCKUP on cpu 3 <4>[ 1211.603047] Modules linked in: snd_hda_intel i915 vgem <4>[ 1211.603053] irq event stamp: 13366 <4>[ 1211.603053] hardirqs last enabled at (13365): ... <4>[ 1211.603059] Call Trace: <4>[ 1211.603059] ? delay_tsc+0x3d/0xc0 <4>[ 1211.603059] __delay+0xa/0x10 <4>[ 1211.603060] __const_udelay+0x31/0x40 <4>[ 1211.603060] snd_hdac_bus_stop_cmd_io+0x96/0xe0 [snd_hda_core] <4>[ 1211.603060] ? azx_dev_disconnect+0x20/0x20 [snd_hda_intel] <4>[ 1211.603061] snd_hdac_bus_stop_chip+0xb1/0x100 [snd_hda_core] <4>[ 1211.603061] azx_stop_chip+0x9/0x10 [snd_hda_codec] <4>[ 1211.603061] azx_suspend+0x72/0x220 [snd_hda_intel] <4>[ 1211.603061] pci_pm_suspend+0x71/0x140 <4>[ 1211.603062] dpm_run_callback+0x6f/0x330 <4>[ 1211.603062] ? pci_pm_freeze+0xe0/0xe0 <4>[ 1211.603062] __device_suspend+0xf9/0x370 <4>[ 1211.603062] ? dpm_watchdog_set+0x60/0x60 <4>[ 1211.603063] async_suspend+0x1a/0x90 <4>[ 1211.603063] async_run_entry_fn+0x34/0x160 <4>[ 1211.603063] process_one_work+0x1f4/0x6d0 <4>[ 1211.603063] ? process_one_work+0x16e/0x6d0 <4>[ 1211.603064] worker_thread+0x49/0x4a0 <4>[ 1211.603064] kthread+0x107/0x140 <4>[ 1211.603064] ? process_one_work+0x6d0/0x6d0 <4>[ 1211.603065] ? kthread_create_on_node+0x40/0x40 <4>[ 1211.603065] ret_from_fork+0x2e/0x40 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100419 Fixes: 38b19ed7f81ec ("ALSA: hda: fix to wait for RIRB & CORB DMA to set") Reported-by: Marta Lofstedt <marta.lofstedt@intel.com> Suggested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Acked-by: Vinod Koul <vinod.koul@intel.com> CC: stable <stable@vger.kernel.org> # 4.7 Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-05-10perf/callchain: Force USER_DS when invoking perf_callchain_user()Will Deacon
Perf can generate and record a user callchain in response to a synchronous request, such as a tracepoint firing. If this happens under set_fs(KERNEL_DS), then we can end up walking the user stack (and dereferencing/saving whatever we find there) without the protections usually afforded by checks such as access_ok. Rather than play whack-a-mole with each architecture's stack unwinding implementation, fix the root of the problem by ensuring that we force USER_DS when invoking perf_callchain_user from the perf core. Reported-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-10drm/i915/gvt: avoid unnecessary vgpu switchPing Gao
It's no need to switch vgpu if next vgpu is the same with current vgpu, otherwise it will make performance drop in some case. v2: correct the comments. Signed-off-by: Ping Gao <ping.a.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-05-09Don't delay freeing mids when blocked on slow socket write of requestSteve French
When processing responses, and in particular freeing mids (DeleteMidQEntry), which is very important since it also frees the associated buffers (cifs_buf_release), we can block a long time if (writes to) socket is slow due to low memory or networking issues. We can block in send (smb request) waiting for memory, and be blocked in processing responess (which could free memory if we let it) - since they both grab the server->srv_mutex. In practice, in the DeleteMidQEntry case - there is no reason we need to grab the srv_mutex so remove these around DeleteMidQEntry, and it allows us to free memory faster. Signed-off-by: Steve French <steve.french@primarydata.com> Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
generated by cgit (git 2.34.1) at 2025-09-15 10:14:23 +0000