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ä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <paulo.r.zanoni@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 88a48e297b
Author: Rob Clark <robdclark@gmail.com>
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/20150928194822.GA3930@kernel.dk
Reported-by: Jens Axboe <axboe@fb.com>
Tested-by: Jens Axboe <axboe@fb.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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
The commit 55ce74d4bf (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 <mpatocka@redhat.com>
Fixes: 55ce74d4bf ("md/raid1: ensure device failure recorded before write request returns.")
Fixes: 95af587e95 ("md/raid10: ensure device failure recorded before write request returns.")
Signed-off-by: NeilBrown <neilb@suse.com>
This reverts commit 5d250b0591.
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ä <ville.syrjala@linux.intel.com>
References: http://mid.gmane.org/20151008133548.GX26517@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
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 <srinivas.pandruvada@linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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 <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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 <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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 <mw@semihalf.com>
Cc: <stable@vger.kernel.org> # v4.2
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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 <nadavh@marvell.com>
Cc: <stable@vger.kernel.org> # v4.2
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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 <nadavh@marvell.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Cc: <stable@vger.kernel.org> # v4.2
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For some reason, only the little-endian flavor of
powerpc provided the zero_bytemask() implementation.
Reported-by: Michal Sojka <sojkam1@fel.cvut.cz>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
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 <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <javier@osg.samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <javier@osg.samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Starting with commit 7d607f9170 ("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: 7d607f9170 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc")
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit c55d7a0553.
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: 7d607f9170 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc")
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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 <alexander.deucher@amd.com>
need to decrease visible vram usage by default.
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: monk.liu <monk.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Calculate the driver state in sw_init and program the
registers in hw init.
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
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 a6dfa128ce
"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 <christian.melki@t2data.com>
Signed-off-by: Christian Melki <christian.melki@t2data.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWFTcnAAoJECTWi3JdVIfQATYH+wSTTl5PecusiHmrb3kS08V7
Ka7EgqP+PyPRh4QxqxA+fBQJOcbiD42I1FzYyj16INmaDP10AE2fNc/Q1xSmFVRd
6iJl7mKlJqNgYmORWFynlrnrPVipJIBmS5SXt9z3GeRo6jhJk5G3UiJkA+WkKzDN
r+3ASeEdZHeLKj5zeAPsY0KTMOaBskpSVFer5g7kQE5+naYFOzXJ4NsivjML2cge
TH/8Ef22oJi8FNtfFCnz8hTMKFo0mnBYbjmZZcwhj0/Ne0yeJhE0VOaZroaS2Ec2
VjvKcA5pWPAAbsZtjO1A2x35V3oy5T4N8HsiQfvuJ5+6rSNpsJ2V8qXCSl7RTCw=
=4n+5
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v4.3-rc4' of 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.
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 <atoth@atoth.sote.hu>
Tested-by: Tóth Attila <atoth@atoth.sote.hu>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJWFO+aAAoJELescNyEwWM0z14IALpleyenZXl+xqxMjNyOXouG
/2SbTZH7iD/vnfCL6G7/Poq00I2ghtBSRFGXajfg7V0mjH1HTfVXVN19IXaUUwjW
IfAMqSyC43dDBdsGn3A1ZqPRNk+chxjwz7zimGqPowuM87C4aj/sqetBSnuybZtB
lSYfCFGpDj8cpsJ0xwYYhuq8xUgixQMslTj+rVAFtfsLkDHUu175l+vP7t2xOv5v
bmyPlz15O/v9febnLYFVFPWZB2IWfvaFkR30qUGsMe6BGWdGDe/RGUPksZDLlPdL
Yj4AKq+9Bx0lPvO+vNEqfvScKdVjMpttVEMfi2cQ8kUbD1rRPZ7ZTHsfcEOuB1w=
=Zi+I
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of 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
* fbdev: Minor fixes to broadsheetfb, fsl-diu-fb, mb862xxfb, tridentfb, omapfb
* display-timing: Fix memory leak in error path
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWFQlvAAoJEPo9qoy8lh711iYQAK4tBVPRPRPgNFkCWfeqaRvd
UvJcLrsVddmwFqQj+CW+PxHWqhFEcSRFaaJmWirBAtumGCAYxy2BeFjY6H32JzvK
tFVIwt1GuaO+89d3xq6AuvamiH9X4pPuu/bVfIWAP4hfpKsuKAQ+UtdPHRsRTkBe
2PVKLc4ghxPMnp0XdcDYRmJ0RrejctISmmelScc6waqhRC8+bnEcVZB5CP/N8iM9
+PvoxmS2e7Cn6ZxMMqSrEsFwpqtxuUhzrIEVrcbfAnymp37uiKai76FJe1JEev3T
gXnqXAsfMbdNjtVpHQVeb3B43ZsslEruXOQZHyhW9CH2+7QgOsVfE9PDyIEDxM+9
UZH8jLwh0EhLhnfBMBmeUmy9mQXXUhyQ5qBXJ4ubBc304tS/2LnVvh507WbzKEhY
2gk0ZmqsSzpn1+NoZ0HEkZM1toG7sWEo/KuYehyifzNrPikG6jzPqbdF64ZED5Ev
mS+fOfIus4vCXX/7cf4waDXzOhlZl+arAEOM1+FK9bE80JPZnK1xZQain7wrPSHR
uaM5AAtbPSVj3w5lk1ntY7ck/2R+DRKjwVGr8Qm7EdWnE5LQcUrS619q77Y9NJ7r
sqnfMToKarqAnfcU/4sQ2ObV8nfhsZQimeffOBVRnbMlRIo7aD+d+n4WXAICNvH+
3A/vqTo/pbWL9TBXce/E
=hZoA
-----END PGP SIGNATURE-----
Merge tag 'fbdev-fixes-4.3' of 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
- 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 <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWFTzLAAoJENZQFvNTUqpAUTEP+QGYUnFGpm9SYiEr94uzbPqe
OlyC3TVtMbwv332fscauXpMGc95nyfvIauXakfHQSqAd04XA9abltPXVzHRrPi/S
QyTb2NNWSSvb2fLXZL113HInrq11GJlhMepVbEXij3qCg6Bl3kSksBmdUkiolhir
ZtyQ2gxsm3s+T25voupKlvBm/Y3zpM2FBa7dmdFqYqyViIBa1LxDbwaEmj5wwBqF
BPtqVNbISgVGJpZud4vRAVaOxDlCA9FrdzeBVSB3guV65yn2GA499zy5VxVXiY+/
FanzwAyg5ZKSWaGASvqVzjx8pXlRFDCkVzvRjaqu+6/iNz2JSDNMiyZSxX4NrrGJ
htlwQKcTaRFrgD62AYBdpNX0QJKP2c5PUJEOJdbXuXli+B5gmLMMjLwdrKYWiE03
zJql6wpaUilJwCRD9RIjYROQS8ttDy62IdqML8g/KzNcaDxxeMPaTKhYNdwfT06G
JTx/Z8npYsK6a9uq4O9d3Wl359KqOAikFFjL+wbx/0A6Bryfev/0X6jMf1dx6/19
u50vJP8ou0DRmoWDPwPkrCOpkkghiauz2gQtrlU0VseXttPetLzYaqAosHkjYD7i
yBRrg7pb0Nxy8SJAVfgZ4ctU2OK0KEK+Qz/d4+8crcia166j9RDvcwM6Vj78QsbR
FhNyWt85UvATPTVBTXQ6
=Dr5G
-----END PGP SIGNATURE-----
Merge tag 'perf-urgent-for-mingo' of 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 <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
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 <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In
commit 8f0e2b9d95
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <currojerez@riseup.net>
Cc: Francisco Jerez <currojerez@riseup.net>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Appease gcc and remove the unused variable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <vincent.abriou@st.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
[danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface
change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <ankitprasad.r.sharma@intel.com>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Add note about state of Bspec.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Add note about retire_requests.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <chris@chris-wilson.co.uk>
[danvet: Add summary of why we need a pile of retire_requests.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <chris@chris-wilson.co.uk>
[danvet: Add a note that there's also slab_start/end and why they're
insufficient.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add the item of i915_component.h in DocBook and add the DOC for
i915_component.h. Explain the struct i915_audio_component_ops and
struct i915_audio_component_audio_ops usage.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add the kerneldoc for i915_audio_component in i915_component.h
Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
