Age | Commit message (Collapse) | Author | Files | Lines |
|
When the SOR is disabled in DP mode as part of an unplug event, do not
attempt to power the DP link down. Powering down the link requires the
DPAUX to transmit AUX messages which only works if there's a connected
sink.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The SOR0 on Tegra210 does, contrary to what was previously assumed, in
fact support DisplayPort. The difference between SOR0 and SOR1 is that
the latter supports audio and HDCP over DP, whereas the former doesn't.
The code for eDP and DP is now almost identical and the differences can
easily be parameterized based on the presence of a panel. There is no
need any longer to duplicate the code.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The correct I/O pad needs to be powered up before DP can be used. Make
sure the correct default is set for Tegra generations where the I/O pad
cannot be derived from the SOR instance.
Signed-off-by: Thierry Reding <[email protected]>
|
|
With the clocks modelled consistently across SoC generations, the clock
setup for eDP, HDMI and DP can now be unified.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Reuse parameters from earlier generations to support DisplayPort on
Tegra194.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The connector type detection code is duplicated in two places. Keeping
both places in sync is an extra maintenance burden that can be avoided
by comparing the connector type operations that are set upon the first
detection.
Signed-off-by: Thierry Reding <[email protected]>
|
|
So far the pad clock was only needed on the second SOR instance. The
clock does exist for all SOR instances, though, so make sure it is
always implemented. This prepares for further unification of the code
in subsequent patches.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The device tree bindings for the Tegra210 SOR don't require the
controller instance to be defined, since the instance can be derived
from the compatible string. The index is never used on Tegra210, so we
got away with it not getting set. However, subsequent patches will
change that, so make sure the proper index is used.
Signed-off-by: Thierry Reding <[email protected]>
|
|
It turns out that SOR1 is just another instance of the same block as the
SOR0, so there is no need to distinguish them.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Add support for regular DisplayPort on Tegra210 and Tegra186.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The SOR found on Tegra SoCs does not support all the rates potentially
advertised by eDP 1.4. Make sure that the rates that are not supported
are filtered out.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Rework eDP code to correspond more closely to what's documented. This
also improves the reliability of modesets.
Signed-off-by: Thierry Reding <[email protected]>
|
|
This is necessary for the output abstraction to retrieve a list of valid
modes from the EDID of a connected panel/monitor. This will be useful in
conjunction with DisplayPort support that will be added in a subsequent
patch, so that the driver can read EDID via the AUX channel.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Make use of the DP link training helpers to implement full and fast link
training. While at it, refactor some of the code and remove various code
sequences that are not necessary.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Add a helper that will perform link training as described in the
DisplayPort specification.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Parses additional link rates from DPCD if the sink supports eDP 1.4.
Signed-off-by: Thierry Reding <[email protected]>
|
|
This helper chooses an appropriate configuration, according to the
bitrate requirements of the video mode and the capabilities of the
DisplayPort sink.
Signed-off-by: Thierry Reding <[email protected]>
|
|
If the sink is eDP and supports the alternate scrambler reset, enable
it.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Make use of ANSI 8B/10B channel coding if the DisplayPort sink supports
it.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Store the AUX read interval from DPCD, so that it can be used to wait
for the durations given in the specification during link training.
Signed-off-by: Thierry Reding <[email protected]>
|
|
If the sink supports eDP, read the eDP revision from it's DPCD.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Parse from the sink capabilities whether or not the eDP alternate
scrambler reset value of 0xfffe is supported.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Parse from the sink capabilities whether or not it supports ANSI 8B/10B
channel coding as specified in ANSI X3.230-1994, clause 11.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The TPS3 capability can be exposed by DP 1.2 and later sinks if they
support the alternative training pattern for channel equalization.
Signed-off-by: Thierry Reding <[email protected]>
|
|
While probing the DisplayPort link, query the fast training capability.
If supported, drivers can use the fast link training sequence instead of
the more involved full link training sequence.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Use existing parsing helpers to probe a DisplayPort link.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Rather than storing capabilities as flags in an integer, use a separate
boolean per capability. This simplifies the code that checks for these
capabilities.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Store capabilities in max_* fields and add separate fields for the
currently selected settings.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Subsequent patches will add non-volatile fields to struct drm_dp_link,
so introduce a function to zero out only the volatile fields.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The drm_dp_link structure tracks capabilities on the DP link. Add some
kerneldoc to explain what each of its fields means.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The CMH, DRVZ and DRVI values vary depending on the SoC generation. Move
them into SoC specific structures so that DT compatible string matching
can be used to select the right parameters and write them to hardware at
the right time.
Signed-off-by: Thierry Reding <[email protected]>
|
|
In order to properly make the VDD supply optional, all accesses to the
regulator need to be ignored, because the regulator core doesn't treat
NULL special.
Signed-off-by: Thierry Reding <[email protected]>
|
|
When a transfer didn't complete transmission of the requested number of
bytes, signal that the transaction should be retried.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The dpaux driver has a quirk built-in that will delay initialization of
the display driver for a short while, trying to detect an eDP panel. The
reason for this quirk is that the panel may not report as connected
until after the display driver has initialized, at which point the fbdev
emulation will have fallen back to 1024x768 as default resolution, which
will likely not be the eDP panel's native resolution.
With upcoming DisplayPort support, the code needs to be able to cope
with hotpluggable monitors as well. Waiting for a panel to show up is no
longer going to work because the monitor may not be attached on boot. If
the output runs in DisplayPort mode, skip waiting for the panel to show
up.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Instead of manually creating the SG table for a discontiguous buffer,
use the existing sg_alloc_table_from_pages(). Note that this is not safe
to be used with the ARM DMA/IOMMU integration code because that will not
ensure that the whole buffer is mapped contiguously. Depending on the
size of the individual entries the mapping may end up containing holes
to ensure alignment.
However, we only ever use these buffers with explicit IOMMU API usage
and know how to avoid these holes.
Signed-off-by: Thierry Reding <[email protected]>
|
|
When an importer wants to map a DMA-BUF, make sure to always actually
map it, irrespective of whether the buffer is contiguous or not.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Rather than manually creating an SG table in an incorrect way, let the
standard dma_get_sgtable() function do it.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The address can refer to either physical memory or IO virtual memory.
If referring to IO virtual memory, there will always be an associated
physical memory address. Rename this variable to "iova" to clarify in
all cases that this is the IO virtual memory, which in the absence of
an IOMMU is identical to the physical address.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Handling of the IOMMU group attachment is common to all clients, so move
the group into the client to simplify code.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Reuse common code to attach to or detach from an IOMMU domain.
Signed-off-by: Thierry Reding <[email protected]>
|
|
VIC, just like all other host1x clients, has the same addressing range
as its parent host1x device. Inherit the DMA mask to reflect that.
Signed-off-by: Thierry Reding <[email protected]>
|
|
If VIC is not behind an IOMMU, don't touch any of the registers related
to stream ID programming.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The driver-specific messages should use the DRM_UT_DRIVER category so
that they can be properly filtered.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The display controllers and VIC don't have any limitations on the
DMA segment size. Inherit the DMA parameters from the parent device,
which also doesn't have any such limitations.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The host1x_cdma_wait_pushbuffer_space() function is not declared or
directly called from outside the file it is in, so make it static.
Fixes the following sparse warning:
drivers/gpu/host1x/cdma.c:235:5: warning: symbol 'host1x_cdma_wait_pushbuffer_space' was not declared. Should it be static?
Signed-off-by: Ben Dooks <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
A struct device doesn't carry much information that a channel might be
interested in, but the client very much does. Request channels for the
clients rather than their parent devices and store a pointer to them
in order to have that information available when needed.
Signed-off-by: Thierry Reding <[email protected]>
|
|
It's technically not required to explicitly initialize the fields that
will be zero by default, but it's easier to read these structures if
they are all initialized uniformly.
Signed-off-by: Thierry Reding <[email protected]>
|
|
Signed-off-by: Thierry Reding <[email protected]>
|
|
host1x nor any its clients have any limitations on the DMA segment size,
so don't pretend that they do.
Signed-off-by: Thierry Reding <[email protected]>
|
|
The TODO item is misleading and makes it seem as if fbdev emulation
cannot be used with SHMEM. Rephrase the text to describe the current
situation more correctly.
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Noralf Trønnes <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|