From: Mark yao <mark.yao@rock-chips.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: xw@rock-chips.com, zwl@rock-chips.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
dkm@rock-chips.com, sandy.huang@rock-chips.com,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/5] drm/rockchip: vop: fix yuv plane support
Date: Thu, 02 Jul 2015 14:53:38 +0800 [thread overview]
Message-ID: <5594DFF2.8020609@rock-chips.com> (raw)
In-Reply-To: <CAAFQd5AAYSMNRtJBVU+2LHhA=JhJQVTEGmf2+pVt5JMXbbmg-g@mail.gmail.com>
Hi Tomasz
Thanks for your review, I will fix it soon.
On 2015年07月02日 14:00, Tomasz Figa wrote:
> Hi Mark,
>
> Please see my comments inline.
>
> On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao <mark.yao@rock-chips.com> wrote:
>> vop support yuv with NV12, NV16 and NV24, only 2 plane yuv.
>>
>> Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
>>
>> Changes in v2:
>> - Uv buffer not support odd offset, align it.
>> - Fix error display when move yuv image.
>>
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 63 ++++++++++++++++++++++++---
>> 1 file changed, 57 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index 3c9f4f3..6ca08f8 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -373,6 +373,18 @@ static enum vop_data_format vop_convert_format(uint32_t format)
>> }
>> }
>>
>> +static bool is_yuv_support(uint32_t format)
>> +{
>> + switch (format) {
>> + case DRM_FORMAT_NV12:
>> + case DRM_FORMAT_NV16:
>> + case DRM_FORMAT_NV24:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +}
>> +
>> static bool is_alpha_support(uint32_t format)
>> {
>> switch (format) {
>> @@ -577,16 +589,21 @@ static int vop_update_plane_event(struct drm_plane *plane,
>> struct vop *vop = to_vop(crtc);
>> struct drm_gem_object *obj;
>> struct rockchip_gem_object *rk_obj;
>> + struct drm_gem_object *uv_obj;
>> + struct rockchip_gem_object *rk_uv_obj;
>> unsigned long offset;
>> unsigned int actual_w;
>> unsigned int actual_h;
>> unsigned int dsp_stx;
>> unsigned int dsp_sty;
>> unsigned int y_vir_stride;
>> + unsigned int uv_vir_stride;
>> dma_addr_t yrgb_mst;
>> + dma_addr_t uv_mst;
>> enum vop_data_format format;
>> uint32_t val;
>> bool is_alpha;
>> + bool is_yuv;
>> bool visible;
>> int ret;
>> struct drm_rect dest = {
>> @@ -608,6 +625,12 @@ static int vop_update_plane_event(struct drm_plane *plane,
>> };
>> bool can_position = plane->type != DRM_PLANE_TYPE_PRIMARY;
>>
>> + if (drm_format_num_planes(fb->pixel_format) > 2) {
>> + DRM_ERROR("unsupport more than 2 plane format[%08x]\n",
>> + fb->pixel_format);
>> + return -EINVAL;
>> + }
> Hmm, do you need to check this? Doesn't the core guarantee that with
> given pixel_format you always get the right plane count? (Possibly at
> fb creation time, but I haven't checked that.)
I just want to point out that update_plane can't handle buffer number >
2 case.
But since all windows can't support 3 buffer count format, this check
can remove.
>> +
>> ret = drm_plane_helper_check_update(plane, crtc, fb,
>> &src, &dest, &clip,
>> DRM_PLANE_HELPER_NO_SCALING,
>> @@ -624,28 +647,52 @@ static int vop_update_plane_event(struct drm_plane *plane,
>> if (format < 0)
>> return format;
>>
>> + is_yuv = is_yuv_support(fb->pixel_format);
> nit: Could you group this together with other is_* assignments, above
> the call to vop_convert_format()?
OK.
>> +
>> obj = rockchip_fb_get_gem_obj(fb, 0);
>> if (!obj) {
>> DRM_ERROR("fail to get rockchip gem object from framebuffer\n");
>> return -EINVAL;
>> }
>>
>> + if (is_yuv) {
>> + src.x1 &= (~1) << 16;
>> + src.y1 &= (~1) << 16;
> Hmm, if you align x1 and y1, shouldn't you also offset x2 and y2, so
> the width and height of the rectangle are preserved? Also I couldn't
> find any details on this, but what are the semantics of
> .update_plane(), should it really align the values or maybe just fail?
for yuv format, the buffer start point need align, can't be odd.
OK, I will fix the x2 and y2 offset.
>> + }
>> +
>> rk_obj = to_rockchip_obj(obj);
>>
>> actual_w = (src.x2 - src.x1) >> 16;
>> actual_h = (src.y2 - src.y1) >> 16;
>> - crtc_x = max(0, crtc_x);
>> - crtc_y = max(0, crtc_y);
>>
>> - dsp_stx = crtc_x + crtc->mode.htotal - crtc->mode.hsync_start;
>> - dsp_sty = crtc_y + crtc->mode.vtotal - crtc->mode.vsync_start;
>> + dsp_stx = dest.x1 + crtc->mode.htotal - crtc->mode.hsync_start;
>> + dsp_sty = dest.y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
> This change could be split into separate patch, which actually fixes
> the coordinates used for this calculation, because that's why we do
> clipping with drm_plane_helper_check_update() first to use dest not
> crtc_{x,y}.
OK
>> - offset = (src.x1 >> 16) * (fb->bits_per_pixel >> 3);
>> + offset = (src.x1 >> 16) * drm_format_plane_cpp(fb->pixel_format, 0);
>> offset += (src.y1 >> 16) * fb->pitches[0];
>> - yrgb_mst = rk_obj->dma_addr + offset;
>>
>> + yrgb_mst = rk_obj->dma_addr + offset + fb->offsets[0];
> This (missing offsets[0] addition) should also be a separate patch,
> because it was obviously incorrect before this patch.
OK.
>
> Best regards,
> Tomasz
>
>
>
--
Mark Yao
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-07-02 6:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 10:07 [PATCH v2 0/5] drm/rockchip: support yuv overlay and plane scale Mark Yao
2015-06-26 10:07 ` [PATCH v2 1/5] drm/rockchip: vop: optimize virtual stride calculate Mark Yao
2015-07-02 4:59 ` Tomasz Figa
2015-07-02 6:13 ` Mark yao
2015-06-26 10:07 ` [PATCH v2 2/5] drm/rockchip: vop: fix yuv plane support Mark Yao
2015-07-02 6:00 ` Tomasz Figa
2015-07-02 6:53 ` Mark yao [this message]
[not found] ` <5594DFF2.8020609-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-07-02 7:07 ` Tomasz Figa
2015-06-26 10:07 ` [PATCH v2 3/5] drm/rockchip: vop: support plane scale Mark Yao
2015-07-03 7:46 ` Tomasz Figa
2015-07-03 9:17 ` Mark yao
[not found] ` <55965344.5050502-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-07-03 9:58 ` Tomasz Figa
2015-07-03 10:14 ` Russell King - ARM Linux
2015-07-03 10:22 ` Mark yao
2015-07-03 14:37 ` Tomasz Figa
2015-06-26 10:07 ` [PATCH v2 4/5] drm/rockchip: vop: switch cursor plane to window 3 Mark Yao
2015-07-03 7:55 ` Tomasz Figa
2015-07-21 7:38 ` Tomasz Figa
2015-06-26 10:10 ` [PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit Mark Yao
2015-07-03 8:02 ` Tomasz Figa
2015-07-03 8:19 ` Mark yao
2015-07-03 9:24 ` Tomasz Figa
2015-07-03 10:08 ` Mark yao
2015-07-21 7:33 ` Tomasz Figa
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=5594DFF2.8020609@rock-chips.com \
--to=mark.yao@rock-chips.com \
--cc=dkm@rock-chips.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=sandy.huang@rock-chips.com \
--cc=tfiga@chromium.org \
--cc=xw@rock-chips.com \
--cc=zwl@rock-chips.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;
as well as URLs for NNTP newsgroup(s).