Re: [PATCH 4/6] drm/omap: Allow allocation of larger buffers

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2834 bytes --]

On 14/04/14 13:18, Archit Taneja wrote:
> On Monday 14 April 2014 02:55 PM, Tomi Valkeinen wrote:
>> On 11/04/14 10:23, Archit Taneja wrote:
>>> The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers
>>> which are
>>> greater than what is specified in the driver through dev->mode_config.
>>>
>>> Create helpers for DISPC which return the max manager width and
>>> height supported
>>> by the device. The maximum width for a framebuffer is set to the
>>> combined width
>>> of the all the crtcs, assuming they are arranged horizontally.
>>>
>>> Signed-off-by: Archit Taneja <archit@ti.com>
>>> ---
>>>   drivers/gpu/drm/omapdrm/omap_drv.c | 10 ++++++----
>>>   drivers/video/omap2/dss/dispc.c    | 12 ++++++++++++
>>>   include/video/omapdss.h            |  2 ++
>>>   3 files changed, 20 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
>>> b/drivers/gpu/drm/omapdrm/omap_drv.c
>>> index c8270e4..55ec575 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>>> @@ -306,11 +306,13 @@ static int omap_modeset_init(struct drm_device
>>> *dev)
>>>       dev->mode_config.min_width = 32;
>>>       dev->mode_config.min_height = 32;
>>>
>>> -    /* note: eventually will need some cpu_is_omapXYZ() type stuff here
>>> -     * to fill in these limits properly on different OMAP generations..
>>> +    /*
>>> +     * Note: the maximum width is set to the combined width of all the
>>> +     * crtcs. We could assume the same for the maximum height too, but
>>> +     * we generally don't use such a configuration.
>>>        */
>>> -    dev->mode_config.max_width = 2048;
>>> -    dev->mode_config.max_height = 2048;
>>> +    dev->mode_config.max_width = num_crtcs * dispc_mgr_max_width();
>>> +    dev->mode_config.max_height = dispc_mgr_max_height();
>>
>> This looks very strange.
>>
>> If the max size is supposed to be the maximum output size we support,
>> then multiplying with num_crtcs doesn't make sense.
>>
>> If, on the other hand, it tells the possible maximum size of the
>> framebuffer in the memory, of which only small part is shown (where's
>> the max size of that "part" defined, then?), then there should be no
>> limits as the only limit is the size of the memory.
> 
> These parameters are used to tell the max size of framebuffer we can
> allocate in memory.
> 
> I'm not sure why there is a limit in the first place, but if we have a
> really low minimum(like 2048 pixels right now), we can't have multiple
> displays showing different regions of the same buffer.

In that case shouldn't the limit be 0 (if that's allowed) or some surely
high enough value, say, 32767. Why calculate it at all based on the
dispc's maximum, if it has no relevance?

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel