summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-10-28drm/tegra: dp: Add drm_dp_link_choose() helperThierry Reding2-0/+60
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>
2019-10-28drm/tegra: dp: Enable alternate scrambler reset when supportedThierry Reding1-0/+7
If the sink is eDP and supports the alternate scrambler reset, enable it. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28drm/tegra: dp: Set channel coding on link configurationThierry Reding1-1/+10
Make use of ANSI 8B/10B channel coding if the DisplayPort sink supports it. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28drm/tegra: dp: Read AUX read interval from DPCDThierry Reding2-0/+42
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>
2019-10-28drm/tegra: dp: Read eDP version from DPCDThierry Reding2-2/+18
If the sink supports eDP, read the eDP revision from it's DPCD. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28drm/tegra: dp: Read alternate scrambler reset capability from sinkThierry Reding2-0/+12
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>
2019-10-28drm/tegra: dp: Read channel coding capability from sinkThierry Reding2-0/+10
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>
2019-10-28drm/tegra: dp: Read TPS3 capability from sinkThierry Reding2-0/+10
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>
2019-10-28drm/tegra: dp: Read fast training capability from linkThierry Reding2-0/+10
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>
2019-10-28drm/tegra: dp: Probe link using existing parsing helpersThierry Reding1-7/+6
Use existing parsing helpers to probe a DisplayPort link. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28drm/tegra: dp: Turn link capabilities into booleansThierry Reding3-8/+36
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>
2019-10-28drm/tegra: dp: Track link capabilities alongside settingsThierry Reding4-28/+39
Store capabilities in max_* fields and add separate fields for the currently selected settings. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28drm/tegra: dp: Add drm_dp_link_reset() implementationThierry Reding1-1/+12
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>
2019-10-28drm/tegra: Add missing kerneldoc for struct drm_dp_linkThierry Reding1-0/+7
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>
2019-10-28drm/tegra: dpaux: Parameterize CMH, DRVZ and DRVIThierry Reding1-10/+38
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>
2019-10-28drm/tegra: dpaux: Fix crash if VDD supply is absentThierry Reding1-8/+14
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>
2019-10-28drm/tegra: dpaux: Retry on transfer size mismatchThierry Reding1-7/+18
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>
2019-10-28drm/tegra: dpaux: Support monitor hotpluggingThierry Reding1-18/+29
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>
2019-10-28drm/tegra: gem: Use sg_alloc_table_from_pages()Thierry Reding1-7/+2
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>
2019-10-28drm/tegra: gem: Always map SG tables for DMA-BUFsThierry Reding1-3/+3
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>
2019-10-28drm/tegra: gem: Use dma_get_sgtable()Thierry Reding1-4/+2
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>
2019-10-28drm/tegra: gem: Rename paddr -> iovaThierry Reding5-16/+16
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>
2019-10-28drm/tegra: Move IOMMU group into host1x clientThierry Reding7-40/+29
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>
2019-10-28drm/tegra: vic: Use common IOMMU attach/detach codeThierry Reding1-19/+8
Reuse common code to attach to or detach from an IOMMU domain. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28drm/tegra: vic: Inherit DMA mask from host1xThierry Reding1-0/+7
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>
2019-10-28drm/tegra: vic: Skip stream ID programming without IOMMUThierry Reding1-3/+5
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>
2019-10-28drm/tegra: Use DRM_DEBUG_DRIVER for driver messagesThierry Reding1-4/+4
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>
2019-10-28drm/tegra: Inherit device DMA parameters from host1xThierry Reding2-0/+18
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>
2019-10-28gpu: host1x: Make host1x_cdma_wait_pushbuffer_space() staticBen Dooks (Codethink)1-3/+3
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>
2019-10-28gpu: host1x: Request channels for clients, not devicesThierry Reding5-9/+11
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>
2019-10-28gpu: host1x: Explicitly initialize host1x_info structuresThierry Reding1-0/+12
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>
2019-10-28gpu: host1x: Remove gratuitous blank lineThierry Reding1-1/+0
Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28gpu: host1x: Do not limit DMA segment sizeThierry Reding3-1/+6
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>
2019-10-24drm/tegra: Use cec_notifier_conn_(un)register()Dariusz Marcinkiewicz1-7/+21
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>
2019-10-24drm/tegra: Fix ordering of cleanup codeThierry Reding1-7/+7
Commit Fixes: b9f8b09ce256 ("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: b9f8b09ce256 ("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>
2019-10-24drm/tegra: sor: Move register programming out of ->init()Thierry Reding1-13/+11
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>
2019-10-23drm/tegra: Move drm_dp_link helpers to Tegra DRMThierry Reding6-128/+162
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. After all other drivers have been converted not to use these helpers anymore, move these helpers into the last remaining user: Tegra DRM. If at some point these helpers are deemed more widely useful, they can be moved out into the DRM DP helpers again. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-14-thierry.reding@gmail.com
2019-10-23drm/rockchip: Avoid drm_dp_link helpersThierry Reding3-17/+17
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-13-thierry.reding@gmail.com
2019-10-23drm/msm: edp: Avoid drm_dp_link helpersThierry Reding1-21/+49
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-12-thierry.reding@gmail.com
2019-10-23drm/bridge: tc358767: Use DP nomenclatureThierry Reding1-1/+1
The DP specification uses the term "default framing" instead of "non- enhanced framing". Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-11-thierry.reding@gmail.com
2019-10-23drm/bridge: tc358767: Avoid drm_dp_link helpersThierry Reding1-22/+41
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. v3: make link rate unsigned int to avoid overflow Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-10-thierry.reding@gmail.com
2019-10-23drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpersThierry Reding1-17/+39
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. v4: use bulk DPCD writes if possible (Daniel Vetter) Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191022145211.2258525-1-thierry.reding@gmail.com
2019-10-23drm/dp: Add helper to get post-cursor adjustmentsThierry Reding1-0/+10
If the transmitter supports pre-emphasis post cursor2 the sink will request adjustments in a similar way to how it requests adjustments to the voltage swing and pre-emphasis settings. Add a helper to extract these adjustments on a per-lane basis from the DPCD link status. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-8-thierry.reding@gmail.com
2019-10-23drm/dp: Do not busy-loop during link trainingThierry Reding1-12/+18
Use microsecond sleeps for the clock recovery and channel equalization delays during link training. The duration of these delays can be from 100 us up to 16 ms. It is rude to busy-loop for that amount of time. While at it, also convert to standard coding style by putting the opening braces in a function definition on a new line. Also switch to using an unsigned int for the AUX read interval to match the data type of the parameters to usleep_range(). v2: use correct multiplier for training delays (Philipp Zabel) v3: clarify data type change in commit message Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-7-thierry.reding@gmail.com
2019-10-23drm/dp: Remove a gratuituous blank lineThierry Reding1-1/+0
It's idiomatic to check the return value of a function call immediately after the function call, without any blank lines in between, to make it more obvious that the two lines belong together. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-3-thierry.reding@gmail.com
2019-10-23Merge drm/drm-next into drm-misc-nextSean Paul644-15833/+23430
Parroting Daniel's backmerge justification from 2e79e22e092acd55da0b2db066e4826d7d152c41: Thierry needs fd70c7755bf0 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Signed-off-by: Sean Paul <seanpaul@chromium.org>
2019-10-23Revert "drm/omap: add OMAP_BO flags to affect buffer allocation"Sean Paul1-52/+2
This reverts commit 23b482252836ab3c5e6b3b20ed3038449cbc7679. This patch does not have an acceptable open source userspace implementation, and as such it does not meet the requirements for adding new UAPI. Discussion is in the Link. Link: https://lists.freedesktop.org/archives/dri-devel/2019-October/240586.html Fixes: 23b482252836 ("drm/omap: add OMAP_BO flags to affect buffer allocation") Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191022204733.235801-1-sean@poorly.run
2019-10-23Merge v5.4-rc4 into drm-nextDaniel Vetter307-4301/+2850
Thierry needs fd70c7755bf0 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Some adjacent changes conflicts, plus some clashes in i915 due to cherry-picking and git trying to be helpful and leaving both versions in. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-10-23drm/doc: Drop misleading comment on drm_mode_config_cleanupDaniel Vetter1-2/+0
This is not something we'll fix, because failing to clean up stuff (or doing it in the wrong order) is a driver bug. The offending FIXME goes all the way back to the original modeset merge. We've added a WARN_ON in commit 2b677e8c08eed11e4ebe66a7c334f03e389a19a3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Dec 10 21:16:05 2012 +0100 drm: reference framebuffers which are on the idr including a comment blaming drivers on this. Right thing to do is most likely drm_atomic_helper_shutdown plus making sure that drm_mode_config_cleanup is not called too early (i.e. not in driver unload, but only in the final drm_device release callback). Cc: Mihail Atanassov <Mihail.Atanassov@arm.com> Reported-by: Mihail Atanassov <Mihail.Atanassov@arm.com> Reviewed-by: Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022163717.1064-1-daniel.vetter@ffwll.ch
2019-10-22drm/vc4: Use drm_hdmi_avi_infoframe_bars()Ville Syrjälä1-4/+1
Use the new drm_hdmi_avi_infoframe_bars() helper instead of hand rolling it. Cc: Eric Anholt <eric@anholt.net> Cc: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008164814.5894-2-ville.syrjala@linux.intel.com Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-07 22:05:34 +0000