The only remaining use for this is to protect against setting a new exclusive
fence while we grab both exclusive and shared. That can also be archived by
looking if the exclusive fence has changed or not after completing the
operation.
v2: switch setting excl fence to rcu_assign_pointer
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/322380/
The midgard/bifrost GPUs need to allocate GPU heap memory which is
allocated on GPU page faults and not pinned in memory. The vendor driver
calls this functionality GROW_ON_GPF.
This implementation assumes that BOs allocated with the
PANFROST_BO_NOEXEC flag are never mmapped or exported. Both of those may
actually work, but I'm unsure if there's some interaction there. It
would cause the whole object to be pinned in memory which would defeat
the point of this.
On faults, we map in 2MB at a time in order to utilize huge pages (if
enabled). Currently, once we've mapped pages in, they are only unmapped
if the BO is freed. Once we add shrinker support, we can unmap pages
with the shrinker.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-9-robh@kernel.org
Executable buffers have an alignment restriction that they can't cross
16MB boundary as the GPU program counter is 24-bits. This restriction is
currently not handled and we just get lucky. As current userspace
assumes all BOs are executable, that has to remain the default. So add a
new PANFROST_BO_NOEXEC flag to allow userspace to indicate which BOs are
not executable.
There is also a restriction that executable buffers cannot start or end
on a 4GB boundary. This is mostly avoided as there is only 4GB of space
currently and the beginning is already blocked out for NULL ptr
detection. Add support to handle this restriction fully regardless of
the current constraints.
For existing userspace, all created BOs remain executable, but the GPU
VA alignment will be increased to the size of the BO. This shouldn't
matter as there is plenty of GPU VA space.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-6-robh@kernel.org
We clear the callback list on kref_put so that by the time we
release the fence it is unused. No one should be adding to the cb_list
that they don't themselves hold a reference for.
This small change is actually making the structure 16% smaller.
v2: add the comment to the code as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/322916/
CRC generation can be impacted by commits coming from userspace, and
enabling CRC generation may itself trigger a commit. Add notes about
this to the kerneldoc.
Changes since v1:
- Clarified that anything that would disable CRCs counts as a full
modeset, and so userspace needs to reconfigure after full modesets
Changes since v2:
- Add these notes
- Rebase onto drm-misc-next (trivial conflict in comment)
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link:- https://patchwork.freedesktop.org/patch/321974/
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
v6:
Kernel docs are modified [pekka]
v7:
More details in Kernel docs. [pekka]
v8:
Few more clarification into kernel doc of content type [pekka]
v9:
Small fixes in coding style.
v10:
Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14
Add generic code which creates symbolic links in sysfs, pointing to ddc
interface used by a particular video output. For example:
ls -l /sys/class/drm/card0-HDMI-A-1/ddc
lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
-> ../../../../soc/13880000.i2c/i2c-2
This makes it easy for user to associate a display with its ddc adapter
and use e.g. ddcutil to control the chosen monitor.
This patch adds an i2c_adapter pointer to struct drm_connector. Particular
drivers can then use it instead of using their own private instance. If a
connector contains a ddc, then create a symbolic link in sysfs.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d470def6cd661b777faeee67b5838a4623c4010e.1564161140.git.andrzej.p@collabora.com
All available downstream ports - physical and logical - are exposed for
each MST device. They are listed in /dev/, following the same naming
scheme as SST devices by appending an incremental ID.
Although all downstream ports are exposed, only some will work as
expected. Consider the following topology:
+---------+
| ASIC |
+---------+
Conn-0|
|
+----v----+
+----| MST HUB |----+
| +---------+ |
| |
|Port-1 Port-2|
+-----v-----+ +-----v-----+
| MST | | SST |
| Display | | Display |
+-----------+ +-----------+
|Port-1
x
MST Path | MST Device
----------+----------------------------------
sst:0 | MST Hub
mst:0-1 | MST Display
mst:0-1-1 | MST Display's disconnected DP out
mst:0-1-8 | MST Display's internal sink
mst:0-2 | SST Display
On certain MST displays, the upstream physical port will ACK DPCD reads.
However, reads on the local logical port to the internal sink will
*NAK*. i.e. reading mst:0-1 ACKs, but mst:0-1-8 NAKs.
There may also be duplicates. Some displays will return the same GUID
when reading DPCD from both mst:0-1 and mst:0-1-8.
There are some device-dependent behavior as well. The MST hub used
during testing will actually *ACK* read requests on a disconnected
physical port, whereas the MST displays will NAK.
In light of these discrepancies, it's simpler to expose all downstream
ports - both physical and logical - and let the user decide what to use.
v3 changes:
* Change WARN_ON_ONCE -> DRM_ERROR on dpcd read errors
* Docstring and cosmetic fixes
v2 changes:
Moved remote aux device (un)registration to new mst connector late
register and early unregister helpers. Drivers should call these from
their own mst connector function hooks.
This is to solve an issue during driver unload, where mst connector
devices are unregistered before the remote aux devices are. In a setup
where aux devices are created as children of connector devices, the aux
device would be removed too early, and uncleanly. Doing so in
early_unregister solves this issue, as that is called before connector
unregistration.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190723232808.28128-3-sunpeng.li@amd.com
Split struct mipi_dbi into an interface part and a display pipeline part.
The interface part can be used by drivers that need to initialize the
controller, but that won't upload the framebuffer over this interface.
MIPI DBI supports 3 interface types:
- A. Motorola 6800 type parallel bus
- B. Intel 8080 type parallel bus
- C. SPI type with 3 options:
I've embedded the SPI type specifics in the mipi_dbi struct to avoid
adding unnecessary complexity. If more interface types will be supported
in the future, the type specifics might have to be split out.
Rename functions to match the new struct mipi_dbi_dev:
- drm_to_mipi_dbi() -> drm_to_mipi_dbi_dev().
- mipi_dbi_init*() -> mipi_dbi_dev_init*().
Cc: Eric Anholt <eric@anholt.net>
Cc: David Lechner <david@lechnology.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: David Lechner <david@lechnology.com>
Acked-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-5-noralf@tronnes.org
struct mipi_dbi is going to be split into an interface part and a display
pipeline part. The interface part can be used by drivers that need to
initialize the controller, but that won't upload the framebuffer over
this interface.
tinydrm uses the variable name 'mipi' but this is not a good name since
MIPI refers to a lot of standards. This patch changes the variable name
to 'dbidev' where it refers to the pipeline part of struct mipi_dbi.
Cc: Eric Anholt <eric@anholt.net>
Cc: David Lechner <david@lechnology.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: David Lechner <david@lechnology.com>
Acked-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-4-noralf@tronnes.org
struct mipi_dbi is going to be split into an interface part and a display
pipeline part. The interface part can be used by drivers that need to
initialize the controller, but that won't upload the framebuffer over
this interface.
tinydrm uses the variable name 'mipi' but this is not a good name since
MIPI refers to a lot of standards. This patch changes the variable name
to 'dbi' where it refers to the interface part of struct mipi_dbi.
Functions that use both future parts will have both variables temporarily
pointing to the same structure.
Cc: Eric Anholt <eric@anholt.net>
Cc: David Lechner <david@lechnology.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: David Lechner <david@lechnology.com>
Acked-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-3-noralf@tronnes.org
The MIPI DBI standard support more pixel formats than what this helper
supports. Add an init function that lets the driver use different
format(s). This avoids open coding mipi_dbi_init() in st7586.
st7586 sets preferred_depth but this is not necessary since it only
supports one format.
v2: Forgot to remove the mipi->rotation assignment in st7586,
mipi_dbi_init_with_formats() handles it.
Cc: David Lechner <david@lechnology.com>
Acked-by: David Lechner <david@lechnology.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Tested-by: David Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-11-noralf@tronnes.org
This is only used by mipi-dbi drivers so move it there.
The reason this isn't moved to the SPI subsystem is that it will in a
later patch pass a dummy rx buffer for SPI controllers that need this.
Low memory boards (64MB) can run into a problem allocating such a "large"
contiguous buffer on every transfer after a long up time.
This leaves a very specific use case, so we'll keep the function here.
mipi-dbi will first go through a refactoring though, before this will
be done.
Remove SPI todo entry now that we're done with the tinydrm.ko SPI code.
v2: Drop moving the mipi_dbi_spi_init() declaration (Sam)
Cc: David Lechner <david@lechnology.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: : David Lechner <david@lechnology.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-8-noralf@tronnes.org
Prep work before moving the function to mipi-dbi.
tinydrm_spi_transfer() was made to support one class of drivers in
drivers/staging/fbtft that has not been converted to DRM yet, so strip
away the unused functionality:
- Start byte (header) is not used.
- No driver relies on the automatic 16-bit byte swapping on little endian
machines with SPI controllers only supporting 8 bits per word.
Other changes:
- No need to initialize ret
- No need for the WARN since mipi-dbi only uses 8 and 16 bpw.
- Use spi_message_init_with_transfers()
Cc: David Lechner <david@lechnology.com>
Acked-by: : David Lechner <david@lechnology.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-7-noralf@tronnes.org
spi-bcm2835 can handle >64kB buffers now so there is no need to check
->max_dma_len. The tinydrm_spi_max_transfer_size() max_len argument is
not used by any callers, so not needed.
Then we have the spi_max module parameter. It was added because
staging/fbtft has support for it and there was a report that someone used
it to set a small buffer size to avoid popping on a USB soundcard on a
Raspberry Pi. In hindsight it shouldn't have been added, I should have
waited for it to become a problem first. I don't know it anyone is
actually using it, but since tinydrm_spi_transfer() is being moved to
mipi-dbi, I'm taking the opportunity to remove it. I'll add it back to
mipi-dbi if someone complains.
With that out of the way, spi_max_transfer_size() can be used instead.
The chosen 16kB buffer size for Type C Option 1 (9-bit) interface is
somewhat arbitrary, but a bigger buffer will have a miniscule impact on
transfer speed, so it's probably fine.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-6-noralf@tronnes.org
tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers.
Add a SPI connector type to match the actual connector.
X will list the connector as Unknown:
X.Org X Server 1.19.2
Release Date: 2017-03-02
<...>
[ 53523.905] (II) modeset(0): Output Unknown19-1 has no monitor section
[ 53523.908] (II) modeset(0): EDID for output Unknown19-1
[ 53523.910] (II) modeset(0): Printing probed modes for output Unknown19-1
[ 53523.911] (II) modeset(0): Modeline "320x240"x0.0 0.00 320 320 320 320 240 240 240 240 (0.0 kHz eP)
[ 53523.911] (II) modeset(0): Output Unknown19-1 connected
[ 53523.912] (II) modeset(0): Using exact sizes for initial modes
[ 53523.912] (II) modeset(0): Output Unknown19-1 using initial mode 320x240 +0+0
The weston source shows that it will be listed as UNNAMED.
v2: Split patch in core and driver changes, expand commit message (Daniel)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: David Lechner <david@lechnology.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-2-noralf@tronnes.org
After migrating several drivers to the generic fbdev
emulation there are no users left of drm_gem_fbdev_fb_create.
Delete the function.
Noticed that there was no callers while browsing
around in the drm_fb* code.
The code that referenced the function was removed by:
commit 13aff184ed ("drm/qxl: remove dead qxl fbdev emulation code")
The actual use was removed by:
commit 26d4707d44 ("drm/qxl: use generic fbdev emulation")
v2:
- Updated changelog based on feedback from Noralf
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190721140610.GA20842@ravnborg.org
Pull NTB updates from Jon Mason:
"New feature to add support for NTB virtual MSI interrupts, the ability
to test and use this feature in the NTB transport layer.
Also, bug fixes for the AMD and Switchtec drivers, as well as some
general patches"
* tag 'ntb-5.3' of git://github.com/jonmason/ntb: (22 commits)
NTB: Describe the ntb_msi_test client in the documentation.
NTB: Add MSI interrupt support to ntb_transport
NTB: Add ntb_msi_test support to ntb_test
NTB: Introduce NTB MSI Test Client
NTB: Introduce MSI library
NTB: Rename ntb.c to support multiple source files in the module
NTB: Introduce functions to calculate multi-port resource index
NTB: Introduce helper functions to calculate logical port number
PCI/switchtec: Add module parameter to request more interrupts
PCI/MSI: Support allocating virtual MSI interrupts
ntb_hw_switchtec: Fix setup MW with failure bug
ntb_hw_switchtec: Skip unnecessary re-setup of shared memory window for crosslink case
ntb_hw_switchtec: Remove redundant steps of switchtec_ntb_reinit_peer() function
NTB: correct ntb_dev_ops and ntb_dev comment typos
NTB: amd: Silence shift wrapping warning in amd_ntb_db_vector_mask()
ntb_hw_switchtec: potential shift wrapping bug in switchtec_ntb_init_sndev()
NTB: ntb_transport: Ensure qp->tx_mw_dma_addr is initaliazed
NTB: ntb_hw_amd: set peer limit register
NTB: ntb_perf: Clear stale values in doorbell and command SPAD register
NTB: ntb_perf: Disable NTB link after clearing peer XLAT registers
...
