- 22 May, 2019 13 commits
-
-
Icenowy Zheng authored
Some SoCs adds a bus clock gate to the Mali Midgard GPU. Add the binding for the bus clock. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Signed-off-by:
Clément Péron <peron.clem@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Christian König authored
That is now done by the DMA-buf helpers instead. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.kernel.org/patch/10943055/
-
Christian König authored
To allow a smooth transition from pinning buffer objects to dynamic invalidation we first start to cache the sg_table for an attachment. v2: keep closer to the DRM implementation Signed-off-by:
-
Sam Ravnborg authored
Drop remaining uses of the deprecated drmP.h in gma500 Replaced drmp.h with forward declarations or include files as relevant. Moved all include files to blocks in following order: \#include <linux/*> \#include <asm/*> \#include <drm/*> \#include "" And within each block sort the include files alphabetically. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190519195526.3422-6-sam@ravnborg.org
-
Sam Ravnborg authored
The DRM_UDELAY wrapper from drm_os_linux.h is used in a few places, all other places calls udelay() with no wrapper. There is no reason to continue to use this wrapper - so drop it and direct call udelay(). Signed-off-by:
-
Sam Ravnborg authored
Add proper forward declarations to minimize dependencies on other header files. Just add enough that we can safely include all header files in alphabetically order in relevant files. Signed-off-by:
-
Sam Ravnborg authored
Drop use of drmp.h from all header files in drm/gma500. Fix fallout in all files. In some cases moved include lines and sorted them too. With drmP.h removed from all header files it can now be removed from each .c file without any further dependencies Signed-off-by:
-
Sam Ravnborg authored
The header file gma_drm.h is empty so remove it and drop all uses of the file. Signed-off-by:
-
Thomas Zimmermann authored
We may not call drm_gem_vram_{pin,unpin}_locked() with an unlocked BO. Now test for this. Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Thomas Zimmermann authored
To align with the rest of DRM terminology, the GEM VRAM helpers now use lock and unlock in places where reserve and unreserve where used before. All callers have been adapted. Signed-off-by:
-
Thomas Zimmermann authored
The push-to-system function forces a buffer out of video RAM. This decision should rather be made by the memory manager. By replacing the function with calls to the kunmap and unpin functions, the buffer's memory becomes available, but the buffer remains in VRAM until it's evicted by a pin operation. This patch replaces the remaining instances of drm_gem_vram_push_to_system() in ast and mgag200, and removes the function from DRM. Signed-off-by:
-
Matthias Kaehlcke authored
The GPU can be used as a thermal cooling device, add an optional '#cooling-cells' property. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190516172510.181473-1-mka@chromium.org
-
Erico Nunes authored
After "5918045c drm/scheduler: rework job destruction", jobs are only deleted when the timeout handler is able to be cancelled successfully. In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT), job cleanup would be skipped which may result in memory leaks. Add the handling for the (timeout == MAX_SCHEDULE_TIMEOUT) case in drm_sched_cleanup_jobs. Signed-off-by:
Erico Nunes <nunes.erico@gmail.com> Signed-off-by:
-
- 21 May, 2019 4 commits
-
-
Maxime Ripard authored
We introduced new functions in the commit bf39607c ("drm/fourcc: Pass the format_info pointer to drm_format_plane_width/height") based on previous ones but with a slightly different prototype. However, the documentation wasn't changed to reflect that change. Fixes: bf39607c ("drm/fourcc: Pass the format_info pointer to drm_format_plane_width/height") Reported-by:
kbuild test robot <lkp@intel.com> Reviewed-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190521110906.15268-1-maxime.ripard@bootlin.com
-
Christian König authored
He unfortunately doesn't work for AMD any more. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/302519/?series=60097&rev=1
-
Erico Nunes authored
After "5918045c drm/scheduler: rework job destruction", lima started to leak memory due to buffers not being destroyed after job execution in the drm scheduler. This started happening because the drm scheduler only destroyed buffers after cancelling the job timeout handler, and for lima this handler was never started as lima specified a MAX_SCHEDULE_TIMEOUT timeout. Lima seems to run well in its current state with a real timeout, so to make it more aligned with the other drivers from now on, let's use a real default timeout. This also fixes the observed memory leaks. The 500ms value was chosen as it is the current value for all other embedded gpu drivers using drm sched. Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190520224229.21111-1-nunes.erico@gmail.com
-
Sam Bobroff authored
When unloading the bochs-drm driver, a warning message is printed by drm_mode_config_cleanup() because a reference is still held to one of the drm_connector structs. Correct this by calling drm_atomic_helper_shutdown() in bochs_pci_remove(). Fixes: 6579c395 ("drm/bochs: atomic: switch planes to atomic, wire up helpers.") Signed-off-by:
Sam Bobroff <sbobroff@linux.ibm.com> Link: http://patchwork.freedesktop.org/patch/msgid/93b363ad62f4938d9ddf3e05b2a61e3f66b2dcd3.1558416473.git.sbobroff@linux.ibm.comSigned-off-by:
-
- 20 May, 2019 9 commits
-
-
kbuild test robot authored
drivers/gpu/drm/bochs/bochs_mm.c:19:1-3: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci Fixes: b3a25b9a ("drm/bochs: Convert bochs driver to VRAM MM") CC: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Maxime Ripard authored
drm_format_info_plane_cpp() basically just returns the cpp array content found in the drm_format_info structure. Since it's pretty trivial, let's remove the function and have the users use the array directly Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Maxime Ripard authored
drm_get_format_info directly calls into drm_format_info, but takes directly a struct drm_mode_fb_cmd2 pointer, instead of the fourcc directly. It's shorter to not dereference it, and we can customise the behaviour at the driver level if we want to, so let's switch to it where it makes sense. Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
-
Maxime Ripard authored
So far, the drm_format_plane_height/width functions were operating on the format's fourcc and was doing a lookup to retrieve the drm_format_info structure and return the cpp. However, this is inefficient since in most cases, we will have the drm_format_info pointer already available so we shouldn't have to perform a new lookup. Some drm_fourcc functions also already operate on the drm_format_info pointer for that reason, so the API is quite inconsistent there. Let's follow the latter pattern and remove the extra lookup while being a bit more consistent. In order to be extra consistent, also rename that function to drm_format_info_plane_cpp and to a static function in the header to match the current policy. The parameters order have also be changed to match the other functions prototype. Reviewed-by:
-
Maxime Ripard authored
So far, the drm_format_plane_cpp function was operating on the format's fourcc and was doing a lookup to retrieve the drm_format_info structure and return the cpp. However, this is inefficient since in most cases, we will have the drm_format_info pointer already available so we shouldn't have to perform a new lookup. Some drm_fourcc functions also already operate on the drm_format_info pointer for that reason, so the API is quite inconsistent there. Let's follow the latter pattern and remove the extra lookup while being a bit more consistent. In order to be extra consistent, also rename that function to drm_format_info_plane_cpp and to a static function in the header to match the current policy. Reviewed-by:
-
Maxime Ripard authored
drm_format_horz_chroma_subsampling and drm_format_vert_chroma_subsampling are basically a lookup in the drm_format_info table plus an access to the hsub and vsub fields of the appropriate entry. Most drivers are using this function while having access to the entry already, which means that we will perform an unnecessary lookup. Removing the call to these functions is therefore more efficient. Some drivers will not have access to that entry in the function, but in this case the overhead is minimal (we just have to call drm_format_info() to perform the lookup) and we can even avoid multiple, inefficient lookups in some places that need multiple fields from the drm_format_info structure. This is amplified by the fact that most of the time the callers will have to retrieve both the vsub and hsub fields, meaning that they would perform twice the lookup. Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Maxime Ripard authored
drm_format_num_planes() is basically a lookup in the drm_format_info table plus an access to the num_planes field of the appropriate entry. Most drivers are using this function while having access to the entry already, which means that we will perform an unnecessary lookup. Removing the call to drm_format_num_planes is therefore more efficient. Some drivers will not have access to that entry in the function, but in this case the overhead is minimal (we just have to call drm_format_info() to perform the lookup) and we can even avoid multiple, inefficient lookups in some places that need multiple fields from the drm_format_info structure. Reviewed-by:
-
Maxime Ripard authored
The Rockchip VOP driver has a function, scl_vop_cal_scl_fac, that will lookup the drm_format_info structure from the fourcc passed to it by its caller. However, its only caller already derefences the drm_format_info structure it has access to to retrieve that fourcc. Change the prototype of that function to pass the drm_format_info structure directly, removing the need for an extra lookup. Reviewed-by:
Sean Paul <sean@poorly.run> Suggested-by:
-
Sabyasachi Gupta authored
Remove duplicate header which is included twice Signed-off-by:
Sabyasachi Gupta <sabyasachi.linux@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/5cdd8109.1c69fb81.6e003.b84b@mx.google.com
-
- 17 May, 2019 4 commits
-
-
Thomas Zimmermann authored
The original bochs and vbox implementations of pin and unpin functions automatically reserved BOs during validation. This functionality got lost while converting the code to a generic implementation. This may result in validating unlocked TTM BOs. Adding the reserve and unreserve operations to GEM VRAM's pin and unpin functions fixes the bochs and vbox drivers. Additionally the patch changes the mgag200, ast and hibmc drivers to not reserve BOs by themselves. Signed-off-by:
-
Thomas Zimmermann authored
The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the GEM VRAM pin/unpin functions that do not reserve the BO during validation. The mgag200 driver requires this behavior for its cursor handling. The patch also converts the driver to use the new interfaces. Signed-off-by: -
Yannick Fertré authored
Add support of regulator for the phy part of the DSI controller. Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Acked-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1557826556-10079-3-git-send-email-yannick.fertre@st.com
-
Yannick Fertré authored
This patch adds documentation of a new property phy-dsi-supply to the STM32 DSI controller. Signed-off-by:
-
- 16 May, 2019 9 commits
-
-
James Clarke authored
Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t types, which differs from the BSDs' headers. Thus we should include stdint.h to ensure we have all the required integer types. Signed-off-by:
James Clarke <jrtc27@jrtc27.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190115150418.68080-1-jrtc27@jrtc27.comReviewed-by:
-
Eric Anholt authored
We were setting the wrong flags to enable PTI errors, so we were seeing reads to invalid PTEs show up as write errors. Also, we weren't turning on the interrupts. The AXI IDs we were dumping included the outstanding write number and so they looked basically random. And the VIO_ADDR decoding was based on the MMU VA_WIDTH for the first platform I worked on and was wrong on others. In short, this was a thorough mess from early HW enabling. Tested on V3D 4.1 and 4.2 with intentional L2T, CLE, PTB, and TLB faults. Signed-off-by:
-
Eric Anholt authored
Looking at a hang recently, I noticed these registers that might tell me if something obvious was wrong. They didn't help in this case, but keep it around for the future. Signed-off-by:
-
Eric Anholt authored
On 7278, we've got 40 bits to work with. Signed-off-by:
-
Eric Anholt authored
They're in the hub, not the individual cores. Signed-off-by:
-
Eric Anholt authored
The point of this review process is that userspace using the new uAPI can actually live with the uAPI being provided, and it's hard to know that without having actually looked into a kernel patch yourself. Signed-off-by:
-
Eric Anholt authored
I was trying to figure out if it was permissible to merge the Mesa side of V3D's CSD support yet while it's in drm-misc-next but not drm-next, and developers on #dri-devel IRC had differing opinions of what the requirement was. v2: Restrict to just drm-next or drm-misc-next on airlied's request. Signed-off-by:
-
Noralf Trønnes authored
drm_fb_helper_hotplug_event() should tolerate the fb_helper argument being NULL. Commit 03a9606e ("drm/fb-helper: Avoid race with DRM userspace") introduced a fb_helper dereference before the NULL check. Fixup by moving the dereference after the NULL check. Fixes: 03a9606e ("drm/fb-helper: Avoid race with DRM userspace") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
-
Jagan Teki authored
Some DSI panels do use GENERIC_SHORT_WRITE_2 transfer protocol to host DSI driver and which is similar to GENERIC_SHORT_WRITE. Add support for the same transfer, so-that so-that the panels which are requesting similar transfer type will process properly. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Tested-by:
Merlijn Wajer <merlijn@wizzup.org> Signed-off-by:
-
- 15 May, 2019 1 commit
-
-
Thomas Zimmermann authored
The data structure |struct drm_vram_mm| and its helpers replace hibmc's TTM-based memory manager. It's the same implementation; except for the type names. v5: * set .llseek via DRM_VRAM_MM_FILE_OPERATIONS v4: * don't select DRM_TTM or DRM_VRAM_MM_HELPER v3: * use drm_gem_vram_mm_funcs * convert driver to drm_device-based instance v2: * implement hibmc_mmap() with drm_vram_mm_mmap() Signed-off-by:
-
