Received: by 10.223.176.5 with SMTP id f5csp264746wra; Mon, 5 Feb 2018 21:34:30 -0800 (PST) X-Google-Smtp-Source: AH8x225c55Lk3BuFc9V5W/E098fL71Gwk1N/vTbeKtGkyOruCPdA+QvoQhn/eoXKe6FGSF+TRcLx X-Received: by 10.99.123.92 with SMTP id k28mr999416pgn.71.1517895270204; Mon, 05 Feb 2018 21:34:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517895270; cv=none; d=google.com; s=arc-20160816; b=DQo85lGb+2mbzAzgqdXnauj9w/glZ4I4owb1ZVxIinF2+PqqiD7kxgVFs7JMeZmvad utxT4go5TNneU8p1k7p4wOSdXyOm6sAndhYIA3OIpSEXX/0ZT+deKaXin3JtHoImEaRU o6cvTD4GX3O5YmQ79+OCrIxuEg3TEUaFUf0LBYw8ZU0GlCzjmyin0348fGnFnnhqkTXT 0YaSN9yPs8/jrwM0PgCfIGv1WBso18Jl/HZ8dfrw9wShdlV69DNGpFLwVkiHbW6vp6fx Ob96r6PvwZEDLquK17SZd0Es+yR/4kFZ7x0fXDQZy8P5NARz2nCGFhL0PKeK/J/F0GX6 lFiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=BXMGSxsH1Q2Tg+7kfThDO3+KrPvt1GnsEl759qQZTAA=; b=jgtQGEBrDulof+6AQYQCNRFuQpay6kY0ZGsEg949B/q6E9cks9GJnzVOOUeCk8Zv9s LuGYZN38hj+YdC8EqcMjoNfEnNfMN86/OOiB2TVl9NwN7FYnvXPWOnkC2glHW/Vxt04w ivzO55kwyWXVnzyYd4EKp9GwChMoXUfG3fHhS2Fq3GLgdXsMHfPEAdQPK332KL3LBUz4 lEGwlgr7gGtkrSbpfziq0eiSlTRNZrc/m1P/5GcwivI3VZh3jrJSKQ2VEZeoR36axFb5 OXzUMrzL2HC6uL4E4o7qEgrbu8rLWHxezQpsyRnu+dCDoW8cxdhzk1+zvEfYEeFgbHwG GOCg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a67si691972pgc.151.2018.02.05.21.34.14; Mon, 05 Feb 2018 21:34:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752117AbeBFFcs (ORCPT + 99 others); Tue, 6 Feb 2018 00:32:48 -0500 Received: from mga14.intel.com ([192.55.52.115]:52666 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750751AbeBFFcl (ORCPT ); Tue, 6 Feb 2018 00:32:41 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2018 21:32:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,467,1511856000"; d="scan'208";a="29112300" Received: from hao-dev.bj.intel.com (HELO localhost) ([10.238.157.61]) by orsmga001.jf.intel.com with ESMTP; 05 Feb 2018 21:32:37 -0800 Date: Tue, 6 Feb 2018 13:23:15 +0800 From: Wu Hao To: Alan Tull Cc: Moritz Fischer , "Luebbers, Enno" , linux-fpga@vger.kernel.org, linux-kernel , linux-api@vger.kernel.org, "Kang, Luwei" , "Zhang, Yi Z" , Tim Whisonant , Shiva Rao , Christopher Rauer , Xiao Guangrong Subject: Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME Message-ID: <20180206052315.GA4882@hao-dev> References: <1511764948-20972-1-git-send-email-hao.wu@intel.com> <1511764948-20972-15-git-send-email-hao.wu@intel.com> <20180202094213.GB17015@hao-dev> <20180203002626.GA51125@eluebber-mac02.jf.intel.com> <20180203104124.luniynyrr6iwxozd@derp-derp.local> <20180204100546.GB26184@hao-dev> <20180206021756.GA3971@hao-dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 05, 2018 at 10:25:27PM -0600, Alan Tull wrote: > On Mon, Feb 5, 2018 at 8:17 PM, Wu Hao wrote: > > On Mon, Feb 05, 2018 at 11:21:52AM -0600, Alan Tull wrote: > >> On Sun, Feb 4, 2018 at 4:05 AM, Wu Hao wrote: > >> > On Sat, Feb 03, 2018 at 11:41:24AM +0100, Moritz Fischer wrote: > >> >> Hi Hao, > >> >> > >> >> On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote: > >> >> > Hi Hao, Alan, > >> >> > > >> >> > On Fri, Feb 02, 2018 at 05:42:13PM +0800, Wu Hao wrote: > >> >> > > On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote: > >> >> > > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao wrote: > >> >> > > > > >> >> > > > Hi Hao, > >> >> > > > > >> >> > > > A few comments below. Besides that, looks good. > >> >> > > > > >> >> > > > > This patch adds fpga manager driver for FPGA Management Engine (FME). It > >> >> > > > > implements fpga_manager_ops for FPGA Partial Reconfiguration function. > >> >> > > > > > >> >> > > > > Signed-off-by: Tim Whisonant > >> >> > > > > Signed-off-by: Enno Luebbers > >> >> > > > > Signed-off-by: Shiva Rao > >> >> > > > > Signed-off-by: Christopher Rauer > >> >> > > > > Signed-off-by: Kang Luwei > >> >> > > > > Signed-off-by: Xiao Guangrong > >> >> > > > > Signed-off-by: Wu Hao > >> >> > > > > ---- > >> >> > > > > v3: rename driver to dfl-fpga-fme-mgr > >> >> > > > > implemented status callback for fpga manager > >> >> > > > > rebased due to fpga api changes > >> >> > > > > --- > >> >> > > > > .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr | 8 + > >> >> > > > > drivers/fpga/Kconfig | 6 + > >> >> > > > > drivers/fpga/Makefile | 1 + > >> >> > > > > drivers/fpga/fpga-dfl-fme-mgr.c | 318 +++++++++++++++++++++ > >> >> > > > > drivers/fpga/fpga-dfl.h | 39 ++- > >> >> > > > > 5 files changed, 371 insertions(+), 1 deletion(-) > >> >> > > > > create mode 100644 Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr > >> >> > > > > create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c > >> >> > > > > > >> >> > > > > diff --git a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr > >> >> > > > > new file mode 100644 > >> >> > > > > index 0000000..2d4f917 > >> >> > > > > --- /dev/null > >> >> > > > > +++ b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr > >> >> > > > > @@ -0,0 +1,8 @@ > >> >> > > > > +What: /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id > >> >> > > > > +Date: November 2017 > >> >> > > > > +KernelVersion: 4.15 > >> >> > > > > +Contact: Wu Hao > >> >> > > > > +Description: Read-only. It returns interface id of partial reconfiguration > >> >> > > > > + hardware. Userspace could use this information to check if > >> >> > > > > + current hardware is compatible with given image before FPGA > >> >> > > > > + programming. > >> >> > > > > >> >> > > > I'm a little confused by this. I can understand that the PR bitstream > >> >> > > > has a dependency on the FPGA's static image, but I don't understand > >> >> > > > the dependency of the bistream on the hardware that is used to program > >> >> > > > the bitstream to the FPGA. > >> >> > > > >> >> > > Sorry for the confusion, the interface_id is used to indicate the version of > >> >> > > the hardware for partial reconfiguration (it's part of the static image of > >> >> > > the FPGA device). Will improve the description on this. > >> >> > >> >> I'm not sure userland should be making the call on whether what you're > >> >> trying to load is compatible or not. > >> > >> Could you explain more about what your concern was about this (unless > >> Hao has covered it below)? > >> > >> It makes sense to me in this use case at least since userspace has a > >> pile of images and is choosing which one to load. > >> > >> >> Isn't there a way to check this in > >> >> your PR reconfiguration handler in-kernel? > >> > > >> > Hi Moritz > >> > > >> > Actually with current driver interface, doing a partial reconfiguration with an > >> > incompatible image, then driver will report PR failure with error code > >> > FPGA_MGR_STATUS_INCOMPATIBLE_IMAGE_ERR as hardware checks it, but anyway user > >> > needs to know hardware interface_id information to find or re-generated correct > >> > images. I think it's more flexible to leave it to userspace on using this > >> > information exposed by driver. : ) > >> > > >> > Thanks > >> > Hao > >> > > >> >> > >> >> > > > >> >> > > >> >> > The interface_id expresses the compatibility of the static region with PR > >> >> > bitstreams generated for it. It changes every time a new static region is > >> >> > generated. > >> > >> In the near future the DFL framework will be used with SoC's that have > >> a hard FPGA PR manager (that's not part of the static region). The > >> hard FPGA manager driver won't know anything about the static region. > >> > >> >> > > >> >> > Would it make more sense to have the interface_id exposed as part of the FME > >> >> > device (which represents the static region)? I'm not sure - it kind of also > >> >> > makes sense here, where you would have all the information in one place (if the > >> >> > interface_id matches, I can use this component to program a bitstream). > >> > >> According to the intel-fpga.txt document, the identifier for the > >> static image is at > >> > >> /sys/class/fpga_region/regionX/fpga-dfl-fme.n/bitstream_id > > > > Hi Alan > > Hi Hao, > > > > > This bitstream_id refects the full static region version. As you know, PR is > > only a sub feature of the FME functional unit, it's possible that we have > > different static region (different bitstream_id) but it has the exact same > > PR sub feature under the FME, only changes on other sub features or function > > units. > > OK, thanks for that explanation. That makes sense but could have > easily been different. Please document this somewhere. Sure, will do. Thanks Hao