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
Nirmoy Das [Wed, 24 Jun 2020 18:26:47 +0000 (20:26 +0200)]
drm/bochs: use drm_gem_vram_offset to get bo offset v2
Switch over to GEM VRAM's implementation to retrieve bo->offset.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372931/
Nirmoy Das [Wed, 24 Jun 2020 18:26:46 +0000 (20:26 +0200)]
drm/vram-helper: don't use ttm bo->offset v4
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372938/
Nirmoy Das [Wed, 24 Jun 2020 18:26:45 +0000 (20:26 +0200)]
drm/qxl: don't use ttm bo->offset
This patch removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar.
This patch also removes unused qxl_bo_gpu_offset()
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372934/
Nirmoy Das [Wed, 24 Jun 2020 18:26:42 +0000 (20:26 +0200)]
drm/radeon: don't use ttm bo->offset
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-and-tested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372935/
Nirmoy Das [Wed, 24 Jun 2020 18:26:41 +0000 (20:26 +0200)]
drm/amdgpu: move ttm bo->offset to amdgpu_bo
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372930/
Daniel Vetter [Fri, 12 Jun 2020 07:05:35 +0000 (09:05 +0200)]
dma-buf: minor doc touch-ups
Just some tiny edits:
- fix link to struct dma_fence
- give slightly more meaningful title - the polling here is about
implicit fences, explicit fences (in sync_file or drm_syncobj) also
have their own polling
v2: I misplaced the .rst include change corresponding to this patch.
Daniel Vetter [Fri, 12 Jun 2020 16:00:55 +0000 (18:00 +0200)]
drm/mipi-dbi: Remove ->enabled
The atomic helpers try really hard to not lose track of things,
duplicating enabled tracking in the driver is at best confusing.
Double-enabling or disabling is a bug in atomic helpers.
In the fb_dirty function we can just assume that the fb always exists,
simple display pipe helpers guarantee that the crtc is only enabled
together with the output, so we always have a primary plane around.
Now in the update function we need to be a notch more careful, since
that can also get called when the crtc is off. And we don't want to
upload frames when that's the case, so filter that out too.
Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: David Lechner <david@lechnology.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.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: David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-7-daniel.vetter@ffwll.ch
Dave Airlie [Tue, 23 Jun 2020 00:58:28 +0000 (10:58 +1000)]
Merge tag 'drm-misc-next-2020-06-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v5.9:
UAPI Changes:
- Add DRM_MODE_TYPE_USERDEF for video modes specified in cmdline.
Cross-subsystem Changes:
- Assorted devicetree binding updates.
- Add might_sleep() to dma_fence_wait().
- Fix fbdev's get_user_pages_fast() handling, and use pin_user_pages.
- Small cleanup with IS_BUILTIN in video/fbdev drivers.
- Fix video/hdmi coding style for infoframe size.
Core Changes:
- Silence vblank output during init.
- Fix DP-MST corruption during send msg timeout.
- Clear leak in drm_gem_objecs_lookup().
- Make newlines work with force connector attribute.
- Fix module refcounting error in drm_encoder_slave, and use new i2c api.
- Header fix for drm_managed.c
- More struct_mutex removal for !legacy drivers:
- Remove gem_free_object()
- Removal of drm_gem_object_put_unlocked().
- Show current->comm alongside pid in debug printfs.
- Add drm_client_modeset_check() + drm_client_framebuffer_flush().
- Replace drm_fb_swab16 with drm_fb_swap that also supports 32-bits.
- Remove mode->vrefresh, and compactify drm_display_mode.
- Use drm_* macros for logging and warnings.
- Add WARN when drm_gem_get_pages is used on a private obj.
- Handle importing and imported dmabuf better in shmem helpers.
- Small fix for drm/mm hole size comparison, and remove invalid entry optimization.
- Add a drm/mm selftest.
- Set DSI connector type for DSI panels.
- Assorted small fixes and documentation updates.
- Fix DDI I2C device registration for MST ports, and flushing on destroy.
- Fix master_set return type, used by vmwgfx.
- Make the drm_set/drop_master ioctl symmetrical.
Driver Changes:
Allow iommu in the sun4i driver and use it for sun8i.
- Simplify backlight lookup for omap, amba-clcd and tilcdc.
- Hold reg_lock for rockchip.
- Add support for bridge gpio and lane reordering + polarity to ti-sn65dsi86, and fix clock choice.
- Small assorted fixes to tilcdc, vc4, i915, omap, fbdev/sm712fb, fbdev/pxafb, console/newport_con, msm, virtio, udl, malidp, hdlcd, bridge/ti-sn65dsi86, panfrost.
- Remove hw cursor support for mgag200, and use simple kms helper + shmem helpers.
- Add support for KOE Allow iommu in the sun4i driver and use it for sun8i.
- Simplify backlight lookup for omap, amba-clcd and tilcdc.
- Hold reg_lock for rockchip.
- Add support for bridge gpio and lane reordering + polarity to ti-sn65dsi86, and fix clock choice.
- Small assorted fixes to tilcdc, vc4 (multiple), i915.
- Remove hw cursor support for mgag200, and use simple kms helper + shmem helpers.
- Add support for KOE TX26D202VM0BWA panel.
- Use GEM CMA functions in arc, arm, atmel-hlcdc, fsi-dcu, hisilicon, imx, ingenic, komeda, malidp, mcde, meson, msxfb, rcar-du, shmobile, stm, sti, tilcdc, tve200, zte.
- Remove gem_print_info.
- Improve gem_create_object_helper so udl can use shmem helpers.
- Convert vc4 dt bindings to schemas, and add clock properties.
- Device initialization cleanups for mgag200.
- Add a workaround to fix DP-MST short pulses handling on broken hardware in i915.
- Allow build test compiling arm drivers.
- Use managed pci functions in mgag200 and ast.
- Use dev_groups in malidp.
- Add per pixel alpha support for PX30 VOP in rockchip.
- Silence deferred probe logs in panfrost.
Laurent Pinchart [Tue, 26 May 2020 01:15:00 +0000 (04:15 +0300)]
drm: bridge: dw-hdmi: Make connector creation optional
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() notify to report HPD. This provides the
necessary API to support disabling connector creation, do so by
accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in dw_hdmi_bridge_attach().
Laurent Pinchart [Tue, 26 May 2020 01:14:59 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass drm_connector to internal functions as needed
To prepare for making connector creation optional in the driver, pass
the drm_connector explicitly to the internal functions that require it.
The functions that still access the connector from the dw_hdmi structure
are dw_hdmi_connector_create() and __dw_hdmi_probe(). The former access
is expected, as that's where the internal connector is created. The
latter will be addressed separately.
Laurent Pinchart [Tue, 26 May 2020 01:14:58 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Store current connector in struct dw_hdmi
Store the connector that the bridge is currently wired to in the dw_hdmi
structure. This is currently identical to the connector field, but will
differ once the driver supports disabling connector creation.
Laurent Pinchart [Tue, 26 May 2020 01:14:56 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass drm_display_info to dw_hdmi_support_scdc()
To prepare for making connector creation optional in the driver, pass
the drm_display_info explicitly to dw_hdmi_support_scdc(). The pointer
is passed to the callers where required, particularly to the
dw_hdmi_phy_ops .init() function.
Laurent Pinchart [Tue, 26 May 2020 01:14:55 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Constify mode argument to internal functions
Several internal functions take a drm_display_mode argument to configure
the HDMI encoder or the HDMI PHY. They must not modify the mode, make
the pointer const to enforce that.
Laurent Pinchart [Tue, 26 May 2020 01:14:53 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass drm_display_info to .mode_valid()
Replace the drm_connector pointer passed to the .mode_valid() function
with a const drm_display_info pointer, as that's all the function should
need. Use the display info passed to the bridge .mode_valid() operation
instead of retrieving it from the connector, to prepare for make
connector creation optional.
Laurent Pinchart [Tue, 26 May 2020 01:14:52 +0000 (04:14 +0300)]
drm: meson: dw-hdmi: Use dw_hdmi context to replace hack
The meson-dw-hdmi driver needs to access its own context from the
.mode_valid() operation. It currently gets it from the dev_private field
of the drm_device retrieved from the connector, which is a hack. Use the
private data passed to the .mode_valid() operation instead.
Laurent Pinchart [Tue, 26 May 2020 01:14:50 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass private data pointer to .configure_phy()
The .configure_phy() operation takes a dw_hdmi_plat_data pointer as a
context argument. This differs from .mode_valid() that takes a custom
private context pointer, causing possible confusion. Make the
dw_hdmi_plat_data operations more consistent by passing the private
context pointer to .configure_phy() as well.
Laurent Pinchart [Tue, 26 May 2020 01:14:49 +0000 (04:14 +0300)]
drm: bridge: dw-hdmi: Pass private data pointer to .mode_valid()
Platform glue drivers for dw_hdmi may need to access device-specific
data from their .mode_valid() implementation. They currently have no
clean way to do so, and one driver hacks around it by accessing the
dev_private data of the drm_device retrieved from the connector.
Add a priv_data void pointer to the dw_hdmi_plat_data structure, and
pass it to the .mode_valid() function.
projects / mirror_ubuntu-kernels.git / log