- 22 Feb, 2022 1 commit
-
-
Arunpravin authored
- Make drm_buddy_alloc a single function to handle range allocation and non-range allocation demands - Implemented a new function alloc_range() which allocates the requested power-of-two block comply with range limitations - Moved order computation and memory alignment logic from i915 driver to drm buddy v2: merged below changes to keep the build unbroken - drm_buddy_alloc_range() becomes obsolete and may be removed - enable ttm range allocation (fpfn / lpfn) support in i915 driver - apply enhanced drm_buddy_alloc() function to i915 driver v3(Matthew Auld): - Fix alignment issues and remove unnecessary list_empty check - add more validation checks for input arguments - make alloc_range() block allocations as bottom-up - optimize order computation logic - replace uint64_t with u64, which is preferred in the kernel v4(Matthew Auld): - keep drm_buddy_alloc_range() function implementation for generic actual range allocations - keep alloc_range() implementation for end bias allocations v5(Matthew Auld): - modify drm_buddy_alloc() passing argument place->lpfn to lpfn as place->lpfn will currently always be zero for i915 v6(Matthew Auld): - fixup potential uaf - If we are unlucky and can't allocate enough memory when splitting blocks, where we temporarily end up with the given block and its buddy on the respective free list, then we need to ensure we delete both blocks, and no just the buddy, before potentially freeing them - fix warnings reported by kernel test robot <lkp@intel.com> v7(Matthew Auld): - revert fixup potential uaf - keep __alloc_range() add node to the list logic same as drm_buddy_alloc_blocks() by having a temporary list variable - at drm_buddy_alloc_blocks() keep i915 range_overflows macro and add a new check for end variable v8: - fix warnings reported by kernel test robot <lkp@intel.com> v9(Matthew Auld): - remove DRM_BUDDY_RANGE_ALLOCATION flag - remove unnecessary function description v10: - keep DRM_BUDDY_RANGE_ALLOCATION flag as removing the flag and replacing with (end < size) logic fails amdgpu driver load Signed-off-by:Arunpravin <Arunpravin.PaneerSelvam@amd.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220221164552.2434-1-Arunpravin.PaneerSelvam@amd.com
-
- 21 Feb, 2022 1 commit
-
-
Ville Syrjälä authored
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Emma Anholt <emma@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-18-ville.syrjala@linux.intel.com
-
- 20 Feb, 2022 3 commits
-
-
Linus Walleij authored
Add some code and config to also support the ACX424AKM used in some Sony (Ericsson) Mobile phones. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220103113822.654592-3-linus.walleij@linaro.org
-
Linus Walleij authored
These IDs were found in the wild in a Sony Xperia vendor tree. Signed-off-by:
-
Linus Walleij authored
A code drop from Sony Mobile reveals that the ACX424 panels are built around the Novatek NT35560 panel controllers so just bite the bullet and rename the driver and all basic symbols so that we can modify this driver to cover any other panels also using the Novatek NT35560 display controller. Signed-off-by:
-
- 16 Feb, 2022 12 commits
-
-
Sankeerth Billakanti authored
Add support for the 14" sharp,lq140m1jw46 eDP panel. Signed-off-by:
Sankeerth Billakanti <quic_sbillaka@quicinc.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Sankeerth Billakanti authored
Add support for sharp LQ140M1JW46 display panel. It is a 14" eDP panel with 1920x1080 display resolution. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Thomas Zimmermann authored
Fbdev's deferred I/O sorts all dirty pages by default, which incurs a significant overhead. Make the sorting step optional and update the few drivers that require it. Use a FIFO list by default. Most fbdev drivers with deferred I/O build a bounding rectangle around the dirty pages or simply flush the whole screen. The only two affected DRM drivers, generic fbdev and vmwgfx, both use a bounding rectangle. In those cases, the exact order of the pages doesn't matter. The other drivers look at the page index or handle pages one-by-one. The patch sets the sort_pagelist flag for those, even though some of them would probably work correctly without sorting. Driver maintainers should update their driver accordingly. Sorting pages by memory offset for deferred I/O performs an implicit bubble-sort step on the list of dirty pages. The algorithm goes through the list of dirty pages and inserts each new page according to its index field. Even worse, list traversal always starts at the first entry. As video memory is most likely updated scanline by scanline, the algorithm traverses through the complete list for each updated page. For example, with 1024x768x32bpp each page covers exactly one scanline. Writing a single screen update from top to bottom requires updating 768 pages. With an average list length of 384 entries, a screen update creates (768 * 384 =) 294912 compare operation. Fix this by making the sorting step opt-in and update the few drivers that require it. All other drivers work with unsorted page lists. Pages are appended to the list. Therefore, in the common case of writing the framebuffer top to bottom, pages are still sorted by offset, which may have a positive effect on performance. Playing a video [1] in mplayer's benchmark mode shows the difference (i7-4790, FullHD, simpledrm, kernel with debugging). mplayer -benchmark -nosound -vo fbdev ./big_buck_bunny_720p_stereo.ogg With sorted page lists: BENCHMARKs: VC: 32.960s VO: 73.068s A: 0.000s Sys: 2.413s = 108.441s BENCHMARK%: VC: 30.3947% VO: 67.3802% A: 0.0000% Sys: 2.2251% = 100.0000% With unsorted page lists: BENCHMARKs: VC: 31.005s VO: 42.889s A: 0.000s Sys: 2.256s = 76.150s BENCHMARK%: VC: 40.7156% VO: 56.3219% A: 0.0000% Sys: 2.9625% = 100.0000% VC shows the overhead of video decoding, VO shows the overhead of the video output. Using unsorted page lists reduces the benchmark's run time by ~32s/~25%. v2: * Make sorted pagelists the special case (Sam) * Comment on drivers' use of pagelist (Sam) * Warn about the overhead in comment Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_stereo.ogg # [1] Link: https://patchwork.freedesktop.org/patch/msgid/20220211094640.21632-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
Return early if a page is already in the list of dirty pages for deferred I/O. This can be detected if the page's list head is not empty. Keep the list head initialized while the page is not enlisted to make this work reliably. v2: * update comment and fix spelling (Sam) Signed-off-by:
-
Javier Martinez Canillas authored
The ssd130x DRM driver also makes use of this Device Tree binding to allow existing users of the fbdev driver to migrate without the need to change their Device Trees. Add myself as another maintainer of the binding, to make sure that I will be on Cc when patches are proposed for it. Suggested-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
-
Javier Martinez Canillas authored
To make sure that tools like the get_maintainer.pl script will suggest to Cc me if patches are posted for this driver. Also include the Device Tree binding for the old ssd1307fb fbdev driver since the new DRM driver was made compatible with the existing binding. Signed-off-by:
-
Javier Martinez Canillas authored
The ssd130x driver only provides the core support for these devices but it does not have any bus transport logic. Add a driver to interface over I2C. Signed-off-by:
-
Javier Martinez Canillas authored
This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED display controllers. It's only the core part of the driver and a bus specific driver is needed for each transport interface supported by the display controllers. Signed-off-by:
-
Javier Martinez Canillas authored
Add support to convert from XR24 to reversed monochrome for drivers that control monochromatic display panels, that only have 1 bit per pixel. The function does a line-by-line conversion doing an intermediate step first from XR24 to 8-bit grayscale and then to reversed monochrome. The drm_fb_gray8_to_mono_reversed_line() helper was based on code from drivers/gpu/drm/tiny/repaper.c driver. Signed-off-by:
-
Javier Martinez Canillas authored
Pull the per-line conversion logic into a separate helper function. This will allow to do line-by-line conversion in other helpers that convert to a gray8 format. Suggested-by:
-
Ville Syrjälä authored
There is no object id in drm_display_mode anymore. Remove stale comments to the contrary. Signed-off-by:
-
Minghao Chi (CGEL ZTE) authored
Use of_device_get_match_data() to simplify the code. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn> Signed-off-by:
-
- 15 Feb, 2022 4 commits
-
-
Douglas Anderson authored
Recently we added generic "edp-panel"s probed by EDID. To support panels in this way we look at the panel ID in the EDID and look up the panel in a table that has power sequence timings. If we find a panel that's not in the table we will still attempt to use it but we'll use conservative timings. While it's likely that these conservative timings will work for most nearly all panels, the performance of turning the panel off and on suffers. We'd like to be able to reliably detect the case that we're using the hardcoded timings without relying on parsing dmesg. This allows us to implement tests that ensure that no devices get shipped that are relying on the conservative timings. Let's add a new debugfs entry to panel devices. It will have one of: * UNKNOWN - We tried to detect a panel but it wasn't in our table. * HARDCODED - We're not using generic "edp-panel" probed by EDID. * A panel name - This is the name of the panel from our table. Signed-off-by:
-
Douglas Anderson authored
We'd like panels to be able to add things to debugfs underneath the connector's directory. Let's plumb it through. A panel will be able to put things in a "panel" directory under the connector's directory. Note that debugfs is not ABI and so it's always possible that the location that the panel gets for its debugfs could change in the future. NOTE: this currently only works if you're using a modern architecture. Specifically the plumbing relies on _both_ drm_bridge_connector and drm_panel_bridge. If you're not using one or both of these things then things won't be plumbed through. As a side effect of this change, drm_bridges can also get callbacks to put stuff underneath the connector's debugfs directory. At the moment all bridges in the chain have their debugfs_init() called with the connector's root directory. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204161245.v2.2.Ib0bd5346135cbb0b63006b69b61d4c8af6484740@changeid
-
Douglas Anderson authored
The ti-sn65dsi86 driver shouldn't hand-roll its own bridge connector. It should use the normal drm_bridge_connector. Let's switch to do that, removing all of the custom code. NOTE: this still _doesn't_ implement DRM_BRIDGE_ATTACH_NO_CONNECTOR support for ti-sn65dsi86 and that would still be a useful thing to do in the future. It was attempted in the past [1] but put on the back burner. However, unless we instantly change ti-sn65dsi86 fully from not supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR at all to _only_ supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR then we'll still need a bit of time when we support both. This is a better way to support the old way where the driver hand rolls things itself. A new notes about the implementation here: * When using the drm_bridge_connector the connector should be created after all the bridges, so we change the ordering a bit. * I'm reasonably certain that we don't need to do anything to "free" the new drm_bridge_connector. If drm_bridge_connector_init() returns success then we know drm_connector_init() was called with the `drm_bridge_connector_funcs`. The `drm_bridge_connector_funcs` has a .destroy() that does all the cleanup. drm_connector_init() calls __drm_mode_object_add() with a drm_connector_free() that will call the .destroy(). * I'm also reasonably certain that I don't need to "undo" the drm_bridge_attach() if drm_bridge_connector_init() fails. The "detach" function is private and other similar code doesn't try to undo the drm_bridge_attach() in error cases. There's also a comment indicating the lack of balance at the top of drm_bridge_attach(). [1] https://lore.kernel.org/r/20210920225801.227211-4-robdclark@gmail.comSigned-off-by:
-
Christian König authored
Use the one provided by TTM instead. v2: drop new_mem parameter as well Signed-off-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by:
-
- 14 Feb, 2022 16 commits
-
-
Pin-Yen Lin authored
The length of EDID block can be longer than 256 bytes, so we should use `int` instead of `u8` for the `edid_pos` variable. Fixes: 8bdfc5da ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP") Signed-off-by:
Pin-Yen Lin <treapking@chromium.org> Reviewed-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220210103827.402436-1-treapking@chromium.org
-
Christian König authored
This is provided by TTM now. Also switch man->size to bytes instead of pages and fix the double printing of size and usage in debugfs. v2: fix size checking as well Signed-off-by:
-
Christian König authored
This is provided by TTM now. Signed-off-by:
-
Christian König authored
This is provided by TTM now. Also switch man->size to bytes instead of pages and fix the double printing of size and usage in debugfs. v2: fix size checking as well Signed-off-by:
-
Kevin Tang authored
platform_get_resource() may fail and return NULL, so check it's value before using it. Reported-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
Kevin Tang <kevin3.tang@gmail.com> Reviewed-by:
-
Kevin Tang authored
'drm' could be null in sprd_drm_shutdown, and drm_warn maybe dereference it, remove this warning log. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Kevin Tang authored
On commit 43531edd ("drm/sprd: add Unisoc's drm kms master"), adds the config DRM_SPRD, which selects DRM_KMS_CMA_HELPER. However, commit 09717af7 ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") just removed the DRM_KMS_CMA_HELPER. So the select DRM_KMS_CMA_HELPER refers to a non-existing kconfig symbol. Reported-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Christian König authored
It makes sense to have this in the common manager for debugging and accounting of how much resources are used. v2: cleanup kerneldoc a bit v3: drop the atomic, update counter under lock instead Signed-off-by:
-
Christian König authored
Leave the man->size units as driver defined. Signed-off-by:
-
Hsin-Yi Wang authored
List panel under aux-bus node if it's connected to anx7625's aux bus. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
-
Hsin-Yi Wang authored
Support reading edid through aux channel if panel is connected to aux bus. Extend anx7625_aux_dpcd_trans() to implement aux transfer function: 1. panel is populated in devm_of_dp_aux_populate_ep_devices(), so move anx7625_parse_dt() after. 2. Use pm runtime autosuspend since aux transfer function is called multiple times when reading edid. 3. No-op if aux transfer length is 0. Signed-off-by:
Xin Ji <xji@analogixsemi.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Hsin-Yi Wang authored
Use devm_kzalloc instead of kzalloc and drop kfree(). Let the memory handled by driver detach. Signed-off-by:
-
Xin Ji authored
Send DPCD command to downstream before anx7625 power down, let downstream monitor enter into standby mode. Signed-off-by:
-
Paul Boddie authored
We have to make sure that - JZ_LCD_OSDC_ALPHAEN is set - plane f0 is disabled as it's not working yet Tested on MIPS Creator CI20 board. Signed-off-by:
Paul Boddie <paul@boddie.org.uk> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Fixes: ef2f5d0a ("drm/ingenic: prepare ingenic drm for later addition of JZ4780") Signed-off-by:
Paul Cercueil <paul@crapouillou.net> [pcercuei: add proper fixes commit, slightly reword commit description] Link: https://patchwork.freedesktop.org/patch/msgid/9d3a2000d2bb014f1afb0613537bdc523202135d.1644681054.git.hns@goldelico.com
-
Thomas Zimmermann authored
Set the VM_DONTDUMP flag on mmap'ed VMAs to omit them from core dumps. It's display-buffer memory; who knows what secrets these buffers contain. Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209155634.3994-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
Initialize default vm_ops in static initialization of the GEM SHMEM funcs, instead of the mmap code. It's simply better style. GEM helpers will later set a VMA's vm_ops from the default automatically. v2: * also update the drivers that build upon GEM SHMEM Signed-off-by:
Steven Price <steven.price@arm.com> Reviewed-by:
-
- 12 Feb, 2022 2 commits
-
-
Sam Ravnborg authored
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC. Based on .txt binding from Zubair Lutfullah Kakakhel Signed-off-by:
-
Erico Nunes authored
Currently when users try to run an application with lima and that hits an issue such as a timeout, a message saying "fail to save task state" and "error task list is full" is shown in dmesg. The error task dump is a debug feature disabled by default, so the error task list is usually not going to be available at all. The message can be misleading and creates confusion in bug reports. We can avoid that code path and that particular message when the user has not explicitly set the max_error_tasks parameter to enable the feature. Signed-off-by:
Erico Nunes <nunes.erico@gmail.com> Reviewed-by:
Qiang Yu <yuq825@gmail.com> Reviewed-by:
-
- 11 Feb, 2022 1 commit
-
-
Andrey Grodzovsky authored
Update function name. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reported-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220211205500.601391-1-andrey.grodzovsky@amd.com
-
