On 09/30/2013 07:12 PM, Jason Gunthorpe wrote:
> On Fri, Sep 27, 2013 at 03:31:53PM +0200, Michal Simek wrote:
>
>> I expect that you are detecting/specifying in the driver which
>> fpga is connected and you also need to know size of this device.
>> Then your driver allocate buffer with this size
On 09/30/2013 07:12 PM, Jason Gunthorpe wrote:
On Fri, Sep 27, 2013 at 03:31:53PM +0200, Michal Simek wrote:
I expect that you are detecting/specifying in the driver which
fpga is connected and you also need to know size of this device.
Then your driver allocate buffer with this size in the
On Fri, Sep 27, 2013 at 03:31:53PM +0200, Michal Simek wrote:
> I expect that you are detecting/specifying in the driver which
> fpga is connected and you also need to know size of this device.
> Then your driver allocate buffer with this size in the kernel
> and streming data to this buffer.
On Fri, Sep 27, 2013 at 03:31:53PM +0200, Michal Simek wrote:
I expect that you are detecting/specifying in the driver which
fpga is connected and you also need to know size of this device.
Then your driver allocate buffer with this size in the kernel
and streming data to this buffer. When
Hi Jason,
On 09/18/2013 10:32 PM, Jason Gunthorpe wrote:
> On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
>
>> + Jason Gunthorpe
>
> Thanks, looks interesting, we could possibly use this interface if it
> met our needs..
>
>> On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal
Hi Jason,
On 09/18/2013 10:32 PM, Jason Gunthorpe wrote:
On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
+ Jason Gunthorpe
Thanks, looks interesting, we could possibly use this interface if it
met our needs..
On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
> >
> > For the Zynq based product I am working on, we encourage the end user to
> > create their own bitstreams to customize their application. So we need
> > an easy way for the user to load a bitstream. cat foo.bin > /dev/xdevcfg
> > works well for us.
>
> You probably don't care if this will
> >
> > * Add this udev rule:
> >SUBSYSTEM=="firmware", ACTION=="add", RUN+="/lib/udev/hotplug-script"
> >
> > * Check that there aren't other 'firmware' udev rules to get in the
> > way.
>
> Hm, don't do that, all "modern" distros will not do firmware loading
> through udev anymore, so
On 09/25/2013 03:55 PM, Yves Vandervennet wrote:
> Greg,
>
>>> The default hotplug-script doesn't do anything special (that the kernel
>>> couldn't do by itself). What's great is that it could call another
>>> script that adds headers or does whatever other special un-gzipping or
>>> other
On 09/25/2013 04:27 PM, Philip Balister wrote:
> On 09/25/2013 08:00 AM, Pavel Machek wrote:
>> Hi!
>>
> The firmware approach is interesting. It might be less flexible
> compared with my original code (see link to git below) that this is
On the other hand... that's the
On 09/25/2013 08:00 AM, Pavel Machek wrote:
> Hi!
>
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
>>>
>>> On the other hand... that's the interface world wants, right? To most
>>> users, fpga
Greg,
>> The default hotplug-script doesn't do anything special (that the kernel
>> couldn't do by itself). What's great is that it could call another
>> script that adds headers or does whatever other special un-gzipping or
>> other massaging that the firmware image needs before it gets loaded.
Hi!
> >> The firmware approach is interesting. It might be less flexible
> >> compared with my original code (see link to git below) that this is
> >
> > On the other hand... that's the interface world wants, right? To most
> > users, fpga bitstream is just a firmware.
> >
>
> No, not really.
On 09/23/2013 07:10 PM, Jason Gunthorpe wrote:
> On Mon, Sep 23, 2013 at 03:10:11PM +0200, Michal Simek wrote:
>
>>> 1) The driver doesn't know what firmware to request. It just knows
>>>how to send it to a FPGA.
>>
>> But dts property in the manager driver which uses this as end driver
>>
Hi,
On 09/25/2013 12:54 AM, H. Peter Anvin wrote:
> On 09/19/2013 03:08 AM, Pavel Machek wrote:
>>
>>> The firmware approach is interesting. It might be less flexible
>>> compared with my original code (see link to git below) that this is
>>
>> On the other hand... that's the interface world
Hi,
On 09/25/2013 12:54 AM, H. Peter Anvin wrote:
On 09/19/2013 03:08 AM, Pavel Machek wrote:
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
On the other hand... that's the interface world wants, right? To
On 09/23/2013 07:10 PM, Jason Gunthorpe wrote:
On Mon, Sep 23, 2013 at 03:10:11PM +0200, Michal Simek wrote:
1) The driver doesn't know what firmware to request. It just knows
how to send it to a FPGA.
But dts property in the manager driver which uses this as end driver
can know that.
Hi!
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
On the other hand... that's the interface world wants, right? To most
users, fpga bitstream is just a firmware.
No, not really.
The typical
Greg,
The default hotplug-script doesn't do anything special (that the kernel
couldn't do by itself). What's great is that it could call another
script that adds headers or does whatever other special un-gzipping or
other massaging that the firmware image needs before it gets loaded.
Only
On 09/25/2013 08:00 AM, Pavel Machek wrote:
Hi!
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
On the other hand... that's the interface world wants, right? To most
users, fpga bitstream is just a
On 09/25/2013 04:27 PM, Philip Balister wrote:
On 09/25/2013 08:00 AM, Pavel Machek wrote:
Hi!
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
On the other hand... that's the interface world wants, right?
On 09/25/2013 03:55 PM, Yves Vandervennet wrote:
Greg,
The default hotplug-script doesn't do anything special (that the kernel
couldn't do by itself). What's great is that it could call another
script that adds headers or does whatever other special un-gzipping or
other massaging that the
* Add this udev rule:
SUBSYSTEM==firmware, ACTION==add, RUN+=/lib/udev/hotplug-script
* Check that there aren't other 'firmware' udev rules to get in the
way.
Hm, don't do that, all modern distros will not do firmware loading
through udev anymore, so please don't try to add
For the Zynq based product I am working on, we encourage the end user to
create their own bitstreams to customize their application. So we need
an easy way for the user to load a bitstream. cat foo.bin /dev/xdevcfg
works well for us.
You probably don't care if this will be
cat
On 09/19/2013 03:08 AM, Pavel Machek wrote:
>
>> The firmware approach is interesting. It might be less flexible
>> compared with my original code (see link to git below) that this is
>
> On the other hand... that's the interface world wants, right? To most
> users, fpga bitstream is just a
On Tue, Sep 24, 2013 at 11:22:54AM -0500, Alan Tull wrote:
> Yes, I could see /sys/class/fpga/fpga0/image.rbf/loading and 'data' and
> a few others (If I was requesting to load 'image.rbf'). It's a nice
> interface.
>
> I just used the linux/Documentation/firmware_class/hotplug-script
> without
On Tue, 2013-09-24 at 17:58 +0200, Michal Simek wrote:
> Hi,
>
> On 09/24/2013 05:55 PM, Alan Tull wrote:
> >
> >> I have ported the altera fpga manager driver to work with your version
> >> of the fpga manager framework. It works fine if I use the
> >> firmware_class.c's built-in support to
Hi,
On 09/24/2013 05:55 PM, Alan Tull wrote:
>
>> I have ported the altera fpga manager driver to work with your version
>> of the fpga manager framework. It works fine if I use the
>> firmware_class.c's built-in support to load the firmware, but not with a
>> userspace helper.
>>
>
>
> Hi
> I have ported the altera fpga manager driver to work with your version
> of the fpga manager framework. It works fine if I use the
> firmware_class.c's built-in support to load the firmware, but not with a
> userspace helper.
>
Hi Michal,
I cleaned up my udev rules and now I see the
I have ported the altera fpga manager driver to work with your version
of the fpga manager framework. It works fine if I use the
firmware_class.c's built-in support to load the firmware, but not with a
userspace helper.
Hi Michal,
I cleaned up my udev rules and now I see the userspace
Hi,
On 09/24/2013 05:55 PM, Alan Tull wrote:
I have ported the altera fpga manager driver to work with your version
of the fpga manager framework. It works fine if I use the
firmware_class.c's built-in support to load the firmware, but not with a
userspace helper.
Hi Michal,
I
On Tue, 2013-09-24 at 17:58 +0200, Michal Simek wrote:
Hi,
On 09/24/2013 05:55 PM, Alan Tull wrote:
I have ported the altera fpga manager driver to work with your version
of the fpga manager framework. It works fine if I use the
firmware_class.c's built-in support to load the
On Tue, Sep 24, 2013 at 11:22:54AM -0500, Alan Tull wrote:
Yes, I could see /sys/class/fpga/fpga0/image.rbf/loading and 'data' and
a few others (If I was requesting to load 'image.rbf'). It's a nice
interface.
I just used the linux/Documentation/firmware_class/hotplug-script
without
On 09/19/2013 03:08 AM, Pavel Machek wrote:
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
On the other hand... that's the interface world wants, right? To most
users, fpga bitstream is just a firmware.
On Mon, Sep 23, 2013 at 03:10:11PM +0200, Michal Simek wrote:
> > 1) The driver doesn't know what firmware to request. It just knows
> >how to send it to a FPGA.
>
> But dts property in the manager driver which uses this as end driver
> can know that.
I think the device tree maintainers
On 09/19/2013 07:28 PM, Jason Gunthorpe wrote:
> On Thu, Sep 19, 2013 at 10:18:03AM -0500, Yves Vandervennet wrote:
>> On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek wrote:
>>
Is there some way a per-device userspace helper can be added that can
handle adding the headers? Such that
On 09/19/2013 05:18 PM, Yves Vandervennet wrote:
> On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek wrote:
>
>>> Is there some way a per-device userspace helper can be added that can
>>> handle adding the headers? Such that different fpga types get different
>>> helpers?
>>
>> What do you exactly
On 09/19/2013 05:18 PM, Yves Vandervennet wrote:
On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek mon...@monstr.eu wrote:
Is there some way a per-device userspace helper can be added that can
handle adding the headers? Such that different fpga types get different
helpers?
What do you exactly
On 09/19/2013 07:28 PM, Jason Gunthorpe wrote:
On Thu, Sep 19, 2013 at 10:18:03AM -0500, Yves Vandervennet wrote:
On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek mon...@monstr.eu wrote:
Is there some way a per-device userspace helper can be added that can
handle adding the headers? Such that
On Mon, Sep 23, 2013 at 03:10:11PM +0200, Michal Simek wrote:
1) The driver doesn't know what firmware to request. It just knows
how to send it to a FPGA.
But dts property in the manager driver which uses this as end driver
can know that.
I think the device tree maintainers would push
On Thu, 2013-09-19 at 13:02 +0200, Michal Simek wrote:
> On 09/19/2013 12:08 PM, Pavel Machek wrote:
> > Hi!
> >
> >> The firmware approach is interesting. It might be less flexible
> >> compared with my original code (see link to git below) that this is
> >
> > On the other hand... that's the
On Thu, 2013-09-19 at 13:02 +0200, Michal Simek wrote:
On 09/19/2013 12:08 PM, Pavel Machek wrote:
Hi!
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
On the other hand... that's the interface world
On Thu 2013-09-19 07:37:15, Greg KH wrote:
> On Thu, Sep 19, 2013 at 10:20:48AM -0400, Jason Cooper wrote:
> > On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
> > > On 09/19/2013 04:06 PM, Greg KH wrote:
> > > > On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
> > > >>
On Thu, Sep 19, 2013 at 10:18:03AM -0500, Yves Vandervennet wrote:
> On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek wrote:
>
> >> Is there some way a per-device userspace helper can be added that can
> >> handle adding the headers? Such that different fpga types get different
> >> helpers?
> >
>
> >> +/**
> >> + * fpga_mgr_attr_read - Read data from fpga
> >> + * @dev: Pointer to the device structure
> >> + * @attr: Pointer to the device attribute structure
> >> + * @buf: Pointer to the buffer location
> >> + *
> >> + * Function reads fpga bitstream and copy them to output buffer
> >> +
On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek wrote:
>> Is there some way a per-device userspace helper can be added that can
>> handle adding the headers? Such that different fpga types get different
>> helpers?
>
> What do you exactly mean by that? Any example what do you want to achieve?
Bit
On Thu, 2013-09-19 at 07:18 -0700, Greg KH wrote:
> On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
> > On 09/19/2013 04:06 PM, Greg KH wrote:
> > > On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
> > >> On Thu 2013-09-19 13:22:00, Michal Simek wrote:
> > >>> On
On 09/19/2013 04:42 PM, Yves Vandervennet wrote:
> HI Michal.,
>
>
> On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek wrote:
>
>>
>>
Will this framework handle more than one fpga at a time?
>>
>>> I didn't tried that because I don't have any suitable hw for this on my
>> desk
>>> but I there
On Thu, Sep 19, 2013 at 10:20:48AM -0400, Jason Cooper wrote:
> On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
> > On 09/19/2013 04:06 PM, Greg KH wrote:
> > > On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
> > >> On Thu 2013-09-19 13:22:00, Michal Simek wrote:
> >
On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
> On 09/19/2013 04:06 PM, Greg KH wrote:
> > On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
> >> On Thu 2013-09-19 13:22:00, Michal Simek wrote:
> >>> On 09/19/2013 01:17 PM, Pavel Machek wrote:
> >>
> > Status is
On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
> On 09/19/2013 04:06 PM, Greg KH wrote:
> > On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
> >> On Thu 2013-09-19 13:22:00, Michal Simek wrote:
> >>> On 09/19/2013 01:17 PM, Pavel Machek wrote:
> >>
> > Status is
On 09/19/2013 04:06 PM, Greg KH wrote:
> On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
>> On Thu 2013-09-19 13:22:00, Michal Simek wrote:
>>> On 09/19/2013 01:17 PM, Pavel Machek wrote:
>>
> Status is just there and for my zynq devcfg driver I do export some status
> bits.
On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
> On Thu 2013-09-19 13:22:00, Michal Simek wrote:
> > On 09/19/2013 01:17 PM, Pavel Machek wrote:
>
> > >> Status is just there and for my zynq devcfg driver I do export some
> > >> status
> > >> bits.
> > >>
> > >> root@petalinux:~#
On Thu 2013-09-19 13:22:00, Michal Simek wrote:
> On 09/19/2013 01:17 PM, Pavel Machek wrote:
> >> Status is just there and for my zynq devcfg driver I do export some status
> >> bits.
> >>
> >> root@petalinux:~# cat /sys/class/fpga/fpga0/status
> >> partial_bitstream_status: 0
> >>
On 09/18/2013 09:02 PM, Dinh Nguyen wrote:
> Hi Michal,
>
> On Wed, 2013-09-18 at 17:56 +0200, Michal Simek wrote:
>> This new subsystem should unify all fpga drivers which
>> do the same things. Load configuration data to fpga
>> or another programmable logic through common interface.
>> It
Hi Ryan,
On 09/19/2013 01:45 AM, Ryan Mallon wrote:
> On 19/09/13 01:56, Michal Simek wrote:
>> This new subsystem should unify all fpga drivers which
>> do the same things. Load configuration data to fpga
>> or another programmable logic through common interface.
>> It doesn't matter if it is
On 09/19/2013 01:17 PM, Pavel Machek wrote:
> Hi!
>
>>> This code also creates a set of files under /sys for each separate fpga.
>>> I.e. checking status by looking at /sys/class/fpga/fpag0/status. It
>>> would be pretty small changes to control reseting the fpga by adding a
>>> 'reset' file
Hi!
> > This code also creates a set of files under /sys for each separate fpga.
> > I.e. checking status by looking at /sys/class/fpga/fpag0/status. It
> > would be pretty small changes to control reseting the fpga by adding a
> > 'reset' file there also (added first to the framework, and an
On 09/19/2013 12:08 PM, Pavel Machek wrote:
> Hi!
>
>> The firmware approach is interesting. It might be less flexible
>> compared with my original code (see link to git below) that this is
>
> On the other hand... that's the interface world wants, right? To most
> users, fpga bitstream is just
Hi Alan,
On 09/18/2013 11:17 PM, Alan Tull wrote:
> On Wed, 2013-09-18 at 14:32 -0600, Jason Gunthorpe wrote:
>> On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
>>
>>> + Jason Gunthorpe
>>
>> Thanks, looks interesting, we could possibly use this interface if it
>> met our needs..
Hi Jason,
On 09/18/2013 10:32 PM, Jason Gunthorpe wrote:
> On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
>
>> + Jason Gunthorpe
>
> Thanks, looks interesting, we could possibly use this interface if it
> met our needs..
That will be great.
>
>> On Wed, Sep 18, 2013 at
Hi!
> The firmware approach is interesting. It might be less flexible
> compared with my original code (see link to git below) that this is
On the other hand... that's the interface world wants, right? To most
users, fpga bitstream is just a firmware.
> Is there some way a per-device userspace
Hi!
> > + Jason Gunthorpe
>
> Thanks, looks interesting, we could possibly use this interface if it
> met our needs..
>
> > On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
> > > This new subsystem should unify all fpga drivers which
> > > do the same things. Load configuration
Hi Joe,
On 09/18/2013 06:11 PM, Joe Perches wrote:
> On Wed, 2013-09-18 at 17:56 +0200, Michal Simek wrote:
>> This new subsystem should unify all fpga drivers which
>> do the same things. Load configuration data to fpga
>> or another programmable logic through common interface.
>> It doesn't
Hi Joe,
On 09/18/2013 06:11 PM, Joe Perches wrote:
On Wed, 2013-09-18 at 17:56 +0200, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter if it
Hi!
+ Jason Gunthorpe
Thanks, looks interesting, we could possibly use this interface if it
met our needs..
On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
Hi!
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
On the other hand... that's the interface world wants, right? To most
users, fpga bitstream is just a firmware.
Is there some way a per-device userspace
Hi Jason,
On 09/18/2013 10:32 PM, Jason Gunthorpe wrote:
On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
+ Jason Gunthorpe
Thanks, looks interesting, we could possibly use this interface if it
met our needs..
That will be great.
On Wed, Sep 18, 2013 at 05:56:39PM
Hi Alan,
On 09/18/2013 11:17 PM, Alan Tull wrote:
On Wed, 2013-09-18 at 14:32 -0600, Jason Gunthorpe wrote:
On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
+ Jason Gunthorpe
Thanks, looks interesting, we could possibly use this interface if it
met our needs..
On Wed, Sep
On 09/19/2013 12:08 PM, Pavel Machek wrote:
Hi!
The firmware approach is interesting. It might be less flexible
compared with my original code (see link to git below) that this is
On the other hand... that's the interface world wants, right? To most
users, fpga bitstream is just a
Hi!
This code also creates a set of files under /sys for each separate fpga.
I.e. checking status by looking at /sys/class/fpga/fpag0/status. It
would be pretty small changes to control reseting the fpga by adding a
'reset' file there also (added first to the framework, and an interface
On 09/19/2013 01:17 PM, Pavel Machek wrote:
Hi!
This code also creates a set of files under /sys for each separate fpga.
I.e. checking status by looking at /sys/class/fpga/fpag0/status. It
would be pretty small changes to control reseting the fpga by adding a
'reset' file there also (added
Hi Ryan,
On 09/19/2013 01:45 AM, Ryan Mallon wrote:
On 19/09/13 01:56, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter if it is MMIO
On 09/18/2013 09:02 PM, Dinh Nguyen wrote:
Hi Michal,
On Wed, 2013-09-18 at 17:56 +0200, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter
On Thu 2013-09-19 13:22:00, Michal Simek wrote:
On 09/19/2013 01:17 PM, Pavel Machek wrote:
Status is just there and for my zynq devcfg driver I do export some status
bits.
root@petalinux:~# cat /sys/class/fpga/fpga0/status
partial_bitstream_status: 0
prog_done_status: 1
On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
On Thu 2013-09-19 13:22:00, Michal Simek wrote:
On 09/19/2013 01:17 PM, Pavel Machek wrote:
Status is just there and for my zynq devcfg driver I do export some
status
bits.
root@petalinux:~# cat
On 09/19/2013 04:06 PM, Greg KH wrote:
On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
On Thu 2013-09-19 13:22:00, Michal Simek wrote:
On 09/19/2013 01:17 PM, Pavel Machek wrote:
Status is just there and for my zynq devcfg driver I do export some status
bits.
On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
On 09/19/2013 04:06 PM, Greg KH wrote:
On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
On Thu 2013-09-19 13:22:00, Michal Simek wrote:
On 09/19/2013 01:17 PM, Pavel Machek wrote:
Status is just there and for my
On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
On 09/19/2013 04:06 PM, Greg KH wrote:
On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
On Thu 2013-09-19 13:22:00, Michal Simek wrote:
On 09/19/2013 01:17 PM, Pavel Machek wrote:
Status is just there and for my
On Thu, Sep 19, 2013 at 10:20:48AM -0400, Jason Cooper wrote:
On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
On 09/19/2013 04:06 PM, Greg KH wrote:
On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
On Thu 2013-09-19 13:22:00, Michal Simek wrote:
On 09/19/2013
On 09/19/2013 04:42 PM, Yves Vandervennet wrote:
HI Michal.,
On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek mon...@monstr.eu wrote:
Will this framework handle more than one fpga at a time?
I didn't tried that because I don't have any suitable hw for this on my
desk
but I there
On Thu, 2013-09-19 at 07:18 -0700, Greg KH wrote:
On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
On 09/19/2013 04:06 PM, Greg KH wrote:
On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
On Thu 2013-09-19 13:22:00, Michal Simek wrote:
On 09/19/2013 01:17 PM,
On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek mon...@monstr.eu wrote:
Is there some way a per-device userspace helper can be added that can
handle adding the headers? Such that different fpga types get different
helpers?
What do you exactly mean by that? Any example what do you want to
+/**
+ * fpga_mgr_attr_read - Read data from fpga
+ * @dev: Pointer to the device structure
+ * @attr: Pointer to the device attribute structure
+ * @buf: Pointer to the buffer location
+ *
+ * Function reads fpga bitstream and copy them to output buffer
+ *
+ * Returns the
On Thu, Sep 19, 2013 at 10:18:03AM -0500, Yves Vandervennet wrote:
On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek mon...@monstr.eu wrote:
Is there some way a per-device userspace helper can be added that can
handle adding the headers? Such that different fpga types get different
helpers?
On Thu 2013-09-19 07:37:15, Greg KH wrote:
On Thu, Sep 19, 2013 at 10:20:48AM -0400, Jason Cooper wrote:
On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
On 09/19/2013 04:06 PM, Greg KH wrote:
On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
On Thu
On 19/09/13 01:56, Michal Simek wrote:
> This new subsystem should unify all fpga drivers which
> do the same things. Load configuration data to fpga
> or another programmable logic through common interface.
> It doesn't matter if it is MMIO device, gpio bitbanging,
> etc. connection. The point is
On Wed, 2013-09-18 at 14:32 -0600, Jason Gunthorpe wrote:
> On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
>
> > + Jason Gunthorpe
>
> Thanks, looks interesting, we could possibly use this interface if it
> met our needs..
>
> > On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal
On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
> + Jason Gunthorpe
Thanks, looks interesting, we could possibly use this interface if it
met our needs..
> On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
> > This new subsystem should unify all fpga drivers which
>
+ Jason Gunthorpe
On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
> This new subsystem should unify all fpga drivers which
> do the same things. Load configuration data to fpga
> or another programmable logic through common interface.
> It doesn't matter if it is MMIO device, gpio
Hi Michal,
On Wed, 2013-09-18 at 17:56 +0200, Michal Simek wrote:
> This new subsystem should unify all fpga drivers which
> do the same things. Load configuration data to fpga
> or another programmable logic through common interface.
> It doesn't matter if it is MMIO device, gpio bitbanging,
>
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter if it is MMIO device, gpio bitbanging,
etc. connection. The point is to have the same
inteface for these drivers.
On Wed, 2013-09-18 at 17:56 +0200, Michal Simek wrote:
> This new subsystem should unify all fpga drivers which
> do the same things. Load configuration data to fpga
> or another programmable logic through common interface.
> It doesn't matter if it is MMIO device, gpio bitbanging,
> etc.
On Wed, 2013-09-18 at 17:56 +0200, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter if it is MMIO device, gpio bitbanging,
etc. connection.
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter if it is MMIO device, gpio bitbanging,
etc. connection. The point is to have the same
inteface for these drivers.
Hi Michal,
On Wed, 2013-09-18 at 17:56 +0200, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter if it is MMIO device, gpio bitbanging,
etc.
+ Jason Gunthorpe
On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter if it is MMIO device, gpio
On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
+ Jason Gunthorpe
Thanks, looks interesting, we could possibly use this interface if it
met our needs..
On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do
On Wed, 2013-09-18 at 14:32 -0600, Jason Gunthorpe wrote:
On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
+ Jason Gunthorpe
Thanks, looks interesting, we could possibly use this interface if it
met our needs..
On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek
On 19/09/13 01:56, Michal Simek wrote:
This new subsystem should unify all fpga drivers which
do the same things. Load configuration data to fpga
or another programmable logic through common interface.
It doesn't matter if it is MMIO device, gpio bitbanging,
etc. connection. The point is to
100 matches
Mail list logo
