Make the default DP port preemphasis configurable via new DT property
"toshiba,pre-emphasis". This is useful in case the DP link properties
are known and starting link training from preemphasis setting of 0 dB
is not useful. The preemphasis can be set separately for both DP lanes
in range 0=0dB, 1=3.5dB, 2=6dB .
Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240708150130.54484-2-marex@denx.de
Document default DP port preemphasis configurable via new DT property
"toshiba,pre-emphasis". This is useful in case the DP link properties
are known and starting link training from preemphasis setting of 0 dB
is not useful. The preemphasis can be set separately for both DP lanes
in range 0=0dB, 1=3.5dB, 2=6dB .
This is an endpoint property, not a port property, because the TC9595
datasheet does mention that the DP might operate in some sort of split
mode, where each DP lane is used to feed one display, so in that case
there might be two endpoints.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240708150130.54484-1-marex@denx.de
Limiting the allocation of higher order pages to the closest NUMA node
and enabling direct memory reclaim provides not only failsafe against
situations when memory becomes too much fragmented and the allocator is
not able to satisfy the request from the local node but falls back to
remote pages (HUGEPAGE) but also offers performance improvement.
Accessing remote pages suffers due to bandwidth limitations and could be
avoided if memory becomes defragmented and in most cases without using
manual compaction. (/proc/sys/vm/compact_memory)
Note: On certain distros such as RHEL, the proactive compaction is
disabled. (https://tinyurl.com/4f32f7rs)
v2 (chk): drop __GFP_RECLAIM since that is already set by GFP_USER
Cc: Dave Airlie <airlied@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240708160636.1147308-1-rajneesh.bhardwaj@amd.com
Signed-off-by: Christian König <christian.koenig@amd.com>
At shutdown if you've got a _properly_ coded DRM modeset driver then
you'll get these two warnings at shutdown time:
Skipping disable of already disabled panel
Skipping unprepare of already unprepared panel
These warnings are ugly and sound concerning, but they're actually a
sign of a properly working system. That's not great.
We're not ready to get rid of the calls to drm_panel_disable() and
drm_panel_unprepare() because we're not 100% convinced that all DRM
modeset drivers are properly calling drm_atomic_helper_shutdown() or
drm_helper_force_disable_all() at the right times. However, having the
warning show up for correctly working systems is bad.
As a bit of a workaround, add some "if" tests to try to avoid the
warning on correctly working systems. Also add some comments and
update the TODO items in the hopes that future developers won't be too
confused by what's going on here.
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240621134427.1.Ieb287c2c3ee3f6d3b0d5f49b29f746b93621749c@changeid
The added lvds driver and a change in the dsi driver resulted in failed
builds when COMMON_CLK is disabled:
x86_64-linux-ld: drivers/gpu/drm/stm/dw_mipi_dsi-stm.o: in function `dw_mipi_dsi_stm_remove':
dw_mipi_dsi-stm.c:(.text+0x51e): undefined reference to `clk_hw_unregister'
x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_remove':
lvds.c:(.text+0xe3): undefined reference to `of_clk_del_provider'
x86_64-linux-ld: lvds.c:(.text+0xec): undefined reference to `clk_hw_unregister'
x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_pll_config':
lvds.c:(.text+0xb5d): undefined reference to `clk_hw_get_rate'
x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_probe':
lvds.c:(.text+0x1476): undefined reference to `clk_hw_register'
x86_64-linux-ld: lvds.c:(.text+0x148b): undefined reference to `of_clk_hw_simple_get'
x86_64-linux-ld: lvds.c:(.text+0x1493): undefined reference to `of_clk_add_hw_provider'
x86_64-linux-ld: lvds.c:(.text+0x1535): undefined reference to `clk_hw_unregister'
Add this as a dependency for the stm driver itself, since it will be
required in practice anyway.
Fixes: 185f99b614 ("drm/stm: dsi: expose DSI PHY internal clock")
Fixes: aca1cbc1c9 ("drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240719075454.3595358-1-arnd@kernel.org
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
There's no VBLANK interrupt on Matrox chipsets. The workaround that is
being used here and in other free Matrox drivers is to program <linecomp>
to the value of <vblkstr> and enable the VLINE interrupt. This triggers
an interrupt at the time when VBLANK begins.
VLINE uses separate registers for enabling and clearing pending interrupts.
No extra synchronization between irq handler and the rest of the driver is
required.
v6:
- clear VLINE status bit before registering IRQ (Jocelyn)
v5:
- disable all interrupts before registering IRQ (Jocelyn)
- don't read from ICLEAR (Jocelyn)
v4:
- recreate patch on latest upstream
- use devm_request_irq() for managed cleanup
- fail if vblanking cannot be initialized
- rename register constants (Sam, Emil)
- clear interrupt before registering handler (Ville)
- move <linecomp> programming into separate commit
- set <linecomp> to <vblkstr>
- fix typo in commit message
v3:
- set <linecomp> to <vdisplay> + 1 to trigger at VBLANK
- expand comment on linecomp
v2:
- only signal vblank on CRTC 0
- use constants for registers and fields
- set VLINECLR before enabling interrupt
- test against STATUS and IEN in irq handler
- coding-style fixes
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240718104551.575912-7-tzimmermann@suse.de
kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
callback.
This patch adds a new struct kmsg_dump_detail, that will hold the
reason and description, and pass it to the dump() callback.
To avoid updating all kmsg_dump() call, it adds a kmsg_dump_desc()
function and a macro for backward compatibility.
I've written this for drm_panic, but it can be useful for other
kmsg_dumper.
It allows to see the panic reason, like "sysrq triggered crash"
or "VFS: Unable to mount root fs on xxxx" on the drm panic screen.
v2:
* Use a struct kmsg_dump_detail to hold the reason and description
pointer, for more flexibility if we want to add other parameters.
(Kees Cook)
* Fix powerpc/nvram_64 build, as I didn't update the forward
declaration of oops_to_nvram()
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Acked-by: Petr Mladek <pmladek@suse.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Acked-by: Kees Cook <kees@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240702122639.248110-1-jfalempe@redhat.com
In case an upstream bridge modified the required clock frequency
in its .atomic_check callback by setting adjusted_mode.clock ,
make sure that clock frequency is generated by the LCDIFv3 block.
This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767
with (e)DP output, where the TC358767 expects precise timing on
its input side, the precise timing must be generated by the LCDIF.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240531202813.277109-1-marex@denx.de
The callbacks disable_vidrst and enable_vidrst are obsolete. Remove
the fields from struct mgag200_device_funcs. Instead call their
implementations directly of the field 'has_vidrst' has been set in
struct mgag200_device_info.
Also change the logic slightly. The BMC used to start and stop scanout
during the CRTC's atomic_enable and atomic_disable. Plane updates were
done while the BMC scanned out the display. Now only stop once in
atomic_disable at the beginning of a modeset and then restart the
scanout at the end of a modeset in atomic_enable. While the modeset
takes place, the BMC does not scanout at all.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240711072415.11831-3-tzimmermann@suse.de
The VRSTEN and HRSTEN bits control whether a CRTC synchronizes its
display signal with an external source on the VIDRST pin. The G200WB
and G200EW3 models synchronize with a BMC chip, but different external
video encoders, such as the Matrox Maven, can also be attached to the
pin.
Only set VRSTEN and HRSTEN bits in the CRTC mode-setting code, so the
bits are independent from the BMC. Add the field set_vidrst to the CRTC
state for this purpose. Off by default, control the CRTC VIDRST setting
from the CRTC's atomic_check helper.
v3:
- don't clear bits unnecessary (Jocelyn)
v2:
- keep logic entirely in CRTC (Jocelyn)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240711072415.11831-2-tzimmermann@suse.de
