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>