lkml.org 
[lkml]   [2013]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] fpga: Introduce new fpga subsystem
From
Date
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 wants, right? To most
> > users, fpga bitstream is just a firmware.
>
> It is one nice way how to get data from one place to another and
> it is easy to handle. Using different methods is also possible.
>
> >> 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?
> >
> > https://www.kernel.org/doc/Documentation/firmware_class/README
> >
> > 4), userspace:
> > - hotplug: cat appropriate_firmware_image > \
> > /sys/class/firmware/xxx/data
> >
> > I assume udev's firmware.sh could be modified to add headers.
> >
> > But... if same bitstream is expected to work across multiple FPGAs (is
> > it?) maybe kernel should hide that difference and provide headers
> > itself.
>
> There could be a configuration where you want to load one bitstream
> to more fpgas with the same type. I can imagine this system and use cases.
>
> Thanks,
> Michal
>
>
Hi Michael,

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.

I see my helper script get called, but I don't see 'loading' and 'data'
show up under /sys. I have CONFIG_FW_LOADER_USER_HELPER=y enabled and
have done enough printf debugging to see that there was no failure in
creating the attributes as far as firmware_class.c is concerned.

More details:
I'm taking cues from Documentation/firmware_class here.
This is with the 3.11 kernel.
I have CONFIG_FW_LOADER_USER_HELPER=y enabled.
I have this udev rule:
SUBSYSTEM=="firmware", ACTION=="add", RUN+="/lib/udev/hotplug-script"
My hotplug-script is linux/Documentation/firmware_class/hotplug-script

What I am seeing when I request 'image.rbf' is that my hotplug-script
gets run with this DEVPATH set:
DEVPATH == /devices/soc.0/ff706000.fpgamgr/fpga/fpga0/image.rbf

I added debug to my hotplug-script and it could not find 'loading' or
'data' appearing under /sys anywhere when it got called. According to
the firmware_class/README, these should appear under
/sys/class/firmware. However according to the
firmware_class/hotplug-script, they should be under /sys/$DEVPATH.

When I look at firmware_class.c, that code wants these attributes
to show up under the firmware class. Again, with printf debugging,
I don't see firmware_class.c being unhappy until it decides it has
timed out (which happens quickly).

I was wondering what behavior you were seeing with userspace helpers.

Alan





\
 
 \ /
  Last update: 2013-09-20 23:21    [W:0.241 / U:7.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site