On Thu, 19 Feb 2015, Michal Simek wrote:
> On 02/17/2015 08:17 PM, Pavel Machek wrote:
> > On Tue 2015-02-17 11:07:53, Rob Landley wrote:
> >>
> >>
> >> On 02/15/2015 04:40 PM, Pavel Machek wrote:
> >>> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
> On Wed, Jan 21, 2015 at 06:33:12PM +0
On 02/17/2015 08:17 PM, Pavel Machek wrote:
> On Tue 2015-02-17 11:07:53, Rob Landley wrote:
>>
>>
>> On 02/15/2015 04:40 PM, Pavel Machek wrote:
>>> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
My point is that the
On Tue 2015-02-17 11:07:53, Rob Landley wrote:
>
>
> On 02/15/2015 04:40 PM, Pavel Machek wrote:
> > On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
> >> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> >> My point is that the current firmware layer is overly cautious and
>
On Sun, Feb 15, 2015 at 11:40:06PM +0100, Pavel Machek wrote:
> > So keeping that much memory pinned in the kernel when I can prove it
> > is uncessary for my system (either because there is no suspend/resume
> > possibility, or because I know the CPU can always access the
> > filesytem) is very u
On 02/15/2015 04:40 PM, Pavel Machek wrote:
> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
>> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
>> My point is that the current firmware layer is overly cautious and
>> FPGAs are very big. My current project on small Xilinx de
On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> > Hi Alan,
> >
> > > On Jan 21, 2015, at 18:01 , One Thousand Gnomes
> > > wrote:
> > >
> > > On Thu, 15 Jan 2015 22:54:46 +0200
> > > Pantelis Antoniou wrote:
> > >
> > >
Hi Jason,
> On Jan 21, 2015, at 22:27 , Jason Gunthorpe
> wrote:
>
> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
>> Hi Alan,
>>
>>> On Jan 21, 2015, at 18:01 , One Thousand Gnomes
>>> wrote:
>>>
>>> On Thu, 15 Jan 2015 22:54:46 +0200
>>> Pantelis Antoniou wrote:
>>>
On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> Hi Alan,
>
> > On Jan 21, 2015, at 18:01 , One Thousand Gnomes
> > wrote:
> >
> > On Thu, 15 Jan 2015 22:54:46 +0200
> > Pantelis Antoniou wrote:
> >
> >> Hi Alan,
> >>
> >>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes
Hi Alan,
> On Jan 21, 2015, at 18:01 , One Thousand Gnomes
> wrote:
>
> On Thu, 15 Jan 2015 22:54:46 +0200
> Pantelis Antoniou wrote:
>
>> Hi Alan,
>>
>>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes
>>> wrote:
>>>
>>> On Thu, 15 Jan 2015 11:47:26 -0700
>>> Jason Gunthorpe wrote:
On Thu, 15 Jan 2015 22:54:46 +0200
Pantelis Antoniou wrote:
> Hi Alan,
>
> > On Jan 15, 2015, at 22:45 , One Thousand Gnomes
> > wrote:
> >
> > On Thu, 15 Jan 2015 11:47:26 -0700
> > Jason Gunthorpe wrote:
> >> It is a novel idea, my concern would be that embedding the FPGA in the
> >> DT ma
Hi!
> I'm looking into moving the sysfs interface to debugfs. Doesn't look too
> hard and you and Alan are making lots of sense about this.
Debugfs: please don't. That's meant for debugging, not for production
use.
Pavel
--
On Tue 2015-01-13 16:21:33, One Thousand Gnomes wrote:
> On Mon, 12 Jan 2015 11:06:08 -0700
> Jason Gunthorpe wrote:
>
> > On Sun, Jan 11, 2015 at 10:29:00AM -0600, atull wrote:
> > > the FPGA image. If someone wants there to be only one FPGA image on
> > > the FGPA forever, they will probably n
On Thu, Jan 15, 2015 at 08:45:02PM +, One Thousand Gnomes wrote:
> > - Hand over to a DT overlay (how does this work?) Lock transfers
> > from FD to kernel
>
> That bit isn't stateful so I would actually have expected something in
> the kernel ABI along the lines of
>
>request
Hi Alan,
> On Jan 15, 2015, at 22:45 , One Thousand Gnomes
> wrote:
>
> On Thu, 15 Jan 2015 11:47:26 -0700
> Jason Gunthorpe wrote:
>> It is a novel idea, my concern would be that embedding the FPGA in the
>> DT makes it permanent unswappable kernel memory.
>> Not having the kernel hold the FP
On Thu, 15 Jan 2015 11:47:26 -0700
Jason Gunthorpe wrote:
> It is a novel idea, my concern would be that embedding the FPGA in the
> DT makes it permanent unswappable kernel memory.
> Not having the kernel hold the FPGA is best for many uses.
If you have a filesysytem before the FPGA is set up th
On Thu, Jan 15, 2015 at 10:34:39AM -0600, atull wrote:
> This is great! The way I had it working was using Pantelis' devicetree
> configfs interface.
I figured you were very close to this already in your overlay work..
> The DT fragment described the FPGA logic and included a filename
> for fi
On Tue, 13 Jan 2015, Jason Gunthorpe wrote:
> On Tue, Jan 13, 2015 at 03:37:14PM -0600, atull wrote:
>
> > > I do agree with this, and I think this is where this patch set goes so
> > > wrong.
> > >
> > > Just exposing all sorts of controls to userspace and having a way for
> > > the kernel to l
On Thu, Jan 15, 2015 at 11:36:17AM +, One Thousand Gnomes wrote:
> yes - there is a model for this in Linux already. Some of the audio
> subsystems have "firmware" files distributed which are actually a
> structured file that userspace parses to get a real set of firmware for
> the controller
On Wed, 14 Jan 2015 11:12:58 -0700
Jason Gunthorpe wrote:
> On Wed, Jan 14, 2015 at 04:06:17PM +, One Thousand Gnomes wrote:
>
> > and I think you effectively have the user usage covered here for such
> > things. It much like GPIO pins - we can describe them but we can also
> > declare they
Hi Jason,
> On Jan 14, 2015, at 20:12 , Jason Gunthorpe
> wrote:
>
> On Wed, Jan 14, 2015 at 04:06:17PM +, One Thousand Gnomes wrote:
>
>> and I think you effectively have the user usage covered here for such
>> things. It much like GPIO pins - we can describe them but we can also
>> decla
On Wed, Jan 14, 2015 at 04:06:17PM +, One Thousand Gnomes wrote:
> and I think you effectively have the user usage covered here for such
> things. It much like GPIO pins - we can describe them but we can also
> declare they are not visible to the user.
A missing element in mainline is a kind
> The request_firmware interface should be for the DT overlay path, and
> other schemes shouldn't use it. The name should come from the DT and
> no place else.
For the static bindings agreed (or ACPI but that's a detail) or other
dynamic discovery post boot.
> 2) The bootloader starts the kernel
> Those people have failed to show up and provide input and/or code.
That doesn't excuse failing to design the code properly.
>
> >> It is one thing to context switch a maths algorithm that is built to
> >> be stateless, it is quite another to context switch between, say an
> >> ethernet core wi
On Tue, Jan 13, 2015 at 03:37:14PM -0600, atull wrote:
> > I do agree with this, and I think this is where this patch set goes so
> > wrong.
> >
> > Just exposing all sorts of controls to userspace and having a way for
> > the kernel to load/unload a bitstream compleletely misses the point that
>
On Tue, 13 Jan 2015, Jason Gunthorpe wrote:
> On Tue, Jan 13, 2015 at 04:28:47PM +, One Thousand Gnomes wrote:
>
> > There is a lot of code overlap in things like loading the bitstreams,
> > there is also some overlap because you want to be able to assign FPGA
> > resources. For example if yo
On Tue, Jan 13, 2015 at 04:28:47PM +, One Thousand Gnomes wrote:
> There is a lot of code overlap in things like loading the bitstreams,
> there is also some overlap because you want to be able to assign FPGA
> resources. For example if you have four FPGAs and you want to use one for
> OS stuf
On Tue, 13 Jan 2015, Pantelis Antoniou wrote:
> Hi Alan,
>
> > On Jan 13, 2015, at 18:28 , One Thousand Gnomes
> > wrote:
> >
> > On Mon, 12 Jan 2015 14:43:14 -0700
> > Jason Gunthorpe wrote:
> >
> >> On Mon, Jan 12, 2015 at 09:01:34PM +, One Thousand Gnomes wrote:
> >>> There are plenty
Hi Alan,
> On Jan 13, 2015, at 18:28 , One Thousand Gnomes
> wrote:
>
> On Mon, 12 Jan 2015 14:43:14 -0700
> Jason Gunthorpe wrote:
>
>> On Mon, Jan 12, 2015 at 09:01:34PM +, One Thousand Gnomes wrote:
>>> There are plenty of people today who treat the FPGA as an entirely
>>> dynamic reso
On Tue, 13 Jan 2015, Pavel Machek wrote:
> On Tue 2015-01-13 09:40:18, Pantelis Antoniou wrote:
> > Hi Pavel,
> >
> > > On Jan 13, 2015, at 09:28 , Pavel Machek wrote:
> > >
> > > Hi!
> > >
> > >> +What: /sys/class/fpga_manager//firmware
> > >> +Date: Octobe
On Mon, 12 Jan 2015 14:43:14 -0700
Jason Gunthorpe wrote:
> On Mon, Jan 12, 2015 at 09:01:34PM +, One Thousand Gnomes wrote:
> > There are plenty of people today who treat the FPGA as an entirely
> > dynamic resource. It's not like flashing a controller, its near
> > immediate.
>
> But this
On Mon, 12 Jan 2015 11:06:08 -0700
Jason Gunthorpe wrote:
> On Sun, Jan 11, 2015 at 10:29:00AM -0600, atull wrote:
> > the FPGA image. If someone wants there to be only one FPGA image on
> > the FGPA forever, they will probably not be using this framework; their
> > FPGA will probably be loaded
On Tue 2015-01-13 09:40:18, Pantelis Antoniou wrote:
> Hi Pavel,
>
> > On Jan 13, 2015, at 09:28 , Pavel Machek wrote:
> >
> > Hi!
> >
> >> +What: /sys/class/fpga_manager//firmware
> >> +Date: October 2014
> >> +KernelVersion:3.18
> >>
Hi Pavel,
> On Jan 13, 2015, at 09:28 , Pavel Machek wrote:
>
> Hi!
>
>> +What: /sys/class/fpga_manager//firmware
>> +Date: October 2014
>> +KernelVersion: 3.18
>> +Contact:Alan Tull
>> +Description:Name of th
Hi!
> +What: /sys/class/fpga_manager//firmware
> +Date: October 2014
> +KernelVersion: 3.18
> +Contact:Alan Tull
> +Description:Name of the FPGA image file to load using
> firmware
> class
On Mon, Jan 12, 2015 at 09:01:34PM +, One Thousand Gnomes wrote:
> There are plenty of people today who treat the FPGA as an entirely
> dynamic resource. It's not like flashing a controller, its near
> immediate.
But this is a completely different use case. Remember, there are
*megabytes* of i
> Then configure udev to load right firmware for you, or ln -s
> image-i-want-now socfpga-fpga-image to select the one to read...?
Your conceptual model is wrong. FPGA firmware is dynamic. There are
already people who lazy reload FPGA firmware on taskswitches. This
proposed fpga manager is broken
On Sun, Jan 11, 2015 at 10:29:00AM -0600, atull wrote:
> the FPGA image. If someone wants there to be only one FPGA image on
> the FGPA forever, they will probably not be using this framework; their
> FPGA will probably be loaded before Linux boots up.
Nonsense, loading the FPGA through Linux is
On Mon, Jan 12, 2015 at 10:05:49AM -0600, Rob Herring wrote:
> On Sun, Jan 11, 2015 at 10:29 AM, atull wrote:
> > Previous uses of the firmware layer has been to use it to load once after
> > bootup; this is different since some use cases will want to switch out
> > the FPGA image. If someone wa
On Sun, Jan 11, 2015 at 10:29 AM, atull wrote:
> On Sat, 10 Jan 2015, Pavel Machek wrote:
>
>> On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
>> > Hi Pavel,
>> >
>> > > On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
>> > >
>> > > On Fri 2015-01-09 13:14:24, atull wrote:
>> > >> On Wed, 7 Ja
On 01/12/2015 09:45 AM, Pavel Machek wrote:
> On Sun 2015-01-11 10:29:00, atull wrote:
>> On Sat, 10 Jan 2015, Pavel Machek wrote:
>>
>>> On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
Hi Pavel,
> On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
>
> On Fri 2015-01-09 13:1
On Sun 2015-01-11 10:29:00, atull wrote:
> On Sat, 10 Jan 2015, Pavel Machek wrote:
>
> > On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
> > > Hi Pavel,
> > >
> > > > On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
> > > >
> > > > On Fri 2015-01-09 13:14:24, atull wrote:
> > > >> On Wed, 7
On Sat, 10 Jan 2015, Pavel Machek wrote:
> On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
> > Hi Pavel,
> >
> > > On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
> > >
> > > On Fri 2015-01-09 13:14:24, atull wrote:
> > >> On Wed, 7 Jan 2015, Pavel Machek wrote:
> > >>
> > >>> On Tue 2015-
On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
> Hi Pavel,
>
> > On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
> >
> > On Fri 2015-01-09 13:14:24, atull wrote:
> >> On Wed, 7 Jan 2015, Pavel Machek wrote:
> >>
> >>> On Tue 2015-01-06 14:13:37, at...@opensource.altera.com wrote:
> +
Hi Pavel,
> On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
>
> On Fri 2015-01-09 13:14:24, atull wrote:
>> On Wed, 7 Jan 2015, Pavel Machek wrote:
>>
>>> On Tue 2015-01-06 14:13:37, at...@opensource.altera.com wrote:
+
+What: /sys/class/fpga_manager//firmware
+Date:
On Fri 2015-01-09 13:14:24, atull wrote:
> On Wed, 7 Jan 2015, Pavel Machek wrote:
>
> > On Tue 2015-01-06 14:13:37, at...@opensource.altera.com wrote:
> > > +
> > > +What:/sys/class/fpga_manager//firmware
> > > +Date:October 2014
> > > +KernelVersion: 3.18
> > > +Contact
On Wed, 7 Jan 2015, Pavel Machek wrote:
> On Tue 2015-01-06 14:13:37, at...@opensource.altera.com wrote:
> > +
> > +What: /sys/class/fpga_manager//firmware
> > +Date: October 2014
> > +KernelVersion: 3.18
> > +Contact: Alan Tull
> > +Description: Name of the
On Tue 2015-01-06 14:13:37, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Add documentation under drivers/staging for new fpga manager's
> sysfs interface.
>
> Signed-off-by: Alan Tull
> ---
> v5 : (actually second version, but keeping version numbers
> aligned with rest of pa
From: Alan Tull
Add documentation under drivers/staging for new fpga manager's
sysfs interface.
Signed-off-by: Alan Tull
---
v5 : (actually second version, but keeping version numbers
aligned with rest of patch series)
Move document to drivers/staging/fpga/Documentation/ABI
v6 :
48 matches
Mail list logo
