Rename "ring_mirror_list" to "pending_list",
to describe what something is, not what it does,
how it's used, or how the hardware implements it.
This also abstracts the actual hardware
implementation, i.e. how the low-level driver
communicates with the device it drives, ring, CAM,
etc., shouldn't be exposed to DRM.
The pending_list keeps jobs submitted, which are
out of our control. Usually this means they are
pending execution status in hardware, but the
latter definition is a more general (inclusive)
definition.
Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/405573/
Cc: Alexander Deucher <Alexander.Deucher@amd.com>
Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Christian König <christian.koenig@amd.com>
Add DP support to display-connector driver. The driver will support HPD
via a GPIO and DP PWR.
DP PWR will be enabled at probe, which is not optimal, but I'm not sure
what would be a good place to enable and disable DP PWR. Perhaps
attach/detach, but I don't know if enabling HW is something that attach
is supposed to do.
In any case, I don't think there's much difference in power consumption
between the version in this patch and enabling the regulator later: if
the driver probes, supposedly it will attach very soon afterwards, and
we need to enable the DP PWR as soon as possible.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130112919.241054-3-tomi.valkeinen@ti.com
Add binding for DisplayPort connector. A few notes:
* Similar to hdmi-connector, it has hpd-gpios as an optional property,
as the HPD could also be handled by, e.g., the DP bridge.
* dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it
is not strictly required: standard DP cables do not even have the pin
connected.
* Connector type. Full size and mini connectors are identical except for
the connector size and form, so I believe there is no functional need
for this property. But similar to 'label' property, it might be used
to present information about the connector to the userspace.
* No eDP. There's really no "eDP connector", as it's always a custom
made connection between the DP and the DP panel, although the eDP spec
does offer a few suggested pin setups. So possibly there is no need for
edp-connector binding, but even if there is, I don't want to guess what
it could look like, and could it be part of the dp-connector binding.
* No DP++. I'm not familiar with DP++. DP++ might need an i2c bus added
to the bindings.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201130112919.241054-2-tomi.valkeinen@ti.com
This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.
The init values was taken from the vendor source tree, comments were added to the
know values but most of the init table is undocumented.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
[narmstrong: call drm_panel_remove if mipi_dsi_attach fails]
Link: https://patchwork.freedesktop.org/patch/msgid/20201204081949.38418-3-narmstrong@baylibre.com
The DSI version of the panel behaved instable and close
scrutiny of the vendor driver from the Samsung
GT-S8190 shows a different initialization sequence for
the DSI mode panel than the DPI mode panel.
Make the initialization depend on whether we are in
DSI or DPI mode and handle the differences.
After this the panel on the GT-I8190 becomes much more
stable.
Also spell out some more custom DCS commands found in
the vendor source code to cut down a bit on magic
where we can.
Fixes: f0aee45ffc ("drm/panel: s6e63m0: Fix init sequence")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Stephan Gerhold <stephan@gerhold.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20201205122229.1952980-1-linus.walleij@linaro.org
This moves the MCDE bindings over to using the YAML schema
to describe the ST-Ericsson MCDE display controller,
making use of the generic DSI controller schema.
In the process we correct an error in the old text bindings:
the clocks for the SDI host controllers were specified as
part of the main MCDE component while they should be
specified in the DSI host controller subnodes. This was
a leftover from an earlier iteration of the first patch
series adding the MCDE.
We also add the "port" node, we will use this when adding
LCD panels using the direct parallel interface DPI instead
of DSI.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20201115185145.566772-1-linus.walleij@linaro.org
gcc warns about an out-of-bounds access when the using nonzero
values for 'plane_id' on kmb->plane_status:
drivers/gpu/drm/kmb/kmb_plane.c: In function 'kmb_plane_atomic_disable':
drivers/gpu/drm/kmb/kmb_plane.c:128:20: warning: array subscript 3 is above array bounds of 'struct layer_status[1]' [-Warray-bounds]
128 | kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
| ~~~~~~~~~~~~~~~~~^~~~~~~~~~
drivers/gpu/drm/kmb/kmb_plane.c:125:20: warning: array subscript 2 is above array bounds of 'struct layer_status[1]' [-Warray-bounds]
125 | kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
| ~~~~~~~~~~~~~~~~~^~~~~~~~~~
drivers/gpu/drm/kmb/kmb_plane.c:122:20: warning: array subscript 1 is above array bounds of 'struct layer_status[1]' [-Warray-bounds]
122 | kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
Having the array truncated to one entry seems intentional, so add
a range check before indexing it to make it clearer what is going
on and shut up the warning.
I received the warning from the kernel test robot after a private
patch that turns on Warray-bounds unconditionally.
Fixes: 7f7b96a8a0 ("drm/kmb: Add support for KeemBay Display")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Anitha Chrisanthus <anitha.chrisanthus@intel.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201129200927.1854104-1-arnd@kernel.org
The Ingenic DRM uses Common Clock Framework thus it cannot be built on
platforms without it (e.g. compile test on MIPS with RALINK and
SOC_RT305X):
/usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/ingenic/ingenic-drm-drv.o: in function `ingenic_drm_bind.isra.0':
ingenic-drm-drv.c:(.text+0x1600): undefined reference to `clk_get_parent'
/usr/bin/mips-linux-gnu-ld: ingenic-drm-drv.c:(.text+0x16b0): undefined reference to `clk_get_parent'
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20201116175301.402787-2-krzk@kernel.org
The main problem with this error handling was that it didn't clean up if
i2c_add_numbered_adapter() failed. This code is pretty old, and doesn't
match with today's checkpatch.pl standards so I took the opportunity to
tidy it up a bit. I changed the NULL comparison, and removed the
WARNING message if kzalloc() fails and updated the label names.
Fixes: 1b082ccf59 ("gma500: Add Oaktrail support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/X8ikkAqZfnDO2lu6@mwanda
This an incremental refactor towards multiple dma-fence contexts
in virtio-gpu. Since all fences are still allocated using
&virtio_gpu_fence_driver.context, nothing should break and every
processed fence will be signaled.
The overall idea is every 3D context can allocate a number of
dma-fence contexts. Each dma-fence context refers to it's own
timeline.
For example, consider the following case where virgl submits
commands to the GPU (fence ids 1, 3) and does a metadata query with
the CPU (fence id 5). In a different process, gfxstream submits
commands to the GPU (fence ids 2, 4).
fence_id (&dma_fence.seqno) | 1 2 3 4 5
----------------------------------|-----------
fence_ctx 0 (virgl gpu) | 1 3
fence_ctx 1 (virgl metadata query)| 5
fence_ctx 2 (gfxstream gpu) | 2 4
With multiple fence contexts, we can wait for the metadata query
to finish without waiting for the virgl gpu to finish. virgl gpu
does not have to wait for gfxstream gpu. The fence id still is the
monotonically increasing sequence number, but it's only revelant to
the specific dma-fence context.
To fully enable this feature, we'll need to:
- have each 3d context allocate a number of fence contexts. Not
too hard with explicit context initialization on the horizon.
- have guest userspace specify fence context when performing
ioctls.
- tag each fence emitted to the host with the fence context
information. virtio_gpu_ctrl_hdr has padding + flags available,
so that should be easy.
This change goes in the direction specified above, by:
- looking up the virtgpu_fence given a fence_id
- signalling all prior fences in a given context
- signalling current fence
v2: fix grammar in comment
v3: add r-b tags
Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-3-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
virtio_gpu_fence_event_process sets the last_fence_id and
subsequently calls dma_fence_signal_locked(..).
dma_fence_signal_locked(..) sets DMA_FENCE_FLAG_SIGNALED_BIT,
which is actually checked before &dma_fence_ops.(*signaled) is
called.
The check for last_fence_id is therefore a bit redundant, and
it will not be sufficient to check the last_fence_id for multiple
synchronization timelines. Remove it.
v3: add r-b tags
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-2-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
