Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753444AbdFSGeI (ORCPT ); Mon, 19 Jun 2017 02:34:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45858 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751083AbdFSGeG (ORCPT ); Mon, 19 Jun 2017 02:34:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 16DF680C1D Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 16DF680C1D Message-ID: <1497854053.4207.2.camel@redhat.com> Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations From: Gerd Hoffmann To: Alex Williamson , Kirti Wankhede Cc: Xiaoguang Chen , chris@chris-wilson.co.uk, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, zhenyuw@linux.intel.com, zhiyuan.lv@intel.com, intel-gvt-dev@lists.freedesktop.org, zhi.a.wang@intel.com, kevin.tian@intel.com Date: Mon, 19 Jun 2017 08:34:13 +0200 In-Reply-To: <20170616103959.3b6f1681@t450s.home> References: <1497513611-2814-1-git-send-email-xiaoguang.chen@intel.com> <1497513611-2814-6-git-send-email-xiaoguang.chen@intel.com> <1497542438.29252.1.camel@redhat.com> <20170615143833.7526351b@w520.home> <24c4880b-24f5-ea07-834c-c77d3e895c78@nvidia.com> <20170616103959.3b6f1681@t450s.home> 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.26]); Mon, 19 Jun 2017 06:34:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1197 Lines: 46 Hi, > So perhaps this becomes: > > struct vfio_device_gfx_plane_info { > __u64 start; > __u64 drm_format_mod; > __u32 drm_format; > __u32 width; > __u32 height; > __u32 stride; > __u32 size; > __u32 x_pos; > __u32 y_pos; > }; Looks good. > struct vfio_device_query_gfx_plane { > __u32 argsz; > __u32 flags; > #define VFIO_GFX_PLANE_FLAGS_REGION_ID (1 << 0) > #define VFIO_GFX_PLANE_FLAGS_PLANE_ID (1 << 1) > struct vfio_device_gfx_plane_info plane_info; > __u32 id;  > }; Hmm, plane isn't really an ID, it is a type, with type being either DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think the flage above make sense. What are the nvidia plane for cursor support btw? > The flag defines the data in the id field as either referring to a > region (perhaps there could be multiple regions with only one active) Well, we have a "start" field in vfio_device_gfx_plane_info (maybe we should rename that to "offset"), which can be used to place multiple planes into a single, fixed region. Also I think it would be useful to have some way to figure the device capabilities as the userspace workflow will look quite different for the two cases. cheers, Gerd