Hi,
Anything regarding this.
> My whole point has been that you register them from the main pruss
> driver
> based on run-time data instead of compile-time pre-configured stuff in
> the
> board file.
I'm not so sure - if the usage is fixed as a result of the pins on the
device being wired a CAN bus then it seems reasonable to tell the system
about that so it'll stop the user trying to run SPI or something against
it at runtime.
I'm mostly worried about the case where the pins are not hardwired for
some specific function -- Subhasish was mentioning that these may be
implemented using a pluggable extension board and I want to make sure
that you are not required to recompile the kernel when changing the
extension board.
However, you made a good point that in many cases it will be hardwired
so it may be valuable to preconfigure this in a way that does not require
scripts to set up variables in sysfs when you already know what is there.
Note that my suggestion to put the device name into the firmware file
covers this case, because you can then simply ship a firmware blob that
matches the hardware configuration. Thinking about the future device
tree setup, you can even put the firmware blob itself into a property
in the device tree file.
I earlier had an implementation where I used a pruss_devices structure
in the board file.
http://linux.omap.com/pipermail/davinci-linux-open-source/
2011-March/022339.html.
We can use this implementation along with the sysfs to load the devices
runtime. The configs that I have in the board_file for the devices
structure, are fixed for a board. To swap the boards, we do not need to
re-compile the kernel.
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
