search for: sz_8

...m_size gsize; - - args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8); - - args->size = PAGE_ALIGN(args->pitch * args->height); + union omap_gem_size gsize = { }; + int ret; - gsize = (union omap_gem_size){ - .bytes = args->size, - }; + ret = drm_mode_size_dumb(dev, args, SZ_8, 0); + if (ret) + return ret; + gsize.bytes = args->size; return omap_gem_new_handle(dev, file, gsize, OMAP_BO_SCANOUT | OMAP_BO_WC, &args->handle); -- 2.47.1

...ode enum. Ah, right... That's horrible =). And I assume it's not really possible to define the bpp to mean bits per pixel, except for a few special cases like 15? Why do we even really care about color depth here? We're just allocating memory. Doesn't DIV_ROUND_UP(args->bpp, SZ_8) work fine for XRGB1555 too? >> So, I'm all for a new ioctl, but I don't right away see why the >> current ioctl couldn't be used. Which makes me wonder about the >> drm_warn() in your patch, and the "userspace throws in arbitrary >> values for bpp and r...

...'s horrible =). > > And I assume it's not really possible to define the bpp to mean bits > per pixel, except for a few special cases like 15? > > Why do we even really care about color depth here? We're just > allocating memory. Doesn't DIV_ROUND_UP(args->bpp, SZ_8) work fine for > XRGB1555 too? Drivers always did that, but it does not work correctly for (bpp < 8). As we already have helpers to deal with bpp, it makes sense to use them.? This also aligns dumb buffers with the kernel's video= parameter, which as the same odd semantics. The fallb...

Dumb-buffer pitch and size is specified by width, height, bits-per-pixel plus various hardware-specific alignments. The calculation of these values is inconsistent and duplicated among drivers. The results for formats with bpp < 8 are incorrect. This series fixes this for most drivers. Default scanline pitch and buffer size are now calculated with the existing 4CC helpers. There is a new

...o that the each scanline fits into + * the allocated buffer. + */ + fourcc = drm_driver_color_mode_format(drm, args->bpp); + if (fourcc == DRM_FORMAT_INVALID) + return -EINVAL; + info = drm_format_info(fourcc); + if (!info) + return -EINVAL; + pitch_align = drm_format_info_min_pitch(info, 0, SZ_8); + if (!pitch_align || pitch_align > U32_MAX) + return -EINVAL; + ret = drm_mode_size_dumb(drm, args, pitch_align, 0); if (ret) return ret; - args->width = width; - return ret; + return drm_gem_dma_dumb_create(file_priv, drm, args); } static const struct drm_driver imx_drm_driver...

Hi Am 15.01.25 um 11:58 schrieb Tomi Valkeinen: [...] >> These are all good points. Did you read my discussion with Andy on >> patch 2? I think it resolves all the points you have. The current >> CREATE_DUMB > > I had missed the discussion, and, indeed, the patch you attached fixes > the problem on Xilinx. Great. Thanks for testing. > >> ioctl is

...> >> And I assume it's not really possible to define the bpp to mean bits >> per pixel, except for a few special cases like 15? >> >> Why do we even really care about color depth here? We're just >> allocating memory. Doesn't DIV_ROUND_UP(args->bpp, SZ_8) work fine for >> XRGB1555 too? > > Drivers always did that, but it does not work correctly for (bpp < 8). > As we already have helpers to deal with bpp, it makes sense to use > them.? This also aligns dumb buffers with the kernel's video= parameter, > which as the...