Hi
Am 03.02.20 um 10:53 schrieb Daniel Vetter:
> On Mon, Feb 03, 2020 at 10:49:30AM +0100, Daniel Vetter wrote:
>> On Sat, Feb 01, 2020 at 01:27:41PM +0100, Thomas Zimmermann wrote:
>>> Devices with low amount of dedicated video memory may not be able
>>> to use all possible display modes, as the framebuffers may not fit
>>> into VRAM. The new helper function drm_vram_helper_mode_valid()
>>> implements a simple test to sort out all display modes that can
>>> not be used in any case. Drivers should call this function from
>>> struct drm_mode_config_funcs.mode_valid.
>>>
>>> Calling drm_vram_helper_mode_valid() works best for 32-bit framebuffers;
>>> drivers with framebuffers of different color depth can use
>>> drm_vram_helper_mode_valid_internal() instead.
>>>
>>> The functionality was originally implemented by the ast driver, which
>>> is being converted as well.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx>
>>> ---
>>> drivers/gpu/drm/ast/ast_main.c | 24 +--------
>>> drivers/gpu/drm/drm_gem_vram_helper.c | 76 +++++++++++++++++++++++++++
>>> include/drm/drm_gem_vram_helper.h | 14 +++++
>>> 3 files changed, 91 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
>>> index b79f484e9bd2..18a0a4ce00f6 100644
>>> --- a/drivers/gpu/drm/ast/ast_main.c
>>> +++ b/drivers/gpu/drm/ast/ast_main.c
>>> @@ -388,31 +388,9 @@ static int ast_get_dram_info(struct drm_device *dev)
>>> return 0;
>>> }
>>>
>>> -enum drm_mode_status ast_mode_config_mode_valid(struct drm_device *dev,
>>> - const struct drm_display_mode *mode)
>>> -{
>>> - static const unsigned long max_bpp = 4; /* DRM_FORMAT_XRGBA8888 */
>>> -
>>> - struct ast_private *ast = dev->dev_private;
>>> - unsigned long fbsize, fbpages, max_fbpages;
>>> -
>>> - /* To support double buffering, a framebuffer may not
>>> - * consume more than half of the available VRAM.
>>> - */
>>> - max_fbpages = (ast->vram_size / 2) >> PAGE_SHIFT;
>>> -
>>> - fbsize = mode->hdisplay * mode->vdisplay * max_bpp;
>>> - fbpages = DIV_ROUND_UP(fbsize, PAGE_SIZE);
>>> -
>>> - if (fbpages > max_fbpages)
>>> - return MODE_MEM;
>>> -
>>> - return MODE_OK;
>>> -}
>>> -
>>> static const struct drm_mode_config_funcs ast_mode_funcs = {
>>> .fb_create = drm_gem_fb_create,
>>> - .mode_valid = ast_mode_config_mode_valid,
>>> + .mode_valid = drm_vram_helper_mode_valid,
>>> .atomic_check = drm_atomic_helper_check,
>>> .atomic_commit = drm_atomic_helper_commit,
>>> };
>>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
>>> index a4863326061a..89aebd500655 100644
>>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
>>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>>> @@ -1141,3 +1141,79 @@ void drm_vram_helper_release_mm(struct drm_device *dev)
>>> dev->vram_mm = NULL;
>>> }
>>> EXPORT_SYMBOL(drm_vram_helper_release_mm);
>>> +
>>> +/*
>>> + * Mode-config helpers
>>> + */
>>> +
>>> +/**
>>> + * drm_vram_helper_mode_valid_internal - Tests if a display mode's
>>> + * framebuffer fits into the available video memory.
>>> + * @dev: the DRM device
>>> + * @mode: the mode to test
>>> + * @max_bpp: the maximum number of bytes per pixel
>>
>> Does this render correctly? I thought an empty comment line is required
>> between comments and the free-form paragraphs ... Also usual style (in drm
>> at least) is that the Returns: block is more towards the end of the text,
>> and not indented.
Will be checked and possibly fixed for v2.
>>
>>
>>> + * Returns:
>>> + * MODE_OK the display mode is supported, or an error code of type
>>> + * enum drm_mode_status otherwise.
>>> + *
>>> + * This function tests if enough video memory is available using the
>>> + * specified display mode. Atomic modesetting requires importing the
>>> + * designated framebuffer into video memory before evicting the active
>>> + * one. Hence, any framebuffer may consume at most half of the available
>>> + * VRAM. Display modes that require a larger framebuffer can not be used,
>>> + * even of the CRTC does support them.
>>> + *
>>> + * Drivers should call this function from
>>> + * struct drm_mode_config_funcs.mode_valid. See drm_vram_helper_mode_valid()
>>> + * for framebuffers that use at most 32-bit color depth.
>>> + *
>>> + * Note:
>>> + * The function can only test if the display mode is supported in
>>> + * general. If you have too many framebuffers pinned to video memory,
>>> + * a display mode may still not be usable in practice.
>>> + */
>>> +enum drm_mode_status
>>> +drm_vram_helper_mode_valid_internal(struct drm_device *dev,
>>> + const struct drm_display_mode *mode,
>>> + unsigned long max_bpp)
>>> +{
>>> + struct drm_vram_mm *vmm = dev->vram_mm;
>>> + unsigned long fbsize, fbpages, max_fbpages;
>>> +
>>> + if (!dev->vram_mm)
>>
>> This is a driver bug imo (most likely of enabling hotplug/output detection
>> before the vram handling is set up), needs to be wrapped in a WARN_ON to
>> catch this.
>>
>>> + return MODE_BAD;
>>> +
>>> + max_fbpages = (vmm->vram_size / 2) >> PAGE_SHIFT;
>>> +
>>> + fbsize = mode->hdisplay * mode->vdisplay * max_bpp;
>>> + fbpages = DIV_ROUND_UP(fbsize, PAGE_SIZE);
>>> +
>>> + if (fbpages > max_fbpages)
>>> + return MODE_MEM;
>>> +
>>> + return MODE_OK;
>>> +}
>>> +EXPORT_SYMBOL(drm_vram_helper_mode_valid_internal);
>>
>> Anyway, patch looks good (with the nits addressed one way or the other):
>>
>> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
>>> +
>>> +/**
>>> + * drm_vram_helper_mode_valid - Tests if a display mode's
>>> + * framebuffer fits into the available video memory.
>>> + * @dev: the DRM device
>>> + * @mode: the mode to test
>>> + * Returns:
>>> + * MODE_OK the display mode is supported, or an error code of type
>>> + * enum drm_mode_status otherwise.
>>> + *
>>> + * This function is a variant of drm_vram_helper_mode_valid_internal()
>>> + * for framebuffers that use at most 32-bit color depth. It can be plugged
>>> + * directly into struct drm_mode_config_funcs.mode_valid.
>>> + */
>>> +enum drm_mode_status
>>> +drm_vram_helper_mode_valid(struct drm_device *dev,
>>> + const struct drm_display_mode *mode)
>>> +{
>>> + static const unsigned long max_bpp = 4; /* DRM_FORMAT_XRGBA8888 */
>>> +
>>> + return drm_vram_helper_mode_valid_internal(dev, mode, max_bpp);
>
> Since you don't use the _internal() version anywhere yet ... What about
> unexporting that and instead using the preferred_bpp setting to compute
> valid modes? I suspect that should dtrt almost anywhere ...
Even though that might work, it's asks for problems. ast sets a
preferred depth of 24, when it actually wants 32 for most buffers. I'd
rather just unexport the _internal function until we need it and go with
the max_bpp of 4.
To me, preferred_bpp looks like a fossil from the early days of DRM. (?)
If we want to do something meaningful to auto-detect max_bpp, we should
walk over primary planes and compute the value from the planes' formats
arrays. But for now, the result will always be 4, so there's really no need.
Best regard
Thomas
> -Daniel
>
>>> +}
>>> +EXPORT_SYMBOL(drm_vram_helper_mode_valid);
>>> diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h
>>> index 573e9fd109bf..e7d9144c79ad 100644
>>> --- a/include/drm/drm_gem_vram_helper.h
>>> +++ b/include/drm/drm_gem_vram_helper.h
>>> @@ -6,6 +6,7 @@
>>> #include <drm/drm_file.h>
>>> #include <drm/drm_gem.h>
>>> #include <drm/drm_ioctl.h>
>>> +#include <drm/drm_modes.h>
>>> #include <drm/ttm/ttm_bo_api.h>
>>> #include <drm/ttm/ttm_bo_driver.h>
>>> #include <drm/ttm/ttm_placement.h>
>>> @@ -205,4 +206,17 @@ struct drm_vram_mm *drm_vram_helper_alloc_mm(
>>> struct drm_device *dev, uint64_t vram_base, size_t vram_size);
>>> void drm_vram_helper_release_mm(struct drm_device *dev);
>>>
>>> +/*
>>> + * Mode-config helpers
>>> + */
>>> +
>>> +enum drm_mode_status
>>> +drm_vram_helper_mode_valid_internal(struct drm_device *dev,
>>> + const struct drm_display_mode *mode,
>>> + unsigned long max_bpp);
>>> +
>>> +enum drm_mode_status
>>> +drm_vram_helper_mode_valid(struct drm_device *dev,
>>> + const struct drm_display_mode *mode);
>>> +
>>> #endif
>>> --
>>> 2.25.0
>>>
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
