| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is
in DMA-able memory and should be accessed with the CPU's regular
memory ops.
v2:
* drop FBINFO_FLAG_DEFAULT
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by : Inki Dae <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Cc: Inki Dae <[email protected]>
Cc: Seung-Woo Kim <[email protected]>
Cc: Kyungmin Park <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Alim Akhtar <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use fbdev's DMA helpers for fbdev emulation. The driver previously
used the I/O-memory helpers, while allocating DMA-able system memory.
This could (in theory) result in bus errors from accessing the memory
range.
This bug has been present since the exynos driver was first added.
v2:
* drop the pointless Fixes tag (Javier)
* fix typo in commit message
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Inki Dae <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Cc: Inki Dae <[email protected]>
Cc: Seung-Woo Kim <[email protected]>
Cc: Kyungmin Park <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Alim Akhtar <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Tegra uses DMA-able memory, which has to be acessed with CPU ops
for system-memory. Store the framebuffer's vmap address in struct
fb_info.screen_buffer. The currently used field 'screen_base' is
for I/O memory.
Suggested-by: Thierry Reding <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Mikko Perttunen <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is
in DMA-able memory and should be accessed with the CPU's regular
memory ops.
v2:
* drop FBINFO_DEFAULT
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Mikko Perttunen <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use fbdev's DMA helpers for fbdev emulation. They are equivalent to the
previously used system-memory helpers, so no functional changes here.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Mikko Perttunen <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use fbdev's DMA helpers for fbdev-dma. They are equivalent to the
previously used system-memory helpers, so no functional changes here.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add initializer macros for struct fb_ops for framebuffers in DMA-able
memory areas. Also add a corresponding Kconfig token. As of now, this
is equivalent to system framebuffers and mostly useful for labeling
drivers correctly.
A later patch may add a generic DMA-specific mmap operation. Linux
offers a number of dma_mmap_*() helpers for different use cases.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
These variables are never referenced in the code.
Signed-off-by: Luca Ceresoli <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Most fbdev drivers depend on framebuffer_alloc() to initialize the
allocated memory to 0. Document this guarantee.
v3:
* slightly reword the sentence (Miguel)
Suggested-by: Miguel Ojeda <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Miguel Ojeda <[email protected]>
Reviewed-by: Sui Jingfeng <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No
functional changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by a static declaration. So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Jaya Kumar <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Peter Jones <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: Maik Broemme <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: Michal Januszewski <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Andy Walls <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Hans Verkuil <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Acked-by: Benjamin Tissoires <[email protected]>
Acked-by: Bruno Prémont <[email protected]>
Cc: "Bruno Prémont" <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Benjamin Tissoires <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Cc: Miguel Ojeda <[email protected]>
Cc: Robin van der Gracht <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_.
v3:
* include board name in commit message (Adrian)
v2:
* assign FB_MODE_IS_UNKNOWN (Adrian)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Acked-by: John Paul Adrian Glaubitz <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Kirti Wankhede <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Timur Tabi <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Ferenc Bakonyi <[email protected]>
Cc: "K. Y. Srinivasan" <[email protected]>
Cc: Haiyang Zhang <[email protected]>
Cc: Wei Liu <[email protected]>
Cc: Dexuan Cui <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Maik Broemme <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Kristoffer Ericson <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Steve Glendinning <[email protected]>
Cc: Bernie Thompson <[email protected]>
Cc: Florian Tobias Schandinat <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by devm_kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Russell King <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by a static declaration. So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Patrik Jakobsson <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: "Christian König" <[email protected]>
Cc: "Pan, Xinhui" <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Backmerging to get v6.5-rc2.
Signed-off-by: Thomas Zimmermann <[email protected]>
|
|
This code is not using the correct gfp flags which were passed in.
However, this does not affect runtime because kstrdup_const() is a
no-op in this context. (It just returns the "kmalloc" string literal
without doing an allocation.)
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
These two drivers embed a i2c_client in their private driver data, but
only strict device is actually needed. Replace the i2c_client reference
with a struct device one.
Signed-off-by: Pin-yen Lin <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace the spaces with tab characters in the Kconfig file.
Signed-off-by: Pin-yen Lin <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The device lock is used to serialize the low level power sequencing
operations. Since drm_helper_hpd_irq_event() could end up calling
.atomic_enable, which also calls power sequencing functions through
runtime PM, this results in a real deadlock. This was observed on an
MT8192-based Chromebook's external display (with appropriate patches [1]
and DT changes applied).
Move the drm_helper_hpd_irq_event() call outside of the lock range. The
lock only needs to be held so that the device status can be read back.
This is the bare minimum change to avoid the deadlock. The lock could
be dropped completely and have pm_runtime_get_if_in_use() increase the
reference count, but this is not the same as pm_runtime_suspended().
Dropping the lock completely also causes the internal display of the
same device to not function correctly if the internal bridge's
interrupt line is added in the device tree. Both the internal and
external display of said device each use one anx7625 bridge.
[1] https://lore.kernel.org/dri-devel/[email protected]/
Fixes: 60487584a79a ("drm/bridge: anx7625: refactor power control to use runtime PM framework")
Signed-off-by: Chen-Yu Tsai <[email protected]>
Reviewed-by: Robert Foss <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Now that fbdev core has been split in FB_CORE and FB, make the DRM symbol
to select the FB_CORE option if the DRM fbdev emulation layer is enabled.
This allows to disable the CONFIG_FB option if is not needed, which will
avoid the need to explicitly disable each of the legacy fbdev drivers.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Tested-by: Arnd Bergmann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
drivers are needed (e.g: only to have support for framebuffer consoles).
The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB
and so it can only be enabled if that dependency is enabled as well.
That means fbdev drivers have to be explicitly disabled if users want to
enable CONFIG_FB, only to use fbcon and/or the DRM fbdev emulation layer.
This patch introduces a non-visible CONFIG_FB_CORE symbol that could be
enabled just to have core support needed for CONFIG_DRM_FBDEV_EMULATION,
allowing CONFIG_FB to be disabled (and automatically disabling all the
fbdev drivers).
Nothing from fb_backlight.o and fbmon.o is used by the DRM fbdev emulation
layer so these two objects can be compiled out when CONFIG_FB is disabled.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Tested-by: Arnd Bergmann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The drivers/video/fbdev/Kconfig defines both symbols for fbdev drivers and
core fbdev symbols, that can be enabled independently of the fbdev drivers.
Split the Kconfig in two, one that only has the symbols for fbdev drivers
and another one that contains the fbdev core symbols.
Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Tested-by: Arnd Bergmann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The drivers in this subsystem are for either character-based or monochrome
LCD controllers. Which can fall into the same category of the DRM/KMS and
fbdev drivers, that are located under the "Graphics support" menu.
Add the auxdisplay drivers there as well to have all display drivers under
the same menu.
Suggested-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Tested-by: Arnd Bergmann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The page height must be taken into account only for vertical coordinates
and heights, not for horizontal coordinates and widths.
Fixes: 179a790aaf2a ("drm/ssd130x: Set the page height value in the device info data")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/54deec2ec533e90544faa8c60a0c2518c58f3e9c.1689252746.git.geert@linux-m68k.org
|
|
The documentation is not clear about how this delay works.
Empirical tests have shown that with a VSDELAY of 0, the first
scanline is not properly formatted in the output stream when
DSI->DP mode is used. The calculation spreadsheets from Toshiba
seem to always make this value equal to the HFP + 10 for DSI->DP
use-case. For DSI->DPI this value should be > 2 and for DPI->DP
it seems to always be 0x64.
Signed-off-by: David Jander <[email protected]>
Signed-off-by: Lucas Stach <[email protected]>
Tested-by: Marek Vasut <[email protected]> # TC9595
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The PLL often fails to lock with this delay. The new value was
determined by trial and error increasing the delay bit by bit
until the error did not occurr anymore even after several tries.
Then double that value was taken as the minimum delay to be safe.
Signed-off-by: David Jander <[email protected]>
Signed-off-by: Lucas Stach <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Tested-by: Marek Vasut <[email protected]> # TC9595
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The Komeda driver always expects the remote connector node to initialize
an encoder. It uses the component aggregator framework which consists
of component->bind() calls used to initialize the remote encoder and attach
it to the crtc. This makes it incompatible with connector drivers which
implement drm_bridge APIs.
Remove all component framework calls from the komeda driver and declare and
attach an encoder inside komeda_crtc_add().
The remote connector driver has to implement the DRM bridge APIs which
can be used to glue the encoder to the remote connector. Since we
usually pair this with a component encoder that also implements a
drm_bridge, dropping support is not expected to affect users of this
driver.
Signed-off-by: Faiz Abbas <[email protected]>
Message-ID: <[email protected]>
[small white space fixes flagged by checkpatch.pl]
Signed-off-by: Liviu Dudau <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
For ADV7533 and ADV7535 low refresh rate is selected using
bits [3:2] of 0x4a main register.
So depending on ADV model write 0xfb or 0x4a register.
Fixes: 2437e7cd88e8 ("drm/bridge: adv7533: Initial support for ADV7533")
Reviewed-by: Robert Foss <[email protected]>
Reviewed-by: Nuno Sa <[email protected]>
Signed-off-by: Bogdan Togorean <[email protected]>
Signed-off-by: Alexandru Ardelean <[email protected]>
Reviewed-by: Frieder Schrempf <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Acked-by: Liviu Dudau <[email protected]>
Reviewed-by: Kieran Bingham <[email protected]>
Acked-by: Robert Foss <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There is apparently no reasons to open-code of_device_uevent() besides:
- The helper receives a struct device while we want to use the of_node
member of the struct device *parent*.
- of_device_uevent() could not be called by modules because of a missing
EXPORT_SYMBOL*().
In practice, the former point is not very constraining, just calling
of_device_uevent(dev->parent, ...) would have made the trick.
The latter point is more an observation rather than a real blocking
point because nothing prevented of_uevent() (called by the inline
function of_device_uevent()) to be exported to modules. In practice,
this helper is now exported, so nothing prevent us from using
of_device_uevent() anymore.
Let's use the core helper directly instead of open-coding it.
Cc: Thierry Reding <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Mikko Perttunen <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Frank Rowand <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The content of of_device_uevent() is currently hardcoded in a driver
that can be compiled as a module. Nothing prevents of_device_uevent() to
be exported to modules, most of the other helpers in of/device.c
actually are. The reason why this helper was not exported is because it
has been so far only useful in drivers/base, which is built-in anyway.
With the idea of getting rid of the hardcoded implementation of
of_device_uevent() in other places in the kernel, let's export it to GPL
modules (very much like its cousins in the same file).
Signed-off-by: Miquel Raynal <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Casting a pointer to an integer of a different size generates a warning
from the compiler. First cast the pointer to a pointer-sized type to
keep the compiler happy.
Fixes: 4f66feeab173 ("drm: debugfs: provide infrastructure to dump a DRM GPU VA space")
Reviewed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Steven Price <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
sizeof() returns a size_t which may be different to an unsigned long.
Use the correct format specifier of '%zu' to prevent compiler warnings.
Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
Reviewed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Steven Price <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This has been superseded by RPM in commit
3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare")
and the last user of the non-RPM case has been dropped in commit
b6d5ffce11dd ("drm/panel-simple: Non-eDP panels don't need "HPD" handling")
whatever is left in this driver is just assigned and never used.
Drop the remaining parts.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Introduce a new DRM_IOCTL_SYNCOBJ_EVENTFD IOCTL which signals an
eventfd from a syncobj.
This is useful for Wayland compositors to handle wait-before-submit.
Wayland clients can send a timeline point to the compositor
before the point has materialized yet, then compositors can wait
for the point to materialize via this new IOCTL.
The existing DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT IOCTL is not suitable
because it blocks. Compositors want to integrate the wait with
their poll(2)-based event loop.
Requirements for new uAPI:
- User-space patch: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4262
- IGT: https://lists.freedesktop.org/archives/igt-dev/2023-July/057893.html
v2:
- Wait for fence when flags is zero
- Improve documentation (Pekka)
- Rename IOCTL (Christian)
- Fix typo in drm_syncobj_add_eventfd() (Christian)
v3:
- Link user-space + IGT patches
- Add reference from overview docs
v4: fix IOCTL number conflict with GETFB2 (Nicholas Choi, Vitaly Prosyak)
Signed-off-by: Simon Ser <[email protected]>
Reviewed-by: Christian König <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Cc: Jason Ekstrand <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Bas Nieuwenhuizen <[email protected]>
Cc: Daniel Stone <[email protected]>
Cc: James Jones <[email protected]>
Cc: Austin Shafer <[email protected]>
Cc: Vitaly Prosyak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This commit adds a function to dump a DRM GPU VA space and a macro for
drivers to register the struct drm_info_list 'gpuvas' entry.
Most likely, most drivers might maintain one DRM GPU VA space per struct
drm_file, but there might also be drivers not having a fixed relation
between DRM GPU VA spaces and a DRM core infrastructure, hence we need the
indirection via the driver iterating it's maintained DRM GPU VA spaces.
Reviewed-by: Boris Brezillon <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager implementation.
New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start implementing, allow userspace applications to request multiple and
arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is
intended to serve the following purposes in this context.
1) Provide infrastructure to track GPU VA allocations and mappings,
using an interval tree (RB-tree).
2) Generically connect GPU VA mappings to their backing buffers, in
particular DRM GEM objects.
3) Provide a common implementation to perform more complex mapping
operations on the GPU VA space. In particular splitting and merging
of GPU VA mappings, e.g. for intersecting mapping requests or partial
unmap requests.
Acked-by: Thomas Hellström <[email protected]>
Acked-by: Matthew Brost <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Tested-by: Matthew Brost <[email protected]>
Tested-by: Donald Robson <[email protected]>
Suggested-by: Dave Airlie <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|