IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We'll need to propagate drm_edid everywhere. This is a clunky start, but
a start nonetheless. We'll eventually convert all of the EDID parsing to
struct drm_edid.
Initially, we'll just create the struct drm_edid in stack. This will be
the compat layer for legacy struct edid code. In the future, we'll have
EDID read return drm_edid objects.
v2: Add legacy init helper.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/000452fddedbaf7f473ac25d4dde2502e60b8e39.1652097712.git.jani.nikula@intel.com
Introduce new opaque type struct drm_edid to encapsulate the EDID data
and the size allocated for it. The contents will be private to
drm_edid.c.
There are a number of reasons for adding a container around struct edid:
* struct edid is a raw blob pointer to data that usually originates
outside of the kernel. Its size is contained within the structure.
* There's no way to attach meta information (such as allocated memory
size) to struct edid.
* Validation of the EDID blob and its size become crucial, and it's
spread all over the subsystem, with varying levels of accuracy.
* HDMI Forum has introduced an HF-EEODB extension that defines an
override EDID size within an EDID extension. The size allocated for an
EDID depends on whether the allocator understands the HF-EEODB
extension. Given a struct edid *, it's impossible to know how much
memory was actually allocated for it.
There are also some reasons for making the container type struct
drm_edid opaque and private to drm_edid.c:
* Have only one place for creating and parsing the EDID, to avoid
duplicating bugs.
* Prepare for reading a pure DisplayID 2.0 from its own DDC address, and
adding it within the same struct drm_edid container, transparently,
and for all drivers.
* With the idea that the drm_edid objects are immutable during their
lifetimes, it will be possible to refcount them and reduce EDID
copying everywhere (this is left for future work).
Initially, just add the type. In follow-up, we'll start converting the
guts of drm_edid.c to use it, and finally add interfaces around it.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f3ecabd8a219aea678ad00f7bcdecf77b27b3c78.1652097712.git.jani.nikula@intel.com
The driver has runtime but no build time dependency with X86, so it can
be built for testing purposes if the COMPILE_TEST option is enabled.
This is useful to have more build coverage and make sure that the driver
is not affected by changes that could cause build regressions.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220505120419.314136-1-javierm@redhat.com
Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, call to remove_conflicting_framebuffers().
This function takes the registration_lock mutex, to prevent a race when
drivers register framebuffer devices. But if a conflicting framebuffer
device is found, the underlaying platform device is unregistered and this
will lead to the platform driver .remove callback to be called. Which in
turn will call to unregister_framebuffer() that takes the same lock.
To prevent this, a struct fb_info.forced_out field was used as indication
to unregister_framebuffer() whether the mutex has to be grabbed or not.
But this could be unsafe, since the fbdev core is making assumptions about
what drivers may or may not do in their .remove callbacks. Allowing to run
these callbacks with the registration_lock held can cause deadlocks, since
the fbdev core has no control over what drivers do in their removal path.
A better solution is to drop the lock before platform_device_unregister(),
so unregister_framebuffer() can take it when called from the fbdev driver.
The lock is acquired again after the device has been unregistered and at
this point the removal loop can be restarted.
Since the conflicting framebuffer device has already been removed, the
loop would just finish when no more conflicting framebuffers are found.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511113039.1252432-1-javierm@redhat.com
Implement DSI-to-e(DP) mode, which is a mix of currently supported
DSI-to-DPI and DPI-to-(e)DP modes. The input side is configured as
either DSI or DPI, the DP AUX channel is registered for both input
side options, and the DSI host is attached for both DPI and (e)DP
output side options.
One notable detail is that the DSI-to-(e)DP mode requires the Pixel
PLL to be always enabled, which is not needed for DPI-to-(e)DP mode
which gets the matching clock direct from DPI Pixel Clock instead.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220429205644.245480-2-marex@denx.de
Factor out register programming to configure the chip video RX side for
reception of video data from DSI or DPI. This is particularly useful in
the (e)DP output mode, where the video data can be received from either
DPI or DSI. While only the former is supported in (e)DP output mode so
far, this patch is added in preparation for addition of the later.
There is a change in the order or register programming in case of the
DSI-to-DPI mode. The DSI RX side is now programmed and enabled all in
one place after the output mode has been configured. Before this change,
the DSI RX has been programmed before the output mode has been set and
only enabled afterward. The order makes no difference however, since the
DSI RX is only enabled at the end either way.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220429205644.245480-1-marex@denx.de
Some MGA200 hardware is broken and can't use a start address > 0.
v2: Warn if startaddr is not 0, and hw doesn't support it.
(instead of removing MGAG200_FLAG_HW_BUG_NO_STARTADD)
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504134026.283417-4-jfalempe@redhat.com
When there are multiple damage clips, previous code merged them into one
big rectangle. As the Matrox memory is very slow, it's faster to copy each
damage clip.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504134026.283417-2-jfalempe@redhat.com
The driver does support damage clips, but doesn't advertise it.
So when running gnome/wayland on Matrox hardware, the full frame is
copied to the slow Matrox memory, which leads to very poor performances.
Add drm_plane_enable_fb_damage_clips() to advertise this capability to
userspace.
With this patch, gnome/wayland becomes usable on Matrox GPU.
Suggested-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504134026.283417-2-jfalempe@redhat.com
I've been contributing to v3d through improvements, reviews, testing,
debugging, etc. So, I'm adding myself as a co-maintainer of the V3D
driver.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Acked-by: Juan A. Suarez <jasuarez@igalia.com>
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220429193317.ol3u4e5jpt5jucox@mail.igalia.com
Add support for pre_enable and post_enable drm bridge control functions.
Making sure that host to be prepared before panel is powered up,
for the panels like TC358762.
Signed-off-by: Jayshri Pawar <jpawar@cadence.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220411140606.15654-1-jpawar@cadence.com
Many of the kselftests in DRM can be converted to kunit tests instead,
since that framework is more suitable for unit testing.
Suggested-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220509130846.694397-1-javierm@redhat.com
We still need to calculate a virtual start address for the resource to
aid checking of it is visible or not. Only matters on small BAR systems,
but better save than sorry.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510113649.879821-1-christian.koenig@amd.com
This gives us the standard atomic implicit and explicit fencing rules.
v2: move the wait to amdgpu_dm_atomic_commit_tail
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Roman Li <Roman.Li@amd.com>
Cc: Qingqing Zhuo <qingqing.zhuo@amd.com>
Cc: Jude Shih <shenshih@amd.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220509074712.163899-1-christian.koenig@amd.com
'cat /sys/kernel/debug/dma_buf/bufinfo' will print the Dma-buf
Objects' information when the CONFIG_DEBUG_FS=y.
However, the printed table header information does not contain
the name field. So we need to add the name field to the table
header and use the '<none>' to replace the empty buf_obj->name.
Signed-off-by: Yuanzheng Song <songyuanzheng@huawei.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220428063924.3570409-1-songyuanzheng@huawei.com
The DP-helper module has been replaced by the display-helper module.
So the driver have to select it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 1e0f66420b13("drm/display: Introduce a DRM display-helper module")
Signed-off-by: Ren Zhijie <renzhijie2@huawei.com>
Reviewed-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220507100910.93705-1-renzhijie2@huawei.com
Add missing reg and reg-names properties for both 'LDB_CTRL'
and 'LVDS_CTRL' registers.
Fixes: 463db5c2ed4ae ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Robby Cai <robby.cai@nxp.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
To: dri-devel@lists.freedesktop.org
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504012601.423644-1-marex@denx.de
The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
works with a Mixel MIPI DPHY + LVDS PHY combo to support either
a MIPI DSI display or a LVDS display. So, this patch calls
phy_set_mode() from nwl_dsi_mode_set() to set PHY mode to MIPI DPHY
explicitly.
Cc: Guido Günther <agx@sigxcpu.org>
Cc: Robert Chiras <robert.chiras@nxp.com>
Cc: Martin Kepplinger <martin.kepplinger@puri.sm>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Acked-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220419010852.452169-2-victor.liu@nxp.com
Convert drm_find_cea_extension() to a predicate function to check if the
EDID has a CTA extension or a DisplayID CTA data block. This is mainly
to avoid adding new users that only find the first CTA extension.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a5bf228942e6bd0fc70d5cf7a14c249a14a7afcd.1651569697.git.jani.nikula@intel.com
The DisplayID CTA data block version does not necessarily match the CTA
revision. Simplify by postponing drm_edid_to_eld() slightly, and reusing
the CTA revision extracted by drm_parse_cea_ext().
By not bailing out early in drm_edid_to_eld() we may end up filling
meaningless data to the ELD. However, the main decision for audio is not
the ELD, but rather drm_detect_monitor_audio() called by drivers.
(Arguably a future cleanup could do that in drm_add_edid_modes() and
cache the result in the connector.)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/163ebbfd765066acbfc267256fb3b67fc711a78d.1651569697.git.jani.nikula@intel.com
Convert drm_find_cea_extension() to EDID block iterator in color format
and CTA revision detection. Detect them in all CTA extensions.
Also parse CTA Data Blocks in DisplayID even if there's no CTA EDID
extension.
v2:
- Don't assume DRM_COLOR_FORMAT_RGB444 support if there's only DisplayID
CTA Data Blocks (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220505105242.1198521-1-jani.nikula@intel.com
Iterate through all CTA data blocks across all CTA extensions and
DisplayID data blocks. This may gather more data than before, and if
there's duplicated data, some is overwritten by whichever comes last.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8bdc67aa731857111eddd08a9c192d41d40b5f5a.1651569697.git.jani.nikula@intel.com
