- 11 Jun, 2020 10 commits
-
-
Thomas Zimmermann authored
Moving the initializer and cleanup functions for device instances to mgag200_drv.c prepares for the conversion to managed code. No functional changes are made. Remove mgag200_main.c, which is now empty. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200605135803.19811-11-tzimmermann@suse.de
-
Thomas Zimmermann authored
The naming of symbols in mgag200_drv.c is inconsistent. Fix that by prefixing all names with mgag200_. v2: * clarify commit message Signed-off-by:
-
Thomas Zimmermann authored
Moving the DRM driver structures from the middle of the PCI code to the top of the file makes it more readable. Also remove an obsolete comment. Signed-off-by:
-
Thomas Zimmermann authored
The memory-management code now cleans up automatically as part of device destruction. Signed-off-by:
-
Thomas Zimmermann authored
The VRAM setup in mgag200_drv.c is part of memory management and should be done in the same place. Merge the code into the memory management's init function. Signed-off-by:
-
Thomas Zimmermann authored
The MM setup code on mgag200 reads PCI BAR 0's start and length several times. Reusing these values makes the code more readable. Signed-off-by:
-
Thomas Zimmermann authored
The mgag200 driver does not use TTM any longer. Rename the related file to mgag200_mm.c (as in 'memory management'). Signed-off-by:
-
Thomas Zimmermann authored
Using the managed function simplifies the error handling. After unloading the driver, the PCI device should now get disabled as well. Signed-off-by:
-
Thomas Zimmermann authored
Support for HW cursors got remove by commit 5a77e2bf ("drm/mgag200: Remove HW cursor") Apparently the source file was not deleted. Removed it now. Signed-off-by:
-
Thomas Zimmermann authored
Commit 94668ac7 ("drm/mgag200: Convert mgag200 driver to VRAM MM") removed the implementation of mgag200_mmap(). Also remove the declaration. Signed-off-by:
-
- 10 Jun, 2020 30 commits
-
-
Kieran Bingham authored
The word 'descriptor' is misspelled throughout the tree. Fix it up accordingly: decriptors -> descriptors Signed-off-by:Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200609124610.3445662-9-kieran.bingham+renesas@ideasonboard.com
-
Maxime Ripard authored
The HACT_ACT field only needs to be written to when using a DSI display. Let's move that setup to our DSI branch to clear a bit the common path. Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/7a93436f97666a2aa025686ef3ff3606de4bec67.1590594512.git-series.maxime@cerno.tech
-
Maxime Ripard authored
The hvs_latency_pix variable doesn't need to be a variable and can just be defined. Reviewed-by:
-
Maxime Ripard authored
We'll need to access the crtc_state from outside of vc4_crtc.c, so let's move it to vc4_drv.h Reviewed-by:
-
Maxime Ripard authored
of_device_get_match_data allow to simplify a bit the retrieval of the data associated to the pixelvalve compatible. Let's use it. Reviewed-by:
-
Maxime Ripard authored
Since we're going to introduce pixelvalve data structures for other SoCs than the BCM2835, let's rename the structures defined in the code to make it obvious which SoC we're targeting. Reviewed-by:
-
Maxime Ripard authored
So far the plane creation was done when each CRTC was bound, and those planes were only tied to the CRTC that was registering them. This causes two main issues: - The planes in the vc4 hardware are actually not tied to any CRTC, but can be used with every combination - More importantly, so far, we allocate 10 planes per CRTC, with 3 CRTCs. However, the next generation of hardware will have 5 CRTCs, putting us well above the maximum of 32 planes currently allowed by DRM. This patch is the first one in a series of patches that will take down both of these issues so that we can support the next generation of hardware while keeping a good amount of planes. We start by changing the way the planes are registered to first registering the primary planes for each CRTC in the CRTC bind function as we used to, but moving the overlay and cursor creation to the main driver bind function, after all the CRTCs have been bound, and make the planes associated to all CRTCs. This will slightly change the ID order of the planes, since the primary planes of all CRTCs will be first, and then a pattern of 8 overlays, 1 cursor plane for each CRTC. This shouldn't cause any trouble since the ordering between the planes is preserved though. Reviewed-by: -
Maxime Ripard authored
The planes so far were created as part of the CRTC binding code with each planes created associated only to one CRTC. However, the hardware in the vc4 doesn't really have such constraint and can be used with any CRTC. In order to rework this, let's first move the overlay and cursor planes creation to a function of its own. Reviewed-by:
-
Maxime Ripard authored
vc4_drv.h doesn't have any include guards which prevents it from being included twice. Let's add them. Reviewed-by:
-
Maxime Ripard authored
While the device tree and the driver expected a clock-names property, it wasn't explicitly documented in the previous binding. The documented order was wrong too, so make sure clock-names is there and in the proper order. Cc: devicetree@vger.kernel.org Reviewed-by:
Rob Herring <robh+dt@kernel.org> Signed-off-by:
-
Maxime Ripard authored
While the device tree and the driver expected a clock-names and a clock-cells properties, it wasn't explicitly documented in the previous binding. Make sure it is now. Cc: devicetree@vger.kernel.org Reviewed-by:
-
Maxime Ripard authored
While the device tree and the driver expected a clock-names property, it wasn't explicitly documented in the previous binding. Make sure it is now. Cc: devicetree@vger.kernel.org Reviewed-by:
-
Maxime Ripard authored
The BCM283x SoCs have a display pipeline composed of several controllers with device tree bindings that are supported by Linux. Now that we have the DT validation in place, let's split into separate files and convert the device tree bindings for those controllers to schemas. This is just a 1:1 conversion though, and some bindings were incomplete so it results in example validation warnings that are going to be addressed in the following patches. Acked-by:
-
Thomas Zimmermann authored
The udl driver contains an implementation of GEM vmap and mmap operations that is identical to the common SHMEM helper; except that udl's code uses cached pages by default. Convert udl to regular SHMEM helper functions. There's no reason to have udl behave differently from all other SHMEM drivers. The udl driver uses the SHMEM helper to enable caching. v3: * rebased onto Daniel's shmem untangle series v2: * implement .gem_create_object with SHMEM helper Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200609090820.20256-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
The helper drm_gem_shmem_create_object_cached() allocates an GEM SHMEM object and sets the map_cached flag. Useful for drivers that want cached mappings. v3: * style fixes Signed-off-by:
-
Thomas Zimmermann authored
The .gem_print_info callback in struct drm_driver is obsolete and has no users left. Remove it. Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-44-tzimmermann@suse.de
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE sets the functions in struct drm_driver to their defaults. No functional changes are made. v2: * update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE Signed-off-by:
Philippe Cornu <philippe.cornu@st.com> Reviewed-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE sets the functions in struct drm_driver to their defaults. No functional changes are made. v2: * update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
