From: Alan Tull <atull@kernel.org>
To: "Wu, Hao" <hao.wu@intel.com>
Cc: Moritz Fischer <moritz.fischer@ettus.com>,
"linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Kang, Luwei" <luwei.kang@intel.com>,
"Zhang, Yi Z" <yi.z.zhang@intel.com>,
"Whisonant, Tim" <tim.whisonant@intel.com>,
"Luebbers, Enno" <enno.luebbers@intel.com>,
"Rao, Shiva" <shiva.rao@intel.com>,
"Rauer, Christopher" <christopher.rauer@intel.com>,
"Tull, Alan" <alan.tull@intel.com>,
Xiao Guangrong <guangrong.xiao@linux.intel.com>
Subject: Re: [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub feature support
Date: Wed, 5 Apr 2017 10:39:05 -0500 [thread overview]
Message-ID: <CANk1AXQb3tHZXqfaPNZLCtsqrn=-85ARdn0WXcrehV9HONmpSg@mail.gmail.com> (raw)
In-Reply-To: <CANk1AXSbR037T9jzcs3DtduOiy8Pt-dDcesEnJuY9LTa9vF_og@mail.gmail.com>
On Wed, Apr 5, 2017 at 10:26 AM, Alan Tull <atull@kernel.org> wrote:
> On Wed, Apr 5, 2017 at 6:40 AM, Wu, Hao <hao.wu@intel.com> wrote:
>>> >> The fpga_image_info struct started life as just image specific info,
>>> >> but I want it to go in the direction of including parameters needed to
>>> >> program it this specific time. Otherwise we are stuck having to keep
>>> >> adding parameters as our use of FPGA develops. It probably could be
>>> >> documented better as 'information needed to program a FPGA image'
>>> >> rather than strictly 'information about this particular FPGA image'.
>>> >> My patch "fpga-mgr: pass parameters for loading fpga in image info"
>>> >> goes in this direction by having the buf, firmware name, or sg list
>>> >> passed in the info for the added fpga_mgr_load() function. Actually I
>>> >> should probably simplify the API and get rid of fpga_mgr_buf_load,
>>> >> fpga_mgr_buf_load_sg, and fpga_mgr_firmware_load and require people to
>>> >> use fpga_mgr_load (passing all parameters in fpga_image_info).
>>> >>
>>> >
>>> > Make sense.
>>> >
>>> >> > It may be a
>>> >> > little confusing. One rough idea is that keep this info under fpga region
>>> >> > (maybe its private data), and pass the fpga-region to fpga_mgr_buf_load,
>>> >>
>>> >> Yes, keep this info in fpga-region. When the region wants to program
>>> >> using fpga-mgr, add the region id to fpga_image_info. I propose
>>> >> calling it region_id.
>>> >
>>> > Hm.. Do we need a function which moves info from region to image info?
>>>
>>> No, just code that sets that variable in the struct before calling the
>>> fpga_region_program_fpga function.
>>>
>>> >
>>> > Another idea is, add a priv to fpga_image_info, and use a common function
>>> > to pass the fpga_region's priv to fpga_image_info's priv before PR.
>>> > fpga-mgr then knows fpga_region priv info from the fpga_image_info.
>>> >
>>>
>>> Adding priv would make the interface for fpga-mgr non-uniform. The point
>>> of having a fpga-mgr framework is that there
>>> is the potential of the upper layers working for different FPGA devices.
>>> If the interface for each FPGA device were different, that would then
>>> be broken.
>>>
>>
>> I mean drivers can register their own fpga-mgr ops, and handle priv of
>> fpga_image_info in driver specific way for pr (e.g write_init function).
>> We don't need to change the any upper layer interfaces.
>
> I'm trying to avoid driver specific ways of doing things. Think of this
> all as a set of blocks and we want to be able to switch out individual
> blocks in the future. It's future-proofing and also making code more
> generally usable.
>
> fpga_mgr_info is part of the interface for calls to fpga-mgr to do
> reprogramming. My patchset will push it further in that direction
> as pointers to the image are added to fpga_mgr_info.
>
> Adding 'priv' to fpga_mgr_info makes that interface specific to a this driver.
> It's better to add a region_id variable to fpga_mgr_info that may not be used by
> all fpga-mgr drivers. The current model is that a fpga-mgr driver checks
> fpga_mgr_info flags to see if its correct. The fpga-mgr driver can check
> any other needed fpga_mgr_info variables and return error if the params
> look invalid. And ignore any it doesn't need.
>
> I don't think priv belongs in fpga_image_info. priv tends to be information
> for a specific instance of a driver that can have several instances. priv
> usually stores a driver's memory mappings, interrupts, etc for that instance.
> It's called private info as it is info that other blocks don't need to know
> and don't get to look at. It's private. So priv as in interface strikes me as
> not private any more and is sort of a red flag.
>
> Alan
Besides that, I see that region_id is needed both for the fme_pr and
for determining which port to disable/enable. So adding it to the
fpga_image_info would allow the fpga-region to figure out which
bridge to control as well as pass it to the mgr.
>
>>
>> If you prefer the region_id for fpga_image_info, we can go with region_id
>> for sure. : )
>>
>> Thanks
>> Hao
next prev parent reply other threads:[~2017-04-05 15:40 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 12:08 [PATCH 00/16] Intel FPGA Device Drivers Wu Hao
2017-03-30 12:08 ` [PATCH 01/16] docs: fpga: add a document for Intel FPGA driver overview Wu Hao
2017-03-31 18:24 ` matthew.gerlach
2017-03-31 18:38 ` Alan Tull
2017-04-01 11:16 ` Wu Hao
2017-04-02 14:41 ` Moritz Fischer
2017-04-03 20:44 ` Alan Tull
2017-04-04 5:24 ` Wu Hao
2017-04-04 5:06 ` Wu Hao
2017-04-11 18:02 ` Alan Tull
2017-04-12 3:22 ` Wu, Hao
2017-03-30 12:08 ` [PATCH 02/16] fpga: add FPGA device framework Wu Hao
2017-03-31 6:09 ` Greg KH
2017-03-31 7:48 ` Wu Hao
2017-03-31 9:03 ` Greg KH
2017-03-31 12:19 ` Wu Hao
2017-03-31 19:01 ` matthew.gerlach
2017-04-01 12:18 ` Wu Hao
2017-07-25 21:32 ` Alan Tull
2017-07-26 9:50 ` Wu Hao
2017-07-26 14:20 ` Alan Tull
2017-07-26 22:29 ` Alan Tull
2017-07-27 4:54 ` Wu Hao
2017-03-31 6:13 ` Greg KH
[not found] ` <82D7661F83C1A047AF7DC287873BF1E167C90F1B@SHSMSX101.ccr.corp.intel.com>
2017-03-31 13:31 ` Wu Hao
2017-03-31 14:10 ` Greg KH
2017-04-01 11:36 ` Wu Hao
2017-03-30 12:08 ` [PATCH 03/16] fpga: intel: add FPGA PCIe device driver Wu Hao
2017-04-04 2:10 ` Moritz Fischer
2017-04-05 13:14 ` Wu, Hao
2017-03-30 12:08 ` [PATCH 04/16] fpga: intel: pcie: parse feature list and create platform device for features Wu Hao
2017-04-03 21:44 ` Alan Tull
2017-04-05 11:58 ` Wu Hao
2017-04-11 20:21 ` Alan Tull
2017-04-13 4:12 ` Wu, Hao
2017-04-04 2:44 ` Moritz Fischer
2017-04-05 12:57 ` Wu Hao
2017-04-04 22:09 ` Alan Tull
2017-04-05 14:09 ` Wu Hao
2017-05-04 15:13 ` Li, Yi
2017-05-05 3:03 ` Wu Hao
2017-03-30 12:08 ` [PATCH 05/16] fpga: intel: pcie: add chardev support for feature devices Wu Hao
2017-03-30 12:08 ` [PATCH 06/16] fpga: intel: pcie: adds fpga_for_each_port callback for fme device Wu Hao
2017-03-30 12:08 ` [PATCH 07/16] fpga: intel: add feature device infrastructure Wu Hao
2017-03-30 12:08 ` [PATCH 08/16] fpga: intel: add FPGA Management Engine driver basic framework Wu Hao
2017-03-30 12:08 ` [PATCH 09/16] fpga: intel: fme: add header sub feature support Wu Hao
2017-03-30 12:08 ` [PATCH 10/16] fpga: intel: fme: add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support Wu Hao
2017-03-30 12:08 ` [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub feature support Wu Hao
2017-03-30 20:30 ` Alan Tull
2017-03-31 4:11 ` Xiao Guangrong
2017-03-31 8:50 ` Wu Hao
2017-04-03 20:26 ` Alan Tull
2017-04-04 5:25 ` Wu Hao
2017-03-31 19:10 ` Alan Tull
2017-04-01 11:08 ` Wu Hao
2017-04-03 16:30 ` Alan Tull
2017-04-04 6:05 ` Wu Hao
2017-04-04 22:37 ` Alan Tull
2017-04-05 11:40 ` Wu, Hao
2017-04-05 15:26 ` Alan Tull
2017-04-05 15:39 ` Alan Tull [this message]
2017-04-06 10:57 ` Wu Hao
2017-04-06 19:27 ` Alan Tull
2017-04-07 5:56 ` Wu Hao
2017-03-31 23:45 ` kbuild test robot
2017-04-01 1:12 ` kbuild test robot
2017-04-03 21:24 ` Alan Tull
2017-04-03 22:49 ` matthew.gerlach
2017-04-04 6:48 ` Wu Hao
2017-04-04 6:28 ` Wu Hao
2017-03-30 12:08 ` [PATCH 12/16] fpga: intel: add FPGA Accelerated Function Unit driver basic framework Wu Hao
2017-03-30 12:08 ` [PATCH 13/16] fpga: intel: afu: add header sub feature support Wu Hao
2017-03-30 12:08 ` [PATCH 14/16] fpga: intel: afu add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support Wu Hao
2017-03-30 12:08 ` [PATCH 15/16] fpga: intel: afu: add user afu sub feature support Wu Hao
2017-03-30 12:08 ` [PATCH 16/16] fpga: intel: afu: add FPGA_PORT_DMA_MAP/UNMAP ioctls support Wu Hao
2017-04-01 0:00 ` kbuild test robot
2017-04-01 1:33 ` kbuild test robot
2017-03-30 17:17 ` [PATCH 00/16] Intel FPGA Device Drivers Moritz Fischer
2017-04-06 20:27 ` Jerome Glisse
2017-04-11 19:38 ` Luebbers, Enno
2017-04-12 13:29 ` Jerome Glisse
2017-04-12 14:46 ` Moritz Fischer
2017-04-12 15:37 ` Jerome Glisse
2017-04-14 19:48 ` Luebbers, Enno
2017-04-14 20:49 ` Jerome Glisse
2017-04-17 15:35 ` Alan Tull
2017-04-17 15:57 ` Jerome Glisse
2017-04-17 16:22 ` Alan Tull
2017-04-17 17:15 ` Jerome Glisse
2017-04-18 13:36 ` Alan Cox
2017-04-18 14:59 ` Jerome Glisse
2017-04-25 20:02 ` One Thousand Gnomes
2017-05-01 16:41 ` Jerome Glisse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANk1AXQb3tHZXqfaPNZLCtsqrn=-85ARdn0WXcrehV9HONmpSg@mail.gmail.com' \
--to=atull@kernel.org \
--cc=alan.tull@intel.com \
--cc=christopher.rauer@intel.com \
--cc=enno.luebbers@intel.com \
--cc=guangrong.xiao@linux.intel.com \
--cc=hao.wu@intel.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luwei.kang@intel.com \
--cc=moritz.fischer@ettus.com \
--cc=shiva.rao@intel.com \
--cc=tim.whisonant@intel.com \
--cc=yi.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).