Ville Syrjälä [Wed, 27 May 2020 13:03:09 +0000 (16:03 +0300)]
drm/edid: Iterate through all DispID ext blocks
Apparently there are EDIDs in the wild with multiple DispID extension
blocks. Iterate through them all.
In one particular case the tile information is specicied in the
second DispID ext block, and since the current parser only looks
at the first DispID ext block we don't notice that we're dealing
with a tiled display.
While at it change a few functions to return void since we have
no use for the errno.
Ville Syrjälä [Wed, 27 May 2020 13:03:08 +0000 (16:03 +0300)]
drm/edid: Allow looking for ext blocks starting from a specified index
Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
for iterating through multiple ext blocks of the same type by
passing the starting ext block index to drm_find_edid_extension(). Well
also have drm_find_edid_extension() update the index to point to the
next ext block on success. Thus we should be able to call
drm_find_edid_extension() in loop.
Chris Wilson [Wed, 8 Jul 2020 15:49:11 +0000 (16:49 +0100)]
drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
In particular, vgem_gem_dumb_map() was trying to reject mmapping an
imported dmabuf by checking the existence of obj->filp. Unfortunately,
we always allocated an obj->filp, even if unused for an imported dmabuf.
Instead, the drm_gem_dumb_map_offset(), since commit 90378e589192
("drm/gem: drm_gem_dumb_map_offset(): reject dma-buf"), uses the
obj->import_attach to reject such invalid mmaps.
This prevents vgem from allowing userspace mmapping the dumb handle and
attempting to incorrectly fault in remote pages belonging to another
device, where there may not even be a struct page.
v2: Use the default drm_gem_dumb_map_offset() callback
Marek Vasut [Sat, 29 Feb 2020 22:16:49 +0000 (23:16 +0100)]
drm/stm: repair runtime power management
Add missing pm_runtime_get_sync() into ltdc_crtc_atomic_enable() to
match pm_runtime_put_sync() in ltdc_crtc_atomic_disable(), otherwise
the LTDC might suspend via runtime PM, disable clock, and then fail
to resume later on.
The test which triggers it is roughly -- run qt5 application which
uses eglfs platform and etnaviv, stop the application, sleep for 15
minutes, run the application again. This leads to a timeout waiting
for vsync, because the LTDC has suspended, but did not resume.
Fixes: 35ab6cfbf211 ("drm/stm: support runtime power management") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Yannick Fertré <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@st.com>
To: dri-devel@lists.freedesktop.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-arm-kernel@lists.infradead.org Acked-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Yannick Fertre <yannick.fertre@st.com> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200229221649.90813-1-marex@denx.de
Neil Armstrong [Tue, 7 Jul 2020 13:50:09 +0000 (15:50 +0200)]
drm/meson: overlay: fix build failure
The recent GCC compiler is very picky with the VD_H_START() and
AFBC_DEC_PIXEL_BGN_H() macros, triggering a runtime assert error as:
In function 'meson_overlay_setup_scaler_params',
inlined from 'meson_overlay_atomic_update' at
drivers/gpu/drm/meson/meson_overlay.c:542:2:
./include/linux/compiler.h:392:38: error: call to
'__compiletime_assert_341' declared with attribute error: FIELD_PREP:
value too large for the field
drivers/gpu/drm/meson/meson_overlay.c:413:4: note: in expansion of macro
'AFBC_DEC_PIXEL_BGN_H'
413 | AFBC_DEC_PIXEL_BGN_H(hd_start_lines - afbc_left) |
| ^~~~~~~~~~~~~~~~~~~~
./include/linux/compiler.h:392:38: error: call to
'__compiletime_assert_401' declared with attribute error: FIELD_PREP:
value too large for the field
It's not expected to overflow these fields, but the compiler did
find a case where it overflows.
We can safely ignore this, so mask the value with the field width.
drm/ast: Initialize mode setting in ast_mode_config_init()
There's modesetting init code in ast_main.c. Move it to ast_mode.c and
merge it with the modesetting init code in ast_mode_init(). The result
is ast_mode_config_init(), which initalizes the whole modesetting.
drm/ast: Replace struct ast_crtc with struct drm_crtc
Struct ast_crtc has been cleaned up and it's now a wrapper around the
DRM CRTC structure struct drm_crtc. This patch converts the driver to
struct drm_crtc and removes struct ast_crtc.
drm/ast: Init cursors before creating modesetting structures
The cursor helpers reserve buffer objects in VRAM and update their
content. So although tied to modesetting, cursor helpers are more
of a memory manager. The modesetting's cursor plane requires this
functionality, so initialize cursors before modesetting.
While at it, also add an error check for ast_cursor_init().
Updating the image in a cursor's HW BO requires a mapping of the BO's
buffer in the kernel's address space. Cursor image updates can happen
frequently and create CPU overhead.
As cursor HW BOs are small and never move, they are now map exactly
once during the initialization and the mapping is used throughout the
driver's lifetime.
This change also removes a possible source of failures from
ast_cursor_show(). As the helper does not establish mappings, it cannot
fail. As a result, the cursor plane's atomic-update helper does not
call any failable interfaces. All failures are detected before trying
to update the cursor plane.
drm/ast: Replace ast_cursor_move() with ast_cursor_show()
Having a cursor move function is misleading, as it actually enables the
cursor's image for displaying. So rename it to ast_cursor_show(). It's
semantics is to show a cursor at the specified location on the screen.
The displayed cursor is always the image in the cursor front BO.
This change also simplifies struct ast_crtc to being a mere wrapper around
around struct drm_crtc. It will be removed by a later patch.
drm/ast: Move cursor fb pinning and mapping into helper
The new helper ast_cursor_blit() updates a cursor's backbuffer HW
BO from a framebuffer structure. The cursor plane's prepare_fb()
function now uses the new interface.
Pinning and mapping of BOs is done automatically by the helper. This
includes the source BO, which was not pinned by the original code in
prepare_fb().
Maxime Ripard [Thu, 11 Jun 2020 13:36:54 +0000 (15:36 +0200)]
drm/vc4: crtc: Remove the feed_txp tests
Now that the code in vc4_crtc accessing registers is only meant for the
pixelvalve, it doesn't make sense anymore to test whether we're accessing
the TXP or not and we can safely remove those checks.
Maxime Ripard [Thu, 11 Jun 2020 13:36:53 +0000 (15:36 +0200)]
drm/vc4: txp: Turn the TXP into a CRTC of its own
The TXP so far has been leveraging the PixelValve infrastructure in the
driver, that was really two things: the interaction with DRM's CRTC
concept, the setup of the underlying pixelvalve and the setup of the shared
HVS, the pixelvalve part being irrelevant to the TXP since it accesses the
HVS directly.
Now that we have a clear separation between the three parts, we can
represent the TXP as a CRTC of its own, leveraging the common CRTC and HVS
code, but leaving aside the pixelvalve setup.
Maxime Ripard [Thu, 11 Jun 2020 13:36:51 +0000 (15:36 +0200)]
drm/vc4: crtc: Move the CRTC initialisation to a separate function
The upcoming patches to turn the TXP into a full-blown CRTC will have the
same CRTC initialisation code, so let's move it into a separate, public,
function so that we can reuse it later on.
Maxime Ripard [Thu, 11 Jun 2020 13:36:50 +0000 (15:36 +0200)]
drm/vc4: crtc: Only access the PixelValve registers if we have to
The CRTC hooks are called both for the TXP and the pixelvalve, yet some
will read / write the registers as if the device was a pixelvalve, which
won't really work.
Let's make sure we only access those registers if we are running on a
PixelValve.
Maxime Ripard [Thu, 11 Jun 2020 13:36:49 +0000 (15:36 +0200)]
drm/vc4: crtc: Split CRTC data in two
The vc4_crtc_data structure is currently storing data related to both the
general CRTC information needed by the rest of the vc4 driver (like HVS
output and available FIFOs) and some related to the pixelvalve attached to
that CRTC. Let's split this into two structures so that we can reuse the
CRTC part into the TXP later on.
Maxime Ripard [Thu, 11 Jun 2020 13:36:47 +0000 (15:36 +0200)]
drm/vc4: crtc: Move HVS setup code to the HVS driver
The CRTC in vc4 is backed by two devices, the HVS that does the composition
and the PixelValve that does the timing generation.
The writeback is kind of a special case since it doesn't have an associated
pixelvalve but goes straight from the HVS to the TXP. Therefore, it makes
sense to move out the HVS setup code into helpers so that we can also reuse
them from the TXP driver.
Maxime Ripard [Thu, 11 Jun 2020 13:36:46 +0000 (15:36 +0200)]
drm/vc4: Reorder the bind order of the devices
We'll need the HVS to be bound before the TXP for the upcoming reworks, but
it needs to happen before the PV are bound so that the code to set the
possible_crtcs field works properly on the TXP. Move it right between the
two devices.
Maxime Ripard [Fri, 3 Jul 2020 13:57:13 +0000 (15:57 +0200)]
drm/vc4: Convert register accessors to FIELD_*
The VC4_SET_FIELD and VC4_GET_FIELD are reimplementing most of the logic
already defined in FIELD_SET and FIELD_GET. Let's convert the vc4 macros to
use the FIELD_* macros.
Brian Starkey [Fri, 26 Jun 2020 16:48:00 +0000 (17:48 +0100)]
drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
describes a generic pixel re-ordering which can be applicable to
multiple vendors.
Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
used to describe this layout in a vendor-neutral way, and add a
comment about the expected usage of such "generic" modifiers.
Changes in v2:
- Move note about future cases to comment (Daniel)
Neil Armstrong [Fri, 3 Jul 2020 08:07:23 +0000 (10:07 +0200)]
drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT
This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.
This introduces the basic layout composed of:
- a body content organized in 64x32 superblocks with 4096 bytes per
superblock in default mode.
- a 32 bytes per 128x64 header block
This layout is tranferrable between Amlogic SoCs supporting this modifier.
The Memory Saving option exist changing the layout superblock size to save memory when
using 8bit components pixels size.
Finally is also adds the Scatter Memory layout, meaning the header contains IOMMU
references to the compressed frames content to optimize memory access
and layout.
In this mode, only the header memory address is needed, thus the content
memory organization is tied to the current producer execution and cannot
be saved/dumped neither transferrable between Amlogic SoCs supporting this
modifier.
Daniel Vetter [Fri, 12 Jun 2020 20:49:40 +0000 (22:49 +0200)]
drm/vmwgfx: Use __drm_atomic_helper_crtc_reset
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Daniel Vetter [Fri, 12 Jun 2020 16:00:53 +0000 (18:00 +0200)]
drm/vc4: Use __drm_atomic_helper_crtc_reset
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Daniel Vetter [Fri, 12 Jun 2020 16:00:52 +0000 (18:00 +0200)]
drm/mtk: Use __drm_atomic_helper_crtc_reset
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-4-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 12 Jun 2020 16:00:51 +0000 (18:00 +0200)]
drm/imx: Use __drm_atomic_helper_crtc_reset
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: linux-arm-kernel@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-3-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 12 Jun 2020 16:00:50 +0000 (18:00 +0200)]
drm/amdgpu: Use __drm_atomic_helper_crtc_reset
Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
which means vblank state isn't ill-defined and fail-y at driver load
before the first modeset on each crtc.
Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Stylon Wang <stylon.wang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-2-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 12 Jun 2020 16:00:49 +0000 (18:00 +0200)]
drm/atomic-helper: reset vblank on crtc reset
Only when vblanks are supported ofc.
Some drivers do this already, but most unfortunately missed it. This
opens up bugs after driver load, before the crtc is enabled for the
first time. syzbot spotted this when loading vkms as a secondary
output. Given how many drivers are buggy it's best to solve this once
and for all in shared helper code.
Aside from moving the few existing calls to drm_crtc_vblank_reset into
helpers (i915 doesn't use helpers, so keeps its own) I think the
regression risk is minimal: atomic helpers already rely on drivers
calling drm_crtc_vblank_on/off correctly in their hooks when they
support vblanks. And driver that's failing to handle vblanks after
this is missing those calls already, and vblanks could only work by
accident when enabling a CRTC for the first time right after boot.
Big thanks to Tetsuo for helping track down what's going wrong here.
There's only a few drivers which already had the necessary call and
needed some updating:
- komeda, atmel and tidss also needed to be changed to call
__drm_atomic_helper_crtc_reset() intead of open coding it
- tegra and msm even had it in the same place already, just code
motion, and malidp already uses __drm_atomic_helper_crtc_reset().
- Laurent noticed that rcar-du and omap open-code their crtc reset and
hence would actually be broken by this patch now. So fix them up by
reusing the helpers, which brings the drm_crtc_vblank_reset() back.
Only call left is in i915, which doesn't use drm_mode_config_reset,
but has its own fastboot infrastructure. So that's the only case where
we actually want this in the driver still.
I've also reviewed all other drivers which set up vblank support with
drm_vblank_init. After the previous patch fixing mxsfb all atomic
drivers do call drm_crtc_vblank_on/off as they should, the remaining
drivers are either legacy kms or legacy dri1 drivers, so not affected
by this change to atomic helpers.
v2: Use the drm_dev_has_vblank() helper.
v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
instead of drm_crtc_vblank_reset. Adjust them too.
v4: Laurent noticed that rcar-du and omap open-code their crtc reset
and hence would actually be broken by this patch now. So fix them up
by reusing the helpers, which brings the drm_crtc_vblank_reset() back.
v5: also mention rcar-du and ompadrm in the proper commit message
above (Laurent).
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: syzbot+0871b14ca2e2fb64f6e3@syzkaller.appspotmail.com Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: zhengbin <zhengbin13@huawei.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-tegra@vger.kernel.org Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-1-daniel.vetter@ffwll.ch
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to wait upon
for a particular point in the timeline. The timeline progresses only
when all the points prior to a given number have completed.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: dc2f7e67a28a5c ("dma-buf: Exercise dma-fence-chain under selftests") Link: https://patchwork.freedesktop.org/patch/372960/ Signed-off-by: Christian König <christian.koenig@amd.com>
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed to
give a fence to wait on for a particular point in the timeline.
In a timeline, a particular value is reached when all the points up to
and including that value have signaled.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372958/ Signed-off-by: Christian König <christian.koenig@amd.com>
Christian König [Wed, 1 Jul 2020 11:24:12 +0000 (13:24 +0200)]
MAINTAINERS: Add myself as DMA-buf maintainer
As discussed on the list.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/373539/
Ondrej Jirman [Wed, 1 Jul 2020 16:29:23 +0000 (18:29 +0200)]
drm/panel: st7703: Move generic part of init sequence to enable callback
Calling sleep out and display on is a controller specific part
of the initialization process. Move it out of the panel specific
initialization function to the enable callback.
Ondrej Jirman [Wed, 1 Jul 2020 16:29:20 +0000 (18:29 +0200)]
drm/panel: st7703: Rename functions from jh057n prefix to st7703
This is done so that code that's not specific to a particular
jh057n panel is named after the controller. Functions specific
to the panel are kept named after the panel.
Ondrej Jirman [Wed, 1 Jul 2020 16:29:18 +0000 (18:29 +0200)]
dt-bindings: panel: Add compatible for Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. It is based on
Sitronix ST7703 LCD controller just like rocktech,jh057n00900. It is
used in PinePhone.
Sam Ravnborg [Tue, 30 Jun 2020 18:05:43 +0000 (20:05 +0200)]
drm/panel: panel-simple: drop use of legacy drm_bus_flags
Replace all uses of the legacy drm_bus_flags with their relevant
_SAMPLE_ variant.
This is a 1:1 replacement, no effort was made to validate the actual
bus flags for the panels.
drm/of: Make drm_of_find_panel_or_bridge() to check graph's presence
When graph isn't defined in a device-tree, the of_graph_get_remote_node()
prints a noisy error message, telling that port node is not found. This is
undesirable behaviour in our case because absence of a panel/bridge graph
is a valid case. Let's check the graph's presence in a device-tree before
proceeding with parsing of the graph.
In some cases it's very useful to silently check whether port node exists
at all in a device-tree before proceeding with parsing the graph. The DRM
bridges code is one example of such case where absence of a graph in a
device-tree is a legit condition.
This patch adds of_graph_is_present() which returns true if given
device-tree node contains OF graph port.
Laurent Pinchart [Mon, 29 Jun 2020 23:33:20 +0000 (02:33 +0300)]
drm: panel: simple: Warn in case of incorrect bus format for LVDS panels
Only the MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG and MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA bus
formats are valid for LVDS panels. Warn at probe time to catch the
common mistake of using an incorrect format, as well as discrepancies
between the bus format and the reported bpc.
Laurent Pinchart [Mon, 29 Jun 2020 23:33:19 +0000 (02:33 +0300)]
drm: panel: simple: Drop drive/sample bus flags for LVDS panels
The DRM bus flags reporting on which clock edge the pixel data and sync
signals are sampled or driven don't make sense for LVDS panels, as the
bus then uses sub-clock timings to send data. Drop those flags and add a
warning in the probe function to make sure the mistake won't be
repeated.
Laurent Pinchart [Mon, 29 Jun 2020 23:33:18 +0000 (02:33 +0300)]
drm: panel: simple: Correct bus format for Satoz SAT050AT40H12R2
The Satoz SAT050AT40H12R2 panel is an LVDS panel, the
MEDIA_BUS_FMT_RGB888_1X24 bus format is thus incorrect. Set it to the
correct value MEDIA_BUS_FMT_RGB888_1X7X4_SPWG.
Added epoch counter checking to intel_encoder_hotplug
in order to be able process all the connector changes,
besides connection status. Also now any change in connector
would result in epoch counter change, so no multiple checks
are needed.
v2: Renamed change counter to epoch counter. Fixed type name.
v3: Fixed rebase conflict
v4: Remove duplicate drm_edid_equal checks from hdmi and dp,
lets use only once edid property is getting updated and
increment epoch counter from there.
Also lets now call drm_connector_update_edid_property
right after we get edid always to make sure there is a
unified way to handle edid change, without having to
change tons of source code as currently
drm_connector_update_edid_property is called only in
certain cases like reprobing and not right after edid is
actually updated.
v5: Fixed const modifiers, removed blank line
v6: Removed drm specific part from this patch, leaving only
i915 specific changes here.
This counter will be used by drm_helper_probe_detect caller to determine
if anything had changed(including edid, connection status and etc).
Hardware specific driver detect hooks are responsible for updating this
counter when some change is detected to notify the drm part,
which can trigger for example hotplug event.
Also now call drm_connector_update_edid_property
right after we get edid always to make sure there is a
unified way to handle edid change, without having to
change tons of source code as currently
drm_connector_update_edid_property is called only in
certain cases like reprobing and not right after edid is
actually updated.
v2: Added documentation for the new counter. Rename change_counter to
epoch_counter.
Maxime Ripard [Fri, 26 Jun 2020 12:11:31 +0000 (14:11 +0200)]
dt-bindings: display: vc4: dpi: Fix panel warning
The example used in the DPI binding before the conversion to YAML had a
simple-panel example that got carried over to the YAML binding.
However, that example doesn't match the simple-panel binding and results in
validation errors. Since it's only marginally helpful, let's remove that
part of the example entirely.
Linus Walleij [Tue, 9 Jun 2020 20:04:45 +0000 (22:04 +0200)]
drm: pl111: Absorb the external register header
The PL111 DRM driver is now the sole user of the external
CLCD registers header file, so let's absorb that into the
pl111_drm.h file and save the external include.
Linus Walleij [Tue, 9 Jun 2020 20:04:44 +0000 (22:04 +0200)]
video: fbdev: amba-clcd: Retire elder CLCD driver
All the functionality in this driver has been reimplemented
in the new DRM driver in drivers/gpu/drm/pl111/* and all
the boards using it have been migrated to use the DRM driver
with all configuration coming from the device tree.
I started the work to migrate the CLCD driver to DRM in
april 2017 and it took a little more than 3 years to do this
properly without leaving any platforms behind.
Emil Velikov [Tue, 5 May 2020 16:03:28 +0000 (17:03 +0100)]
drm/panel: use mipi_dsi_dcs_write_buffer where possible
A few of the new panels create a local macro wrapping around
mipi_dsi_dcs_write. At the same time, they don't really care about the
command/payload split.
mipi_dsi_dcs_write does a kmalloc/memcpy/kfree for payload > 7 bytes.
Avoid that all together by using the _buffer function.
Aside:
panel-xinpeng-xpp055c272.c calls its wrapper "generic" although it
should be "dcs". But that for another day/patch.
Cc: Heiko Stuebner <heiko@sntech.de> Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200505160329.2976059-2-emil.l.velikov@gmail.com
Emil Velikov [Tue, 5 May 2020 16:03:27 +0000 (17:03 +0100)]
drm/dsi: use stack buffer in mipi_dsi_dcs_write()
Currently the function heap allocates when we have any payload. Where in
many case the payload is 1 byte - ouch.
>From casual observation, vast majority of the payloads are smaller than
8 bytes - so use a stack array tx[8] to avoid the senseless kmalloc and
kfree dance.
Nirmoy Das [Wed, 24 Jun 2020 18:26:48 +0000 (20:26 +0200)]
drm/ttm: do not keep GPU dependent addresses
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372937/ Signed-off-by: Christian König <christian.koenig@amd.com>
Nirmoy Das [Thu, 25 Jun 2020 12:07:23 +0000 (14:07 +0200)]
drm/scheduler: improve job distribution with multiple queues
This patch uses score to select a new drm scheduler for better
loadbalance between multiple drm schedulers instead of num_jobs.
Below are test results after running amdgpu_test for ~10 times.
Before this patch:
sched_name num of many times it got schedule
========= ==================================
sdma0 1463
sdma1 198
comp_1.0.1 280
After this patch:
sched_name num of many times it got schedule
========= ==================================
sdma0 925
sdma1 928
comp_1.0.1 177
comp_1.1.1 44
comp_1.2.1 43
comp_1.3.1 44
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/373000/ Signed-off-by: Christian König <christian.koenig@amd.com>
Nirmoy Das [Wed, 24 Jun 2020 18:26:44 +0000 (20:26 +0200)]
drm/nouveau: don't use ttm bo->offset v3
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372932/ Signed-off-by: Christian König <christian.koenig@amd.com>
Nirmoy Das [Wed, 24 Jun 2020 18:26:43 +0000 (20:26 +0200)]
drm/vmwgfx: don't use ttm bo->offset
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372933/ Signed-off-by: Christian König <christian.koenig@amd.com>
Harigovindan P [Tue, 9 Jun 2020 12:04:55 +0000 (17:34 +0530)]
drm/bridge: ti-sn65dsi86: ensure bridge suspend happens during PM sleep
ti-sn65dsi86 bridge is enumerated as a runtime device. When
suspend is triggered, PM core adds a refcount on all the
devices and calls device suspend, since usage count is
already incremented, runtime suspend will not be called
and it kept the bridge regulators and gpios ON which resulted
in platform not entering into XO shutdown.
Add changes to force suspend on the runtime device during pm sleep.
drm/debug: Expose connector VRR monitor range via debugfs
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v2:
* Fix the typo in max_vfreq (Manasi)
* Change the name of node to i915_vrr_info so we can add
other vrr info for more debug info (Manasi)
* Change the VRR capable to display Yes or No (Manasi)
* Fix indentation checkpatch errors (Manasi)
v3:
* Remove the unnecessary debug print (Manasi)
v4:
* Rebase
v5:
* Rename to vrr_range to match AMD debugfs
v6:
* Rebase (manasi)
v7:
* Fix cmpilation due to rebase
v8:
* Move debugfs node creation logic to DRM (Emil)
* Remove AMD specific logic (Emil)
v9:
* Separate patch for removal of AMD specific logic (Manasi)
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> CC: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200622142519.16214-3-bhanuprakash.modem@intel.com
projects / mirror_ubuntu-kernels.git / log