From: Lars-Peter Clausen <lars@metafoo.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3] DRM: Add DRM kms/fb cma helper
Date: Thu, 19 Jul 2012 17:12:28 +0200 [thread overview]
Message-ID: <500823DC.90104@metafoo.de> (raw)
In-Reply-To: <5008204B.7070205@metafoo.de>
On 07/19/2012 04:57 PM, Lars-Peter Clausen wrote:
> On 07/19/2012 04:41 PM, Laurent Pinchart wrote:
>> On Thursday 19 July 2012 16:02:41 Laurent Pinchart wrote:
>>> On Thursday 19 July 2012 15:55:56 Lars-Peter Clausen wrote:
>>>> On 07/19/2012 03:33 PM, Laurent Pinchart wrote:
>>>>> On Thursday 19 July 2012 15:34:26 Lars-Peter Clausen wrote:
>>>>>> On 07/19/2012 02:46 PM, Laurent Pinchart wrote:
>>>>>>> On Monday 02 July 2012 16:37:47 Lars-Peter Clausen wrote:
>>>>>>>> This patchset introduces a set of helper function for implementing
>>>>>>>> the KMS framebuffer layer for drivers which use the drm gem CMA
>>>>>>>> helper function.
>>>>>>>>
>>>>>>>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Note: This patch depends on Sascha's "DRM: add drm gem CMA helper"
>>>>>>>> patch
>>>>>>>>
>>>>>>>> Changes since v2:
>>>>>>>> * Adapt to changes in the GEM CMA helper
>>>>>>>> * Add basic buffer size checking in drm_fb_cma_create
>>>>>>>>
>>>>>>>> Changes since v1:
>>>>>>>> * Some spelling fixes
>>>>>>>> * Add missing kfree in drm_fb_cma_alloc error path
>>>>>>>> * Add multi-plane support
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> drivers/gpu/drm/Kconfig | 10 +
>>>>>>>> drivers/gpu/drm/Makefile | 1 +
>>>>>>>> drivers/gpu/drm/drm_fb_cma_helper.c | 393
>>>>>>>> +++++++++++++++++++++++++++
>>>>>>>> include/drm/drm_fb_cma_helper.h | 27 +++
>>>>>>>> 4 files changed, 431 insertions(+)
>>>>>>>> create mode 100644 drivers/gpu/drm/drm_fb_cma_helper.c
>>>>>>>> create mode 100644 include/drm/drm_fb_cma_helper.h
>>>>>>>
>>>>>>> [snip]
>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>>>>>>>> b/drivers/gpu/drm/drm_fb_cma_helper.c new file mode 100644
>>>>>>>> index 0000000..9042233
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>>>>>>>
>>>>>>> [snip]
>>>>>>>
>>>>>>>> +/**
>>>>>>>> + * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create
>>>>>>>> callback function
>>>>>>>> + *
>>>>>>>> + * If your hardware has special alignment or pitch requirements
>>>>>>>> these
>>>>>>>> should be
>>>>>>>> + * checked before calling this function.
>>>>>>>> + */
>>>>>>>> +struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
>>>>>>>> + struct drm_file *file_priv, struct drm_mode_fb_cmd2 *mode_cmd)
>>>>>>>> +{
>>>>>>>> + struct drm_fb_cma *fb_cma;
>>>>>>>> + struct drm_gem_cma_object *objs[4];
>>>>>>>> + struct drm_gem_object *obj;
>>>>>>>> + int ret;
>>>>>>>> + int i;
>>>>>>>> +
>>>>>>>> + for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format);
>> i++)
>>>>>>>> {
>>>>>>>> + obj = drm_gem_object_lookup(dev, file_priv, mode_cmd-
>>>>>>
>>>>>> handles[i]);
>>>>>>
>>>>>>>> + if (!obj) {
>>>>>>>> + dev_err(dev->dev, "Failed to lookup GEM object\n");
>>>>>>>> + ret = -ENXIO;
>>>>>>>> + goto err_gem_object_unreference;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + if (obj->size < mode_cmd->height * mode_cmd->pitches[i]) {
>>>>>>>
>>>>>>> Shouldn't this be
>>>>>>>
>>>>>>> if (obj->size < mode_cmd->height * mode_cmd->pitches[i]
>>>>>>>
>>>>>>> + mode_cmd->offsets[i])
>>>>>>>
>>>>>>> ?
>>>>>>
>>>>>> That's actually a good question. I'd expect the offset to be included
>>>>>> in the pitch.
>>>>>>
>>>>>> If you access pixels like mem[offset + x * bpp + y * pitch] then pitch
>>>>>> has to be greater equal to offset + max_x * bpp, otherwise you'd have
>>>>>> overlapping lines.
>>>>>
>>>>> My understanding is that the offset is a linear offset from the start of
>>>>> the buffer to allow X/Y panning. In that case the pitch is a frame
>>>>> buffer property that is not be influenced by the offset at all.
>>>>
>>>> Hi,
>>>>
>>>> I think panning is normally done by setting the x and y offset for the
>>>> crtc.
>>>>
>>>> But yes, you are right the offset might just be a linear offset to the
>>>> start of the actual data. I was just thinking about the case where the
>>>> different planes are interleaved. But for panning or non-interleaved
>>>> planes it obviously is different.
>>>>
>>>> Though this leaves us with a problem. If the planes are interleaved and
>>>> the offset is included in the pitch your check may fail, even though the
>>>> buffer is large enough.
>>>>
>>>> Maybe we need to handle both cases differently. If offset < pitch check
>>>> for
>>>> obj->size < mode_cmd->height * mode_cmd->pitches[i] otherwise check for
>>>> obj->size < mode_cmd->height * mode_cmd->pitches[i] + mode_cmd->offsets[i]
>>>>
>>>> But that doesn't quite work either if you have both interleaved planes and
>>>> a linear offset...
>>>
>>> What about first finding out what those offsets are supposed to be used for
>>> ?
>>>
>>> Ville, git blame points to you as the author of the offsets field :-) Could
>>> you please comment on this ?
>>
>> My bad, I was looking at drm_framebuffer and not drm_mode_fb_cmd2.
>>
>> Offset really looks like it is a linear offset from the beginning of the
>> buffer. This allows placing several planes at different locations in a single
>> buffer. I think we need to add mode_cmd->offsets[i] unconditionally when
>> checking the size.
>>
>
> There are two cases to consider interleaved and non-interleaved planes in a
> single buffer.
>
> a) Separate planes
> [Y Y Y Y ....]
> [Y Y Y Y ....]
> [ .......... ]
> [Y Y Y Y ....]
> [CBCR CBCR CBCR CBCR .... ]
> [CBCR CBCR CBCR CBCR .... ]
> [ ....................... ]
> [CBCR CBCR CBCR CBCR .... ]
>
> Plane 0:
> bpp = 1
> offset = 0
>
> Plane 1:
> bpp = 1
> offset = plane0_size
>
>
> b) Interleaved planes
> [Y CBCR Y CBCR Y CBCR ....]
> [Y CBCR Y CBCR Y CBCR ....]
> [ ....................... ]
> [Y CBCR Y CBCR Y CBCR ....]
>
> Plane 0:
> bbp = 2
> offset = 0
>
> Plane 1:
> bbp = 2
> offset = 1
To make things more complicated add:
c) Line interleaved planes
[Y Y Y Y .... ]
[CBCR CBCR CBCR CBCR .... ]
[Y Y Y Y .... ]
[CBCR CBCR CBCR CBCR .... ]
[ ....................... ]
So maybe:
min_size = height * pitch;
min_size -= bpp - drm_format_plane_cpp();
min_size -= pitch - width * bpp;
min_size += offset;
- Lars
next prev parent reply other threads:[~2012-07-19 15:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-02 14:37 [PATCH v3] DRM: Add DRM kms/fb cma helper Lars-Peter Clausen
2012-07-11 18:53 ` Sascha Hauer
2012-07-19 12:46 ` Laurent Pinchart
2012-07-19 13:31 ` Laurent Pinchart
2012-07-19 13:34 ` Lars-Peter Clausen
2012-07-19 13:33 ` Laurent Pinchart
2012-07-19 13:55 ` Lars-Peter Clausen
2012-07-19 14:02 ` Laurent Pinchart
2012-07-19 14:41 ` Laurent Pinchart
2012-07-19 14:57 ` Lars-Peter Clausen
2012-07-19 15:01 ` Lars-Peter Clausen
2012-07-19 15:01 ` Laurent Pinchart
2012-07-19 15:36 ` Lars-Peter Clausen
2012-07-19 15:12 ` Lars-Peter Clausen [this message]
2012-07-19 15:46 ` Laurent Pinchart
2012-07-19 16:01 ` Lars-Peter Clausen
2012-08-08 14:43 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=500823DC.90104@metafoo.de \
--to=lars@metafoo.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox