From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932229AbdKGID0 (ORCPT ); Tue, 7 Nov 2017 03:03:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52502 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752641AbdKGIDZ (ORCPT ); Tue, 7 Nov 2017 03:03:25 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3DB7A267D8 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=kraxel@redhat.com Message-ID: <1510041801.24424.5.camel@redhat.com> Subject: Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation From: Gerd Hoffmann To: "Zhang, Tina" , "alex.williamson@redhat.com" , "chris@chris-wilson.co.uk" , "joonas.lahtinen@linux.intel.com" , "zhenyuw@linux.intel.com" , "Lv, Zhiyuan" , "Wang, Zhi A" , "Tian, Kevin" , "daniel@ffwll.ch" , "kwankhede@nvidia.com" Cc: Daniel Vetter , "intel-gfx@lists.freedesktop.org" , "intel-gvt-dev@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" Date: Tue, 07 Nov 2017 09:03:21 +0100 In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C626C77@SHSMSX101.ccr.corp.intel.com> References: <1509934758-5003-1-git-send-email-tina.zhang@intel.com> <1509934758-5003-6-git-send-email-tina.zhang@intel.com> <1509958887.30277.4.camel@redhat.com> <237F54289DF84E4997F34151298ABEBC7C626C77@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 07 Nov 2017 08:03:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > Add a head field here?  People asked @ kvm forum about multihead > > support. > > Even if the initial driver version doesn't support it we could add > > a field so it > > becomes easier to add it at some point in the future. > > > > Probing for available heads could be done with the PROBE flag, i.e. > > flags = PROBE | DMABUF, plane_type = PRIMARY, head = 0, 1, ... > > Does the multihead mean multiple display monitor? So each head can > have its own one primary plane, one cursor plane and maybe some > sprite planes if supported. Yes and yes. > And the flow could be like this: > 1) flags = PROBE | DMABUF, then return the number of heads in > vfio_device_gfx_plane_info.head. I'd suggest to use { .flags = PROBE | DMABUF, .head = 0 } to check whenever dmabuf is supported for head 0, then { .flags = PROBE | DMABUF, .head = 1 } to check for head 1 support, ... Driver returns success if the head is supported and -EINVAL otherwise, simliar to the dmabuf vs. region probing. It is less confusing because .head is always an input field then. It is also a bit more flexible because different heads can support different modes (I don't expect drivers will actually use that though). > 2) flags = DMABUF with plane_type = PRIMARY, head = 0, 1, ..., then > return the id of the exposed framebuffer of that head. Yes. > Another question is if the sprite plane is supported, how we're going > to identify them, as there could be several sprite planes for one > display monitor. Do you mean DRM_PLANE_TYPE_OVERLAY? > Add another field "num_plane" for it? Then, I guess the flow could be > like this: > 1) flags = PROBE | DMABUF, then return the number of heads in > vfio_device_gfx_plane_info.head. > 2) flags = PROBE | DMABUF and head = 0, 1, ..., and plane_type = > PRIMARY/CURSOR/SPRITE, then return the num_plane. I'd suggest to do it simliar to the head probe outlined above, i.e. userspace calls { .flags = PROBE | DMABUF, .head = 0, .plane_type = OVERLAY, plane_num = 0, 1, 2, ... } and the driver returns -EINVAL or 0 depending on whenever it is supported or not. cheers, Gerd