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 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 Sim
> >
> > 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 pl
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 massag
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
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
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
>> can
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 want
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 firm
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 m
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 loa
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 Mic
> 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 userspa
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 woul
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 diffe
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 m
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 i
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
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 09/19/20
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 just
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
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:~# c
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_stat
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
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 M
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 ther
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 int
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 05:56:
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 da
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 matt
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 S
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 b
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,
> et
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. connectio
49 matches
Mail list logo
