On Tue, Feb 21, 2017 at 12:33 PM, Alan Tull wrote:
> On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer
> wrote:
>> Hi Alan,
>>
>> On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull
>> wrote:
>>> On Sun, Feb 19, 2017 at
On Tue, Feb 21, 2017 at 12:33 PM, Alan Tull wrote:
> On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer
> wrote:
>> Hi Alan,
>>
>> On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull
>> wrote:
>>> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull
>>> wrote:
On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
On Mon, 27 Feb 2017, Moritz Fischer wrote:
Alan,
On Mon, Feb 27, 2017 at 12:09 PM, Alan Tull 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
On Mon, 27 Feb 2017, Moritz Fischer wrote:
Alan,
On Mon, Feb 27, 2017 at 12:09 PM, Alan Tull 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:
Alan,
On Mon, Feb 27, 2017 at 12:09 PM, Alan Tull 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 +
Alan,
On Mon, Feb 27, 2017 at 12:09 PM, Alan Tull 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
On Wed, Feb 22, 2017 at 9:54 AM, Jason Gunthorpe
wrote:
> On Wed, Feb 22, 2017 at 09:50:54AM -0800, Moritz Fischer wrote:
>
>> > For instance, we could mark Encrypted as required, and a zynq driver
>> > that does not support the Encrypted tag would not load the
On Wed, Feb 22, 2017 at 9:54 AM, Jason Gunthorpe
wrote:
> On Wed, Feb 22, 2017 at 09:50:54AM -0800, Moritz Fischer wrote:
>
>> > For instance, we could mark Encrypted as required, and a zynq driver
>> > that does not support the Encrypted tag would not load the bitfile
>> > rather than try to
On Wed, Feb 22, 2017 at 09:50:54AM -0800, Moritz Fischer wrote:
> > For instance, we could mark Encrypted as required, and a zynq driver
> > that does not support the Encrypted tag would not load the bitfile
> > rather than try to load it wrongly.
>
> Funny you'd mention that. Thanks to your
On Wed, Feb 22, 2017 at 09:50:54AM -0800, Moritz Fischer wrote:
> > For instance, we could mark Encrypted as required, and a zynq driver
> > that does not support the Encrypted tag would not load the bitfile
> > rather than try to load it wrongly.
>
> Funny you'd mention that. Thanks to your
Jason,
On Wed, Feb 22, 2017 at 8:44 AM, Jason Gunthorpe
wrote:
> On Tue, Feb 21, 2017 at 10:05:42PM -0800, Moritz Fischer wrote:
>
>> That being said older drivers / fpga-mgr will not deal with newer features.
>> TLV / KV or whatever doesn't change this fact, or
Jason,
On Wed, Feb 22, 2017 at 8:44 AM, Jason Gunthorpe
wrote:
> On Tue, Feb 21, 2017 at 10:05:42PM -0800, Moritz Fischer wrote:
>
>> That being said older drivers / fpga-mgr will not deal with newer features.
>> TLV / KV or whatever doesn't change this fact, or am I missing something?
>
>
On Wed, Feb 22, 2017 at 10:44 AM, Moritz Fischer
wrote:
> On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull wrote:
>> On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
>> wrote:
>>
>> Hi Moritz,
>>
>>> Hi all,
>>>
>>> On
On Wed, Feb 22, 2017 at 10:44 AM, Moritz Fischer
wrote:
> On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull wrote:
>> On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
>> wrote:
>>
>> Hi Moritz,
>>
>>> Hi all,
>>>
>>> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
>>> wrote:
On Tue, Feb 21,
On Tue, Feb 21, 2017 at 10:05:42PM -0800, Moritz Fischer wrote:
> That being said older drivers / fpga-mgr will not deal with newer features.
> TLV / KV or whatever doesn't change this fact, or am I missing something?
Often a scheme will have an OPTIONAL and REQUIRED flag for each
value. If a
On Tue, Feb 21, 2017 at 10:05:42PM -0800, Moritz Fischer wrote:
> That being said older drivers / fpga-mgr will not deal with newer features.
> TLV / KV or whatever doesn't change this fact, or am I missing something?
Often a scheme will have an OPTIONAL and REQUIRED flag for each
value. If a
On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull wrote:
> On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
> wrote:
>
> Hi Moritz,
>
>> Hi all,
>>
>> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
>> wrote:
>>>
On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull wrote:
> On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
> wrote:
>
> Hi Moritz,
>
>> Hi all,
>>
>> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
>> wrote:
>>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>>>
fdt does this
On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
wrote:
Hi Moritz,
> Hi all,
>
> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
> wrote:
>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>>
>>> fdt does this out of
On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
wrote:
Hi Moritz,
> Hi all,
>
> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
> wrote:
>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>>
>>> fdt does this out of the box, too. So far I've seen nothing fdt
>>> couldn't do
On Tue, Feb 21, 2017 at 9:46 PM, Nadathur, Sundar
wrote:
> On February 21, 2017 9:39 PM, Moritz Fischer wrote:
>
>> TLV Seems easy enough. To give an update, I played with fdt a bit to see how
>> far I get in half an hour. I got bool / int / strings to work quite fast
On Tue, Feb 21, 2017 at 9:46 PM, Nadathur, Sundar
wrote:
> On February 21, 2017 9:39 PM, Moritz Fischer wrote:
>
>> TLV Seems easy enough. To give an update, I played with fdt a bit to see how
>> far I get in half an hour. I got bool / int / strings to work quite fast
>> (~30mins).
>> Please
On February 21, 2017 9:39 PM, Moritz Fischer wrote:
> TLV Seems easy enough. To give an update, I played with fdt a bit to see how
> far I get in half an hour. I got bool / int / strings to work quite fast
> (~30mins).
> Please disregard the horrible hackyness of this ...
> [...]
> So I'm fairly
On February 21, 2017 9:39 PM, Moritz Fischer wrote:
> TLV Seems easy enough. To give an update, I played with fdt a bit to see how
> far I get in half an hour. I got bool / int / strings to work quite fast
> (~30mins).
> Please disregard the horrible hackyness of this ...
> [...]
> So I'm fairly
Hi all,
On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
wrote:
> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>
>> fdt does this out of the box, too. So far I've seen nothing fdt
>> couldn't do (or doesn't do let's rather say).
>
>
Hi all,
On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
wrote:
> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>
>> fdt does this out of the box, too. So far I've seen nothing fdt
>> couldn't do (or doesn't do let's rather say).
>
> tlv/fdt/http headers are all essentially
On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
> fdt does this out of the box, too. So far I've seen nothing fdt
> couldn't do (or doesn't do let's rather say).
tlv/fdt/http headers are all essentially exactly the same
thing. Key/value pairs with various encoding schemes.
I
On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
> fdt does this out of the box, too. So far I've seen nothing fdt
> couldn't do (or doesn't do let's rather say).
tlv/fdt/http headers are all essentially exactly the same
thing. Key/value pairs with various encoding schemes.
I
Hi Sundar,
On Tue, Feb 21, 2017 at 7:13 PM, Nadathur, Sundar
wrote:
>> >>> Is there a standard you are looking at? Have you seen any use of
>> >>> TLV's in the Linux kernel you could point to?
>
> Here are some examples of TLVs in the Linux kernel:
>
Hi Sundar,
On Tue, Feb 21, 2017 at 7:13 PM, Nadathur, Sundar
wrote:
>> >>> Is there a standard you are looking at? Have you seen any use of
>> >>> TLV's in the Linux kernel you could point to?
>
> Here are some examples of TLVs in the Linux kernel:
>
derven...@linux.intel.com>; Jason Gunthorpe
> <jguntho...@obsidianresearch.com>; matthew.gerl...@linux.intel.com;
> linux-kernel <linux-kernel@vger.kernel.org>; linux-f...@vger.kernel.org;
> Marek Vašut <ma...@denx.de>
> Subject: Re: [RFC 7/8] fpga-region: add sy
nux-f...@vger.kernel.org;
> Marek Vašut
> Subject: Re: [RFC 7/8] fpga-region: add sysfs interface
>
> On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer
> wrote:
> > Hi Alan,
> >
> > On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull
> wrote:
> >> On Sun, Feb 19, 20
On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer
wrote:
> Hi Alan,
>
> On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull wrote:
>> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull
>> wrote:
>>> On Sat, Feb 18, 2017 at 2:45 PM,
On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer
wrote:
> Hi Alan,
>
> On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull wrote:
>> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull
>> wrote:
>>> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
>>> wrote:
On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan
Hi Alan,
On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull wrote:
> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull wrote:
>> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
>> wrote:
>>> On Sat, Feb 18, 2017 at 02:10:43PM
Hi Alan,
On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull wrote:
> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull wrote:
>> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
>> wrote:
>>> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull wrote:
> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
> wrote:
>> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
>>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
>>>
On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull wrote:
> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
> wrote:
>> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
>>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
>>> wrote:
>>>
>>> > Hi all,
>>> >Interesting discussion. The
On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
wrote:
> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
>> wrote:
>>
>> > Hi all,
>> >Interesting discussion. The discussion
On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
wrote:
> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
>> wrote:
>>
>> > Hi all,
>> >Interesting discussion. The discussion so far has brought out many
>> > concerns such as OS
On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
> wrote:
>
> > Hi all,
> >Interesting discussion. The discussion so far has brought out many
> > concerns such as OS independence. There is an existing
On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
> wrote:
>
> > Hi all,
> >Interesting discussion. The discussion so far has brought out many
> > concerns such as OS independence. There is an existing format, well-known
> > to
On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
wrote:
> Hi all,
>Interesting discussion. The discussion so far has brought out many
> concerns such as OS independence. There is an existing format, well-known to
> developers, with widespread support, and which
On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
wrote:
> Hi all,
>Interesting discussion. The discussion so far has brought out many
> concerns such as OS independence. There is an existing format, well-known to
> developers, with widespread support, and which is quite extensible:
>
On February 17, 2017 6:30 PM, Moritz Fischer wrote:
On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote:
> Moritz,
>
> whatever solution we decide to go with has to work with other OS'es.
> The last thing we want to do is to have wrappers that are Linux specific.
I do agree
On February 17, 2017 6:30 PM, Moritz Fischer wrote:
On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote:
> Moritz,
>
> whatever solution we decide to go with has to work with other OS'es.
> The last thing we want to do is to have wrappers that are Linux specific.
I do agree
On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote:
> Moritz,
>
> whatever solution we decide to go with has to work with other OS'es. The
> last thing we want to do is to have wrappers that are Linux specific.
I do agree that we should make sure the format is reasonably well
On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote:
> Moritz,
>
> whatever solution we decide to go with has to work with other OS'es. The
> last thing we want to do is to have wrappers that are Linux specific.
I do agree that we should make sure the format is reasonably well
Moritz,
whatever solution we decide to go with has to work with other OS'es. The
last thing we want to do is to have wrappers that are Linux specific.
Yves
On Wed, 15 Feb 2017, Moritz Fischer wrote:
>>Hi Jason,
>>
>>On Wed, Feb 15, 2017 at 12:37 PM, Jason Gunthorpe
Moritz,
whatever solution we decide to go with has to work with other OS'es. The
last thing we want to do is to have wrappers that are Linux specific.
Yves
On Wed, 15 Feb 2017, Moritz Fischer wrote:
>>Hi Jason,
>>
>>On Wed, Feb 15, 2017 at 12:37 PM, Jason Gunthorpe
>> wrote:
>>> On Wed, Feb
On Thu, Feb 16, 2017 at 9:56 AM, Jason Gunthorpe
wrote:
> On Thu, Feb 16, 2017 at 11:47:08AM -0600, Alan Tull wrote:
>
>> > Just to clarify: I was proposing using the binary format of dts,
>> > not actually requiring devicetree for it to work. There's plenty
>> >
On Thu, Feb 16, 2017 at 9:56 AM, Jason Gunthorpe
wrote:
> On Thu, Feb 16, 2017 at 11:47:08AM -0600, Alan Tull wrote:
>
>> > Just to clarify: I was proposing using the binary format of dts,
>> > not actually requiring devicetree for it to work. There's plenty
>> > of people running u-boot on x86
On Thu, Feb 16, 2017 at 11:47:08AM -0600, Alan Tull wrote:
> > Just to clarify: I was proposing using the binary format of dts,
> > not actually requiring devicetree for it to work. There's plenty
> > of people running u-boot on x86 using FIT images to boot.
>
> The FPGA images should not be
On Thu, Feb 16, 2017 at 11:47:08AM -0600, Alan Tull wrote:
> > Just to clarify: I was proposing using the binary format of dts,
> > not actually requiring devicetree for it to work. There's plenty
> > of people running u-boot on x86 using FIT images to boot.
>
> The FPGA images should not be
On Wed, Feb 15, 2017 at 6:16 PM, Moritz Fischer
wrote:
> On Wed, Feb 15, 2017 at 2:42 PM, Alan Tull wrote:
>> On Wed, Feb 15, 2017 at 3:36 PM, Moritz Fischer
>> wrote:
>>> Jason,
>>>
>>> On Wed, Feb 15, 2017 at 1:15
On Wed, Feb 15, 2017 at 6:16 PM, Moritz Fischer
wrote:
> On Wed, Feb 15, 2017 at 2:42 PM, Alan Tull wrote:
>> On Wed, Feb 15, 2017 at 3:36 PM, Moritz Fischer
>> wrote:
>>> Jason,
>>>
>>> On Wed, Feb 15, 2017 at 1:15 PM, Jason Gunthorpe
>>> wrote:
On Wed, Feb 15, 2017 at 12:54:27PM -0800,
On Wed, Feb 15, 2017 at 2:42 PM, Alan Tull wrote:
> On Wed, Feb 15, 2017 at 3:36 PM, Moritz Fischer
> wrote:
>> Jason,
>>
>> On Wed, Feb 15, 2017 at 1:15 PM, Jason Gunthorpe
>> wrote:
>>> On Wed, Feb 15, 2017
On Wed, Feb 15, 2017 at 2:42 PM, Alan Tull wrote:
> On Wed, Feb 15, 2017 at 3:36 PM, Moritz Fischer
> wrote:
>> Jason,
>>
>> On Wed, Feb 15, 2017 at 1:15 PM, Jason Gunthorpe
>> wrote:
>>> On Wed, Feb 15, 2017 at 12:54:27PM -0800, Moritz Fischer wrote:
>>>
Well I don't know ;-) With
On Wed, Feb 15, 2017 at 04:49:58PM -0600, Alan Tull wrote:
> So this script takes the bitfile and its build logs as input, parses
> the build logs for image information, does some manipulations on bit
> order as needed, and adds the header. So it's really doing (at least)
> two things: adding
On Wed, Feb 15, 2017 at 04:49:58PM -0600, Alan Tull wrote:
> So this script takes the bitfile and its build logs as input, parses
> the build logs for image information, does some manipulations on bit
> order as needed, and adds the header. So it's really doing (at least)
> two things: adding
On Wed, Feb 15, 2017 at 1:49 PM, Jason Gunthorpe
wrote:
> On Wed, Feb 15, 2017 at 12:23:28PM -0600, Alan Tull wrote:
>> > This is usually the sort of stuff I'd punt to userspace, but since the
>> > kernel is doing request_firmware it is hard to see how that is an
On Wed, Feb 15, 2017 at 1:49 PM, Jason Gunthorpe
wrote:
> On Wed, Feb 15, 2017 at 12:23:28PM -0600, Alan Tull wrote:
>> > This is usually the sort of stuff I'd punt to userspace, but since the
>> > kernel is doing request_firmware it is hard to see how that is an
>> > option in this case...
>>
>>
On Wed, Feb 15, 2017 at 3:36 PM, Moritz Fischer
wrote:
> Jason,
>
> On Wed, Feb 15, 2017 at 1:15 PM, Jason Gunthorpe
> wrote:
>> On Wed, Feb 15, 2017 at 12:54:27PM -0800, Moritz Fischer wrote:
>>
>>> Well I don't know ;-) With something
On Wed, Feb 15, 2017 at 3:36 PM, Moritz Fischer
wrote:
> Jason,
>
> On Wed, Feb 15, 2017 at 1:15 PM, Jason Gunthorpe
> wrote:
>> On Wed, Feb 15, 2017 at 12:54:27PM -0800, Moritz Fischer wrote:
>>
>>> Well I don't know ;-) With something fdt based we already have
>>> parsers there,
>>
>> Not
Jason,
On Wed, Feb 15, 2017 at 1:15 PM, Jason Gunthorpe
wrote:
> On Wed, Feb 15, 2017 at 12:54:27PM -0800, Moritz Fischer wrote:
>
>> Well I don't know ;-) With something fdt based we already have
>> parsers there,
>
> Not sure.. How does incbin work in DTB?
>
>
Jason,
On Wed, Feb 15, 2017 at 1:15 PM, Jason Gunthorpe
wrote:
> On Wed, Feb 15, 2017 at 12:54:27PM -0800, Moritz Fischer wrote:
>
>> Well I don't know ;-) With something fdt based we already have
>> parsers there,
>
> Not sure.. How does incbin work in DTB?
>
> We have the FPGA in a s/g list so
Hi Jason,
On Wed, 15 Feb 2017 11:06:12 -0700
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
...
>The kernel could detect the bitfile starts with 'Linux_FPGA_BIT/1.0\n'
>and then proceed to decode the header providing compat with the
>current scheme.
>
>This is usually the sort of stuff
Hi Jason,
On Wed, 15 Feb 2017 11:06:12 -0700
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
...
>The kernel could detect the bitfile starts with 'Linux_FPGA_BIT/1.0\n'
>and then proceed to decode the header providing compat with the
>current scheme.
>
>This is usually the sort of stuff
On Wed, Feb 15, 2017 at 12:54:27PM -0800, Moritz Fischer wrote:
> Well I don't know ;-) With something fdt based we already have
> parsers there,
Not sure.. How does incbin work in DTB?
We have the FPGA in a s/g list so we cannot pass the entire file to
libfdt - is that consistent with incbin?
On Wed, Feb 15, 2017 at 12:54:27PM -0800, Moritz Fischer wrote:
> Well I don't know ;-) With something fdt based we already have
> parsers there,
Not sure.. How does incbin work in DTB?
We have the FPGA in a s/g list so we cannot pass the entire file to
libfdt - is that consistent with incbin?
Hi Jason,
On Wed, Feb 15, 2017 at 12:37 PM, Jason Gunthorpe
wrote:
> On Wed, Feb 15, 2017 at 12:07:15PM -0800, matthew.gerl...@linux.intel.com
> wrote:
>
>> The format of the meta data associated with a fpga bitstream is certainly a
>> subject on its own. HTTP
Hi Jason,
On Wed, Feb 15, 2017 at 12:37 PM, Jason Gunthorpe
wrote:
> On Wed, Feb 15, 2017 at 12:07:15PM -0800, matthew.gerl...@linux.intel.com
> wrote:
>
>> The format of the meta data associated with a fpga bitstream is certainly a
>> subject on its own. HTTP style plain text is definately
On Wed, Feb 15, 2017 at 12:07:15PM -0800, matthew.gerl...@linux.intel.com wrote:
> The format of the meta data associated with a fpga bitstream is certainly a
> subject on its own. HTTP style plain text is definately easy to understand
> and more importantly it is extendable. On the other hand,
On Wed, Feb 15, 2017 at 12:07:15PM -0800, matthew.gerl...@linux.intel.com wrote:
> The format of the meta data associated with a fpga bitstream is certainly a
> subject on its own. HTTP style plain text is definately easy to understand
> and more importantly it is extendable. On the other hand,
Hi Jason, Alan, and Moritz,
On Wed, 15 Feb 2017, Alan Tull wrote:
On Wed, Feb 15, 2017 at 12:06 PM, Jason Gunthorpe
wrote:
Hi Jason,
On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
I agree. I've heard some discussions about adding a header.
Hi Jason, Alan, and Moritz,
On Wed, 15 Feb 2017, Alan Tull wrote:
On Wed, Feb 15, 2017 at 12:06 PM, Jason Gunthorpe
wrote:
Hi Jason,
On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
I agree. I've heard some discussions about adding a header. We would
want it to not be
On Wed, Feb 15, 2017 at 12:23:28PM -0600, Alan Tull wrote:
> > This is usually the sort of stuff I'd punt to userspace, but since the
> > kernel is doing request_firmware it is hard to see how that is an
> > option in this case...
>
> I like how extensible (and readable!) this is. It wouldn't
On Wed, Feb 15, 2017 at 12:23:28PM -0600, Alan Tull wrote:
> > This is usually the sort of stuff I'd punt to userspace, but since the
> > kernel is doing request_firmware it is hard to see how that is an
> > option in this case...
>
> I like how extensible (and readable!) this is. It wouldn't
Hi Jason, Alan
On Wed, Feb 15, 2017 at 7:23 PM, Alan Tull wrote:
>> This is usually the sort of stuff I'd punt to userspace, but since the
>> kernel is doing request_firmware it is hard to see how that is an
>> option in this case...
>
> I like how extensible (and
Hi Jason, Alan
On Wed, Feb 15, 2017 at 7:23 PM, Alan Tull wrote:
>> This is usually the sort of stuff I'd punt to userspace, but since the
>> kernel is doing request_firmware it is hard to see how that is an
>> option in this case...
>
> I like how extensible (and readable!) this is. It
On Wed, Feb 15, 2017 at 12:06 PM, Jason Gunthorpe
wrote:
Hi Jason,
> On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
>> I agree. I've heard some discussions about adding a header. We would
>> want it to not be manufacturer or fpga device specific.
On Wed, Feb 15, 2017 at 12:06 PM, Jason Gunthorpe
wrote:
Hi Jason,
> On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
>> I agree. I've heard some discussions about adding a header. We would
>> want it to not be manufacturer or fpga device specific. That would be
>> nice and would
On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
> I agree. I've heard some discussions about adding a header. We would
> want it to not be manufacturer or fpga device specific. That would be
> nice and would eliminate some of this struct. We would need a tool to
> add the header,
On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
> I agree. I've heard some discussions about adding a header. We would
> want it to not be manufacturer or fpga device specific. That would be
> nice and would eliminate some of this struct. We would need a tool to
> add the header,
On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
> On Wed, Feb 15, 2017 at 11:21 AM, Jason Gunthorpe
> wrote:
> > On Wed, Feb 15, 2017 at 10:14:20AM -0600, Alan Tull wrote:
> >> Add a sysfs interface to control programming FPGA.
> >>
> >> Each
On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
> On Wed, Feb 15, 2017 at 11:21 AM, Jason Gunthorpe
> wrote:
> > On Wed, Feb 15, 2017 at 10:14:20AM -0600, Alan Tull wrote:
> >> Add a sysfs interface to control programming FPGA.
> >>
> >> Each fpga-region will get the following files
On Wed, Feb 15, 2017 at 11:21 AM, Jason Gunthorpe
wrote:
> On Wed, Feb 15, 2017 at 10:14:20AM -0600, Alan Tull wrote:
>> Add a sysfs interface to control programming FPGA.
>>
>> Each fpga-region will get the following files which set values
>> in the
On Wed, Feb 15, 2017 at 11:21 AM, Jason Gunthorpe
wrote:
> On Wed, Feb 15, 2017 at 10:14:20AM -0600, Alan Tull wrote:
>> Add a sysfs interface to control programming FPGA.
>>
>> Each fpga-region will get the following files which set values
>> in the fpga_image_info struct for that region. More
On Wed, Feb 15, 2017 at 10:14:20AM -0600, Alan Tull wrote:
> Add a sysfs interface to control programming FPGA.
>
> Each fpga-region will get the following files which set values
> in the fpga_image_info struct for that region. More files will
> need to be added as fpga_image_info expands.
>
>
On Wed, Feb 15, 2017 at 10:14:20AM -0600, Alan Tull wrote:
> Add a sysfs interface to control programming FPGA.
>
> Each fpga-region will get the following files which set values
> in the fpga_image_info struct for that region. More files will
> need to be added as fpga_image_info expands.
>
>
90 matches
Mail list logo