From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37D64C32771 for ; Tue, 21 Jan 2020 02:47:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 04E5622527 for ; Tue, 21 Jan 2020 02:47:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="k5Y/zRI6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729047AbgAUCre (ORCPT ); Mon, 20 Jan 2020 21:47:34 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:39204 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726890AbgAUCre (ORCPT ); Mon, 20 Jan 2020 21:47:34 -0500 Received: by mail-lf1-f67.google.com with SMTP id y1so911811lfb.6 for ; Mon, 20 Jan 2020 18:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u+pn4ui6Ng1mXgrGseSlzDVL23QH8gYAt0SNyPFDv94=; b=k5Y/zRI6Wpse+DVtUn6DWcc3oHOaKMJi8rO8oUf0yr3k7vwSfyqGe3o17AVJwHwnWc /13egervIl3dHHvuRG6d+X08x0TUflRFlekOxVyke/Br5rQ4bBkqp4ZCHo+urJE2JNKn R4QzmJpL8X4FcVQRfuGv/BTc/ZGf9b2JJwzhQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u+pn4ui6Ng1mXgrGseSlzDVL23QH8gYAt0SNyPFDv94=; b=QRs4XxBIez4FylqOYCDMLURUKfwliJ8ReDjQKKZiD6LQMFuo43EJYgm9Ze5MXJ9uC8 E4pICEG+uLdhNf+g6mAtDBXpFUR8HVYbN3ZepjAOcfxlhhWyG01+TdYna7y8A4befip6 nCcT/j/uv1p7Q5EheJkHcEmuTM83nwJS5VZi4Dt1hA32M64tiVofG6XU8+dGJFttRYGk a69bgjJ0xXyIsPVV2N6Ps7/0/mWUsmAEZVCqigkurnecBWzQyLKgapf4kfrTZMDv/Zp3 D8sbVXO6ABPwmtY47PGcPfDvS+aI9wbyysw/YmhraMwYnYBVOntKHfXu9tXE/CQfbVzl 50kQ== X-Gm-Message-State: APjAAAX/fD9COHN4etvnp6Q0N9yDPCoTwwHrFBTsxib5icfoqg+vH2w3 gDHdHGLMkO20/3Gx5S64MgvuEZRuqcVmmV2Js/0cCQ== X-Google-Smtp-Source: APXvYqz+Ie2Hk3Qp7MF/iN7GrivJEAQgQCuAnCKG3YCbPWbBc0x+hWlAEllhS5hJQfgoBPtmRrFzQSC78RwYWttwHk4= X-Received: by 2002:ac2:5a43:: with SMTP id r3mr1297798lfn.150.1579574852798; Mon, 20 Jan 2020 18:47:32 -0800 (PST) MIME-Version: 1.0 References: <20191218130214.170703-1-keiichiw@chromium.org> <7740094.NyiUUSuA9g@os-lin-dmo> <20200113095636.blov62o4gbf27om5@sirius.home.kraxel.org> <12433898.dW097sEU6C@os-lin-dmo> <20200113110521.5ogc3fcy4zq32yzg@sirius.home.kraxel.org> <20200113132654.r4lhspfx2z7zse2v@sirius.home.kraxel.org> <20200115112640.52kemwg4lncuvvir@sirius.home.kraxel.org> <20200120104755.3hhxlx6x6o32bagf@sirius.home.kraxel.org> In-Reply-To: <20200120104755.3hhxlx6x6o32bagf@sirius.home.kraxel.org> From: Keiichi Watanabe Date: Tue, 21 Jan 2020 11:47:20 +0900 Message-ID: Subject: Re: [virtio-dev] Re: [PATCH v2 0/1] VirtIO video device specification To: Gerd Hoffmann Cc: Tomasz Figa , Dmitry Sepp , spice-devel@lists.freedesktop.org, virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alexandre Courbot , Alex Lau , Daniel Vetter , Dylan Reid , Enrico Granata , Frediano Ziglio , Hans Verkuil , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Pawel Osciak , David Stevens , uril@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi, On Mon, Jan 20, 2020 at 7:48 PM Gerd Hoffmann wrote: > > Hi, > > > > Hmm, using (ii) the API, then check whenever your three plane buffers > > > happen to have the correct layout for (1) hardware looks somewhat > > > backwards to me. > > > > Can't this problem be solved by adding "offset" field in virtio_video_mem_entry? > > > > struct virtio_video_mem_entry { > > le64 addr; > > le32 length; > > le32 offset; > > u8 padding[4]; > > }; > > > > Here, "addr" must be the same in every mem_entry for (1) hardware. > > No. virtio_video_mem_entry is basically a scatter list entry, you use > an *array* of these entries to describe your buffer (unless you are > using CMA due to hardware requirements, in this special case you have > only one entry in your array). I see. I forgot about scatter list. However, I'm still not sure about the usage for CMA. if we're using CMA for a multiplanar format, how can the device know where the second plane start from? In my understanding, the number of entries in this case should be the same with the number of planes and "entries[0].addr + entries[0].length == entries[1].addr" should hold. > > > > I'd suggest to use (i) API and allow the device specify alignment > > > requirements. So (1) hardware would say "need_align=0", whereas (3) > > > hardware would probably say "need_align=PAGE_SIZE" so it can easily > > > split the single buffer into three per-plane buffers. > > > > Just to confirm, is "need_align" a field added in virtio_video_format_desc? > > Given that different formats might have different alignment > requirements this looks like a good place to me. Maybe rename to > plane_align to make clear what kind of alignment this is. "plane_align" sounds better. Thanks. Best regards, Keiichi > > cheers, > Gerd > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6668-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 9B381985EFF for ; Tue, 21 Jan 2020 02:47:34 +0000 (UTC) MIME-Version: 1.0 References: <20191218130214.170703-1-keiichiw@chromium.org> <7740094.NyiUUSuA9g@os-lin-dmo> <20200113095636.blov62o4gbf27om5@sirius.home.kraxel.org> <12433898.dW097sEU6C@os-lin-dmo> <20200113110521.5ogc3fcy4zq32yzg@sirius.home.kraxel.org> <20200113132654.r4lhspfx2z7zse2v@sirius.home.kraxel.org> <20200115112640.52kemwg4lncuvvir@sirius.home.kraxel.org> <20200120104755.3hhxlx6x6o32bagf@sirius.home.kraxel.org> In-Reply-To: <20200120104755.3hhxlx6x6o32bagf@sirius.home.kraxel.org> From: Keiichi Watanabe Date: Tue, 21 Jan 2020 11:47:20 +0900 Message-ID: Subject: Re: [virtio-dev] Re: [PATCH v2 0/1] VirtIO video device specification Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To: Gerd Hoffmann Cc: Tomasz Figa , Dmitry Sepp , spice-devel@lists.freedesktop.org, virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alexandre Courbot , Alex Lau , Daniel Vetter , Dylan Reid , Enrico Granata , Frediano Ziglio , Hans Verkuil , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Pawel Osciak , David Stevens , uril@redhat.com List-ID: Hi, On Mon, Jan 20, 2020 at 7:48 PM Gerd Hoffmann wrote: > > Hi, > > > > Hmm, using (ii) the API, then check whenever your three plane buffers > > > happen to have the correct layout for (1) hardware looks somewhat > > > backwards to me. > > > > Can't this problem be solved by adding "offset" field in virtio_video_m= em_entry? > > > > struct virtio_video_mem_entry { > > le64 addr; > > le32 length; > > le32 offset; > > u8 padding[4]; > > }; > > > > Here, "addr" must be the same in every mem_entry for (1) hardware. > > No. virtio_video_mem_entry is basically a scatter list entry, you use > an *array* of these entries to describe your buffer (unless you are > using CMA due to hardware requirements, in this special case you have > only one entry in your array). I see. I forgot about scatter list. However, I'm still not sure about the usage for CMA. if we're using CMA for a multiplanar format, how can the device know where the second plane start from? In my understanding, the number of entries in this case should be the same with the number of planes and "entries[0].addr + entries[0].length =3D=3D entries[1].addr" should hold. > > > > I'd suggest to use (i) API and allow the device specify alignment > > > requirements. So (1) hardware would say "need_align=3D0", whereas (3= ) > > > hardware would probably say "need_align=3DPAGE_SIZE" so it can easily > > > split the single buffer into three per-plane buffers. > > > > Just to confirm, is "need_align" a field added in virtio_video_format_d= esc? > > Given that different formats might have different alignment > requirements this looks like a good place to me. Maybe rename to > plane_align to make clear what kind of alignment this is. "plane_align" sounds better. Thanks. Best regards, Keiichi > > cheers, > Gerd > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org