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
