- 28 Oct, 2019 37 commits
-
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
Add a helper that will perform link training as described in the DisplayPort specification. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Parses additional link rates from DPCD if the sink supports eDP 1.4. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
If the sink is eDP and supports the alternate scrambler reset, enable it. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Make use of ANSI 8B/10B channel coding if the DisplayPort sink supports it. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
If the sink supports eDP, read the eDP revision from it's DPCD. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Parse from the sink capabilities whether or not the eDP alternate scrambler reset value of 0xfffe is supported. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
Use existing parsing helpers to probe a DisplayPort link. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
Store capabilities in max_* fields and add separate fields for the currently selected settings. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
Reuse common code to attach to or detach from an IOMMU domain. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
If VIC is not behind an IOMMU, don't touch any of the registers related to stream ID programming. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The driver-specific messages should use the DRM_UT_DRIVER category so that they can be properly filtered. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Ben Dooks (Codethink) authored
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 <ben.dooks@codethink.co.uk> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
Thierry Reding authored
Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
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 <treding@nvidia.com>
-
- 24 Oct, 2019 3 commits
-
-
Dariusz Marcinkiewicz authored
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector, and fill in the cec_connector_info. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Commit Fixes: b9f8b09c ("drm/tegra: Setup shared IOMMU domain after initialization") changed the initialization order of the IOMMU related bits but didn't update the cleanup path accordingly. This asymmetry can cause failures during error recovery. Fixes: b9f8b09c ("drm/tegra: Setup shared IOMMU domain after initialization") Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com>
-
Thierry Reding authored
The hardware is not guaranteed to be enabled during execution of the tegra_sor_init() function, which can lead to a crash on some Tegra SoCs. Fix this by moving all register programming into code that is guaranteed to only be executed when the hardware is enabled. Signed-off-by: Thierry Reding <treding@nvidia.com>
-