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>
Pull in the i915/hda changes for N/CTS setting so I can apply the
follow-up documentation work for drm/i915.
Some conflicts because ofc we had to rework i915 while that N/CTS work
was going on. But not more than adjacent changes really.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
As the shrinker_control now passes us unsigned long targets, update our
shrinker functions to match.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've botched this, so let's fix it.
Botched in
commit eb0b44adc0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 18 14:47:59 2015 +0100
drm/i915: kerneldoc for i915_gem_shrinker.c
v2: Be a good citizen^Wmaintainer and add the proper commit citation.
Noticed by Jani.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The new amdgpu driver passes a user space pointer in a 64-bit structure
member, which is the correct way to do it, but it attempts to
directly cast it to a __user pointer in the kernel, which causes
a warning in three places:
drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_init':
drm/amd/amdgpu/amdgpu_cs.c:180:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
chunk_array_user = (uint64_t __user *)(cs->in.chunks);
This changes all three to add an intermediate cast to 'unsigned long'
as other drivers do. This avoids the warning and works correctly on
both 32-bit and 64-bit architectures.
Fixes: e60b344f6c ("drm/amdgpu: optimize amdgpu_parser_init")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
perf_regs.c does not get built on Powerpc as CONFIG_PERF_REGS is false.
So the weak definition for 'sample_regs_masks' doesn't get picked up.
Adding perf_regs.o to util/Build unconditionally, exposes a redefinition
error for 'perf_reg_value()' function (due to the static inline version
in util/perf_regs.h). So use #ifdef HAVE_PERF_REGS_SUPPORT' around that
function.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: linuxppc-dev@ozlabs.org
Link: http://lkml.kernel.org/r/20150930182836.GA27858@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
A couple of fixes for the debugfs information on the register map,
fixing issues with very small reads potentially causing underflows and
wraparounds.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWFPtTAAoJECTWi3JdVIfQlRUH/1j/cFl0+eDBnjQjg25+bMOn
HhGQtxcGlOXIwDzRc7vCzuH8RjqJnY6jLlYzAjbYiIEoRAHVOEtWZCeSMN8bTfaK
lUe2XN6TLrAweJYP+LC+NoIXKzW4jUDXG3ZqhkRllsnn9eoLsIFBxBV+E5jS4LNo
8AFMfdlzbKaEIrAu9w6c5pHmgwacyXETOKej+GuJ/RP6a5SRPAS1FWCznLc8gY7n
NBh+vMeYdtRV57PpXxVa/sAFjqkglwXhf4C7Gkhcv5Ecu4utf5LqL3w9i5Al5Rmz
5DxO3JaFdK4ae74wdo8iCFddXJBu+TiB9UB6mvhrZ63W8ECw3xjcE4PcYuL3BN0=
=QeA5
-----END PGP SIGNATURE-----
Merge tag 'regmap-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"A couple of fixes for the debugfs information on the register map,
fixing issues with very small reads potentially causing underflows and
wraparounds"
* tag 'regmap-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: debugfs: Don't bother actually printing when calculating max length
regmap: debugfs: Ensure we don't underflow when printing access masks
A couple of very minor fixes, one for error handling in the Davinci
driver probe function and another making the Renesas sh-msiof DT binding
documentation correspond to what's actually implemented.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWFPjZAAoJECTWi3JdVIfQvWcH/0aOEA6dcgurWr4IlWpI9vS0
ueMrT3CEDwyJOhkizxMTQSDs7K01OGOag1Dq6nZm2k38niFD7CeUU6iNXZrKoTXf
TSBiqgRitZ5HnpYJhYz/HP8HTktAZVuFaTD2IpSX6+gqiTinIYKVX4MrnZmIcRjR
uGXosAd2n3552hXjcDVOuRlmvjmd30wP96/hc0/24yfrehEcBoksM4dgnpMDC5d4
OQaP6Y8ZXkqeYYrL+xN4i6w9wwTdt+Io+7cYZoRVKJ3+CB9jHAnONRJzTPqRWEDz
vhOA2/fHmvLierP1JySz1CZzYdVekVpPYsobmsYHKddoLXBLvlaYWJajj1kTMlc=
=RMP1
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A couple of very minor fixes, one for error handling in the Davinci
driver probe function and another making the Renesas sh-msiof DT
binding documentation correspond to what's actually implemented"
* tag 'spi-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: sh-msiof: Match renesas,rx-fifo-size in DT bindings doc with driver
spi: davinci: fix handling platform_get_irq result
Two fixes here, one device specific fix for axp20x and a core fix for
cases where one regulator is supplying another which broke probe
deferral, substituting in a dummy regulator too aggressively.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWFO2YAAoJECTWi3JdVIfQl6YH/iBuGvFaDNJn6qBI1/qae9KO
HQYWda7fVKB8l/4aotV4tfzW0ikIDMeIzSzvekpZK6SKgVnKAr3dzKLL3tkDT9IE
tl5ibs5nJOynGk30liVSALfUFU2IPqV0ikNQxbhBq13mIR9YJinFuow8kcCAWoSj
BJUIE/cp6fHoDXWMqJDETCBtwERBmU7VZ6WWhaZZKTrmMzM0zdfNyjisrOTx+Npm
k2+4zAs8ep7MCn0Q9V4Q+DdNOq3zZPcMjx6yMLZt71pJBiG+TP/wK89AIAq7vyjk
y5qUqdFBN/4cvtmLCLI4F9lThSBgRHLSl1NOJc9TWQgu/xT8YEmK2xqE9J+cyLQ=
=xZTQ
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"Two fixes here, one device specific fix for axp20x and a core fix for
cases where one regulator is supplying another which broke probe
deferral, substituting in a dummy regulator too aggressively"
* tag 'regulator-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Handle probe deferral from DT when resolving supplies
regulator: axp20x: Fix enable bit indexes for DCDC4 and DCDC5
If of_parse_display_timing() fails we are printing an error message and
jumping to the error path but we missed freeing "dt".
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Pull strscpy fixes from Chris Metcalf :
"This patch series fixes up a couple of architecture issues where
strscpy wasn't configured correctly (missing on h8300, duplicating
local and asm-generic copies on powerpc and tile).
It also adds a use of zero_bytemask() to the final store for strscpy
to avoid writing uninitialized data to the destination. However, to
make this work we had to add support for zero_bytemask() to the two
architectures that didn't have it (alpha and tile), because they were
providing their own local copies, but didn't provide the
zero_bytemask() that was previously only required when building with
CONFIG_DCACHE_WORD_ACCESS"
[ Side note: there is still no actual users of strscpy except for the
one preexisting use in arch/tile that predates the generic version.
So this is all about fixing the infrastructure so that we eventually
can start using it. - Linus ]
* 'strscpy' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
strscpy: zero any trailing garbage bytes in the destination
word-at-a-time.h: support zero_bytemask() on alpha and tile
word-at-a-time.h: fix some Kbuild files
* mxc_nand: a "refactoring only" change in 4.3-rc1 had some bad pointer
(array) arithmetic. Fix that
* sunxi_nand:
- Fix an old list manipulation / memory management bug in the device
release() code path
- Correct a few mistakes in OOB write support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJWFALTAAoJEFySrpd9RFgt6gIP/in7Zl3mpVZi3D36ui6+EIiF
cHSLItczBtUg5JrE3gm7RzXsOI8CE/ExvN0Yqc1uHM5EDHZWHWIKlRxdD9CrhIv8
srM2icbG4AJBeiizCuufok3/nOMjt5azHX6RdDA2BClYP2T5GH/CthJabfTHRpqb
yhDs7WRAbS7jPhmLe0rl3yTBnMnY798bzzo7VQD0g95lgOU4K2Wj78NyuMx5NSsK
l8mH0GuNne7cHCh1z4HSiSzSyJQoTnjhd8sA1B/39t/V89EHm87P7iYN4NQ7zayK
vq9GEOrm1/jVDCPxGihJkt3jkt4QmnQeU8z+Ne42muySvvP+eXpihfX/xSstBYQl
QsTX/odoU7UpBwy9gd3dO/2o5s/+/E16VtEKEWJfExVaRHwhSmrBY/aSAnzGMomh
JSwOkgI5r/hToDB+sQ9/MANwQ1kq1gZIIzaANkdK+rm0x0HuVh3ODZYC3xBexgdf
5FVAaLhxMQaFhGv7JGgL5aPZAZzboUn0awmMBdiH5JWA5hCuCEUkyN6ggcTqvJlM
wxS4lkofpnEfTVNiOjitS+nPnXj8Vn3OB5fKUoPe0u33GZuJraq+OW6gCgSZtSWp
+cOxC1WiREOkxei6+MiR5eOF2kU4uZUGjUeZeNs1QdXUNkSTX66DtmT/ep6WrtVi
aDI1fczLhpi966uI05gw
=A7qE
-----END PGP SIGNATURE-----
Merge tag 'for-linus-20151006' of git://git.infradead.org/linux-mtd
Pull MTD fixes from Brian Norris:
"A few MTD fixes:
- mxc_nand: a "refactoring only" change in 4.3-rc1 had some bad
pointer (array) arithmetic. Fix that
- sunxi_nand:
- Fix an old list manipulation / memory management bug in the device
release() code path
- Correct a few mistakes in OOB write support"
* tag 'for-linus-20151006' of git://git.infradead.org/linux-mtd:
mxc_nand: fix copy_spare
mtd: nand: sunxi: fix sunxi_nand_chips_cleanup()
mtd: nand: sunxi: fix OOB handling in ->write_xxx() functions
Highlights include:
Bugfixes:
- Fix a use-after-free bug in the RPC/RDMA client
- Fix a write performance regression
- Fix up page writeback accounting
- Don't try to reclaim unused state owners
- Fix a NFSv4 nograce recovery hang
- reset states to use open_stateid when returning delegation voluntarily
- Fix a tracepoint NULL-pointer dereference
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWFIgBAAoJEGcL54qWCgDy3qwQAJrMvwiO0shZe9+PsUZcDIhw
1CnDmWYafJmpNGK+YEZatI+tdR9pwSYXdfiCGj/Ijfvl1PXUgyVAmNARAB9oFUza
DVvZjqJ6aiFzeawGC8f2IfwY4XcAy4+BIZOiwp2JafepRnoSgZl24olKbO4cQ7UD
i5IaDrYYvAxefsUoRogEF19H1y8zC1yUA2aDKrriV6A9rEZSbaZLRfS8BHppXBjY
w0OP74neD4rnn/rL0YDEdsjiI17W7QwoMk05yzOJH3wQt/Y4Ll/lwLO4y3URpIGF
wzHzMIeggGPPEM9e1JixPc3Y9F9kCHW8YjGJ3xxY2C6q8vt7dzpaVhh10AxycZtZ
gcbepjMhoL7gJqu5DQ/0S86Sb5jNaL0KlUDsEnqtOfe3/UiyTJ/f57TMfdscm+wI
pdyFFtxUHcFueO1a2XuEOuSIUFzFuwIQ2aiHlbu90ev04dd7dqzU0PffhRlzu3tJ
8+ZHQMbSmotUmhxlpI+VA4rG0JUsaLY09chH5r0NvsXm0LR+z3vX7Q6oONN7IBDv
5hULj4ecB69smBv+FjQyVUAu0LiahINAGu0p0wEjTdBwFMic5qpVVfhTs8qrkGRZ
M8RYrANtVhY17fJf5WF7Wyt58icAWRKDHslGdzUav+2VFBfNK1ZeG+QhYYqDNF5k
SkJsG4iCIN9JazwqfqJI
=aoNS
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-4.3-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client bugfixes from Trond Myklebust:
"Highlights include:
Bugfixes:
- Fix a use-after-free bug in the RPC/RDMA client
- Fix a write performance regression
- Fix up page writeback accounting
- Don't try to reclaim unused state owners
- Fix a NFSv4 nograce recovery hang
- reset states to use open_stateid when returning delegation
voluntarily
- Fix a tracepoint NULL-pointer dereference"
* tag 'nfs-for-4.3-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
NFS: Fix a tracepoint NULL-pointer dereference
nfs4: reset states to use open_stateid when returning delegation voluntarily
NFSv4: Fix a nograce recovery hang
NFSv4.1: nfs4_opendata_check_deleg needs to handle NFS4_OPEN_CLAIM_DELEG_CUR_FH
NFSv4: Don't try to reclaim unused state owners
NFS: Fix a write performance regression
NFS: Fix up page writeback accounting
xprtrdma: disconnect and flush cqs before freeing buffers
This reverts commit 998ef75ddb.
The commit itself does not appear to be buggy per se, but it is exposing
a bug in ext4 (and Ted thinks ext3 too, but we solved that by getting
rid of it). It's too late in the release cycle to really worry about
this, even if Dave Hansen has a patch that may actually fix the
underlying ext4 problem. We can (and should) revisit this for the next
release.
The problem is that moving the prefaulting later now exposes a special
case with partially successful writes that isn't handled correctly. And
the prefaulting likely isn't normally even that much of a performance
issue - it looks like at least one reason Dave saw this in his
performance tests is that he also ran them on Skylake that now supports
the new SMAP code, which makes the normally very cheap user space
prefaulting noticeably more expensive.
Bisected-and-acked-by: Ted Ts'o <tytso@mit.edu>
Analyzed-and-acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
qxl_bo_unref calls drm_gem_object_unreference_unlocked which
locks dev->struct_mutex. However this lock could be already
locked if the call came from qxl_gem_object_free.
As we don't need to call qxl_bo_ref/qxl_bo_unref cause
qxl_release_list_add will hold a reference by itself avoid
to call them and the possible deadlock.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This avoid a dependency lock error.
According to https://lwn.net/Articles/548909/ users of WW mutex API
should avoid using different context.
When a buffer is reserved with qxl_bo_reserve a ww_mutex_lock without
context is used. However during qxl_draw_dirty_fb different locks
with specific context are used.
This is detected during a machine booting with a debug kernel with lock
dependency checking enabled.
Like many other function in this file to avoid this problem object
pinning is used. Once the object is pinned is not necessary to keep
the lock so it can be released avoiding the locking problem.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit "c0fe07a drm/qxl: rewrite framebuffer support" has a bug in the
dirty rectangle tracking: Instead of ignoring an empty dirty rectangle
when adding a new dirty region the dirty region gets extended to the
upper left corner. Fix it.
Cc: linux-stable@vger.kernel.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Running xfstest generic/013 with the tracepoint nfs:nfs4_open_file
enabled produces a NULL-pointer dereference when calculating fileid and
filehandle of the opened file. Fix this by checking if state is NULL
before trying to use the inode pointer.
Reported-by: Olga Kornievskaia <aglo@umich.edu>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
HDMI sinks are permitted to de-assert and re-assert the HPD signal to
indicate that their EDID has been updated, which may not involve a
change of video information.
An example of where such a situation can arise is when an AV receiver
is connected between the source and the display device. Events which
can cause the HPD to be deasserted include:
* turning on or switching to standby the AV receiver.
* turning on or switching to standby the display device.
Each of these can change the entire EDID data, or just a part of the
EDID data - it's up to the connected HDMI sink to do what they desire
here. For example
- with the AV receiver and display device both in standby, a source
connected to the AV receiver may provide its own EDID to the source.
- turning on the display device causes the display device's EDID to be
made available in an unmodified form to the source.
- subsequently turning on the AV receiver then provides a modified
version of the display device's EDID.
Moreover, HPD doesn't tell us whether something is actually listening
on the HDMI TDMS signals. The phy gives us a set of RXSENSE indications
which tell us whether there is a sink connected to the TMDS signals.
Currently, we use the HPD signal to enable or disable the HDMI block,
which is questionable when HPD is used in this manner. Using the
RXSENSE would be more appropriate, but there is some bad behaviour
which needs to be coped with. The iMX6 implementation lets the TMDS
signals float when the phy is "powered down", which cause spurious
interrupts. Rather than just using RXSENSE, use RXSENSE and HPD
becoming both active to signal the presence of a device, but loss
of RXSENSE to indicate that the device has been unplugged.
The side effect of this change is that a sink deasserting the HPD
signal to cause a re-read of the EDID data will not cause the bridge
to immediately disable the video signal.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When connected to HDMI sources, some DVI monitors de-assert their HPD
signal and TDMS loads for one seconds every four seconds when there is
no signal present on the connection.
Unfortunately, this behaviour is indistinguishable from a proper HDMI
setup with an AV receiver in the path to the display: the HDMI spec
requires us to detect HPD deassertions as short as 100ms, which indicate
that the EDID has changed.
Since it is possible to connect a DVI monitor to an AV receiver and then
to a HDMI source, merely working around this by detecting the lack of
HDMI vendor block in the EDID is insufficient - the AV receiver is at
liberty to modify the EDID as it sees fit, and it will place its own
parameters into the EDID including the HDMI vendor block.
DRM has support for forcing the state of a connector, which we should
implement to allow us to work around these broken DVI monitors - we can
tell DRM to force the connection state to indicate that there is always
a device connected to work around this problem. Although this requires
manual configuration, it is better than nothing at all.
When a forced connection state has been set, there is no point handling
our RXSENSE interrupts, so disable them in this circumstance.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for interlaced video modes to the dw_hdmi bridge. This
mainly involves halving the vertical parameters to be programmed into
the bridge registers, and setting the interlace_allowed connector flag.
This brings working 1080i support. However, 480i and 576i fail to
work due to the lack of proper pixel repetition support, which is not
trivial to add due to the tabular PLL parameterisation. Hence, we
filter out these modes in our mode_valid() method.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The support for interlaced video modes seems to be broken; we don't use
anything other than the vtotal/htotal from the timing information to
define the various sync counters.
Freescale patches for interlaced video support contain an alternative
sync counter setup, which we include here. This setup produces the
hsync and vsync via the normal counter 2 and 3, but moves the display
enable signal from counter 5 to counter 6. Therefore, we need to
change the display controller setup as well.
The corresponding Freescale patches for this change are:
iMX6-HDMI-support-interlaced-display-mode.patch
IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch
This produces a working interlace format output from the IPU.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tony Lindgren