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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
