Thierry Reding [Mon, 28 Oct 2019 12:37:18 +0000 (13:37 +0100)]
drm/tegra: Optionally attach clients to the IOMMU
If a client is already attached to an IOMMU domain that is not the
shared domain, don't try to attach it again. This allows using the
IOMMU-backed DMA API.
Since the IOMMU-backed DMA API is now supported and there's no way
to detach from it on 64-bit ARM, don't bother to detach from it on
32-bit ARM either.
Thierry Reding [Mon, 28 Oct 2019 12:37:17 +0000 (13:37 +0100)]
drm/tegra: Support DMA API for display controllers
If a display controller is not attached to an explicit IOMMU domain,
which usually means that it's connected to an IOMMU domain controlled by
the DMA API, make sure to map the framebuffer to the display controller
address space. This allows us to transparently handle setups where the
display controller is attached to an IOMMU or setups where it isn't. It
also allows the driver to work with a DMA API that is backed by an
IOMMU.
Thierry Reding [Mon, 28 Oct 2019 12:37:16 +0000 (13:37 +0100)]
drm/tegra: falcon: Clarify address usage
Rename paddr -> iova and vaddr -> virt to make it clearer how these
addresses are used. This is important for a subsequent patch that makes
a distinction between the physical address (physical address of the
system memory from the CPU's point of view) and the IOVA (physical
address of the system memory from the device's point of view).
Thierry Reding [Mon, 28 Oct 2019 12:37:15 +0000 (13:37 +0100)]
drm/tegra: Remove memory allocation from Falcon library
Having to provide allocator hooks to the Falcon library is somewhat
cumbersome and it doesn't give the users of the library a lot of
flexibility to deal with allocations. Instead, remove the notion of
Falcon "operations" and let drivers deal with the memory allocations
themselves.
Thierry Reding [Mon, 28 Oct 2019 12:37:14 +0000 (13:37 +0100)]
gpu: host1x: Set DMA mask based on IOMMU setup
If the Tegra DRM clients are backed by an IOMMU, push buffers are likely
to be allocated beyond the 32-bit boundary if sufficient system memory
is available. This is problematic on earlier generations of Tegra where
host1x supports a maximum of 32 address bits for the GATHER opcode. More
recent versions of Tegra (Tegra186 and later) have a wide variant of the
GATHER opcode, which allows addressing up to 64 bits of memory.
If host1x itself is behind an IOMMU as well this doesn't matter because
the IOMMU's input address space is restricted to 32 bits on generations
without support for wide GATHER opcodes.
However, if host1x is not behind an IOMMU, it won't be able to process
push buffers beyond the 32-bit boundary on Tegra generations that don't
support wide GATHER opcodes. Restrict the DMA mask to 32 bits on these
generations prevents buffers from being allocated from beyond the 32-bit
boundary.
Thierry Reding [Mon, 28 Oct 2019 12:37:13 +0000 (13:37 +0100)]
gpu: host1x: Support DMA mapping of buffers
If host1x_bo_pin() returns an SG table, create a DMA mapping for the
buffer. For buffers that the host1x client has already mapped itself,
host1x_bo_pin() returns NULL and the existing DMA address is used.
Thierry Reding [Mon, 28 Oct 2019 12:37:12 +0000 (13:37 +0100)]
gpu: host1x: Allocate gather copy for host1x
Currently when the gather buffers are copied, they are copied to a
buffer that is allocated for the host1x client that wants to execute the
command streams in the buffers. However, the gather buffers will be read
by the host1x device, which causes SMMU faults if the DMA API is backed
by an IOMMU.
Fix this by allocating the gather buffer copy for the host1x device,
which makes sure that it will be mapped into the host1x's IOVA space if
the DMA API is backed by an IOMMU.
Thierry Reding [Mon, 28 Oct 2019 12:37:11 +0000 (13:37 +0100)]
gpu: host1x: Add direction flags to relocations
Add direction flags to host1x relocations performed during job pinning.
These flags indicate the kinds of accesses that hardware is allowed to
perform on the relocated buffers.
Thierry Reding [Mon, 28 Oct 2019 12:37:10 +0000 (13:37 +0100)]
gpu: host1x: Clean up debugfs on removal
The debugfs files created for host1x are never removed, causing these
files to be left dangling in debugfs. This results in a crash when any
of these files are accessed after the host1x driver has been removed,
as well as a failure to create the debugfs entries when they are added
again on driver probe.
Thierry Reding [Mon, 28 Oct 2019 12:37:09 +0000 (13:37 +0100)]
gpu: host1x: Overhaul host1x_bo_{pin,unpin}() API
The host1x_bo_pin() and host1x_bo_unpin() APIs are used to pin and unpin
buffers during host1x job submission. Pinning currently returns the SG
table and the DMA address (an IOVA if an IOMMU is used or a physical
address if no IOMMU is used) of the buffer. The DMA address is only used
for buffers that are relocated, whereas the host1x driver will map
gather buffers into its own IOVA space so that they can be processed by
the CDMA engine.
This approach has a couple of issues. On one hand it's not very useful
to return a DMA address for the buffer if host1x doesn't need it. On the
other hand, returning the SG table of the buffer is suboptimal because a
single SG table cannot be shared for multiple mappings, because the DMA
address is stored within the SG table, and the DMA address may be
different for different devices.
Subsequent patches will move the host1x driver over to the DMA API which
doesn't work with a single shared SG table. Fix this by returning a new
SG table each time a buffer is pinned. This allows the buffer to be
referenced by multiple jobs for different engines.
Change the prototypes of host1x_bo_pin() and host1x_bo_unpin() to take a
struct device *, specifying the device for which the buffer should be
pinned. This is required in order to be able to properly construct the
SG table. While at it, make host1x_bo_pin() return the SG table because
that allows us to return an ERR_PTR()-encoded error code if we need to,
or return NULL to signal that we don't need the SG table to be remapped
and can simply use the DMA address as-is. At the same time, returning
the DMA address is made optional because in the example of command
buffers, host1x doesn't need to know the DMA address since it will have
to create its own mapping anyway.
Thierry Reding [Mon, 28 Oct 2019 12:37:08 +0000 (13:37 +0100)]
drm/tegra: Simplify IOMMU group selection
All the devices that make up the DRM device are now part of the same
IOMMU group. This simplifies the handling of the IOMMU attachment and
also avoids exhausting the number of IOMMUs available on early Tegra
SoC generations.
Thierry Reding [Mon, 28 Oct 2019 12:16:10 +0000 (13:16 +0100)]
drm/tegra: Do not use ->load() and ->unload() callbacks
The ->load() and ->unload() drivers are midlayers and should be avoided
in modern drivers. Fix this by moving the code into the driver ->probe()
and ->remove() implementations, respectively.
v2: kick out conflicting framebuffers before initializing fbdev
v3: rebase onto drm/tegra/for-next
Thierry Reding [Mon, 24 Jun 2019 13:13:16 +0000 (15:13 +0200)]
drm/tegra: sor: Extract common audio enabling code
The code to enable audio support is split into two parts, one being
generic for the SOR and another part that is specific whether the SOR is
in HDMI mode or in DP mode. Split out the common part in preparation for
reusing the code in DP mode.
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.
Thierry Reding [Thu, 27 Jun 2019 10:34:57 +0000 (12:34 +0200)]
drm/tegra: sor: Unify eDP and DP support
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.
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.
Thierry Reding [Thu, 27 Jun 2019 10:29:56 +0000 (12:29 +0200)]
drm/tegra: sor: Deduplicate connector type detection code
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.
Thierry Reding [Mon, 24 Jun 2019 15:06:34 +0000 (17:06 +0200)]
drm/tegra: sor: Implement pad clock for all SOR instances
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.
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.
Thierry Reding [Thu, 1 Feb 2018 16:47:07 +0000 (17:47 +0100)]
drm/tegra: sor: Filter eDP rates
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.
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.
Thierry Reding [Tue, 15 Oct 2019 12:57:42 +0000 (14:57 +0200)]
drm/tegra: sor: Use DP link training helpers
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.
This helper chooses an appropriate configuration, according to the
bitrate requirements of the video mode and the capabilities of the
DisplayPort sink.
Thierry Reding [Thu, 3 Dec 2015 12:07:43 +0000 (13:07 +0100)]
drm/tegra: dp: Read fast training capability from link
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.
Thierry Reding [Thu, 3 Dec 2015 11:45:45 +0000 (12:45 +0100)]
drm/tegra: dp: Turn link capabilities into booleans
Rather than storing capabilities as flags in an integer, use a separate
boolean per capability. This simplifies the code that checks for these
capabilities.
Thierry Reding [Thu, 27 Jun 2019 10:24:41 +0000 (12:24 +0200)]
drm/tegra: dpaux: Parameterize CMH, DRVZ and DRVI
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.
Thierry Reding [Mon, 24 Jun 2019 11:30:24 +0000 (13:30 +0200)]
drm/tegra: dpaux: Fix crash if VDD supply is absent
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.
Thierry Reding [Mon, 3 Aug 2015 12:08:34 +0000 (14:08 +0200)]
drm/tegra: dpaux: Support monitor hotplugging
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.
Thierry Reding [Fri, 8 Jun 2018 13:00:05 +0000 (15:00 +0200)]
drm/tegra: gem: Use sg_alloc_table_from_pages()
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.
Thierry Reding [Mon, 4 Jun 2018 15:36:50 +0000 (17:36 +0200)]
drm/tegra: gem: Rename paddr -> iova
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.
drm/tegra: Inherit device DMA parameters from host1x
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.
Thierry Reding [Mon, 18 Jun 2018 12:01:51 +0000 (14:01 +0200)]
gpu: host1x: Request channels for clients, not devices
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.
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.
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.
Thierry Reding [Wed, 20 Feb 2019 09:03:46 +0000 (10:03 +0100)]
drm/tegra: sor: Move register programming out of ->init()
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.
Thierry Reding [Mon, 21 Oct 2019 14:34:37 +0000 (16:34 +0200)]
drm/tegra: Move drm_dp_link helpers to Tegra DRM
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.
Thierry Reding [Mon, 21 Oct 2019 14:34:36 +0000 (16:34 +0200)]
drm/rockchip: Avoid drm_dp_link helpers
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.
Thierry Reding [Mon, 21 Oct 2019 14:34:35 +0000 (16:34 +0200)]
drm/msm: edp: Avoid drm_dp_link helpers
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.
Thierry Reding [Mon, 21 Oct 2019 14:34:33 +0000 (16:34 +0200)]
drm/bridge: tc358767: Avoid drm_dp_link helpers
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.
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)
Thierry Reding [Mon, 21 Oct 2019 14:34:31 +0000 (16:34 +0200)]
drm/dp: Add helper to get post-cursor adjustments
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.
Thierry Reding [Mon, 21 Oct 2019 14:34:30 +0000 (16:34 +0200)]
drm/dp: Do not busy-loop during link training
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
Thierry Reding [Mon, 21 Oct 2019 14:34:26 +0000 (16:34 +0200)]
drm/dp: Remove a gratuituous blank line
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.
Daniel Vetter [Tue, 22 Oct 2019 15:25:30 +0000 (17:25 +0200)]
drm/todo: Add levels
Should help new people pick suitable tasks.
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Sean Paul <sean@poorly.run> Reviewed-by: Sean Paul <sean@poorly.run> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022152530.22038-2-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 22 Oct 2019 16:37:17 +0000 (18:37 +0200)]
drm/doc: Drop misleading comment on drm_mode_config_cleanup
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.
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).
Mihail Atanassov [Mon, 21 Oct 2019 15:01:56 +0000 (15:01 +0000)]
MAINTAINERS: Add Mihail to Komeda DRM driver
I'll be the main point of contact.
Cc: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Sean Paul <sean@poorly.run> Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191021150123.19570-1-mihail.atanassov@arm.com
Wambui Karuga [Sat, 19 Oct 2019 07:18:40 +0000 (10:18 +0300)]
drm: remove unnecessary return variable
Remove unnecessary variable `ret` in drm_dp_atomic_find_vcpi_slots()
only used to hold the function return value and have the function
return the value directly.
Issue found by coccinelle:
@@
local idexpression ret;
expression e;
@@
Kangjie Lu [Fri, 18 Oct 2019 04:41:50 +0000 (23:41 -0500)]
drm/gma500: fix memory disclosures due to uninitialized bytes
"clock" may be copied to "best_clock". Initializing best_clock
is not sufficient. The fix initializes clock as well to avoid
memory disclosures and informaiton leaks.
Kangjie Lu [Fri, 18 Oct 2019 04:29:53 +0000 (23:29 -0500)]
gma/gma500: fix a memory disclosure bug due to uninitialized bytes
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
projects / kernel.git / log