Hi Sebastian On Thursday 18 September 2008, Sebastian Kuzminsky wrote: > The fundamental problem is the low-level board drivers need to support > multiple boards, and each board has multiple pwmgen and stepgen > instances etc, each of which will need its own configuration information > eventually. So really what's needed is an array of board-config > structures. Lacking that, a two-dimensional array for pwmgen configs, > another one for stepgens, etc, would work. But modparams dont support > either of those data structures. > > I could hack up something like this: > > "loadrt hm2_5i20 firmware0=hm2/5i20/SVST12.BIT > firmware1=hm2/5i20/SVST8_4.BIT encoder_enable0=1,1 > encoder_enable0=0,0,0,0,0,0,0,0 encoder_index0=1,0 > stepgen_enable1=1,1,0,0 stepgen_width1=2,2"
There is a limit on the line length passed to a module, and once you start talking about passing large number of parameters, things get messy. > That's not exactly pretty either, but maybe it's better than the > alternatives. > > You (JMK & SWP) solved this configuration problem by (iirc) adding an > "r" chunk to the bit files, but I dont like that, I think the config > should be separate from the FPGA firmware. eeww... Any samples of this in the current code base ? > I considered putting the config info in a separate file and let the user > supply the filename as a modparam, the driver would request_firmware() > to pull it in and parse it in kernel space. That's pretty gross though, > the user would have to put the file in /lib/firmware, and writing a > config-file parser in kernel space will not make me any friends. :-/ You won't win friends by dumping configuration files in /lib/firmware (they should be in /etc/). Nor do you want to be doing config parsing in kernel space, but then you already know that ;- > What's there now is essentially that, except the file contents are > passed in in the "config" modparam, and the kernel driver parses *that*. Last time I looked at some of the "parsing code", it was buggy and open to serious abuse. Fortunately, the kernel already provides a mechanism for copying data to/from user space that doesn't involve hijacking the firmware subsystem. Seeing as your driver(s) will only work with 2.6.x series kernels, you can maximise the use of the newer hooks for passing data. --- Paul. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
