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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Commit Fixes: b9f8b09ce2 ("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: b9f8b09ce2 ("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>
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>
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
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
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
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
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
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
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
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
Parroting Daniel's backmerge justification from
2e79e22e09:
Thierry needs fd70c7755b ("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>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl2su/AeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGvm4H/1jkheCrvB/GJS69
wd18vizAg+eFmNCzxlGVhpQTKGymNRy+g6clnoli3cNJ3pSVKcYgVyB3oXaONIhp
g/ANudnBjTdjqYgJzfLij5AGecrGwDpF3YL0kuKrCB63s2I/HwQGYy/aPrYY8emy
gAYdaf1DGRu5/DIIB6soTo/TnpKoAyTE+XY5MaPSug++t/Flov19tlU40IZxXW94
bjTXbm0yklrsIx+LL5mYYGGnygSTCF66JjFg1qhDCBQaS2MZ21h1ZgaOtGZTwZcc
WgEiqLC5S1Iyj96zir1t78RcVQ4RzgvDbhUOgIqUFsYAO2wOicvxyFE3Hj8rPOKd
uGgVPRM=
=xgZa
-----END PGP SIGNATURE-----
Merge v5.4-rc4 into drm-next
Thierry needs fd70c7755b ("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>
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
Done with
commit aef9f33b76
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Oct 23 17:43:10 2018 +0300
drm/i915: Ensure proper HDA suspend/resume ordering with a device link
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022152530.22038-1-daniel.vetter@ffwll.ch
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 2b677e8c08
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
Add a function to fill the AVI infoframe bar information from
the standard tv margin properties.
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-1-ville.syrjala@linux.intel.com
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
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
GCC complains about dubious bitwise OR operand:
drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y
CC [M] drivers/gpu/drm/drm_mipi_dbi.o
As long as buffer is consist of byte (u8) values, we may use
simple right shift and satisfy compiler. It also reduces amount of
operations needed.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Tested-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191017114912.61522-1-andriy.shevchenko@linux.intel.com
