From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751611AbdB0Wut (ORCPT <rfc822;w@1wt.eu>);
        Mon, 27 Feb 2017 17:50:49 -0500
Received: from mail-qk0-f181.google.com ([209.85.220.181]:35120 "EHLO
        mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751470AbdB0Wur (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 27 Feb 2017 17:50:47 -0500
MIME-Version: 1.0
In-Reply-To: <CANk1AXTFr0+fKr5TJDmLxrFB7=L7vATO53+5SRyO5HyqK+Ttfg@mail.gmail.com>
References: <CANk1AXTxSrtXmfO53jVx3EqmKc_KWptbpAkmkSttCdA-BXowVw@mail.gmail.com>
 <20170215180612.GB3317@obsidianresearch.com> <CANk1AXSTMynxMrDZ=aHsoX4naqByJnsRXPBvRGTSBpv2_5WptQ@mail.gmail.com>
 <alpine.DEB.2.20.1702151133150.2458@mgerlach-VirtualBox> <20170215203734.GC5531@obsidianresearch.com>
 <CAAtXAHfDXCcKutuLOWq0cK3zBp2ujV+GcvC9bYSFw==guOzBdA@mail.gmail.com>
 <alpine.DEB.2.11.1702171627290.3664@artsy.artland.art> <20170218023010.GA8244@live.com>
 <1CC272501B5BC543A05DB90AA509DED50AF5EC@fmsmsx122.amr.corp.intel.com>
 <CANk1AXT7EMDw-5qWqKCDJcwySQjhhVGf_1m-b9NTbyzVRkO7cg@mail.gmail.com>
 <20170218204509.GA32544@live.com> <CANk1AXTCi6ccimHmXrNPXUn_MJBAoserCmC2kmapQ3Y=zjM79w@mail.gmail.com>
 <CANk1AXTVuVJR6mAKPWgs-+fyRRU1akgmYidu2ubcGJXAwu0oBQ@mail.gmail.com>
 <CAAtXAHd5C4yz3s0WZBL_YKjhwEEntbowsvfg1GUdRDbnq+t9zg@mail.gmail.com>
 <CANk1AXQxpcbGm-MrjrE-7FCmnXAW=Cieg+8QV6ypc6OSCLHTQg@mail.gmail.com> <CANk1AXTFr0+fKr5TJDmLxrFB7=L7vATO53+5SRyO5HyqK+Ttfg@mail.gmail.com>
From: Moritz Fischer <moritz.fischer@ettus.com>
Date: Mon, 27 Feb 2017 14:49:00 -0800
Message-ID: <CAAtXAHcc+kbGCHsixP2GhbrUKEE3XJZmS8QnYnteJNp2-zspxg@mail.gmail.com>
Subject: Re: [RFC 7/8] fpga-region: add sysfs interface
To: Alan Tull <delicious.quinoa@gmail.com>
Cc: "Nadathur, Sundar" <sundar.nadathur@intel.com>,
        Yves Vandervennet <yves.vandervennet@linux.intel.com>,
        Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
        "matthew.gerlach@linux.intel.com" <matthew.gerlach@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
        =?UTF-8?B?TWFyZWsgVmHFoXV0?= <marex@denx.de>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Alan,

On Mon, Feb 27, 2017 at 12:09 PM, Alan Tull <delicious.quinoa@gmail.com> wrote:


> First case: embedded FPGA.  The hardware has one FPGA.  The image is
> designed for a specific board, so there's no problem including the
> enumeration in the image.

Agreed.

> Second case: embedded FPGA + a PCIe FPGA.  The image will be specific
> as to whether it goes into the embedded FPGA or the PCIe one.

Agreed.


> Third case: multiple PCIe FPGAs.  The enumeration base will be the
> PCIe bus of the individual FPGA.  If the FPGAs don't have unique pin
> connections, then the images could go on any of the PCie FPGAs.  If
> there are unique pin connections, then the image will be specific to
> the FPGA and having the enumeration data in the image is that much
> more helpful for keeping things straight.  Part of the header could
> specify which specific FPGA it should go on if it is restricted.

Agreed.

> Of course if the FPGAs have > 1 PR regions, most FPGA architectures do
> not have relocatable images so those images will be specific for the
> PR region but not specific to the FPGA except as otherwise noted
> above.
>
> So again, including enumeration data in the bitstream should work
> unless I'm missing something.  What am I missing here?

If you enumeration base is sufficiently smart, I suppose that can work.
What you'd probably want is some sort of extension to the platform bus?

I really need to take another look at how non-dt systems enumerate to
give better feedback on this.

Cheers,

Moritz