Depending on exact point of failure, not cleaning would lead to
BUG_ONs/oopses in various distant places.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Port change from "drm/nouveau: Keep RAMIN heap within the channel"
to kernel channel, which has its own ramin heap initialisation.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Younes Manton <younes.m@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Kepler GRAPH has (well, sorta) fixed subchannel<->class assignments, make
this match up to keep it happy without trapping.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This may, perhaps, get re-merged with nvc0_graph.c at some point. It's
still unclear as to how great an idea that'd be. Stay tuned...
Completely dependent on firmware blobs from NVIDIA binary driver currently.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not entirely convinced 0x004018 transitions are correct yet, but, it's
an improvement.
The 750MHz value comes from fiddling with the binary driver + coolbits on
two different DDR3 NVA8 chipsets (T510 NVS3100M, and NVS300), not a clue
where this number comes from.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Probably not quite right, but this is enough now to make NVS300 reclock
between all 3 of its perflvls correctly.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This probably wants a cleanup, but I'm holding off until I know for sure
how the rest of the things that need doing fit together.
Tested on NVS300 by hacking up perflvl 1 to require PLL mode, and switching
between perflvl 3 and 1.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The binary driver appears to do various bits and pieces of the memory
clock frequency change at different times, depending on the particular
transition that's occuring. I've attempted to replicate this here
for div->pll, pll->div and div->div transitions.
With some additional (patches upcoming) magic regs being bashed, this
allows me to correctly transition between all 3 perflvls on NVS300.
pll->pll transitions will *not* work correctly at the moment, pending
me tricking the binary driver into doing one and seeing how to correctly
handle it.
This patch also handles (hopefully) 0x1110e0, which appears to need
changing depending on whether in PLL or divider mode.. Maybe. We'll
see.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The reg calculation may get moved elsewhere at some point, but lets
figure out what exactly we need to do first.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This adds prime->fd and fd->prime support to radeon.
It passes the sg object to ttm and then populates
the gart entries using it.
Compile tested only.
v2: stub kmap + use new helpers + add reimporting
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds handle->fd and fd->handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.
v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.
Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.
Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.
Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).
Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.
v3: Right when I've hit sent I've noticed that I've screwed up one
obj->sg_list (for dmar support) and obj->sg_table (for prime support)
disdinction. We should be able to merge these 2 paths, but that's
material for another patch.
v4: fix the error reporting bugs pointed out by ickle.
v5: fix another error, and stop non-gtt mmaps on shared objects
stop pread/pwrite on imported objects, add fake kmap
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This adds prime->fd and fd->prime support to nouveau,
it passes the SG object to TTM, and then populates the
GART entries using it.
v2: add stubbed kmap + use new function to fill out pages array
for faulting + add reimport test.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the ability for ttm common code to take an SG table
and use it as the backing for a slave TTM object.
The drivers can then populate their GTT tables using the SG object.
v2: make sure to setup VM for sg bos as well.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
udl can only be used as an output offload so doesn't need to support
handle->fd direction.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If userspace attempts to import a buffer it exported on the same device,
we need to return the same GEM handle for it, not a new handle pointing
at the same GEM object.
v2: move removals into a single fn, no need to set to NULL. (Chris Wilson)
Signed-off-by: Dave Airlie <airlied@redhat.com>
the ttm drivers need this currently, in order to get fault handling
working and efficient.
It also allows addrs to be NULL for devices like udl.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull trivial updates from Jiri Kosina:
"As usual, it's mostly typo fixes, redundant code elimination and some
documentation updates."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (57 commits)
edac, mips: don't change code that has been removed in edac/mips tree
xtensa: Change mail addresses of Hannes Weiner and Oskar Schirmer
lib: Change mail address of Oskar Schirmer
net: Change mail address of Oskar Schirmer
arm/m68k: Change mail address of Sebastian Hess
i2c: Change mail address of Oskar Schirmer
net: Fix tcp_build_and_update_options comment in struct tcp_sock
atomic64_32.h: fix parameter naming mismatch
Kconfig: replace "--- help ---" with "---help---"
c2port: fix bogus Kconfig "default no"
edac: Fix spelling errors.
qla1280: Remove redundant NULL check before release_firmware() call
remoteproc: remove redundant NULL check before release_firmware()
qla2xxx: Remove redundant NULL check before release_firmware() call.
aic94xx: Get rid of redundant NULL check before release_firmware() call
tehuti: delete redundant NULL check before release_firmware()
qlogic: get rid of a redundant test for NULL before call to release_firmware()
bna: remove redundant NULL test before release_firmware()
tg3: remove redundant NULL test before release_firmware() call
typhoon: get rid of redundant conditional before all to release_firmware()
...
The omapdrm driver uses this for setting per-overlay rotation. It
is likely also useful for setting YUV->RGB colorspace conversion
matrix, etc.
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A bitmask property is similar to an enum. The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1 << enum_val[n]).
[airlied: 1LL -> 1ULL]
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung:
drm/exynos: add G2D driver
drm/exynos: added vp scaling feature for hdmi
drm/exynos: added source size to overlay structure
drm/exynos: add additional display mode for hdmi
drm/exynos: enable dvi mode for dvi monitor
drm/exynos: fixed wrong pageflip finish event for interlace mode
drm/exynos: add PM functions for hdmi and mixer
drm/exynos: add dpms for hdmi
drm/exynos: use threaded irq for hdmi hotplug
drm/exynos: use platform_get_irq_byname for hdmi
drm/exynos: cleanup for hdmi platform data
drm/exynos: added a feature to get gem buffer information.
drm/exynos: added drm prime feature.
drm/exynos: added cache attribute support for gem.
vgaarb: Provide dummy default device functions
Drivers for hardware without gamma support should not be forced to
implement a no-op gamma set operation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DRM mode config functions structure declared by drivers and pointed
to by the drm_mode_config funcs field is never modified. Make it a const
pointer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Rob Clark <rob.clark@linaro.org>
Reviwed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The GEM vm operations structure is passed to the VM core that stores it
in a const field. There vm operations structures can thus be const in
DRM as well.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <rob.clark@linaro.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A race condition exists in drm_vblank_cleanup() if the vblank disable
timer callback runs after freeing the memory that its callback function
tries to access. Fix this by deleting the timer synchronously.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The power field was never correctly initialized.
[airlied: just took the two drm specific bits]
Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Poulsbo needs a physical address in the cursor base register. We allocate a
stolen memory buffer and copy the cursor image provided by userspace into it.
When/If we get our own userspace driver we can map this stolen memory directly.
The patch also adds a mark in chip ops so we can identify devices that has this
requirement.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some devices don't have a panel connected to LVDS and thus will never power up.
This patch checks the power sequence progress bits in PP_STATUS to prevent an
endless loop on such devices.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This seems to be wrong to me, spotted while thinking about dma-buf.
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to remove the debugfs file. Regression introduce in
commit d54423037f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 27 15:17:40 2012 +0200
drm/i915: allow the existing error_state to be destroyed
Reported-and-Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... flaky ddc hardware can cause a spurious NAK, resulting in the i2c
core and drm edid functions not trying to retry the edid transfer.
Luckily the gmbus quiescenting also times out for these cases, so we
can get out of this mess by returning -ETIMEDOUT for this specific
case. This way we keep the fast-fail of returning -ENXIO if there is
no device present, speeding up the boot process.
This regression has been introduced in
commit e646d57735
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Fri Mar 30 19:46:38 2012 +0800
drm/i915/intel_i2c: always wait for IDLE before clearing NAK
v2: Return -ETIMEDOUT for this case and keep the -ENXIO for real NAKs,
suggested by Daniel Kurtz.
Cc: Daniel Kurtz <djkurtz@chromium.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518
Reported-and-Tested-by: Julian Simioni <julian.simioni@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel wrote:
The last pull I'd like to squeeze into 3.5, safe for the hsw stuff mostly
bugfixes:
- last few patches for basic hsw enabling (Eugeni, infoframe support by
Paulo)
- Fix up infoframe support, we've hopefully squashed all the cargo-culting
in there (Paulo). Among all the issues, this finally fixes some of the
infoframe regressions seen on g4x and snb systems.
- Fixup sdvo infoframe support, this fixes a regression from 2.6.37.
- Correctly enable semaphores on snb, we've enabled it already for 3.5,
but the dmar check was slightly wrong.
- gen6 irq fixlets from Chris.
- disable gmbus on i830, the hw seems to be simply broken.
- fix up the pch pll fallout (Chris & me).
- for_each_ring macro from Chris - I've figured I'll merge this now to
avoid backport pain.
- complain when the rps state isn't what we expect (Chris). Note that this
is shockingly easy to hit and hence pretty much will cause a regression
report. But it only tells us that the gpu turbo state got out of whack,
a problem we know off since a long time (it cause the gpu to get stuck a
a fixed frequency, usually the lowest one). Chris is working on a fix,
but we haven't yet found a magic formula that works perfectly (only
patches that massively reduce the frequency of this happening).
- MAINTAINERS patch, I'm now officially the guy to beat up."
* tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel: (57 commits)
drm/i915: IBX has a fixed pch pll to pch pipe mapping
drm/i915: implement hsw_write_infoframe
drm/i915: small hdmi coding style cleanups
drm/i915: fixup infoframe support for sdvo
drm/i915: Enable the PCH PLL for all generations after link training
drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN
drm/i915: don't clobber the pipe param in sanitize_modesetting
drm/i915: disable gmbus on i830
drm/i915: Replace the feature tests for BLT/BSD with ring init checks
drm/i915: Check whether the ring is initialised prior to dispatch
drm/i915: Introduce for_each_ring() macro
drm/i915: Assert that the transcoder is indeed off before modifying it
drm/i915: hook Haswell devices in place
drm/i915: prepare HDMI link for Haswell
drm/i915: move HDMI structs to shared location
drm/i915: add WR PLL programming table
drm/i915: add support for DDI-controlled digital outputs
drm/i915: detect digital outputs on Haswell
drm/i915: program iCLKIP on Lynx Point
drm/i915: program WM_LINETIME on Haswell
...
This should fix breakage introduced in
commit ee7b9f93fd
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Apr 20 17:11:53 2012 +0100
drm/i915: manage PCH PLLs separately from pipes
v2: Add a DRM_DEBUG_KMS message to explain why a given pll was
selected, suggested by Chris Wilson.
v3: Actually run git add.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both the control and data registers are completely different now.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Changed the coding style of auxiliary infoframe functions to make
them smaller
- Fixed the column alignment of some function definitions
- Remove definition of "struct drm_crtc" in some places as they're
used only to retrieve "struct intel_crtc"
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least the worst offenders:
- SDVO specifies that the encoder should compute the ecc. Testing also
shows that we must not send the ecc field, so copy the dip_infoframe
struct to a temporay place and avoid the ecc field. This way the avi
infoframe is exactly 17 bytes long, which agrees with what the spec
mandates as a minimal storage capacity (with the ecc field it would
be 18 bytes).
- Only 17 when sending the avi infoframe. The SDVO spec explicitly
says that sending more data than what the device announces results
in undefined behaviour.
- Add __attribute__((packed)) to the avi and spd infoframes, for
otherwise they're wrongly aligned. Noticed because the avi infoframe
ended up being 18 bytes large instead of 17. We haven't noticed this
yet because we don't use the uint16_t fields yet (which are the only
ones that would be wrongly aligned).
This regression has been introduce by
3c17fe4b8f is the first bad commit
commit 3c17fe4b8f
Author: David Härdeman <david@hardeman.nu>
Date: Fri Sep 24 21:44:32 2010 +0200
i915: enable AVI infoframe for intel_hdmi.c [v4]
Patch tested on my g33 with a sdvo hdmi adaptor.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI)
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Hidden away within one chipset specific path was the necessary logic to
turn on the PLL. This needs to be done everywhere in order for us to
drive any display! As such as soon as we tested on a non-CougarPoint
chipset, we failed to bring up any DisplayPorts and generated a nice set
of assertion failures in the process. At least one part of our logic is
working, the part that assumes that we have no idea what we are doing.
Reported-by: guang.a.yang@intel.com
References: https://bugs.freedesktop.org/show_bug.cgi?id=49712
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>
Turn a fatal lockup into a merely blank display with lots of shouty
messages.
v2: Whilst in the area, convert the other BUG_ON into less fatal errors.
In particular, note that we may be called on a PCH platform not using
PLLs, such as Haswell, and so we do not always want to BUG_ON(!pll)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... we need it later on in the function to clean up pipe <-> plane
associations. This regression has been introduced in
commit f47166d2b0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Mar 22 15:00:50 2012 +0000
drm/i915: Sanitize BIOS debugging bits from PIPECONF
Spotted by staring at debug output of an (as it turns out) totally
unrelated bug.
v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
Chris Wilson.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Cc: stable@kernel.org (the regression was Cc: stable, too)
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hw just returns garbage.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838
Reported-and-tested-by: Vladyslav <DFEW.Entwickler@googlemail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When userspace asks whether the driver supports the BLT or BSD rings for
this chip, simply report whether those particular rings are initialised
v2: Use intel_ring_initialized()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than use the magic feature tests HAS_BLT/HAS_BSD just check
whether the ring we are about to dispatch the execbuffer on is
initialised.
v2: Use intel_ring_initialized()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In many places we wish to iterate over the rings associated with the
GPU, so refactor them to use a common macro.
Along the way, there are a few code removals that should be side-effect
free and some rearrangement which should only have a cosmetic impact,
such as error-state.
Note that this slightly changes the semantics in the hangcheck code:
We now always cycle through all enabled rings instead of
short-circuiting the logic.
v2: Pull in a couple of suggestions from Ben and Daniel for
intel_ring_initialized() and not removing the warning (just moving them
to a new home, closer to the error).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Added note to commit message about the small behaviour
change, suggested by Ben Widawsky.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Inspired by a recent regression that seems to confuse pch transcoder
state, let's be a bit more paranoid.
References: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Pimped commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch enables i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI, and enable the required clocks with correct dividers for the desired
frequency.
Also, we cannot simple reuse HDMI routines from previous generations of
GPU, as most of HDMI-specific stuff is being done via the DDI port
programming instead of HDMI-specific registers.
This commit take advantage of the WR PLL clock table which is in a
separate (previous) commit to select the right divisors for each mode.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move intel_hdmi data structure and support functions to a shared location,
to allow their usage from intel_ddi module.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
I split it into a separate patch to simplify the HDMI enabling patch which was
getting huge.
Note that this table is a temporary solution for WR PLL programming. It
will be reworked into a more exact algorithm at a later stage. But for
now, it provides the most accurate clock setting solution, so we use it
here.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those are driven by DDIs on Haswell architecture, so we need to keep track
of which DDI is being used on each output.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.
Note that this bit does not indicates whether the output is DP or HDMI.
However, the DDI buffers can be programmed in a way that is shared between
DP/HDMI and FDI/HDMI except for PORT E.
So for now, we detect those digital outputs as being HDMI, but proper DP
support is still pending.
Note that DDI A can only drive eDP, so we do not handle it here for hdmi
initialization.
v2: simplify Haswell handling logic
v3: use generic function for handling digital outputs.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
to do so, it must be programmed to properly do the clock ticks according
to the divisor, phase direction, phase increments and a special auxiliary
divisor for 20MHz clock.
v2: calculate divisor values directly instead of relying on a table.
v3: merged a fix from Ben to properly check for invalid divider values.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The line time can be programmed according to the number of horizontal
pixels vs effective pixel rate ratio.
v2: improve comment as per Chris Wilson suggestion
v3: incorporate latest changes in specs.
v4: move into wm update routine, also mention that the same routine can
program IPS watermarks. We do not have their enablement code yet, nor
handle the required clock settings at the moment, so this patch won't
program those values for now.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For now, we simple reuse the Ivy Bridge routines here.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Starting with Haswell, DDI ports can work in FDI mode to support
connectivity with the outputs located on the PCH.
This commit adds support for such connections in the intel_ddi module, and
provides Haswell-specific functionality to make it work.
v2: simplify the commit as per Daniel Vetter suggestion.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DDI is introduced starting with Haswell GPU generation. So to simplify its
management in the future, we also add intel_ddi.c to hold all the
DDI-related items.
Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the connection
parameters. HDMI uses the last pair of values and ignores the first 9
pairs. So we program HDMI values in both cases, which allows HDMI to work
over both FDI and DP-friendly buffers.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Haswell, only one pipe can work in FDI mode, so this patch prevents
messing with wrong registers when FDI is being used by non-first pipe. And
to prevent this, we also specify that the VGA can only be used on pipe 0
for now in the crtc_mask value.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prevent bogus asserts on DDI-related paths.
Longer explanation from Eugeni by mail:
"For the asserts there are 3 paths where we hit them:
- in assert_fdi_tx (we don't have the FDI_TX_CTL anymore, backup plan
DDI_FUNC_CTL is used instead)
- in assert_fdi_tx_pll_enabled (we have the combination of iCLKIP and
DDI_FUNC_CTL, plus PORT_CLK_SEL and PIPE_CLK_SEL now to make things
work). We could use an assert here indeed - if we configure port to
use one clock, and pipe to use another, everything hangs. Right now,
we configure all of them in one place only; but yes, when DP code
lands it will get more funky.
- and in ironlake_fdi_pll_enable. I reuse part of this function (to
configure the TU sizes), but as in the 1st case, FDI_TX_CTL is gone
so I just ignore it here."
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: Pasted Eugeni's explanation into the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This attempts to enable all the available power wells during the
initialization.
Those power wells can be enabled in parallel or on-demand, and disabled
when no longer needed, but this is out of scope of this initial
enablement. Proper tracking of who uses which power well will require
a considerable rework of our display handling, so we just leave them all
enabled when the driver is loaded for now.
v2: use more generic and future-proof code
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Haswell, the recommended PCH-connected output is the one driven by DDI
E in FDI mode, used for VGA connection. All the others are handled by the
CPU.
Note that this does not accounts for Haswell/PPT combination yet, so if we
encounter such combination an error message is thrown to indicate that
things could go wrong.
v2: improve non-LPT detection warning per Daniel Vetter's suggestion.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should be already configured when FDI auto-negotiation is done.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will throw a BUG() message when an unknown sdvox register is
given to intel_hdmi_init. When this happens, things could going to be pretty
much broken afterwards, so we better detect this as soon as possible.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As suggested by Chris Wilson and Daniel Vetter, this chunk of code can be
simplified with a more simple check.
Also, as noticed by Jesse Barnes, it is worth mentioning that plane is an
enum and num_pipe is an int, so we could be more paranoid here about those
validation checks eventually.
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This adds proper support for calculating those watermarks, checking for
number of available pipes instead of specific GPU variants when deciding
if watermarks for 3rd pipe are necessary.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.
v2: de-inline the function and address changes in bits names
v3: protect operations with dpio_lock, increase timeout to 100 for
paranoia sake.
v4: decrease paranoia a bit, as noticed by Chris Wilson
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Haswell interrupts are mostly similar with Ivy Bridge, so we share same
routines with it.
This patch also simplifies the vblank counter handling for all the Gen5+
architectures.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Haswell has different DIP control registers and offsets which we need to
use for infoframes, which this patch adds.
Note that this does not adds full DIP frames support, but only the basic
functionality necessary for HDMI to work in early enablement.
v2: replace infoframe handling with a debug message, proper support will
be added via a patch from Paulo Zanoni later.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we call gen6_enable_rps() (which writes into the per-ring
register mmio space) from intel_modeset_init_hw() which is called before
we initialise the rings. If we defer intel_modeset_init_hw() until
afterwards (in the intel_modeset_gem_init() phase) all is well.
v2: Rectify ordering of gem vs display HW init upon resume. (Daniel)
v3: Fix up locking. (Paulo)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Smash Paulo's locking fix onto Chris' patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This lets the kernel tell userspace if the device supports prime
import/export.
This is useful for -modesetting at least, but would be nice for other
drivers.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Introduce special struct radeon_afmt for this purpose.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Changelog v3:
- use __u64 instead of pointer in ioctl struct.
The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
This G2D driver is exynos drm specific and supports only G2D(version
4.1) of later Exynos series from Exynos4X12 because supporting DMA.
The G2D is performed by two tasks simply.
1. Configures the rendering parameters, such as foreground color and
coordinates data by setting the drawing context registers.
2. Start the rendering process by setting thre relevant command
registers accordingly.
The G2D version 4.1 supports DMA mode as host interface. User can make
command list to reduce HOST(ARM) loads. The contents of The command list
is setted to relevant registers of G2D by DMA.
The command list is composed Header and command sets and Tail.
- Header: The number of command set(4Bytes)
- Command set: Register offset(4Bytes) + Register data(4Bytes)
- Tail: Pointer of base address of the other command list(4Bytes)
By Tail field, the G2D can process many command lists without halt at
one go.
The G2D has following the rendering pipeline.
--> Primitive Drawing --> Rotation --> Clipping --> Bilinear Sampling
--> Color Key --> ROP --> Mask Operation --> Alpha Blending -->
Dithering --> FrameBuffer
And supports various operations from the rendering pipeline.
- copy
- fast solid color fill
- window clipping
- rotation
- flip
- 4 operand raster operation(ROP4)
- masking operation
- alpha blending
- color key
- dithering
- etc
User should make the command list to data and registers needed by
operation to use. The Exynos G2D driver only manages the command lists
received from user. Some registers needs memory base address(physical
address) of image. User doesn't know its physical address, so fills the
gem handle of that memory than address to command sets, then G2D driver
converts it to memory base address.
We adds three ioctls and one event for Exynos G2D.
- ioctls
DRM_EXYNOS_G2D_GET_VER: get the G2D hardware version
DRM_EXYNOS_G2D_SET_CMDLIST: set the command list from user to driver
DRM_EXYNOS_G2D_EXEC: execute the command lists setted to driver
- event
DRM_EXYNOS_G2D_EVENT: event to give notification completion of the
command list to user
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch adds vp scaling feature for exynos hdmi. Scaling ratio
between source and destination is used for width and height.
Also meaningless variables to set registers are cleaned.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Set plane has source size but exynos overlay structure did
not consider it. This patch adds source size to overlay
structure. For set crtc, source size is set from crtc size.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
1080p@30Hz mode is added to hdmi display mode.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Hdmi monitor and dvi monitor can be distinguished with edid.
This patch enables dvi mode if dvi monitor is connected and does
not enable audio feature for dvi mode because dvi has no audio
feature.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Pageflip finish event for interlace mode has bug on checking top
field vsync because of comparing between dma address converted
by start coordinates and non-converted dma address.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
All radeon_gem_init() does is initialize the gem objects
list. radeon_device.c does this explicitly. r600+ calls
radeon_gem_init() so the list gets initialized twice. Older
asics don't call it at all and rely on the the init in
radeon_device.c. Just call radeon_gem_init() in radeon_device.c
and remove the explicit calls from all the newer asics.
All asics call radeon_gem_fini() in their fini pathes. That
could possibly be cleaned up too.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
connector_names table is just a repeat of information that
already exists in drm_connector_enum_list and the same string
can be retrieved using drm_get_connector_name function.
Nuke the redundant table and use the proper function to retrieve
the connector name.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Without this, e.g. egltri_screen looks scrambled after a GPU reset.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It seems imac pannel doesn't like whe we change the hot plug setup
and then refuse to work. This help but doesn't fully fix:
https://bugzilla.redhat.com/show_bug.cgi?id=726143
v2: fix typo and improve commit message
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_core_ioremap() initializes ->handle. We already know
"dev->agp_buffer_map" is a valid pointer.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
CC [M] drivers/gpu/drm/i915/i915_gem_evict.o
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c: In function ‘psb_chip_errata’:
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:360:1: warning: no return statement in function returning non-void [-Wreturn-type]
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c: At top level:
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:379:2: warning: initialization from incompatible pointer type [enabled by default]
/ssd/git/drm-core-next/drivers/gpu/drm/gma500/psb_device.c:379:2: warning: (near initialization for ‘psb_chip_ops.errata’) [enabled by default]
Signed-off-by: Dave Airlie <airlied@redhat.com>
If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that:
drivers/gpu/drm/gma500/opregion.c:154:6: warning:
unused variable ‘max’ [-Wunused-variable]
Which give me a chance to use the new config_enabled() macro. :)
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We can just return -ENOMEM here if the allocation fails.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The i915 driver needs this for the rotation and overscan compensation
properties. Other drivers might need this too.
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This way, we don't need to count every time, so we're a little bit
faster and code is a little bit smaller.
Change suggested by Ville Syrjälä.
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the future, we may want to kill the internal functions:
- drm_connector_attach_property
- drm_connector_property_set_value
- drm_connector_property_get_value
It seems the IOCTL drm_mode_connector_property_set_ioctl will have to live, but
we may change libdrm to not use it anymore, if we want.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Useless for connector properties (since they already have their own
ioctls), but useful when we add properties to CRTCs, planes and other
objects.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For now, only connectors have it. In the future, all objects that need
properties should use it. Since the structure is referenced inside
struct drm_mode_object, we will be able to deal with object properties
without knowing the real type of the object.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Also return void instead of int. We have more than 100 callers and
no one checks for the return value.
If this function fails the property won't be exposed by the get/set
ioctls, but we should probably survive. If this starts happening,
the solution will be to increase DRM_CONNECTOR_MAX_PROPERTY and
recompile the Kernel.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move code from drm_mode_connector_property_set_ioctl to a new
function, so we can reuse this code when we add crtc properties.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Debugging the lid problem tested various error paths which were found
wanting so start fixing them up.
There is a ton of improvement work could be done here so that every bit
of functionality agrees if its _fini, _uninit, etc, and they agree who
is responsible for deciding if the clean up is needed.
That can come later.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The recent changes led to the lid timer code being run on various devices.
It does no harm on most but isn't needed. It also calls unconditionally
into the Poulsbo backlight code which goes bang on Cedartrail.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the initial driver for emulated cirrus GPU found in qemu.
This driver only supports the emulated GPU and doesn't attempt
to bind to any real cirrus GPUs.
This driver is intended to be used with xf86-video-modesetting in userspace.
It requires at least version 0.3.0
This follow the same design as ast and mgag200, and is based on work
done by Matthew Garrett previously.
This GPU has no hw cursor, and it can't scanout 32-bpp, only packed 24-bpp.
i.e. it sucks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a driver for the G200 server engines chips,
it doesn't driver any of the Matrix G series desktop cards.
It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards.
Its based on previous work done my Matthew Garrett but remodelled
to follow the same style and flow as the AST server driver. It also
works along the same lines as the AST server driver wrt memory management.
There is no userspace driver planned, xf86-video-modesetting should be used.
It also appears these GPUs have no ARGB hw cursors.
v2: add missing tagfifo reset + G200 SE memory bw setup pieces.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the initial driver for the Aspeed Technologies chips found in
servers. This driver supports the AST 2000, 2100, 2200, 2150 and 2300. It
doesn't support the AST11xx due to lack of hw to test it on, and them requiring
different codepaths.
This driver is intended to be used with xf86-video-modesetting in userspace.
This driver has a slightly different design than other KMS drivers, but
future server chips will probably share similiar setup. As these GPUs commonly
have low video RAM, it doesn't make sense to put the kms console in VRAM
always. This driver places the kms console into system RAM, and does dirty
updates to a copy in video RAM. When userspace sets a new scanout buffer,
it forcefully evicts the video RAM console, and X can create a framebuffer
that can use all of of video RAM.
This driver uses TTM but in a very simple fashion to control the eviction
to system RAM of the console, and multiple servers.
v2: add s/r support, fix Kconfig.
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'topic/vga-switcheroo' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
vga_switcheroo: Add the support for audio clients
vga_switcheroo: Introduce struct vga_switcheroo_client_ops
vga_switcheroo: Refactor using linked list
Add the support for audio clients to VGA-switcheroo for handling the
HDMI audio controller together with VGA switching. The id of the
audio controller should be given explicitly at registration time
unlike the video controller.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This changes the API as a clean-up. Instead of passing multiple
function pointers at each time, introduce a new struct holding the
whole callback functions and pass it to the registration.
The same struct will be used for the upcoming audio client
registration, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Daniel says
Highlights:
- sparse fixes from Ben.
- tons of little cleanups from Chris all over: tiling_changed
clarification, deferred_free list removal, ...
- fix up irq handler on gen2 & gen3 + related cleanups from Chris
- prep work for wait_rendering_timeout from Ben with some nice
refactorings
- first set of infoframe fixes from Paulo for doubleclocked CEA modes
- improve pch pll handling from Jesse and Chris
- gpu hangman, this also contains the reset fix for gen4
- rps sanity check from Chris - this papers over issues when the gpu fails
to clock up on snb/ivb, and it is shockingly easy to hit. The code
prints a big WARN backtrace and restores the hw to a sane state. The
real fix is still in the works.
Atm I'm aware of 2 regressions in -next:
- One of the gmbus patches (not gmbus itself) regressed lvds detection on
a MacbookPro. I've analyzed the bug already and I think I know what's
going on, patch is awaiting test feedback.
- Just today QA reported that DP on ilk regressed. That bug is fresh of
the press and still awaiting detailed logfiles and the bisect result.
The only thing that's clear atm is that -fixes works and -next doesn't.
Previously these functions would assume that vma->vm_file was the
drm_file. Although if in some cases if the drm driver needs to use
something else for the backing file (such as the tmpfs filp) then this
assumption is no longer true. But vma->vm_private_data is still the
GEM object.
With this change, now the drm_device comes from the GEM object rather
than the drm_file so the driver is more free to play with vma->vm_file.
The scenario where this comes up is for mmap'ing of cached dmabuf's
for non-coherent systems, where the driver needs to use fault handling
and PTE shootdown to simulate coherency. We can't use the vma->vm_file
of the dmabuf, which is using anon_inode's address_space. The most
straightforward thing to do is to use the GEM object's obj->filp for
vma->vm_file in all cases, for which we need this patch.
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't need to check these - they are always going to be the
same for any PVR based device.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cover all D2xxx/N2xxx chips.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[Hand applied to upstream driver]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have a lot of debug type stuff we don't actually need any more.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All the conditional ugly register selection really wants to be
cleaned up. Use a struct describing each pipe and its registers.
This will also let us hide some of the oddments between platforms
for any future merging of bits together. In particular the way the
DPLL and FP registers randomly wander around.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have lots of local assignments that can now be eliminated
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This starts the move away from lots of confused unions of per driver stuff
inherited when we merged the drivers together.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We can take advantage that the PCH_IIR is a subordinate register to
reduce one of the required IIR reads, and that we only need to clear
interrupts handled to reduce the writes. And by simply tidying the code
we can reduce the line count and hopefully make it more readable.
v2: Split out the bugfix from the refactoring.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently the code re-reads PCH_IIR during the hotplug interrupt
processing. Not only is this a wasted read, but introduces a potential
for handling a spurious interrupt as we then may not clear all the
interrupts processed (since the re-read IIR may contains more interrupts
asserted than we clear using the result of the original read).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Inspired by the recent ppgtt regression report, where switching of
dmar only for the gpu seems to fix things completely, I've looked
again at the semaphores+vt-d situation.
Contrary to my earlier testing a few months back my system is now
stable with dmar disabled for the igd, and not only when disabling
dmar completely.
So I'm rather hopeful that all our recent fixes for snb have changed
things for code and it's time to try enabling semaphores again. We've
also had issues with enabling semaphores which are not vt-d related,
but I guess these are all fixed by the autoreport-disabling and lazy
request fix. And there's only one way to find out whether there are
still other issues ...
When I've tried to apply this patch I've noticed that semaphores on
gen6 have already silently been enabled in
commit 2911a35b2e
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Thu Apr 5 14:47:36 2012 -0700
drm/i915: use semaphores for the display plane
Fix this up by only checking whether dmar is enabled on the gfx (not
on the entire system).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/ssd/git/drm-core-next/drivers/gpu/drm/radeon/radeon_fence.c: In function ‘radeon_debugfs_fence_info’:
/ssd/git/drm-core-next/drivers/gpu/drm/radeon/radeon_fence.c:606:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘long long int’ [-Wformat]
Signed-off-by: Dave Airlie <airlied@redhat.com>
No need to malloc it any more.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Christian König <deathsimple@vodafone.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Marcin Slusarz