Skip to content

L
linux
Switch branch/tag
  1. 07 Oct, 2021 10 commits
    • Cai Huoqing's avatar
      drm/shmobile: Make use of the helper function devm_platform_ioremap_resource() · e29505ca
      Cai Huoqing authored 
      Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: default avatarCai Huoqing <caihuoqing@baidu.com>
Reviewed-by: default avatarKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      e29505ca
    • Laurent Pinchart's avatar
      drm/sti: Use correct printk format specifiers for size_t · 668b5136
      Laurent Pinchart authored 
      The correct format specifier for size_t is %zu. Using %d (or %u)
generates a warning on 64-bit platforms. Fix it.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: default avatarPhilippe Cornu <philippe.cornu@foss.st.com>
      668b5136
    • Laurent Pinchart's avatar
      drm/omap: Depend on CONFIG_OF · 8b8a7d80
      Laurent Pinchart authored 
      The driver accesses the drm_bridge.of_node field, which is present only
if CONFIG_OF is enabled. As all platforms using omapdrm are OF-based, we
can simply depend on CONFIG_OF.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8b8a7d80
    • Laurent Pinchart's avatar
      drm/omap: Cast pointer to integer without generating warning · 95f22783
      Laurent Pinchart authored 
      On 64-bit platforms, the compiler complains that casting a void pointer
to an unsigned int loses data. Cast the pointer to a uintptr_t to fix
this.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: default avatarTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
      95f22783
    • Laurent Pinchart's avatar
      drm/omap: Use correct printk format specifiers for size_t · d6a4bf45
      Laurent Pinchart authored 
      The correct format specifier for size_t is %zu. Using %d (or %u)
generates a warning on 64-bit platforms. Fix it.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: default avatarTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
      d6a4bf45
    • Laurent Pinchart's avatar
      drm: property: Replace strncpy() with strscpy_pad() · 753f2674
      Laurent Pinchart authored 
      strncpy() is widely regarded as unsafe due to the fact that it may leave
the destination string without a nul-termination when the source string
size is too large. When compiling the kernel with W=1, the gcc warns
about this:

drivers/gpu/drm/drm_property.c: In function ‘drm_property_create’:
drivers/gpu/drm/drm_property.c:130:2: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation]
  130 |  strncpy(property->name, name, DRM_PROP_NAME_LEN);
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are three occurrences of strncpy() in drm_property.c. None of them
are actually unsafe, as the very next line forces nul-termination of the
destination buffer. The warning is thus a false positive, but adds noise
to the kernel log. It can easily be silenced by using strscpy_pad()
instead. Do so.

One of the three occurrences, in drm_property_add_enum(), fills a char
array that is later copied to userspace with copy_to_user() in
drm_mode_getproperty_ioctl(). To avoid leaking kernel data,
strscpy_pad() is required. Similarly, a second occurrence, in
drm_mode_getproperty_ioctl(), copies the string to an ioctl data buffer
that isn't previously zero'ed, to strscpy_pad() is also required. The
last occurrence, in drm_property_create(), would be safe to replace with
strscpy(), as the destination buffer is copied to userspace with
strscpy_pad(). However, given that this isn't in a hot path, let's avoid
future data leaks in case someone copies the whole char array blindly.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      753f2674
    • Laurent Pinchart's avatar
      drm: rcar-du: Allow importing non-contiguous dma-buf with VSP · 07709278
      Laurent Pinchart authored 
      On R-Car Gen3, the DU uses a separate IP core named VSP to perform DMA
from memory and composition of planes. The DU hardware then only handles
the video timings and the interface with the encoders. This differs from
Gen2, where the DU included a composer with DMA engines.

When sourcing from the VSP, the DU hardware performs no memory access,
and thus has no requirements on imported dma-buf memory types. The GEM
CMA helpers however still create a DMA mapping to the DU device, which
isn't used. The mapping to the VSP is done when processing the atomic
commits, in the plane .prepare_fb() handler.

When the system uses an IOMMU, the VSP device is attached to it, which
enables the VSP to use non physically contiguous memory. The DU, as it
performs no memory access, isn't connected to the IOMMU. The GEM CMA
drm_gem_cma_prime_import_sg_table() helper will in that case fail to map
non-contiguous imported dma-bufs, as the DMA mapping to the DU device
will have multiple entries in its sgtable. The prevents using non
physically contiguous memory for display.

The DRM PRIME and GEM CMA helpers are designed to create the sgtable
when the dma-buf is imported. By default, the device referenced by the
drm_device is used to create the dma-buf attachment. Drivers can use a
different device by using the drm_gem_prime_import_dev() function. While
the DU has access to the VSP device, this won't help here, as different
CRTCs use different VSP instances, connected to different IOMMU
channels. The driver doesn't know at import time which CRTC a GEM object
will be used, and thus can't select the right VSP device to pass to
drm_gem_prime_import_dev().

To support non-contiguous memory, implement a custom
.gem_prime_import_sg_table() operation that accepts all imported dma-buf
regardless of the number of scatterlist entries. The sgtable will be
mapped to the VSP at .prepare_fb() time, which will reject the
framebuffer if the VSP isn't connected to an IOMMU.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: default avatarKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      07709278
    • Laurent Pinchart's avatar
      drm: rcar-du: Set the DMA coherent mask for the DU device · 780d4223
      Laurent Pinchart authored 
      The DU DMA address space is limited to 32 bits, so the DMA coherent mask
should be set accordingly. The DMA mapping implementation will
transparently map high memory buffers to 32-bit addresses through an
IOMMU when present (or through bounce buffers otherwise, which isn't a
supported use case as performances would be terrible).

However, when sourcing frames from a VSP, the situation is more
complicated. The DU delegates all memory accesses to the VSP and doesn't
perform any DMA access by itself. Due to how the GEM CMA helpers are
structured buffers are still mapped to the DU device. They are later
mapped to the VSP as well to perform DMA access, through the IOMMU
connected to the VSP.

Setting the DMA coherent mask to 32 bits for the DU when using a VSP can
cause issues when importing a dma_buf. If the buffer is located above
the 32-bit address space, the DMA mapping implementation will try to map
it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer
will be allocated, which in the best case will waste memory and in the
worst case will just fail.

To work around this issue, set the DMA coherent mask to the full 40-bit
address space for the DU. All dma-buf instances will be imported without
any restriction, and will be mapped to the VSP when preparing the
associated framebuffer.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      780d4223
    • Laurent Pinchart's avatar
      drm: rcar-du: Improve kernel log messages when initializing encoders · 206c5471
      Laurent Pinchart authored 
      Improve the debugging and error messages printing when initializing
encoders by replacing the output number by the output name, printing the
bridge OF node name, and the error code of failed operations.

While at it, move the related rcar_du_output enumeration from
rcar_du_crtc.h to rcar_du_drv.h as it's not specific to the CRTC.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      206c5471
    • Laurent Pinchart's avatar
      drm: rcar-du: Don't create encoder for unconnected LVDS outputs · 187502af
      Laurent Pinchart authored 
      On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
even when LVDS outputs are not used. For this reason, the rcar-lvds
driver probes successfully on those platforms even if no further bridge
or panel is connected to the LVDS output, in order to provide the
rcar_lvds_clk_enable() and rcar_lvds_clk_disable() functions to the DU
driver.

If an LVDS output isn't connected, trying to create a DRM connector for
the output will fail. Fix this by skipping connector creation in that
case, and also skip creation of the DRM encoder as there's no point in
an encoder without a connector.

Fixes: e9e05694 ("drm: rcar-du: lvds: Convert to DRM panel bridge helper")
Reported-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      187502af
  3. 28 Sep, 2021 1 commit
  5. 24 Sep, 2021 1 commit
  7. 23 Sep, 2021 28 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7