linux/drivers/gpu/drm/vkms/vkms_writeback.c, branch v6.2

drm: vkms: Add support to the RGB565 format

2022-09-05T21:25:08Z

This commit also adds new helper macros to deal with fixed-point arithmetic. It was done to improve the precision of the conversion to ARGB16161616 since the "conversion ratio" is not an integer. V3: Adapt the handlers to the new format introduced in patch 7 V3. V5: Minor improvements V6: Minor improvements (Pekka Paalanen) Reviewed-by: Melissa Wen Signed-off-by: Igor Torrente Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20220905190811.25024-10-igormtorrente@gmail.com

drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats

2022-09-05T21:23:38Z

This will be useful to write tests that depends on these formats. ARGB and XRGB follows the a similar implementation of the former formats. Just adjusting for 16 bits per channel. V3: Adapt the handlers to the new format introduced in patch 7 V3. V5: Minor improvements Added le16_to_cpu/cpu_to_le16 to the 16 bits color read/writes. Reviewed-by: Melissa Wen Signed-off-by: Igor Torrente Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20220905190811.25024-9-igormtorrente@gmail.com

drm: vkms: Supports to the case where primary plane doesn't match the CRTC

2022-09-05T21:18:42Z

We will remove the current assumption that the primary plane has the same size and position as CRTC and that the primary plane is the bottom-most in zpos order, or is even enabled. At least as far as the blending machinery is concerned. For that we will add CRTC dimension information to `vkms_crtc_state` and add a opaque black backgound color. Because now we need to fill the background, we had a loss in performance with this change. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times: | Frametime | |:--------------------------------------------:| | Implementation | Previous | This commit | |:---------------:|:---------:|:--------------:| | frametime range | 5~18 ms | 10~22 ms | | Average | 8.47 ms | 12.32 ms | [1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4 V6: Improve the commit description (Pekka Paalanen). Update some comments (Pekka Paalanen). Remove some fields from `vkms_crtc_state` and move where some variables are set (Pekka Paalanen). Reviewed-by: Melissa Wen Signed-off-by: Igor Torrente Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20220905190811.25024-8-igormtorrente@gmail.com

drm: vkms: Refactor the plane composer to accept new formats

2022-09-05T21:18:35Z

Currently the blend function only accepts XRGB_8888 and ARGB_8888 as a color input. This patch refactors all the functions related to the plane composition to overcome this limitation. The pixels blend is done using the new internal format. And new handlers are being added to convert a specific format to/from this internal format. So the blend operation depends on these handlers to convert to this common format. The blended result, if necessary, is converted to the writeback buffer format. This patch introduces three major differences to the blend function. 1 - All the planes are blended at once. 2 - The blend calculus is done as per line instead of per pixel. 3 - It is responsible to calculates the CRC and writing the writeback buffer(if necessary). These changes allow us to allocate way less memory in the intermediate buffer to compute these operations. Because now we don't need to have the entire intermediate image lines at once, just one line is enough. | Memory consumption (output dimensions) | |:--------------------------------------:| | Current | This patch | |:------------------:|:-----------------:| | Width * Heigth | 2 * Width | Beyond memory, we also have a minor performance benefit from all these changes. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times: | Frametime | |:------------------------------------------:| | Implementation | Current | This commit | |:---------------:|:---------:|:------------:| | frametime range | 9~22 ms | 5~17 ms | | Average | 11.4 ms | 7.8 ms | [1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4 V2: Improves the performance drastically, by performing the operations per-line and not per-pixel(Pekka Paalanen). Minor improvements(Pekka Paalanen). V3: Changes the code to blend the planes all at once. This improves performance, memory consumption, and removes much of the weirdness of the V2(Pekka Paalanen and me). Minor improvements(Pekka Paalanen and me). V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant. V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen). Several security/robustness improvents(Pekka Paalanen). Removes check_planes_x_bounds function and allows partial partly off-screen(Pekka Paalanen). V6: Fix a mismatch of some variable sizes (Pekka Paalanen). Several minor improvements (Pekka Paalanen). Reviewed-by: Melissa Wen Reported-by: kernel test robot Signed-off-by: Igor Torrente Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20220905190811.25024-7-igormtorrente@gmail.com

drm: vkms: Add fb information to `vkms_writeback_job`

2022-09-05T21:12:18Z

This commit is the groundwork to introduce new formats to the planes and writeback buffer. As part of it, a new buffer metadata field is added to `vkms_writeback_job`, this metadata is represented by the `vkms_frame_info` struct. Also adds two new function pointers (`line_to_frame_func` and `frame_to_line_func`) are defined to handle format conversion from/to internal format. A new internal format(`struct pixel_argb_u16`) is introduced to deal with all possible inputs. It consists of 16 bits fields that represent each of the channels. These things will allow us, in the future, to have different compositing and wb format types. V2: Change the code to get the drm_framebuffer reference and not copy its contents (Thomas Zimmermann). V3: Drop the refcount in the wb code (Thomas Zimmermann). V5: Add {wb,plane}_format_transform_func to vkms_writeback_job and vkms_plane_state (Pekka Paalanen) V6: Improvements to some struct/struct members names (Pekka Paalanen). Splits this patch in two (Pekka Paalanen). V7: Replace line_to_frame_func and frame_to_line_func typedefs with the function signature and void* (Melissa Wen). Reviewed-by: Melissa Wen Signed-off-by: Igor Torrente Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20220905190811.25024-6-igormtorrente@gmail.com

drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation

2022-09-05T21:12:16Z

Add a helper function to validate the connector configuration received in the encoder atomic_check by the drivers. So the drivers don't need to do these common validations themselves. V2: Move the format verification to a new helper at the drm_atomic_helper.c (Thomas Zimmermann). V3: Format check improvements (Leandro Ribeiro). Minor improvements(Thomas Zimmermann). V5: Fix some grammar issues in the commit message (André Almeida). Reviewed-by: Melissa Wen Signed-off-by: Igor Torrente Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20220905190811.25024-4-igormtorrente@gmail.com

drm: Drop drm_edid.h from drm_crtc.h

2022-06-20T20:53:55Z

drm_crtc.h has no need for drm_edid.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_edid.h. Quite a few placs do currently depend on drm_edid.h without actually including it directly. All of those need to be fixed up. v2: Fix up i915 and msm some more v3: Fix alphabetical ordering (Sam) Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220614090245.30283-1-ville.syrjala@linux.intel.com Acked-by: Sam Ravnborg Acked-by: Jani Nikula

drm: allow passing possible_crtcs to drm_writeback_connector_init()

2022-05-01T23:12:59Z

Clients of drm_writeback_connector_init() initialize the possible_crtcs and then invoke the call to this API. To simplify things, allow passing possible_crtcs as a parameter to drm_writeback_connector_init() and make changes to the other drm drivers to make them compatible with this change. changes in v2: - split the changes according to their functionality changes in v3: - allow passing possible_crtcs for existing users of drm_writeback_connector_init() - squash the vendor changes into the same commit so that each patch in the series can compile individually changes in v4: - keep only changes related to possible_crtcs - add line breaks after ARRAY_SIZE - stop using temporary variables for possible_crtcs changes in v5: - None changes in v6: - None changes in v7: - wrap long lines to match the coding style of existing drivers - Fix indentation and remove parenthesis where not needed - use u32 instead of uint32_t for possible_crtcs Signed-off-by: Abhinav Kumar Acked-by: Liviu Dudau Reviewed-by: Dmitry Baryshkov Reviewed-by: Laurent Pinchart Patchwork: https://patchwork.freedesktop.org/patch/483501/ Link: https://lore.kernel.org/r/1650984096-9964-2-git-send-email-quic_abhinavk@quicinc.com Signed-off-by: Dmitry Baryshkov

dma-buf-map: Rename to iosys-map

2022-02-08T00:35:35Z

Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's just a shim layer to abstract system memory, that can be accessed via regular load and store, from IO memory that needs to be acessed via arch helpers. The idea is to extend this API so it can fulfill other needs, internal to a single driver. Example: in the i915 driver it's desired to share the implementation for integrated graphics, which uses mostly system memory, with discrete graphics, which may need to access IO memory. The conversion was mostly done with the following semantic patch: @r1@ @@ - struct dma_buf_map + struct iosys_map @r2@ @@ ( - DMA_BUF_MAP_INIT_VADDR + IOSYS_MAP_INIT_VADDR | - dma_buf_map_set_vaddr + iosys_map_set_vaddr | - dma_buf_map_set_vaddr_iomem + iosys_map_set_vaddr_iomem | - dma_buf_map_is_equal + iosys_map_is_equal | - dma_buf_map_is_null + iosys_map_is_null | - dma_buf_map_is_set + iosys_map_is_set | - dma_buf_map_clear + iosys_map_clear | - dma_buf_map_memcpy_to + iosys_map_memcpy_to | - dma_buf_map_incr + iosys_map_incr ) @@ @@ - #include + #include Then some files had their includes adjusted and some comments were update to remove mentions to dma-buf-map. Since this is not specific to dma-buf anymore, move the documentation to the "Bus-Independent Device Accesses" section. v2: - Squash patches v3: - Fix wrong removal of dma-buf.h from MAINTAINERS - Move documentation from dma-buf.rst to device-io.rst v4: - Change documentation title and level Signed-off-by: Lucas De Marchi Acked-by: Christian König Acked-by: Sumit Semwal Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220204170541.829227-1-lucas.demarchi@intel.com

drm/vkms: Use offset-adjusted shadow-plane mappings and output

2021-08-08T18:27:52Z

For framebuffers with non-zero offset fields, shadow-plane helpers provide a pointer to the first byte of the contained data. Use it in vkms. Also provide use the offset-adjusted data address for the writeback job's output buffers. Output framebuffers with non-zero offsets now have their content written to the correct location. Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210803125928.27780-12-tzimmermann@suse.de