- 24 Jul, 2023 29 commits
-
-
Thomas Zimmermann authored
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 <thierry.reding@gmail.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Mikko Perttunen <mperttunen@nvidia.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230707083422.18691-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
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:
Maxime Ripard <mripard@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Mikko Perttunen <mperttunen@nvidia.com> Acked-by:
-
Thomas Zimmermann authored
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 authored
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 authored
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:
-
Luca Ceresoli authored
These variables are never referenced in the code. Signed-off-by:
Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230719105829.148011-1-luca.ceresoli@bootlin.com
-
Thomas Zimmermann authored
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 <ojeda@kernel.org> Signed-off-by:
Sui Jingfeng <suijingfeng@loongson.cn> Cc: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-19-tzimmermann@suse.de
-
Thomas Zimmermann authored
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No functional changes. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-18-tzimmermann@suse.de
-
Thomas Zimmermann authored
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 authored
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 authored
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 authored
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 authored
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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-13-tzimmermann@suse.de
-
Thomas Zimmermann authored
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 authored
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:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Bruno Prémont <bonbons@linux-vserver.org> Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-11-tzimmermann@suse.de
-
Thomas Zimmermann authored
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 authored
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:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
Backmerging to get v6.5-rc2. Signed-off-by: -
Dan Carpenter authored
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 <dan.carpenter@linaro.org> Signed-off-by:
-
Pin-yen Lin authored
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 <treapking@chromium.org> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230718110407.1005200-1-wenst@chromium.org
-
Pin-yen Lin authored
Replace the spaces with tab characters in the Kconfig file. Signed-off-by:
-
Chen-Yu Tsai authored
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/20230112042104.4107253-1-treapking@chromium.org/ Fixes: 60487584 ("drm/bridge: anx7625: refactor power control to use runtime PM framework") Signed-off-by:
-
- 22 Jul, 2023 4 commits
-
-
Javier Martinez Canillas authored
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:
Arnd Bergmann <arnd@arndb.de> Tested-by:
Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230719081544.741051-5-javierm@redhat.com
-
Javier Martinez Canillas authored
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 authored
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:
-
Javier Martinez Canillas authored
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:
-
- 21 Jul, 2023 7 commits
-
-
Geert Uytterhoeven authored
The page height must be taken into account only for vertical coordinates and heights, not for horizontal coordinates and widths. Fixes: 179a790a ("drm/ssd130x: Set the page height value in the device info data") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
-
David Jander authored
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 <david@protonic.nl> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Tested-by: Marek Vasut <marex@denx.de> # TC9595 Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
David Jander authored
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:
-
Faiz Abbas authored
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 <faiz.abbas@arm.com> Message-ID: <20230712064937.25192-1-faiz.abbas@arm.com> [small white space fixes flagged by checkpatch.pl] Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230712064937.25192-1-faiz.abbas@arm.com
-
Bogdan Togorean authored
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: 2437e7cd ("drm/bridge: adv7533: Initial support for ADV7533") Reviewed-by:
Nuno Sa <nuno.sa@analog.com> Signed-off-by:
Bogdan Togorean <bogdan.togorean@analog.com> Signed-off-by:
Alexandru Ardelean <alex@shruggie.ro> Reviewed-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by:
-
Rob Herring authored
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 <robh@kernel.org> Acked-by:
Steven Price <steven.price@arm.com> Acked-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by:
-
Rob Herring authored
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:
-
