When enabling runtime PM on VLV, GT power save enabling becomes relatively
frequent, so optimize it a bit.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During runtime suspend there can be a last pending rps.work, so make
sure it's canceled. Note that in the runtime suspend callback we can't
get any RPS interrupts since it's called only after the GPU goes idle
and we set the minimum RPS frequency. The next possibility for an RPS
interrupt is only after getting an RPM ref (for example because of a new
GPU command) and calling the RPM resume callback.
v2:
- patch introduced in v2 of the patchset
v3:
- Change the order of canceling the rps.work and disabling interrupts to
avoid the race between interrupt disabling and the the rps.work. Race
spotted by Ville.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to re-init sizzling on all platforms so move it to the
platform independent runtime resume callback. The ring frequency reinit
is also needed everywhere except on VLV, but gen6_update_ring_freq()
will be a noop on VLV, so we can move this function too to platform
independent code.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is needed by the next patch moving the call out from platform
specific RPM callbacks to platform independent code.
No functional change.
v2:
- patch introduce in v2 of the patchset
v3:
- simplify platform check condition (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to disable the interrupts for all platforms, so make the helpers
for this platform independent and call them from them platform
independent runtime suspend/resume callbacks.
On HSW/BDW this will move interrupt disabling/re-enabling at the
beginning/end of runtime suspend/resume respectively, but I don't see
any reason why this would cause a problem there. In any case this seems
to be the correct thing to do even on those platforms.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV we depend on RC6 to save the GT render and media HW context
before going to the D3 state via RPM, so as a preparation for the
VLV RPM support (added in an upcoming patch) disable RPM if RC6 is
disabled.
There is probably a similar dependency on other platforms too, so for
safety require RC6 for those too. For these platforms (SNB, HSW, BDW)
this is then a possible fix.
v2:
- require RC6 for all RPM platforms, not just for VLV (Paulo, Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm, an invalid enable_rc6 module option will be silently ignored, so
emit an info message about it. Doing an early sanitization we can also
reuse intel_enable_rc6() in a follow-up patch to see if RC6 is actually
enabled. Currently the caller would have to filter a non-zero return
value based on the platform we are running on. For example on VLV with
i915.enable_rc6 set to 2, RC6 won't be enabled but atm
intel_enable_rc6() would still return 2 in this case.
v2:
- simplify the platform check condition (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm, we call intel_gt_powersave_enable() for GEN6 and GEN7 but disable
it for everything starting from GEN6. This is a problem in case of BDW.
Since I don't have a BDW to test if RC6 works properly, just keep it
disabled for now and fix only the disable function.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some platforms need additional power domains to be on in addition to the
device D0 state to access the panel registers.
Suggested by Daniel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.
The move also revealed that we actually don't include this register in
the error report, so fix that too.
v2:
- patch introduced in v2 of the patchset
v3:
- add back !HAS_PCH_SPLIT check (Ville)
[ Ignore my previous comment about the gen<=5 || vlv check, I realized
that it's the same as !HAS_PCH_SPLIT. ]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While checking the error capture path I noticed that this register is
read twice for GEN2, so fix this and also move the read where it's done
for other platforms.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we can end up in the GPU reset deferred work in D3 state if the last
runtime PM reference is dropped between detecting a hang/scheduling the
work and executing the work. At least one such case I could trigger is
the simulated reset via the i915_wedged debugfs entry. Fix this by
getting an RPM reference around accessing the HW in the reset work.
v2:
- Instead of getting/putting the RPM reference in the reset work itself,
get it already before scheduling the work. By this we also prevent
going to D3 before the work gets to run, in addition to making sure
that we run the work itself in D0. (Ville, Daniel)
v3:
- fix inverted logic fail when putting the RPM ref on behalf of a
cancelled GPU reset work (Ville)
v4:
- Taking the RPM ref in the interrupt handler isn't really needed b/c
it's already guaranteed that we hold an RPM ref until the end of the
reset work in all cases we care about. So take the ref in the reset
work (for cases like i915_wedged_set). (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Be we read and chase pointers from the VBT, it is prudent to make sure
that those accesses are wholly contained within the MMIO region, or else
we may cause a kernel panic during boot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make sure that the whole BDB section is within the MMIO region prior to
accessing it contents. That we don't read outside of the secion is left
up to the individual section parsers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least on VLV but probably on other platforms too we depend on RC6
being enabled for RPM, so disable RPM until the delayed RC6 enabling
completes.
v2:
- explain the reason for the _noresume version of RPM get (Daniel)
- use the simpler 'if (schedule_work()) rpm_get();' instead of
'if (!cancel_work_sync()) rpm_get(); schedule_work();'
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Getting struct_mutex around the whole intel_enable_gt_powersave()
function is not necessary, since it's only needed for the ILK path
therein.
This will make intel_enable_gt_powersave() useable on the RPM resume
path for >=GEN6 (added in an upcoming patch to reset the RPS state
during RPM resume), where we can't (and need not) get this mutex.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These debugfs entries access registers that need the D0 power state so
get an RPM ref for them.
v2:
- for all these entries we only need D0 state, so get only an RPM ref,
not a power domain ref (Daniel, Paulo)
- the dpio entry is not an issue any more as it got removed (Ville)
- restore commit message from v1 (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are igt tools that can read/write the DPIO registers, so having a
debugfs entry for only some of those registers is somewhat arbitrary /
redundant. Remove it.
v2:
- instead of fixing the entry by taking a power domain reference around
the register accesses, remove the entry (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The parsing was incorrect for ILK and VLV.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not clearing this flag causes spurious interrupts at least in D3 state,
so before enabling RPM we need to fix this. We were already setting this
flag when enabling interrupts, only clearing it was missing.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These will be needed by the upcoming VLV RPM helpers.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space driver/middle.
Instead the kernel driver will decide which ring is to dispatch the BSD video
command.
As every BSD ring is powerful, it is enough to dispatch the BSD video command
based on the drm fd. In such case it can play back video stream while encoding
another video stream. The coarse ping-pong mechanism is used to determine
which BSD ring is used to dispatch the BSD video command.
V1->V2: Follow Daniel's comment and use the simple ping-pong mechanism.
This is only to add the support of dual BSD rings on BDW GT3 machine.
The further optimization will be considered in another patch set.
V2->V3: Follow Daniel's comment to use the struct_mutext instead of
atomic_t during determining which ring can be used to dispatch Video command.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Gen7 doesn't have the second BSD ring. But it will complain the switch check
warning message during compilation. So just add it to remove the
switch check warning.
V1->V2: Follow Daniel's comment to update the comment
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on the hardware spec, the BDW GT3 machine has two independent
BSD ring that can be used to dispatch the video commands.
So just initialize it.
V3->V4: Follow Imre's comment to do some minor updates. For example:
more comments are added to describe the semaphore between ring.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[danvet: Fix up checkpatch error.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine.
V1->V2: Follow Daniel's comment to pay attention to the stolen check for BDW
in kernel/early-quirks.c
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to make sure that userspace keeps on following the contract,
otherwise we won't be able to use the reserved fields at all.
v2: Add DRM_DEBUG (Chris)
Testcase: igt/gem_exec_params/*-dirt
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A bit tricky since 0 is also a valid constant ...
v2: Add DRM_DEBUG (Chris)
Testcase: igt/gem_exec_params/rel-constants-*
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we catch it, but silently succeed. Our userspace is
better than this.
v2: Add DRM_DEBUG (Chris)
Testcase: igt/gem_exec_params/sol-reset-*
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we include the expected values for the failing ring register checks,
it makes it marginally easier to see which is the culprit.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During module load, if we fail to initialise the rings, we abort the
load reporting EIO. However during resume, even though we report EIO as
we fail to reinitialize the ringbuffers, the resume continues and the
device is restored - albeit in a non-functional state. As we cannot
execute any commands on the GPU, it is effectively wedged, mark it so.
As we now preserve the ringbuffers across resume, this should prevent
UXA from falling into the trap of repeatedly sending invalid
batchbuffers and dropping all further rendering into /dev/null.
Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz>
References: https://bugs.freedesktop.org/show_bug.cgi?id=76554
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
[danvet: Drop unused error, spotted by Oscar.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even without enabling the ringbuffers to allow command execution, we can
still control the display engines to enable modesetting. So make the
ringbuffer initialization failure soft, and mark the GPU as wedged
instead.
v2: Only treat an EIO from ring initialisation as a soft failure, and
abort module load for any other failure, such as allocation failures.
v3: Add an *ERROR* prior to declaring the GPU wedged so that it stands
out like a sore thumb in the logs
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tearing down the ring buffers across resume is overkill, risks
unnecessary failure and increases fragmentation.
After failure, since the device is still active we may end up trying to
write into the dangling iomapping and trigger an oops.
v2: stop_ringbuffers() was meant to call stop(ring) not
cleanup(ring) during resume!
Reported-by: Jae-hyeon Park <jhyeon@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72351
References: https://bugs.freedesktop.org/show_bug.cgi?id=76554
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
[danvet: s/ring->obj == NULL/!intel_ring_initialized(ring)/ as
suggested by Oscar.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For readibility and guess at the meaning behind the constants.
v2: Claim only the meagerest connections with reality.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I don't think this is necessary; at least it doesn't appear to be on my
BYT. Dropping it speeds up our shutdown code a little, in some cases
resulting in faster init times.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Next pull request, this time more of the drm de-midlayering work. The big
thing is that his patch series here removes everything from drm_bus except
the set_busid callback. Thierry has a few more patches on top of this to
make that one optional to.
With that we can ditch all the non-pci drm_bus implementations, which
Thierry has already done for the fake tegra host1x drm_bus.
Reviewed by Thierry, Laurent and David and now also survived some testing
on my intel boxes to make sure the irq fumble is fixed correctly ;-) The
last minute rebase was just to add the r-b tags from Thierry for the 2
patches I've redone.
* 'drm-init-cleanup' of git://people.freedesktop.org/~danvet/drm:
drm/<drivers>: don't set driver->dev_priv_size to 0
drm: Remove dev->kdriver
drm: remove drm_bus->get_name
drm: rip out dev->devname
drm: inline drm_pci_set_unique
drm: remove bus->get_irq implementations
drm: pass the irq explicitly to drm_irq_install
drm/irq: Look up the pci irq directly in the drm_control ioctl
drm/irq: track the irq installed in drm_irq_install in dev->irq
drm: rename dev->count_lock to dev->buf_lock
drm: Rip out totally bogus vga_switcheroo->can_switch locking
drm: kill drm_bus->bus_type
drm: remove drm_dev_to_irq from drivers
drm/irq: remove cargo-culted locking from irq_install/uninstall
drm/irq: drm_control is a legacy ioctl, so pci devices only
drm/pci: fold in irq_by_busid support
drm/irq: simplify irq checks in drm_wait_vblank
Remove occurrences of unused struct qxl_device pointer in functions
qxl_ttm_fault() and qxl_init_mem_type().
Detected by Coverity: CID 1019128, CID 1019129.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For QXL hw we really want the bits to be replaced as we change
the preferred mode on the fly, and the same goes for virgl when
I get to it, however the original fix for this seems to have caused
a wierd regression on Intel G33 that in a stunning display of failure
at opposition to his normal self, Daniel failed to diagnose.
So we are left doing this, ugly ugly ugly ugly, Daniel you fixed
that G33 yet?, ugly, ugly.
Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm-intel-next-2014-04-16:
- vlv infoframe fixes from Jesse
- dsi/mipi fixes from Shobhit
- gen8 pageflip fixes for LRI/SRM from Damien
- cmd parser fixes from Brad Volkin
- some prep patches for CHV, DRRS, ...
- and tons of little things all over
drm-intel-next-2014-04-04:
- cmd parser for gen7 but only in enforcing and not yet granting mode - the
batch copying stuff is still missing. Also performance is a bit ... rough
(Brad Volkin + OACONTROL fix from Ken).
- deprecate UMS harder (i.e. CONFIG_BROKEN)
- interrupt rework from Paulo Zanoni
- runtime PM support for bdw and snb, again from Paulo
- a pile of refactorings from various people all over the place to prep for new
stuff (irq reworks, power domain polish, ...)
drm-intel-next-2014-04-04:
- cmd parser for gen7 but only in enforcing and not yet granting mode - the
batch copying stuff is still missing. Also performance is a bit ... rough
(Brad Volkin + OACONTROL fix from Ken).
- deprecate UMS harder (i.e. CONFIG_BROKEN)
- interrupt rework from Paulo Zanoni
- runtime PM support for bdw and snb, again from Paulo
- a pile of refactorings from various people all over the place to prep for new
stuff (irq reworks, power domain polish, ...)
Conflicts:
drivers/gpu/drm/i915/i915_gem_context.c
Use %pad for dma_addr_t, because a dma_addr_t type can vary
based on build options. So, it prevents possible build warnings
in printks.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
devm_ioremap_resource() returns an error pointer, not NULL. Thus,
the result should be checked with IS_ERR().
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
exynos_drm_crtc_mode_set assigns primary framebuffer to plane without
taking reference. Then during framebuffer removal it is dereferenced twice,
causing oops. The patch fixes it.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
single security fix, cc'd stable.
* 'vmwgfx-fixes-3.15' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2
A single fix for some framebuffer reference counting fallout caused by
the primary plane helpers introduced in 3.15-rc1.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTWQzGAAoJEN0jrNd/PrOhrkAP/2BQvFszaEeMlI1sb18DK9pm
tu3BNf+gB/ZvsMVok79KdeDHi73v5acwqDapDmCcHKS1JRpqbKMgzWDrXYg39WWi
0i+nyWt43ajXqO3/PvrDiqDRTwb4Ee/GdQMVVti6+VcSYlKSMqrcCsL2SStfiUIU
z6tL0WpEF5oKRHwfSKjFP3CRkSiElLbjKDk5Z/b1noZoahjdFrc54fWpK71+Tf5C
HZ7vsWJxgqip0CRtRqYer8auLSdHN7LhNBRVCGWbgSNHMuKp07U/9qktmBFgLtkO
gOGu6W7wLR8sgCmNpDv6ht5pvu3cGWKRCDTSmbF79CTCdc/Wb2rMs/JSeq4CJPcP
wZ+TwnUwNp+Qv2McTONp6wCZ/qpBBcZgymOVCt9bossKs03DMT4H7C5ypri8QrQM
40V8KEmYpiAcO5JN0oXUd4Q2n6NniZwCP4xt/U4cUXTjCqMAnLBozCji8ApDLegX
wmSz2+G0NGAcnJEK482PE+lxavOaWPyRg1y777VCfOSstqiSaukmrg4/xxrMdp+a
fDSZWLdVPqZUaUr5qWPl0Szbihw3brmMSCzubrP5dOtw8MUUHXIRGbBE5w2PH8tD
do4yvxPPO9W0iH6PW+rN4Z4ll+SS0EQwsohBPA0/Z2CAC+CrMAseBb/71/syocqA
JIY2cogdFI0Ynzp6t4xn
=uM53
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.15-rc3' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Fixes for v3.15-rc3
A single fix for some framebuffer reference counting fallout caused by
the primary plane helpers introduced in 3.15-rc1.
* tag 'drm/tegra/for-3.15-rc3' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: restrict plane loops to legacy planes
Fixes for msm for 3.15.. a memory leak fix for devices using vram
carveout instead of iommu. Plus I think finally managed to sort out /
workaround some cursor vs underflow issues. And small fbcon tweak
needed to avoid extra full-modesets at boot.
* 'msm-fixes-3.15-rc3' of git://people.freedesktop.org/~robclark/linux:
drm/msm/mdp4: cure for the cursor blues (v2)
drm/msm: default to XR24 rather than AR24
drm/msm: fix memory leak
Fix regression with DVI and fix warns, and GM45 boot regression.
* tag 'drm-intel-fixes-2014-04-25' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Move all ring resets before setting the HWS page
drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms
drm/i915: Allow full PPGTT with param override
drm/i915: Discard BIOS framebuffers too small to accommodate chosen mode
drm/i915: get power domain in case the BIOS enabled eDP VDD
drm/i915: Don't check gmch state on inherited configs
drm/i915: Allow user modes to exceed DVI 165MHz limit
In commit a51435a313
Author: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Date: Wed Mar 12 16:39:40 2014 +0530
drm/i915: disable rings before HW status page setup
we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.
Reference: http://lkml.kernel.org/r/20140423202248.GA3621@amd.pavel.ucw.cz
Tested-by: Pavel Machek <pavel@ucw.cz>
Cc: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The status bits are unconditionally set, the control bits only enable
the actual interrupt generation. Which means if we get some random
other interrupts we'll bogusly complain about them.
So restrict the WARN to platforms with a sane hotplug interrupt
handling scheme. And even more important also don't attempt to process
the hpd bit since we've detected a storm already. Instead just clear
the bit silently.
This WARN has been introduced in
commit b8f102e8bf
Author: Egbert Eich <eich@suse.de>
Date: Fri Jul 26 14:14:24 2013 +0200
drm/i915: Add messages useful for HPD storm detection debugging (v2)
before that we silently handled the hpd event and so partially
defeated the storm detection.
v2: Pimp commit message (Jani)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: bitlord <bitlord0xff@gmail.com>
Reported-by: bitlord <bitlord0xff@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The hw cursor is relatively adept at triggering underflows, which
manifest as a "blue flash" (since blue is configured as the underflow
color). Juggle a few things around to tighten up the timing for setting
cursor registers in DONE irq.
And most importantly, don't ever disable the hw cursor. Instead flip it
to a blank/empty cursor. This seems far more reliable, as even simply
clearing the cursor-enable bit (with no other updates in previous/
following frames) can in some cases cause underflow.
v1: original
v2: add missing locking spotted by Micah
Cc: Micah Richert <richert@braincorporation.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since X11 is going to create an XR24 fb, if the pixel formats do not
match then crtc helpers will think it is a full modeset even if mode is
the same, which prevents smooth/flickerless handover from fbcon/plymouth
to X11.
Signed-off-by: Rob Clark <robdclark@gmail.com>
In Matt Ropers primary plane series a set of prep patches like
commit af2b653bfb
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Apr 1 15:22:32 2014 -0700
drm/i915: Restrict plane loops to only operate on overlay planes (v2)
ensured that all exisiting users of the mode_config->plane_list
wouldn't change behaviour. Unfortunately tegra seems to have fallen
through the cracks. Fix it.
This regression was introduced in
commit e13161af80
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Apr 1 15:22:38 2014 -0700
drm: Add drm_crtc_init_with_planes() (v2)
The result was that we've unref'ed the fb for the primary plane twice,
leading to a use-after free bug. This is because the drm core will
already set crtc->primary->fb to NULL and do the unref for us, and the
crtc disable hook is called by the drm crtc helpers for exactly this
case.
Aside: Now that the fbdev helpers clean up planes there's no longer a
need to do this in drivers. So this could probably be nuked entirely
in linux-next.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When PPGTT was disabled by default, the patch also prevented the user
from overriding this behavior via module parameter. Being able to test
this on arbitrary kernels is extremely beneficial to track down the
remaining bugs. The patch that prevented this was:
commit 93a25a9e2d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Mar 6 09:40:43 2014 +0100
drm/i915: Disable full ppgtt by default
By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
means full, all other values are reserved.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit d978ef1445
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:51 2014 -0800
drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12
v2: Add a debug message to track the discard of the BIOS fb.
v3: Ville pointed out the difference between ref/unref
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77767
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We already check that the buffer object we're accessing is registered with
the file. Now also make sure that we can't DMA across buffer object boundaries.
v2: Code commenting update.
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Especially not on modesetting drivers - this is used to size
the driver private structure for legacy drm buffers.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the last patch to ditch the ->get_name callbacks the last
user is now gone.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The only user is the info debugfs file, so we only need something
human readable. Now for both pci and platform devices we've used the
name of the underlying device driver, which matches the name of the
drm driver in all cases. So we can just use that instead.
The exception is usb, which used a generic "USB". Not to harmful with
just one usb driver, but better to use "udl", too.
With that converted we can rip out all the ->get_name implementations.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was only ever used to pretty-print the irq driver name. And on
kms systems due to set_version bonghits we never set up the prettier
name, ever. Which make this a bit pointless.
Also, we can always dig out the driver-instance/irq relationship
through other means, so this isn't that useful. So just rip it out to
simplify the set_version/set_busid insanity a bit.
Also delete the temporary busname from drm_pci_set_busid, it's now
unused.
v2: Rebase on top of the new host1x drm_bus for tegra.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is only used for drm versions 1.0, and kms drivers have never
been there. So we can appropriately restrict this to legacy and hence
pci devices and inline everything.
v2: Make the dummy function actually return something, caught by Wu
Fengguang's 0-day tester.
v3: Fix spelling in comment (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that they're all unused we can get rid of them, including the
dummy version in drm_usb.c.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.
With that we can now also remove drm_dev_to_irq from drm_irq.c.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's only ever called for legacy drivers, which are all pci.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.
v2: Add the hunk lost in an earlier patch to this one (Thierry).
v3: Fix up the totally fumbled logic in drm_irq_install and use the
local variable consistently. Spotted by both Thierry and Laurent.
Shame on me for failing to properly test the rebase version of this
patch ...
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since really that's all it protects - legacy horror stories in
drm_bufs.c. Since I don't want to waste any more time on this I didn't
bother to actually look at what it protects in there, but it's at
least contained now.
v2: Move the spurious hunk to the right patch (Thierry).
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.
Unfortunately the vga switcheroo callbacks took this comment at face
value. The problem is that we can't just take the drm_global_mutex
because:
- It would lead to a locking inversion with the driver load/unload
paths.
- It wouldn't actually protect anything, for that we'd need to wrap
the entire vga switcheroo code in the drm_global_mutex. And I'm not
sure whether that would actually solve anything.
What we probably want is a try_to_grab_switcheroo reference kind of
thing which is used in the driver's ->open callback. Then we could
move all that ->can_switch madness into the vga switcheroo core where
it really belongs.
But since that would amount to real work take the easy way out and
just add a comment. It's definitely not going to make anything worse
since doing switcheroo state changes while restarting X just isn't
recommended. Even though the delayed switching code does exactly that.
v2:
- Simplify the ->can_switch implementations more (Thierry)
- Fix comment about the dev->open_count locking (Thierry)
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v1)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(), which trigger a WARN saying that the
refcount of the power domain is less than zero.
The problem happens because the driver gets a refcount whenever it
enables the VDD bit, and puts the refcount whenever it disables the
VDD bit. But on this case, the BIOS enabled VDD, so all we do is to
call put() without calling get() first, so the code added is there to
make sure we always have the get() in case the BIOS enabled the bit.
This regression was introduced in
commit e9cb81a228
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Nov 21 13:47:23 2013 -0200
drm/i915: get a runtime PM reference when the panel VDD is on
v2: - Rebase
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the gmch_pfit state to
it.
3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.
-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Some newer PX laptops have the pci device class
set to DISPLAY_OTHER rather than DISPLAY_VGA. This
properly detects ATPX on those laptops.
Based on a patch from: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: airlied@gmail.com
Avoids a crash in certain cases when thermal irqs are generated
before the display structures have been initialized.
v2: fix the vblank and vrefresh helpers as well
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
We need to check whether drm_ht_create succeed and clean up
if not.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is C standard hair-splitting, but afaict
- sum will be promoted to signed int in computation since
uint8_t fits
- signed overflow is undefined.
No we need to add up an awful lot of bytes to actually make it
overflow. But I guess the real risk is gcc spotting this and going
bananas. Fix this by simply using unsigned in to force all computations
to use the well-defined unsigned behaviour.
Spotted by coverity.
v2: Simplify the entire computation as suggested by Jean.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Jean-Francois Moine <moinejf@free.fr>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Noticed while chasing coverity reports, somehow this one here was not
flagged.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to set it to -ENODEV when we don't recognize the device.
Otherwise we return/print stack garbage.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The context_dtor callback is only called once we've successfully loaded
the driver, which means dev->dev_private is set up. The check is hence
pointless.
Also dev->dev_private is deref already above, so compilers are free
to elide it anyway.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
v2: Fix patch subject.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Should be 5 rather than 4.
Noticed-by: Mathias Fröhlich <Mathias.Froehlich@gmx.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christian König <christian.koenig@amd.com>
In commit
commit 6375b768a9
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Mar 3 11:33:36 2014 +0200
drm/i915: Reject >165MHz modes w/ DVI monitors
the driver started to filter out display modes which exceed the
single-link DVI 165Mz dotclock limits when the monitor doesn't report
itself as being HDMI compliant. The intent was to filter out all
EDID derived modes that require dual-link DVI to operate since we
don't support dual-link.
However the patch went a bit too far and also causes the driver to reject
such modes even when specified by the user. Normally we don't check the
sink limitations when setting a mode from the user. This allows the user
to specify any mode whether the sink reports to support it or not. This
can be useful since often the sinks support more modes than they report
in the EDID.
So relax the checks a bit, and apply the single-link DVI dotclock limit
only when filtering the mode list, and ignore the limit when setting
a user specified mode.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72961
Tested-by: Nicholas Vinson <nvinson@comcast.net>
Cc: stable@vger.kernel.org [3.14]
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Completely unused. Hooray, midlayer mistakes that didn't cause work to
undo!
v2: Rebase on top of the recent tegra changes which added a host1x drm
bus.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only used in some legacy pci drivers, and dereferencing the PCI irq is
actually shorter ...
Since this removes all users for drm_dev_to_irq from the tree except
in drm_irq.c, move the inline helper in there. It'll disappear soon,
too.
v2: Polish commit message (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The dev->struct_mutex locking in drm_irq.c only protects
dev->irq_enabled. Which isn't really much at all and only prevents
especially nasty ums userspace from concurrently installing the
interrupt handling a few times. Or at least trying.
There are tons of unlocked readers of dev->irqs_enabled in the vblank
wait code (and by extension also in the pageflip code since that uses
the same vblank timestamp engine).
Real modesetting drivers should ensure that nothing can go haywire
with a sane setup teardown sequence. So we only really need this for
the drm_control ioctl, everywhere else this will just paper over
nastiness.
Note that drm/i915 is a bit specially due to the gem+ums combination.
So there we also need to properly protect the entervt and leavevt
ioctls. But it's definitely saner to do everything in one go than to
drop the lock in-between.
Finally there's the gpu reset code in drm/i915. That one's just race
(concurrent userspace calls to for vblank waits of pageflips could
spuriously fail). So wrap it up in with a nice comment since fixing
this is more involved.
v2: Rebase and fix commit message (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a ums-only ioctl, and we've only ever supported ums (at least
in upstream) on pci devices. So no point in keeping that piece of
legacy logic abstracted within the drm bus driver.
To keep things work without CONFIG_PCI also add a dummy ioctl.
v2: Block the irq_by_busid ioctl for modeset drivers.
v3: Spelling/whitespace polish (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Checking for both an irq number _and_ whether it's enabled is
redundant. Originally I've thought the drm_dev_to_irq call would break
drivers which do their own irq checking, but those shouldn't have
DRIVER_HAVE_IRQ set as Thierry Reding pointed out. But such drivers
already need to set dev->irq_enabled for other reasons, so we might as
well ditch that check, too.
v2: Also drop the HAVE_IRQ check.
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hpd (hot plug detect) pin assignment got lost
in the conversion to to the common i2c over aux
code. Without this information, aux transactions
do not work properly. Fixes DP failures.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Some i2c fixes over DisplayPort.
* 'drm-next-3.15-wip' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: Improve vramlimit module param documentation
drm/radeon: fix audio pin counts for DCE6+ (v2)
drm/radeon/dp: switch to the common i2c over aux code
drm/dp/i2c: Update comments about common i2c over dp assumptions (v3)
drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
drm/i915: support address only i2c-over-aux transactions
drm/tegra: dp: Support address-only I2C-over-AUX transactions
bochs kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.
Fix this by adding suspend and resume functions.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
cirrus kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.
Fix this by adding suspend and resume functions.
Also make the mode_set function unblank the screen.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.
The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.
It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:
- The locking is all wrong: set_config(NULL) will also unlink encoders
and connectors, but those links are protected with the mode_config
mutex. In the ->disable_plane callback we only hold all modeset
locks, but eventually we want to switch to just grabbing the
per-crtc (and maybe per-plane) locks as needed, maybe based on
ww_mutexes. Having a callback which absolutely needs all modeset
locks is bad for this conversion.
Note that the same isn't true for the provided ->update_plane since
we've audited the crtc helpers to make sure that not encoder or
connector links are changed.
- There's no way to re-enable the plane with an ->update_plane: The
connectors/encoder links are lost and so we can't re-enable the
CRTC. Even without that issue the driver might have reassigned some
shared resources (as opposed to e.g. DPMS off, where drivers are not
allowed to do that to make sure the CRTC can be enabled again).
- The semantics don't make much sense: Userspace asked to scan out
black (or some other color if the driver supports a background
color), not that the screen be disabled.
- Implementing proper primary plane support (i.e. actually disabling
the primary plane without disabling the CRTC) is really simple, at
least if all the hw needs is flipping a bit. The big task is
auditing all the interactions with other ioctls when the CRTC is on
but there's no primary plane (e.g. pageflips). And some of that work
still needs to be done.
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this is a typo vs the ums driver, fix to check correct value.
Found initially by Coverity.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 457e77b264 added two checks applied to a
value received from nv_rd32(bios, 0x619f04). But after this new piece of code
is executed, the addr local variable does not hold the same value it used to
hold before the commit. Here is what is was assigned in the original code:
(u64)(nv_rd32(bios, 0x619f04) & 0xffffff00) << 8
in the committed code it ends up with this value:
(u64)(nv_rd32(bios, 0x619f04) >> 8) << 8
These expressions are obviously not equivalent.
My Nvidia video card does not show anything on the display when I boot a
kernel containing this commit.
The patch fixes the code so that the new checks are still done, but the
side effect of an incorrect addr value is gone.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
appeared in 3.15-rc1:
- fixes for primary-plane handling which caused crashes
- fix all kinds of uninit issues which prevented from unloading the omapdrm
module.
- fixes for HDMI enable/disable issues
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTTkM7AAoJEPo9qoy8lh71JaQP/2NvUIr64vCXd39FqzrpwJ2n
iRwHFt0M5sHld6NCNVyaThQtmRAN7u7fkInwcUWPU1yv0HIkHB2CRAzTx3H1Ca73
S+eaqda6Rog2oGh/Q6xmpAjaxZX0td9QhhGfKm9MlNJQ/a50H/7ovq5XZu2etfj2
m1nW6L1U+43aZYDLjM6T6IOydqWZGZ0jv6sNOAa4vwWWIJ85y+MybL2AL6SOQXpR
LLbe/wI6eMBguJQOiLfZivFtlF7HzvT9I/VRhrtL+aanBOqVeqEFEcxJhutIl8/g
NOZo+XfeRJqGJ5FDbgwFqP/+sDQEKQBHL+9/XfUVdJmKI3ihyhF5o4jCPpkHqYTP
S3hyxQOkPZ/wgP8ucG0BvzhQRZoatSyIUbDE/98etmZ2pqLXk6d+tRs2uAev/0ec
WLDc8/JEbTOE9cG/VAqVZTPsucuoWZ8Ow70v65ZlloqiaD/6QAWigavcQA1EZO+F
cHBuwNXXAu8b2VV1cQcQVbihhga7lt1RFIzr7hQpniERK7tqeVqgapLWruxEJ5HZ
9HTRR+JIUydbXjsr0RtY3KIAKhKyfUiEAn7YIZBPpR7jSlUiexbX2ZrBN4Ea+sst
Kjs/I71KN6j7lI3hh3R+HKOeYw9wqXuoqtojCafx2JRMEMhiSpOrAZuOjsW0fWSD
AJhzTX8ZiFGFOB/oGdwp
=03GJ
-----END PGP SIGNATURE-----
Merge tag 'omapdrm-fixes-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
Fixes for omapdrm, some of which were already present in 3.14, and some which
appeared in 3.15-rc1:
- fixes for primary-plane handling which caused crashes
- fix all kinds of uninit issues which prevented from unloading the omapdrm
module.
- fixes for HDMI enable/disable issues
* tag 'omapdrm-fixes-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
drm/omap: fix the handling of fb ref counts
drm/omap: protect omap_crtc's event with event_lock spinlock
drm/omap: Use old_fb to synchronize between successive page flips
drm/omap: Fix crash when using LCD3 overlay manager
drm/omap: gem sync: wait on correct events
drm/omap: Fix memory leak in omap_gem_op_async
drm/omap: remove warn from debugfs
drm/omap: remove extra plane->destroy from crtc destroy
drm/omap: print warning when rotating non-TILER fb
drm/omap: fix missing unref to fb's buf object
drm/omap: fix plane rotation
drm/omap: fix enabling/disabling of video pipeline
drm/omap: fix missing disable for unused encoder
drm/omap: fix race issue when unloading omapdrm
drm/omap: fix DMM driver (un)registration
drm/omap: fix uninit order in pdev_remove()
drm/omap: fix output enable/disable sequence
1. Fixing PLL regressions
2. A couple of memory reclocking and DPM fixes
3. Small cleanups
* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon/ci: make sure mc ucode is loaded before checking the size
drm/radeon/si: make sure mc ucode is loaded before checking the size
drm/radeon: improve PLL params if we don't match exactly v2
drm/radeon: memory leak on bo reservation failure. v2
drm/radeon: fix VCE fence command
drm/radeon: re-enable mclk dpm on R7 260X asics
drm/radeon: add support for newer mc ucode on CI (v2)
drm/radeon: add support for newer mc ucode on SI (v2)
drm/radeon: apply more strict limits for PLL params v2
drm/radeon: update CI DPM powertune settings
drm/radeon: fix runpm handling on APUs (v4)
drm/radeon: disable mclk dpm on R7 260X
This contains a fix for the host1x driver writing to non-existent syncpt
registers.
A second commit removes an excess pad field in the parameter structure
for the DRM_TEGRA_SUBMIT IOCTL. Archeaology on earlier versions of this
file indicates that this was once there to pad an uneven number of u32
u32 fields, of which one was subsequently removed. Unfortunately nobody
remembered to get rid of the padding when that happened.
Both of these commits are Cc: stable because they fix issues that were
introduced back in v3.10.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTT7oIAAoJEN0jrNd/PrOh+eEP/jTxGkbkGDlIhKXtjnNnoOZ2
CNAxpXETfO5WOxSP3LzJ8BhxZBHWrfJo6qWRhO9NAvAMc7jH7NYlijbPO0mS/Dwv
meFoMBN9RiMFRhdBBvxW3uwahgIc+GSUjcrv25BtTOpPmYSLldnWTdRBq5bzLYSB
iHpsv1iyVa/wI7iE5/VWwAy/JZPGEym7xgcE7IH2x2DVw4cNVZ4/OzBhN1STWWsL
bhR0M5/oKYboJoioZ3NDQ5XsAD6g15hdcW0+CxTJrA1sq5x1Juz/rwfk/+dUzC2f
O133QjbqyS1TY2mLhGk4sUnaFYVtsyIx+EIOWyHdrrIb6uFMjOThSq3MCdCHrRjP
hUghKJrNIGNkM8RrPngQGwUZfbRLzi5IqEFw8ZxNYwclZ1kpUW+vQs4maCG7rt4t
MEuIazUAoF7M0Xr59iF2LDrrZAOLWSjyiolX1nrJpDM+iYY/zaFe/yOU5B2+82dM
dIvEKf1Dm8Ys9RhNRW4qgSZQQHFkLXnwQAF6ulCeGgTtz1/daAchxv7zUIo5iMES
1IreKmUoMLpWBDHsUvGE9TsUlSo3tw/imMfLj1efHCtJl5Sn+cCXzcPtwrNf5SUY
5TZ9bKsduiLbDv5ov31lPFQUOLmOS7sJ+7phhOrI6RiNybxgGFymd0k+mW/GsMkN
5IPdu8D+GOQWtQjlqX0w
=yHpw
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.15-rc2' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Fixes for v3.15-rc2
This contains a fix for the host1x driver writing to non-existent syncpt
registers.
A second commit removes an excess pad field in the parameter structure
for the DRM_TEGRA_SUBMIT IOCTL. Archeaology on earlier versions of this
file indicates that this was once there to pad an uneven number of u32
u32 fields, of which one was subsequently removed. Unfortunately nobody
remembered to get rid of the padding when that happened.
Both of these commits are Cc: stable because they fix issues that were
introduced back in v3.10.
* tag 'drm/tegra/for-3.15-rc2' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Remove gratuitous pad field
gpu: host1x: handle the correct # of syncpt regs
Avoid a possible segfault.
Noticed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Avoid a possible segfault.
Noticed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
On bo reservation failure, we end up leaking fpriv.
v2 (chk): rebased and added missing free on vm failure as well
Fixes: 5e386b574c ("drm/radeon: fix missing bo reservation")
Cc: stable@vger.kernel.org
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Due to a type mismatch that causes an implicit type conversion, the
upper 32 bits of the GPU address have been zeroed out when adding to the
command buffer.
Picked up by Coverity - CID 1198624.
Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
May fix stability issues with some newer cards.
v2: print out mc firmware version used and size
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Letting post and refernce divider get to big is bad for signal stability.
v2: increase the limit to 210
Signed-off-by: Christian König <christian.koenig@amd.com>
The pipe is off at that point in time, so a vblank wait is simply a
50ms wait. Caught by Jesse's verbose "make vblank wait timeouts WARN"
patch. We've probably had a few versions of this float around already.
To document assumptions put a pipe assert into the same place. And
also add a posting read.
If we ever decide to update the eld and infoframes while the pipe is
already on (e.g. for fastboot) then there's lots of work to do. So
better properly document all the hidden assumptions.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BIT_WORD() truncates rather than rounds, so the loops in
syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <=
rather than < in an attempt to process the correct number of registers
when rounding of the conversion of count of bits to count of words is
necessary. However, when rounding isn't necessary because the value is
already a multiple of the divisor (as is the case for all values of
nb_pts the code actually sees), this causes one too many registers to
be processed.
Solve this by using and explicit DIV_ROUND_UP() call, rather than
BIT_WORD(), and comparing with < rather than <=.
Fixes: 7ede0b0bf3 ("gpu: host1x: Add syncpoint wait and interrupts")
Cc: <stable@vger.kernel.org> # 3.10
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-By: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some fixes from Intel.
* tag 'drm-intel-fixes-2014-04-11' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Always use kref tracking for all contexts.
drm/i915: do not setup backlight if not available according to VBT
drm/i915: check VBT for supported backlight type
drm/i915: Disable self-refresh for untiled fbs on i915gm
drm/mm: Don't WARN if drm_mm_reserve_node
We already do this for HSW, but doing it makes sense for everything else
as well. Extend it for ILK/SNB/IVB since that's where the new watermark
code is used.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77297
[danvet: Resolve conflict since I've plucked this out of the middle of
Ville's series.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like on hsw/bdw the pipe isn't actually running yet at this point.
This holds for both pch ports and the cpu edp port according to my
testing on ilk, snb and ivb.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77297
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This cleans up the checkpatch errors for the merged commit -
commit d3b542fcfc
Author: Shobhit Kumar <shobhit.kumar@intel.com>
Date: Mon Apr 14 11:00:34 2014 +0530
drm/i915: Add parsing support for new MIPI blocks in VBT
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When linking the i2c sysfs file into the connector's directory
pass directory and link target in the right order.
This code was introduced with:
commit 931c1c2698
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Feb 11 17:12:51 2014 +0200
drm/i915: sdvo: add i2c sysfs symlink to the connector's directory
This is the same what we do for DP connectors, so make things more
consistent.
Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the recent primary-plane changes for drm, the primary plane's
framebuffer needs to be ref counted the same way as for
non-primary-planes. This was not done by the omapdrm driver, which
caused the ref count to drop to 0 too early, causing problems.
This patch moves the fb unref and ref from omap_plane_update to
omap_plane_mode_set. This way the fb refs are updated for both primary
and non-primary cases, as omap_plane_update calls omap_plane_mode_set.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The vblank_cb callback and the page_flip ioctl can occur together in different
CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when
sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb.
Use the same spinlock in page_flip, to make sure the above omap_crtc parameters
are configured sequentially.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omap_crtc->old_fb is used to check whether the previous page flip has completed
or not. However, it's never initialized to anything, so it's always NULL. This
results in the check to always succeed, and the page_flip to proceed.
Initialize old_fb to the fb that we intend to flip to through page_flip, and
therefore prevent a future page flip to proceed if the last one didn't
complete.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The channel_names list didn't have a string populated for LCD3 manager, this
results in a crash when the display's output is connected to LCD3. Add an entry
for LCD3.
Reported-by: Somnath Mukherjee <somnath@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
A waiter of the type OMAP_GEM_READ should wait for a buffer to be completely
written, and only then proceed with reading it. A similar logic applies for
waiters with OMAP_GEM_WRITE flag.
Currently the function is_waiting() waits on the read_complete/read_target
counts in the sync object.
This should be the other way round, as a reader should wait for users who are
'writing' to this buffer, and vice versa.
Make readers of the buffer(OMAP_GEM_READ) wait on the write counters, and
writers to the buffer(OMAP_GEM_WRITE) wait on the read counters in is_waiting()
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In omap_gem_op_async(), if a waiter is not added to the wait list, it needs to
be free'd in the function itself.
Make sure we free the waiter for this case.
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Patch dfe96ddcfa (omapdrm: simplify locking in
the fb debugfs file) removed taking locks when using omapdrm's debugfs
to dump fb objects.
However, in omap_gem_describe we give a WARN is the lock has not been
taken, so that WARN is now seen every time omapdrm debugfs is used.
So, presuming the removal of locks is ok, we can also remove the WARN.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
All the planes, including primary planes, are now destroyed by the drm
framework. Thus we no longer need the explicit call to plane->destroy
from the crtc's destroy function.
This patch removes the call, thus fixing the crash caused by double
freeing the plane.
remove omap_crtc->plane->funcs->destroy(omap_crtc->plane)
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Print a warning when the user tries to rotate a non-TILER framebuffer.
Also set the rotation to 0, to avoid constant flood of the warnings in
case of page flipping.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omap_fbdev_create() takes a reference to the fb's gem object with
omap_gem_get_paddr(). However, it never releases it with
omap_gem_put_paddr().
This patch adds the missing omap_gem_put_paddr() to omap_fbdev_free().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Plane rotation with omapdrm is currently broken.
It seems omap_plane_mode_set() expects width and height in screen
coordinates, so pass it like that.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
At the moment the omap_crtc_pre_apply() handles the enabling, disabling
and configuring of encoders and panels separately from the CRTC (i.e.
the overlay manager).
However, this doesn't work correctly. The encoder driver has to be in
control of its video input (i.e. the crtc) for correct operation.
This problem causes bugs with (at least) HDMI: the HDMI encoder supplies
pixel clock for DISPC, and DISPC supplies video stream for HDMI. The
current code first enables the HDMI encoder, and CRTC after that.
However, the encoder expects the video stream to start during the
encoder's enable, and if it doesn't, there will be sync lost errors.
The encoder enables its video source by calling src->enable(), and this
call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything
in that function. Similarly for disable, which goes to
omap_crtc_disable().
This patch moves the code to setup and enable/disable the crtc to
omap_crtc_enable. and omap_crtc_disable().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
When an encoder is no longer connected to a crtc, the driver will leave
the encoder enabled.
This patch adds code to track the encoder used for a crtc, and when the
encoder changes, the old one is disabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
At module unload, omap_fbdev_free() gets called which releases the
framebuffers. However, the framebuffers are still used by crtcs, and
will be released only later at vsync. The driver doesn't wait for this,
and goes on to release the rest of the resources, which often
causes a crash.
This patchs adds a omap_crtc_flush() function which waits until the crtc
has finished with its apply queue and page flips.
The function utilizes a simple polling while-loop, as the performance is
not an issue here.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
At the moment the DMM driver is never unregistered, even if it's
registered in the omapdrm module's init function. This means we'll get
errors when reloading the omapdrm module.
Fix this by unregistering the DMM driver properly, and also change the
module init to fail if DMM driver cannot be registered, simplifying the
unregister path as we don't need to keep the state whether we registered
the DMM driver or not.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
When unloading omapdrm driver, the omapdrm platform device is
uninitialized last, after the displays have been disconnected omap_crtc
callbacks have been removed. As the omapdrm pdev uninitialization needs
the features uninitialized in earlier steps, a crash is guaranteed.
This patch fixes the uninitialize order so that the omapdrm pdev is
removed first.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
At the moment it's quite easy to get the following errors when the HDMI
output is enabled or disabled:
[drm:omap_crtc_error_irq] *ERROR* tv: errors: 00008000
The reason for the errors is that the omapdrm driver doesn't properly
handle the sync-lost irqs that happen when enabling the DIGIT crtc,
which is used for HDMI and analog TV. The driver does disable the
sync-lost irq properly, but it fails to wait until the output has been
fully enabled (i.e. the first vsync), so the sync-lost errors are still
seen occasionally.
This patch makes the omapdrm act the same way as the omapfb does:
- When enabling a display, we'll wait for the first vsync.
- When disabling a display, we'll wait for framedone if available, or
odd and even vsyncs.
These changes make sure the output is fully enabled or disabled at the
end of the function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Sanjay Singh Rawat <sanjay.rawat@linaro.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.
v2: Address review comments by Jani
- adjust code for the structure changes for bdb_mipi_config
- add boundry and buffer overflow checks as suggested
- use kmemdup instead of kmalloc and memcpy
v3: More strict check while parsing VBT
- Ensure that at anytime we do not go beyond sequence block
while parsing
- On unknown element fail the whole parsing
v4: Style changes and spell check mostly as suggested by Jani
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Apparently we really only need this when the pfit is enabled, at least
I couldn't dicern any difference here. Furthermore the hacks we have
to reconstruct this bit is a bit glaring, and probably only works
because we can't move the lvds port to any other pipe than pipe B on
gen2/3.
So let's just rip this out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77137 (the LVDS
WARNING log, not the main "VGA can't be turned on" issue).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we always initialize kref for the context, even if we are using fake
contexts for hangstats when there is no hw support, we can forgo the
dance to dereference the ctx->obj and inspect whether we are permitted
to use kref inside i915_gem_context_reference() and _unreference().
My ulterior motive here is to improve the debugging of a use-after-free
of ctx->obj. This patch avoids the dereference here and instead forces
the assertion checks associated with kref.
v2: Refactor the fake contexts to being even more like the real
contexts, so that there is much less duplicated and special case code.
v3: Tweaks.
v4: Tweaks, minor.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76671
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: lu hua <huax.lu@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[Jani: tiny change to backport to drm-intel-fixes.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Some machines use an external EC for controlling the backlight. Info
about this is present in the VBT. Do not setup native backlight control
if no PWM backlight is available or supported according to VBT. The
acpi_backlight interface appears to work for the EC control.
In most cases there has been no harm done, but it looks like there are
machines out there that have both an EC and our PWM line connected to
the same wire. This, obviously, does not end well.
This should fix the regression caused by
commit bc0bb9fd1c
Author: Jani Nikula <jani.nikula@intel.com>
Date: Thu Nov 14 12:14:29 2013 +0200
drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE
AFAICT the quirk removed by the above commit effectively resulted in
i915 not driving the backlight PWM output, thus not messing things up.
Additionally this should fix the regression caused by
commit fbc9fe1b4f
Author: Aaron Lu <aaron.lu@intel.com>
Date: Fri Oct 11 21:27:45 2013 +0800
ACPI / video: Do not register backlight if win8 and native interface exists
which left some machines without a functioning backlight interface.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76276
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=62281
CC: Aaron Lu <aaron.lu@intel.com>
CC: Eric Griffith <EGriffith92@gmail.com>
CC: Kent Baxley <kent.baxley@canonical.com>
Tested-by: Kamal Mostafa <kamal@canonical.com>
Tested-by: Martin <bugs@mrvanes.com>
Tested-by: jrg.otte@gmail.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The only supported types are none and PWM. Other values are obsolete or
reserved, don't add them.
Tested-by: Kamal Mostafa <kamal@canonical.com>
Tested-by: Martin <bugs@mrvanes.com>
Tested-by: jrg.otte@gmail.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This is a requirement added to the spec. This patch will prevent
persistent corruption on the display.
v2: Make the wait before the vblank wait. (Art)
Try to finish early by polling the register
s/present/prevent (Chris)
Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Upgrade debug output to ERROR.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch computes and stored 2nd M/N/TU for switching to different
refresh rate dynamically. PIPECONF_EDP_RR_MODE_SWITCH bit helps toggle
between alternate refresh rates programmed in 2nd M/N/TU registers.
v2: Daniel's review comments
Computing M2/N2 in compute_config and storing it in crtc_config
v3: Modified reference to edp_downclock and edp_downclock_avail based on the
changes made to move them from dev_private to intel_panel.
v4: Modified references to is_drrs_supported based on the changes made to
rename it to drrs_support.
v5: Jani's review comments
Removed superfluous return statements. Changed support for Gen 7 and above.
Corrected indentation. Re-structured the code which finds crtc and connector
from encoder. Changed some logs to be less verbose.
v6: Modifying i915_drrs to include only intel connector as intel_dp can be
derived from intel connector when required.
v7: As per internal review comments, acquiring mutex just before accessing
drrs RR. As per Chris's review comments, added documentation about the use
of locking in the function.
v8: Incorporated Jani's review comments.
Removed reference to edp_downclock.
v9: Jani's review comments. Modified comment in set_drrs. Changed index to
type edp_drrs_refresh_rate_type. Check if PSR is enabled before setting
registers fo DRRS.
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode.
It also checks the VBT fields to see if panel supports seamless DRRS or not.
Based on above data it marks whether eDP panel supports seamless DRRS or not.
This information is needed for supporting seamless DRRS switch for certain
power saving usecases. This patch is tested by enabling the DRM logs and
user should see whether Seamless DRRS is supported or not.
v2: Daniel's review comments
Modified downclock deduction based on intel_find_panel_downclock
v3: Chris's review comments
Moved edp_downclock_avail and edp_downclock to intel_panel
v4: Jani's review comments.
Changed name of the enum edp_panel_type to drrs_support type.
Change is_drrs_supported to drrs_support of type enum drrs_support_type.
v5: Incorporated Jani's review comments
Modify intel_dp_drrs_initialize to return downclock mode. Support for Gen7
and above.
v6: Incorporated Chris's review comments.
Changed initialize to init in intel_drrs_initialize
v7: Incorporated Jani's review comments.
Removed edp_downclock and edp_downclock_avail. Return NULL explicitly.
Make drrs_state and unnamed struct. Move Gen based check inside drrs_init.
v8: Made changes to track PSR enable/disable throughout system use (instead
of just in the init sequence) for disabling/enabling DRRS. Jani's review
comments.
v9: PSR tracking will be done as part of idleness detection patch. Removed
PSR state tracker in i915_drrs. Jani's review comments.
v10: Added log for DRRS not supported in drrs_init
v11: Modification in drrs_init. suggested by Jani
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Apparently it doesn't work. X-tiled self-refresh works flawlessly
otoh. Apparently X still works correctly with linear framebuffers, so
might just be an issue with the initial modeset. It's unclear whether
this just borked wm setup from our side or a hw restriction, but just
disabling gets things going.
Note that this regression was only brought to light with
commit 3f2dc5ac05
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Jan 10 14:06:47 2014 +0200
drm/i915: Fix 915GM self-refresh enable/disable
before that self-refresh for i915GM didn't work at all.
Kudos to Ville for spotting a little bug in the original patch I've
attached to the bug.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103
Tested-by: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: rebase on top of drm-next with primary plane support.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC
return value to detect overlapping framebuffers (which the bios uses
always when lighting up more than one screen). All this fanciness
happens in intel_alloc_plane_obj in intel_display.c.
Since no one else uses this we can safely remove the WARN without
repercussions.
Reported-by: Ben Widawsky <benjamin.widawsky@intel.com>
Tested-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts commit 4b28a1f3ef.
This patch duct-tapes over some issue in the current bdw rps patches
which must wait with enabling rc6/rps until the very first batch has
been submitted by userspace.
But those patches aren't merged yet, and for upstream we need to have
an in-kernel emission of the very first batch. I shouldn't have
merged this patch so let's revert it again.
Also Imre noticed that even when rps is set up normally there's a
small window (due to the 1s delay of the async rps init work) where we
could runtime suspend already and blow up all over the place. Imre has
a proper fix to block runtime pm until the rps init work has
successfully completed.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We will treat Cherryview like Valleyview for most parts. Add a macro
for cases when we need to tell the two apart.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some MIPI panels might not have resolution which is a multiple of 64 like
1366x768. Enable this feature for such panels by default
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Though HS mode also should work.
v2: Change parameter as "bool hs" as suggested by Jani
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for Generic driver
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise, this can stall pipe. We also need DPLL REFA always
enabled
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As per the hw team's recommendation we need to enable the MIPI port
before enabling the plane and pipe. So call MIPI port enable in
pre_enable phase itself
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These are additional registers needed for performance monitoring and
ARB_draw_indirect extensions in mesa.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76719
Cc: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
[danvet: Squash in fixup from Brad requested by Ken.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
haswell_write_eld() is also used on broadwell, so let's not explicitely
mention Haswell. The rest of the function has plenty of debug output
which will print the function name, so we know where we are anyway.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is now clear that this interrupt is for the primary plane and not
something global to the pipe. It also matches what the spec calls it.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Piglit runner and QA are both looking at the dmesg for
DRM_ERRORs with test cases. Add a flag to control those
when we they are expected from related test cases.
Also add flag to control if contexts should be banned
that introduced the hang. Hangcheck is timer based and
preventing bans by adding sleeps to testcases makes
testing slower.
v2: intel_ring_stopped(), readable comment (Chris)
v3: keep compatibility (Daniel)
References: https://bugs.freedesktop.org/show_bug.cgi?id=75876
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since dma_buf_vunmap() procedes blithely on ignorant of whether the
driver failed to actually unmap the backing storage for the dma-buf, we
need to make a best-effort to do so. This involves not allowing
ourselves to be susceptible to signals causing us to leak the storage.
This should have been detectable with the current i-g-t as a misplaced
signal should have left the pages pinned upon freeing the object where
we have a warning in place.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment from Ben: It's a bit unclear whether we need this dance still
on bdw.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GEN8 now has a qword to code for 48bit addresses.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems like it wouldn't be too unlikely to be wanting to use a an
expression in the macro argument and things could go very wrong.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Needs to happen after clock is running or it doesn't behave correctly.
v2: fix subject (Ville)
make it clearer that this occurs in pre_enable (Paulo)
misc bikesheds (Paulo)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allows sending of the null packets for conformance.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We also do a disable later when we write a specific infoframe, but here
we do it to prevent sending a stale one before updating the infoframes.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In case we end up bouncing these around between ports.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We will have another use for the maximum watermark values that the
registers can hold. Pull those out into separate functions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even though the inactive pipes should have their watermarks set to all 0
with enable=true, we can possibly shave off a few cycles by completely
skipping the merge procedure for inactive pipes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_pipe_wm will be used to track the state in different stages
of the watermark update process. For that we need to keep a bit
more state in intel_pipe_wm.
We also need to separate the multi-pipe intel_wm_config computation
from ilk_compute_wm_parameters() as that one deals with the future
state, and we need the intel_wm_config to match the current hardware
state at the time we do the watermark merging for multiple pipes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Frob conflict.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we've learned over time, the HW context is just a series of GPU
commands that we're able to decode without any changes in
intel_error_decode. Since many bugs recently have been implicated in
the HW context state, it makes sense to dump the whole context object
in a form which can be parsed.
Sample:
render ring --- HW Context = 0x042db000
ringbuffer (render ring) at 0x0160c000; HEAD points to: 0x0160c000
0x0160c000: 0x00000000: MI_NOOP
0x0160c004: 0x00000000: MI_NOOP
0x0160c008: 0x00000000: MI_NOOP
0x0160c00c: 0x00000000: MI_NOOP
0x0160c010: 0x00000000: MI_NOOP
0x0160c014: 0x00000000: MI_NOOP
0x0160c018: 0x00000000: MI_NOOP
0x0160c01c: 0x00000000: MI_NOOP
Unfortunately, our decoder isn't quite smart enough to deal with the
variable length LRIs - but that is a tools problem.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Clarify commit message a bit, seems to have lost a few
crucial words.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I opted to do this instead of grabbing the context reference after
eb_create since eb_create can potentially call the shrinker, and that
makes things very complicated. This simple patch balances the ref count
without requiring a great deal of review to make sure the shrinker path
is safe.
Theoretically (by design) the shrinker can end up destroying a context,
which enforces the reasoning for doing the fix this way instead of
moving the reference to later in the function.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Sprite LP2+ registers don't exist on ILK/SNB so don't read them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't do CPU access to GPU contexts so making the GPU access snoop
the CPU caches seems silly, and potentially expensive.
v2: Use !IS_VALLEYVIEW instead of HAS_LLC as this is really
about what the PTEs can represent.
Add a comment clarifying the situation.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Gen4+ platforms (except BDW), Render Cache Operational flush
cannot be enabled.
This WA is apparently required for all Gen4+ platforms,except BDW.
In BDW, the bit has been repurposed otherwise.
This has been tested only on vlv.
v2: Corrected the code regarding the wrong usage of
MASKED_BIT_DISABLE (Chris)
v3: Enhancing the scope of WA to Gen4+ platforms except BDW (Ville)
v4: Adding WA for g4x, crestline, broadwater (Ville)
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sourab Gupta <sourab.gupta@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge drm-next after the big s/crtc->fb/crtc->primary->fb/
cocinelle patch to avoid endless amounts of conflict hilarity in my
-next queue for 3.16.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
There is actually quite a bit of variance based on
the asic.
v2: fix typo noticed by Jerome.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
If you are using the common dp over i2c functionality, it is
asumed that the aux transfer function does not modify the any
of the msg structure other than the reply field. Doing so
breaks the logic in the common code.
v2: update struct drm_dp_aux comments about assumptions
v3 (chk): rebased on upstream changes
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions. This mirrors what the existing dp i2c
over aux algo currently does.
This fixes EDID fetches on certain monitors especially with
dp bridges.
v2: update as per Ville's comments
- Set buffer to NULL for zero sized packets
- abort the entre transaction if one of the messages fails
v3: drop leftover debugging code
v4: integrate Thierry's comments
- add comments about address only transactions
- switch back to i and j
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Needed for proper i2c over aux handling for certain
monitors and configurations (e.g., dp bridges or
adapters).
v2: add comments clarifying tx_size setting.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Certain types of I2C-over-AUX transactions require that only the address
is transferred. Detect this by looking at the AUX message's size and set
the address-only bit appropriately.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Loading cursors to the LCD controller's SRAM can be corrupted when the
configured pixel clock is relatively slow. This seems to be caused
when we write back-to-back to the SRAM registers.
There doesn't appear to be any status register we can read to check
when an access has completed.
Inserting a dummy read between the writes appears to fix the problem.
Cc: <stable@vger.kernel.org> # 3.13
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These changes are mostly for ARM specific device drivers that either
don't have an upstream maintainer, or that had the maintainer ask
us to pick up the changes to avoid conflicts. A large chunk of this
are clock drivers (bcm281xx, exynos, versatile, shmobile), aside from
that, reset controllers for STi as well as a large rework of the
Marvell Orion/EBU watchdog driver are notable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUz/1+GCrR//JCVInAQJmfg/9GyqHatDjjUPUBjUQRIEtKgGdmQwdbDqF
x+OrS/q5B5zYbpIWkbkt1IUYJfU+89Z5ev9jxI4rV824Nu9Y92mHPDnv+N/ptkIh
q2OVP3bQDpWs3aEVV2B1HBNcWrNUuwco9BJu05eegEePii/cto0/wKwWIgUmrmjy
xOLthsnp2YmeplGs7ctC6Dz8XbmELebpawejTGylARXei/SwmzB/YYDgJbYjRL2I
WSCVa8Vo+MZaGC/yxdKVTtvsKVQenxGoMO3ojikJeRdvuVRJds48Cw+UBdzWYNeJ
3Ssvbdx6Xltf9jy/7H0btOUgxPetZuUV+2XpbWfGu0Zr9FcGDv3q9hrxA+UYKnkY
GIGU0otSsmpHnX5Ms3E2xnHiV/fihxA3qohqts5kYRBDr5uc+IpW6SbDymQliCGG
OO4XmIVM3pmsqAqP3Zuseemt9CeSW2yC0XlfXkzjO74yY39c+WLBbtGI40Z5W6i0
mM1C8RD3QSNijYCEC8eqz06BQfRImsPs+jllsnJTZaHfbOsib718uvandjfG26lN
616YMcqq0Sp51HIQ4qW7f2dQr7vOyNqbukdkrwF5JgkY/nVki5kdciRg/yeipRy6
Ey80a+OTq0GQljM0F2dcH/A1eHH9KsuI1L6NdSMJsl0h6guIBORPTwTw3qJ13OkR
wpJyM+Gm+Fk=
=u/FI
-----END PGP SIGNATURE-----
Merge tag 'drivers-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver changes from Arnd Bergmann:
"These changes are mostly for ARM specific device drivers that either
don't have an upstream maintainer, or that had the maintainer ask us
to pick up the changes to avoid conflicts.
A large chunk of this are clock drivers (bcm281xx, exynos, versatile,
shmobile), aside from that, reset controllers for STi as well as a
large rework of the Marvell Orion/EBU watchdog driver are notable"
* tag 'drivers-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (99 commits)
Revert "dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac."
Revert "net: stmmac: Add SOCFPGA glue driver"
ARM: shmobile: r8a7791: Fix SCIFA3-5 clocks
ARM: STi: Add reset controller support to mach-sti Kconfig
drivers: reset: stih416: add softreset controller
drivers: reset: stih415: add softreset controller
drivers: reset: Reset controller driver for STiH416
drivers: reset: Reset controller driver for STiH415
drivers: reset: STi SoC system configuration reset controller support
dts: socfpga: Add sysmgr node so the gmac can use to reference
dts: socfpga: Add support for SD/MMC on the SOCFPGA platform
reset: Add optional resets and stubs
ARM: shmobile: r7s72100: fix bus clock calculation
Power: Reset: Generalize qnap-poweroff to work on Synology devices.
dts: socfpga: Update clock entry to support multiple parents
ARM: socfpga: Update socfpga_defconfig
dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac.
net: stmmac: Add SOCFPGA glue driver
watchdog: orion_wdt: Use %pa to print 'phys_addr_t'
drivers: cci: Export CCI PMU revision
...
Imre Deak