aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-10-09drm/i915: Remove wrong warning from i915_gem_context_cleanTvrtko Ursulin1-1/+1
commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae Author: Tvrtko Ursulin <[email protected]> Date: Mon Oct 5 13:26:36 2015 +0100 drm/i915: Clean up associated VMAs on context destruction Introduced a wrong assumption that all contexts have a ppgtt instance. This is not true when full PPGTT is not active so remove the WARN_ON_ONCE from the context cleanup code. Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Michel Thierry <[email protected]> Reviewed-by: Michel Thierry <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-09drm/i915: Determine the stolen memory base address on gen2Ville Syrjälä1-11/+81
There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable [ 0.000000] BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data [ 0.000000] BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen memory would start there would place it on top of some ACPI memory regions. So not a good idea as already stated. The 9MB region after the ACPI regions at 0x1f700000 however looks promising given that the macine reports the stolen memory size to be 8MB. Looking at the PGTBL_CTL register, the GTT entries are at offset 0x1fee00000, and given that the GTT entries occupy 128KB, it looks like the stolen memory could start at 0x1f700000 and the GTT entries would occupy the last 128KB of the stolen memory. After some more digging through chipset documentation, I've determined the BIOS first allocates space for something called TSEG (something to do with SMM) from the top of memory, and then it allocates the graphics stolen memory below that. Accordind to the chipset documentation TSEG has a fixed size of 1MB on 855. So that explains the top 1MB in the e820 region. And it also confirms that the GTT entries are in fact at the end of the the stolen memory region. Derive the stolen memory base address on gen2 the same as the BIOS does (TOM-TSEG_SIZE-stolen_size). There are a few differences between the registers on various gen2 chipsets, so a few different codepaths are required. 865G is again bit more special since it seems to support enough memory to hit 4GB address space issues. This means the PCI allocations will also affect the location of the stolen memory. Fortunately there appears to be the TOUD register which may give us the correct answer directly. But the chipset docs are a bit unclear, so I'm not 100% sure that the graphics stolen memory is always the last thing the BIOS steals. Someone would need to verify it on a real system. I tested this on the my 830 and 855 machines, and so far everything looks peachy. v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods v3: Fix TSEG size for 830 v4: Add missing 'else' (Chris) Tested-by: Chris Wilson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-09drm/i915: fix FBC buffer size checksPaulo Zanoni1-5/+14
According to my experiments (and later confirmation from the hardware developers), the maximum sizes mentioned in the specification delimit how far in the buffer the hardware tracking can go. And the hardware calculates the size based on the plane address we provide - and the provided plane address might not be the real x:0,y:0 point due to the compute_page_offset() function. On platforms that do the x/y offset adjustment trick it will be really hard to reproduce a bug, but on the current SKL we can reproduce the bug with igt/kms_frontbuffer_tracking/fbc-farfromfence. With this patch, we'll go from "CRC assertion failure" to "FBC unexpectedly disabled", which is still a failure on the test suite but is not a perceived user bug - you will just not save as much power as you could if FBC is disabled. v2, rewrite patch after clarification from the Hadware guys: - Rename function so it's clear what the check is for. - Use the new intel_fbc_get_plane_source_sizes() function in order to get the proper sizes as seen by FBC. v3: - Rebase after the s/sizes/size/ on the previous patch. - Adjust comment wording (Ville). - s/used_/effective_/ (Ville). Testcase: igt/kms_frontbuffer_tracking/fbc-farfromfence (SKL) Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-09drm/i915: fix CFB size calculationPaulo Zanoni1-5/+49
We were considering the whole framebuffer height, but the spec says we should only consider the active display height size. There were still some unclear questions based on the spec, but the hardware guys clarified them for us. According to them: - CFB size = CFB stride * Number of lines FBC writes to CFB - CFB stride = plane stride / compression limit - Number of lines FBC writes to CFB = MIN(plane source height, maximum number of lines FBC writes to CFB) - Plane source height = - pipe source height (PIPE_SRCSZ register) (before SKL) - plane size register height (PLANE_SIZE register) (SKL+) - Maximum number of lines FBC writes to CFB = - plane source height (before HSW) - 2048 (HSW+) For the plane source height, I could just have made our code do I915_READ() in order to be more future proof, but since it's not cool to do register reads I decided to just recalculate the values we use when we actually write to those registers. With this patch, depending on your machine configuration, a lot of the kms_frontbuffer_tracking subtests that used to result in a SKIP due to not enough stolen memory still start resulting in a PASS. v2: Use the clipped src size instead of pipe_src_h (Ville). v3: Use the appropriate information provided by the hardware guys. v4: Bikesheds: s/sizes/size/, s/fb_cpp/cpp/ (Ville). v5: - Don't use crtc->config->pipe_src_x for BDW- (Ville). - Fix the register name written in the comment. Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-09drm/i915: remove pre-atomic check from SKL update_primary_planePaulo Zanoni1-21/+13
The comment suggests the check was there for some non-fully-atomic case, and I couldn't find a case where we wouldn't correctly initialize plane_state, so remove the check. Let's leave a WARN there just in case. Signed-off-by: Paulo Zanoni <[email protected]> Acked-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-09drm/i915: don't allocate fbcon from stolen memory if it's too bigPaulo Zanoni2-2/+15
Technology has evolved and now we have eDP panels with 3200x1800 resolution. In the meantime, the BIOS guys didn't change the default 32mb for stolen memory. On top of that, we can't assume our users will be able to increase the default stolen memory size to more than 32mb - I'm not even sure all BIOSes allow that. So just the fbcon buffer alone eats 22mb of my stolen memroy, and due to the BDW/SKL restriction of not using the last 8mb of stolen memory, all that's left for FBC is 2mb! Since fbcon is not the coolest feature ever, I think it's better to save our precious stolen resource to FBC and the other guys. On the other hand, we really want to use as much stolen memory as possible, since on some older systems the stolen memory may be a considerable percentage of the total available memory. This patch tries to achieve a little balance using a simple heuristic: if the fbcon wants more than half of the available stolen memory, don't use stolen memory in order to leave some for FBC and the other features. The long term plan should be to implement a way to set priorities for stolen memory allocation and then evict low priority users when the high priority ones need the memory. While we still don't have that, let's try to make FBC usable with the simple solution. Cc: Chris Wilson <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-09drm: Fix locking for sysfs dpms fileDaniel Vetter1-9/+3
With atomic drivers we need to make sure that (at least in general) property reads hold the right locks. But the legacy dpms property is special and can be read locklessly. Since userspace loves to just randomly look at that all the time (like with "status") do that. To make it clear that we play tricks use the READ_ONCE compiler barrier (and also for paranoia). Note that there's not really anything bad going on since even with the new atomic paths we eventually end up not chasing any pointers (and hence possibly freed memory and other fun stuff). The locking WARNING has been added in commit 88a48e297b3a3bac6022c03babfb038f1a886cea Author: Rob Clark <[email protected]> Date: Thu Dec 18 16:01:50 2014 -0500 drm: add atomic properties but since drivers are converting not everyone will have seen this from the start. Jens reported this and submitted a patch to just grab the mode_config.connection_mutex, but we can do a bit better. v2: Remove unused variables I failed to git add for real. Reference: http://mid.gmane.org/[email protected] Reported-by: Jens Axboe <[email protected]> Tested-by: Jens Axboe <[email protected]> Cc: Rob Clark <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2015-10-09Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie18-59/+118
into drm-fixes radeon and amdgpu fixes for 4.3. Highlights: - Move pm sysfs setup later in the driver init process to avoid problems with laptop scripts attempting to change pm settings before the driver has finished setting up the pm hardware. - Fix console restore if a drm app (e.g. X) is forcibly killed - Flag iceland support as experimental for now - Misc bug fixes * 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: fix memory leak in amdgpu_vm_update_page_directory drm/amdgpu: fix 32-bit compiler warning drm/amdgpu: flag iceland as experimental drm/amdgpu: check before checking pci bridge registers drm/amdgpu: fix num_crtc on CZ drm/amdgpu: restore the fbdev mode in lastclose drm/radeon: restore the fbdev mode in lastclose drm/radeon: add quirk for ASUS R7 370 drm/amdgpu: add pm sysfs files late drm/radeon: add pm sysfs files late
2015-10-09crash in md-raid1 and md-raid10 due to incorrect list manipulationMikulas Patocka2-4/+4
The commit 55ce74d4bfe1b9444436264c637f39a152d1e5ac (md/raid1: ensure device failure recorded before write request returns) is causing crash in the LVM2 testsuite test shell/lvchange-raid.sh. For me the crash is 100% reproducible. The reason for the crash is that the newly added code in raid1d moves the list from conf->bio_end_io_list to tmp, then tests if tmp is non-empty and then incorrectly pops the bio from conf->bio_end_io_list (which is empty because the list was alrady moved). Raid-10 has a similar bug. Kernel Fault: Code=15 regs=000000006ccb8640 (Addr=0000000100000000) CPU: 3 PID: 1930 Comm: mdX_raid1 Not tainted 4.2.0-rc5-bisect+ #35 task: 000000006cc1f258 ti: 000000006ccb8000 task.ti: 000000006ccb8000 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00001000000001001111111000001111 Not tainted r00-03 000000ff0804fe0f 000000001059d000 000000001059f818 000000007f16be38 r04-07 000000001059d000 000000007f16be08 0000000000200200 0000000000000001 r08-11 000000006ccb8260 000000007b7934d0 0000000000000001 0000000000000000 r12-15 000000004056f320 0000000000000000 0000000000013dd0 0000000000000000 r16-19 00000000f0d00ae0 0000000000000000 0000000000000000 0000000000000001 r20-23 000000000800000f 0000000042200390 0000000000000000 0000000000000000 r24-27 0000000000000001 000000000800000f 000000007f16be08 000000001059d000 r28-31 0000000100000000 000000006ccb8560 000000006ccb8640 0000000000000000 sr00-03 0000000000249800 0000000000000000 0000000000000000 0000000000249800 sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 IASQ: 0000000000000000 0000000000000000 IAOQ: 000000001059f61c 000000001059f620 IIR: 0f8010c6 ISR: 0000000000000000 IOR: 0000000100000000 CPU: 3 CR30: 000000006ccb8000 CR31: 0000000000000000 ORIG_R28: 000000001059d000 IAOQ[0]: call_bio_endio+0x34/0x1a8 [raid1] IAOQ[1]: call_bio_endio+0x38/0x1a8 [raid1] RP(r2): raid_end_bio_io+0x88/0x168 [raid1] Backtrace: [<000000001059f818>] raid_end_bio_io+0x88/0x168 [raid1] [<00000000105a4f64>] raid1d+0x144/0x1640 [raid1] [<000000004017fd5c>] kthread+0x144/0x160 Signed-off-by: Mikulas Patocka <[email protected]> Fixes: 55ce74d4bfe1 ("md/raid1: ensure device failure recorded before write request returns.") Fixes: 95af587e95aa ("md/raid10: ensure device failure recorded before write request returns.") Signed-off-by: NeilBrown <[email protected]>
2015-10-08Revert "drm/i915: Call encoder hotplug for init and resume cases"Daniel Vetter2-11/+1
This reverts commit 5d250b05918c002b63632c7db91c3c5f924c6a3b. It results on a deadlock on platforms where we need to (at least partially) re-init hpd interrupts from power domain code, since ->hot_plug might again grab a power well reference (to do edid/dp_aux transactions. At least chv is affected. Reported-by: Ville Syrjälä <[email protected]> References: http://mid.gmane.org/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2015-10-08Revert "drm/i915: Add hot_plug hook for hdmi encoder"Daniel Vetter1-43/+11
This reverts commit 0b5e88dc25ee6c9040c0355e6e025dcbc9c8de92. It completely breaks booting on at least bsw (and maybe more). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88081 Signed-off-by: Daniel Vetter <[email protected]>
2015-10-08cpufreq: prevent lockup on reading scaling_available_frequenciesSrinivas Pandruvada1-1/+3
When scaling_available_frequencies is read on an offlined cpu, then either lockup or junk values are displayed. This is caused by freed freq_table, which policy is using. Signed-off-by: Srinivas Pandruvada <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-10-08cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpusSrinivas Pandruvada1-0/+3
When freqdomain_cpus attribute is read from an offlined cpu, it will cause crash. This change prevents calling cpufreq_show_cpus when policy driver_data is NULL. Crash info: [ 170.814949] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 [ 170.814990] IP: [<ffffffff813b2490>] _find_next_bit.part.0+0x10/0x70 [ 170.815021] PGD 227d30067 PUD 229e56067 PMD 0 [ 170.815043] Oops: 0000 [#2] SMP [ 170.816022] CPU: 3 PID: 3121 Comm: cat Tainted: G D OE 4.3.0-rc3+ #33 ... ... [ 170.816657] Call Trace: [ 170.816672] [<ffffffff813b2505>] ? find_next_bit+0x15/0x20 [ 170.816696] [<ffffffff8160e47c>] cpufreq_show_cpus+0x5c/0xd0 [ 170.816722] [<ffffffffa031a409>] show_freqdomain_cpus+0x19/0x20 [acpi_cpufreq] [ 170.816749] [<ffffffff8160e65b>] show+0x3b/0x60 [ 170.816769] [<ffffffff8129b31c>] sysfs_kf_seq_show+0xbc/0x130 [ 170.816793] [<ffffffff81299be3>] kernfs_seq_show+0x23/0x30 [ 170.816816] [<ffffffff81240f2c>] seq_read+0xec/0x390 [ 170.816837] [<ffffffff8129a64a>] kernfs_fop_read+0x10a/0x160 [ 170.816861] [<ffffffff8121d9b7>] __vfs_read+0x37/0x100 [ 170.816883] [<ffffffff813217c0>] ? security_file_permission+0xa0/0xc0 [ 170.816909] [<ffffffff8121e2e3>] vfs_read+0x83/0x130 [ 170.816930] [<ffffffff8121f035>] SyS_read+0x55/0xc0 ... ... [ 170.817185] ---[ end trace bc6eadf82b2b965a ]--- Signed-off-by: Srinivas Pandruvada <[email protected]> Acked-by: Viresh Kumar <[email protected]> Cc: 4.2+ <[email protected]> # 4.2+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-10-08mmc: sdhci-of-at91: use SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST quirk[email protected]1-0/+1
The Atmel sdhci device needs the SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST quirk. Without it, the internal clock could never stabilised when changing the sd clock frequency. Signed-off-by: Ludovic Desroches <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-10-08mmc: sdhci: add quirk SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST[email protected]2-0/+7
The Atmel sdhci device needs a new quirk. sdhci_set_clock set the Clock Control Register to 0 before computing the new value and writing it. It disables the internal clock which causes a reset mecanism. If we write the new value before this reset mecanism is done, it will prevent the stabilisation of the internal clock, so a delay is needed. This delay is about 2-3 cycles of the base clock. To be safe, a 1 ms delay is used. Signed-off-by: Ludovic Desroches <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-10-08mmc: sdhci-pxav3: fix error handling of armada_38x_quirksMarcin Wojtas1-1/+1
In case of armada_38x_quirks error, all clocks should be cleaned-up, same as after mv_conf_mbus_windows failure. Signed-off-by: Marcin Wojtas <[email protected]> Cc: <[email protected]> # v4.2 Reviewed-by: Gregory CLEMENT <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-10-08mmc: sdhci-pxav3: disable clock inversion for HS MMC cardsNadav Haklai1-0/+3
According to 'FE-2946959' erratum the clock inversion option is needed to support slow frequencies when the card input hold time requirement is high. This setting is not required for high speed MMC and might cause timing violation. Signed-off-by: Nadav Haklai <[email protected]> Cc: <[email protected]> # v4.2 Reviewed-by: Gregory CLEMENT <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-10-08mmc: sdhci-pxav3: remove broken clock base quirk for Armada 38x sdhci driverNadav Haklai1-0/+1
shci-pxav3 driver is enabling by default the SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN quirk. However this quirk is not required for Armada 38x and leads to wrong clock setting in the divider. Signed-off-by: Nadav Haklai <[email protected]> Signed-off-by: Marcin Wojtas <[email protected]> Cc: <[email protected]> # v4.2 Reviewed-by: Gregory CLEMENT <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-10-08drm/amdgpu: fix memory leak in amdgpu_vm_update_page_directorySudip Mukherjee1-1/+3
If amdgpu_ib_get() fails we returned the error code but we missed freeing ib. Cc: "Christian König" <[email protected]> Cc: Jammy Zhou <[email protected]> Cc: Chunming Zhou <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "monk.liu" <[email protected]> Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-10-08arch/powerpc: provide zero_bytemask() for big-endianChris Metcalf1-0/+5
For some reason, only the little-endian flavor of powerpc provided the zero_bytemask() implementation. Reported-by: Michal Sojka <[email protected]> Acked-by: Michael Ellerman <[email protected]> Signed-off-by: Chris Metcalf <[email protected]>
2015-10-08drm/i915: use error pathSudip Mukherjee1-9/+14
Use goto to handle the error path to avoid duplicating the same code. In the error path intel_dig_port is the last one to be released as it was the first one to be allocated and ideally the error path should be the reverse of the execution path. Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-08drm/i915/irq: Fix misspelled word register in kernel-docJavier Martinez Canillas1-1/+1
There is a typo in the function i915_handle_error() kernel-doc and the word register is spelled wrongly. Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-08drm/i915/irq: Fix kernel-doc warningsJavier Martinez Canillas1-0/+2
Add the dev parameter for the functions i915_enable_asle_pipestat() and i915_reset_and_wakeup() to the kernel-doc to fix the following warnings: .//drivers/gpu/drm/i915/i915_irq.c:586: warning: No description found for parameter 'dev' .//drivers/gpu/drm/i915/i915_irq.c:2400: warning: No description found for parameter 'dev' Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-08mmc: host: omap_hsmmc: Fix MMC for omap3 legacy bootingTony Lindgren1-3/+3
Starting with commit 7d607f917008 ("mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc") MMC on omap3 stopped working for legacy booting. This is because legacy booting sets up some of the resource in the platform init code, and for optional regulators always seem to return -EPROBE_DEFER for the legacy booting. Let's fix the issue by checking for device tree based booting for now. Then when omap3 boots in device tree only mode, this patch can be just reverted. Fixes: 7d607f917008 ("mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc") Cc: Felipe Balbi <[email protected]> Cc: Kishon Vijay Abraham I <[email protected]> Cc: Nishanth Menon <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Tested-by: Russell King <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-10-08Revert "mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status"Tony Lindgren1-2/+6
This reverts commit c55d7a0553643a7e8f120688b82b594471084d3c. Without reverting this commit we get "unbalanced disables for pbias_mmc_omap4" errors on omap4430. It seems that 4430 and 4460 behave in a different way for the PBIAS regulator registers and until that has been debugged further we cannot rely on the regulator status registers in hardare on 4430. Fixes: 7d607f917008 ("mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc") Cc: Felipe Balbi <[email protected]> Cc: Kishon Vijay Abraham I <[email protected]> Cc: Nishanth Menon <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Tested-by: Russell King <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-10-07drm/amdgpu: disable hw semaphores by defaultAlex Deucher1-2/+2
These are buggy on some asics and not really used anymore now that the GPU schedular is enabled. Change-Id: I67182b409d64de308392a15d1a0a15018071dc0b Signed-off-by: Alex Deucher <[email protected]>
2015-10-07drm/amdgpu: enable scheduler by defaultChunming Zhou1-2/+2
Change-Id: Idce64f63e8422324996fc5d583d0bc9a5ac60d0c Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Jammy Zhou <[email protected]> Reviewed-by: Christian König <[email protected]>
2015-10-07drm/amdgpu: add TOPDOWN flag to the whole vramChunming Zhou1-0/+2
need to decrease visible vram usage by default. Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: monk.liu <[email protected]> Reviewed-by: Christian König <[email protected]>
2015-10-07drm/amdgpu: add vram usage into debugfsChunming Zhou1-0/+5
Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Jammy Zhou <[email protected]> Reviewed-by: Christian König <[email protected]>
2015-10-07drm/amdgpu: split gfx8 gpu init into sw and hw partsAlex Deucher1-190/+197
Calculate the driver state in sw_init and program the registers in hw init. Acked-by: Leo Liu <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-10-07swiotlb: Enable it under x86 PAEChristian Melki1-0/+1
Most distributions end up enabling SWIOTLB already with 32-bit kernels due to the combination of CONFIG_HYPERVISOR_GUEST|CONFIG_XEN=y as those end up requiring the SWIOTLB. However for those that are not interested in virtualization and run in 32-bit they will discover that: "32-bit PAE 4.2.0 kernel (no IOMMU code) would hang when writing to my USB disk. The kernel spews million(-ish messages per sec) to syslog, effectively "hanging" userspace with my kernel. Oct 2 14:33:06 voodoochild kernel: [ 223.287447] nommu_map_sg: overflow 25dcac000+1024 of device mask ffffffff Oct 2 14:33:06 voodoochild kernel: [ 223.287448] nommu_map_sg: overflow 25dcac000+1024 of device mask ffffffff Oct 2 14:33:06 voodoochild kernel: [ 223.287449] nommu_map_sg: overflow 25dcac000+1024 of device mask ffffffff ... etc ..." Enabling it makes the problem go away. N.B. With a6dfa128ce5c414ab46b1d690f7a1b8decb8526d "config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected" we also have the important part of the SG macros enabled to make this work properly - in case anybody wants to backport this patch. Reported-and-Tested-by: Christian Melki <[email protected]> Signed-off-by: Christian Melki <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
2015-10-07Merge tag 'asoc-fix-v4.3-rc4' of ↵Takashi Iwai696-4157/+7399
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.3 Quite a few fixes here but they're all very small and driver specific, none of them really stand out if you aren't using the relevant hardware but they're all useful if you do happen to have an affected device.
2015-10-073w-9xxx: don't unmap bounce buffered commandsChristoph Hellwig1-7/+21
3w controller don't dma map small single SGL entry commands but instead bounce buffer them. Add a helper to identify these commands and don't call scsi_dma_unmap for them. Based on an earlier patch from James Bottomley. Fixes: 118c85 ("3w-9xxx: fix command completion race") Reported-by: Tóth Attila <[email protected]> Tested-by: Tóth Attila <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Acked-by: Adam Radford <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2015-10-07Merge tag 'arm64-fixes' of ↵Linus Torvalds4-14/+18
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "This addresses a couple of issues found with RT, a broken initrd message in the console log and a simple performance fix for some MMC workloads. Summary: - A couple of locking fixes for RT kernels - Avoid printing bogus initrd warnings when initrd isn't present - Performance fix for random mmap file readahead - Typo fix" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: replace read_lock to rcu lock in call_break_hook arm64: Don't relocate non-existent initrd arm64: convert patch_lock to raw lock arm64: readahead: fault retry breaks mmap file read random detection arm64: debug: Fix typo in debug-monitors.c
2015-10-07Merge tag 'fbdev-fixes-4.3' of ↵Linus Torvalds7-8/+26
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux Pull fbdev fixes from Tomi Valkeinen: - fbdev: Minor fixes to broadsheetfb, fsl-diu-fb, mb862xxfb, tridentfb, omapfb - display-timing: Fix memory leak in error path * tag 'fbdev-fixes-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: video: of: fix memory leak fbdev: broadsheetfb: fix memory leak OMAPDSS: panel-sony-acx565akm: Export OF module alias information fbdev: omap2: connector-dvi: use of_get_i2c_adapter_by_node interface tridentfb: Fix set_lwidth on TGUI9440 and CYBER9320 tridentfb: fix hang on Blade3D with CONFIG_CC_OPTIMIZE_FOR_SIZE video: fbdev: mb862xx: Fix module autoload for OF platform driver video: fbdev: fsl: Fix the sleep function for FSL DIU module
2015-10-07Merge tag 'perf-urgent-for-mingo' of ↵Ingo Molnar3-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fix from Arnaldo Carvalho de Melo: - Fix build break on (at least) powerpc due to sample_reg_masks, not being available for linking. (Sukadev Bhattiprolu) Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2015-10-07Merge remote-tracking branches 'asoc/fix/tlv320aic3x' and 'asoc/fix/wm8962' ↵Mark Brown2-9/+15
into asoc-linus
2015-10-07Merge remote-tracking branches 'asoc/fix/db1200', 'asoc/fix/dwc', ↵Mark Brown8-38/+43
'asoc/fix/imx-ssi', 'asoc/fix/maintainers', 'asoc/fix/rt5645', 'asoc/fix/sgtl5000' and 'asoc/fix/tas2552' into asoc-linus
2015-10-07drm/i915: Hook up ring workaround writes at context creation time on Gen6-7.Francisco Jerez1-1/+1
intel_rcs_ctx_init() emits all workaround register writes on the list to the ring, in addition to calling i915_gem_render_state_init(). The workaround list is currently empty on Gen6-7 so this shouldn't cause any functional changes. Signed-off-by: Francisco Jerez <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915: Don't warn if the workaround list is empty.Francisco Jerez1-1/+1
It's not an error for the workaround list to be empty if no workarounds are needed. This will avoid spamming the logs unnecessarily on Gen6 after the workaround list is hooked up on pre-Gen8 hardware by the following commits. Signed-off-by: Francisco Jerez <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915: Resurrect golden context on gen6/7Daniel Vetter1-0/+1
In commit 8f0e2b9d95a88ca5d8349deef2375644faf184ae Author: Daniel Vetter <[email protected]> Date: Tue Dec 2 16:19:07 2014 +0100 drm/i915: Move golden context init into ->init_context I've shuffled around per-ctx init code a bit for legacy contexts but accidentally dropped the render state init call on gen6/7. Resurrect it. Reported-by: Francisco Jerez <[email protected]> Cc: Francisco Jerez <[email protected]> Cc: Dave Gordon <[email protected]> Cc: Thomas Daniel <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915/chv: remove pre-production hardware workaroundsJani Nikula1-34/+22
Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> [danvet: Appease gcc and remove the unused variable.] Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915/snb: remove pre-production hardware workaroundJani Nikula1-17/+1
Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm: Stop using drm_vblank_count() as the hw frame counterVille Syrjälä15-13/+31
drm_vblank_count() returns the software counter. We should not pretend it's the hw counter since we use the hw counter to figuere out what the software counter value should be. So instead provide a new function drm_vblank_no_hw_counter() for drivers that don't have a real hw counter. The new function simply returns 0, which is about the only thing it can do. Cc: Vincent Abriou <[email protected]> Cc: Thierry Reding <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Vincent Abriou <[email protected]> [danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface change.] Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915/bxt: Set time interval unit to 0.833usAkash Goel1-1/+4
Note that in Bspec you have to dig around in a section called "Timestamp bases" and Bspec update request is filed. Signed-off-by: Ankitprasad Sharma <[email protected]> Signed-off-by: Akash Goel <[email protected]> Signed-off-by: Sagar Arun Kamble <[email protected]> Reviewed-by: Imre Deak <[email protected]> [danvet: Add note about state of Bspec.] Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915: Kill DRI1 cliprectsChris Wilson2-138/+31
Passing cliprects into the kernel for it to re-execute the batch buffer with different CMD_DRAWRECT died out long ago. As DRI1 support has been removed from the kernel, we can now simply reject any execbuf trying to use this "feature". To keep Daniel happy with the prospect of being able to reuse these fields in the next decade, continue to ensure that current userspace is not passing garbage in through the dead fields. v2: Fix the cliprects_ptr check Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Dave Gordon <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915: Avoid GPU stalls from kswapdChris Wilson2-2/+8
Exclude active GPU pages from the purview of the background shrinker (kswapd), as these cause uncontrollable GPU stalls. Given that the shrinker is rerun until the freelists are satisfied, we should have opportunity in subsequent passes to recover the pages once idle. If the machine does run out of memory entirely, we have the forced idling in the oom-notifier as a means of releasing all the pages we can before an oom is prematurely executed. Note that this relies upon an up-front retire_requests to keep the inactive list in shape, which was added in a previous patch, mostly as execlist ctx pinning band-aids. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> [danvet: Add note about retire_requests.] Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915: Remove dead i915_gem_evict_everything()Chris Wilson2-46/+0
With UMS gone, we no longer use it during suspend. And with the last user removed from the shrinker, we can remove the dead code. Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915: During shrink_all we only need to idle the GPUChris Wilson1-1/+3
We can forgo an evict-everything here as the shrinker operation itself will unbind any vma as required. If we explicitly idle the GPU through a switch to the default context, we not only create a request in an illegal context (e.g. whilst shrinking during execbuf with a request already allocated), but switching to the default context will not free up the memory backing the active contexts - unless in the unlikely situation that context had already been closed (and just kept arrive by being the current context). The saving is near zero and the danger real. To compensate for the loss of the forced retire, add a couple of retire-requests to i915_gem_shirnk() - this should help free up any transitive cache from the requests. Note that the second retire_requests is for the benefit of the hand-rolled execlist ctx active tracking: We need to manually kick requests to get those unpinned again. Once that's fixed we can try to remove this again. Signed-off-by: Chris Wilson <[email protected]> [danvet: Add summary of why we need a pile of retire_requests.] Signed-off-by: Daniel Vetter <[email protected]>
2015-10-07drm/i915: Add a tracepoint for the shrinkerChris Wilson2-0/+22
Often it is very useful to know why we suddenly purge vast tracts of memory and surprisingly up until now we didn't even have a tracepoint for when we shrink our memory. Note that there are slab_start/end tracepoints already, but those don't cover the internal recursion when we directly call into our shrinker code. Hence a separate tracepoint seems justified. Also note that we don't really need a separate tracepoint for the actual amount of pages freed since we already have an unbind tracpoint for that. Signed-off-by: Chris Wilson <[email protected]> [danvet: Add a note that there's also slab_start/end and why they're insufficient.] Signed-off-by: Daniel Vetter <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.