On Fri, 04 Sep 2015, Peter Griffin wrote: > On Fri, 04 Sep 2015, Lee Jones wrote: > > [...] > > > > > > If yes, is it worth having a generic binding? > > > > > > If we decide it is a good idea, then yes. It doesn't look that hard to > > > arrive at something common. > > > > > > Strictly speaking, the firmware name is just an agreed upon name > > > between the kernel and userspace. So why tie that into DT? Would other > > > OS's use it or want something different? What if we started including > > > paths in the names like <soc>/<firmware file>? Now we are imposing a > > > directory structure on the OS filesystem. > > > > In Linux we have a standard place for firmwares, so the path should > > not be required. I certainly agree that DT is no place for absolute > > paths or OS'isums. > > > > [...] > > > > > > Presumably the alternative would be to add a whole bunch of compatibles > > > > in the driver for each SoC, where the only difference from a > > > > functional point of view would be to help build the correct string for > > > > the firmware filename. However I'm also then wondering what the best way > > > > would be to find out the instance name of the IP. > > > > > > If the name/path is Linux specific, then that is probably what we should do. > > > > > > You could perhaps make a policy that firmware files be named by > > > compatible string. So rather than translating from matching compatible > > > to an arbitrary file name, you enforce file name is "<vendor>,<ip > > > block>.fw" or something. I know we don't have policy in the kernel, > > > but we already have it with hardcoded file names and search paths. > > > > Absolutely not. Firmwares have no direct link to DT or platforms that > > run DT specifically. They are carried by most platforms these days. > > Insisting on firmwares using a DT compatible string format is way off. > > > > If we flip it the other way round, some subsystems derive the firmware > > name from the 'node name'. For instance, our zeroth General Purpose > > Co-Processor RemoteProc driver has a corresponding node called > > 'st231-gp0@40000000'. RemoteProc adds an 'rproc-' prefix and a '-fw' > > suffix and et voilà, we load file: > > > > lib/firmware/rproc-st231-gp0-fw > > IMO deriving from the node name seems fragile. Also imposing a linux'ism > "rproc" prefix on the firmware name doesn't seem correct as the firmwares > can be shared across OS's. Although this is how remoteproc subsys core > is currently working. It seems a generic DT firmware binding would actually > be most useful for the remoteproc subsystem. The "rproc-%s-fw", where %s == driver name, is only a fall-back. The RProc driver is welcome to supply a different firmware name if it desires. This is where I think a generic 'firmware' property would be of use. > I guess I should also comment about this on the ST remoteproc thread. > > I'm curious though as to how the ST remoteproc driver then loads the firmware, > as that name doesn't look like a video or audio firmware filename that I've > seen shipped from ST. IIRC Usually it is named something like > > vid_firmware-stih407.elf or audio_firmware-bd-stih407.elf This driver came direct from ST. I'm using their conventions as a default, although I would be happy to conduct some investigation into how this works for releases and suggest a better interface. The only reason I mentioned it here was because this is how others are using other SS which are similar in some way. Same for the Firmware SS I guess. In my unbiased PoV, I'd much prefer the name was derived from a predefined properly. > IMO we should be treating the firmware as a blackbox, and for me that also > includes the filename it is shipped with. Linux drivers making up their own > firmware names based on the name of their subsystem doesn't seem like a > good way forward to me. I guess the driver author was just using the fall-back convention for testing. I'm pretty sure RemoteProc isn't being shipped in products yet. > Presumably to test this driver you have to rename the firmwares > locally on your machine? The firmware that was provided to conduct testing was already named as expected by the driver, but yes, if we were to test the firmwares you mentioned they would either have to be renamed, or those names would have to be provided to the RemoteProc SS in a different way. > > > > We could do it by parsing the node name e.g. fdma0-audio, or by adding > > > > a "instance" DT property to the node? > > > > > > Generally we try to avoid caring about node names. Having some index > > > or numbering also comes up which we also try to avoid. Generally, if > > > you care about which instance you use for something, then there is > > > some property you care about and should add. > > > > Right, the alternative is a property like the ones already used. > > However, as these are becoming more prevalent I suggested > > standardising the property to avoid all these vendor specific firmware > > properties cluttering up the place. > > I agree a proliferation of vendor specific firmware properties isn't > s good way forward. > > > firmware = "firmwarename.fw"; > > OR > > firmware-name = "firmwarename.fw"; > > > > ... seems appropriate. > > Either of those is fine with me. Just need a DT nod and I'll happily code it up. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
