Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/