Re: st_fdma: Firmware filename in DT?

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Friday 04 September 2015, Lee Jones wrote:
> On Fri, 04 Sep 2015, Arnd Bergmann wrote:
> 
> > On Friday 04 September 2015, Lee Jones wrote:
> > > > > 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.
> > 
> > The firmware file name is agreed on between the device driver and the
> > file system, so encoding the linux driver name in it seems appropriate.
> > 
> > Generally speaking, I'd say a good policy would be to try basing
> > the firmware name on the "compatible" property strings. That property
> > already contains a hierarchical list of models, which makes it particularly
> > easy to have firmware files for specific models or those that are shared
> > across multiple variations if necessary. Just ask for the most specific
> > compatible string first and try the more specific compatible strings
> > (with an appropriate prefix and/or postfix added by the driver) until
> > a file is found.
> 
> It depends what you mean by "basing the firmware name on the
> \"compatible\" property" here.  If you mean actually renaming the
> firmware binary file to match a driver's compatible string, that's
> absolutely out of the question.  Firmwares are not only OS agnostic,
> but are also independent of any H/W description language a particular
> OS or platform might be using.  Using DT'isums to rename these
> binaries is not logical.
> 

I was thinking of naming the firmware and the compatible string the
same, and often enough that makes sense when both names are picked
by the same person. However, you make a good point that there are cases
where the firmware file already has a name based on some other
decision process and there may be good reasons not to rename the
file. In that case a driver writer can do a lookup table from
one to the other.

The downside of a lookup table of course is that you have to modify
the driver for each new firmware, but then again a lot of drivers
already require that, and others can come up with a policy that lets
you do a programmatic mapping from one to the other by picking
clever compatible strings.

> However, if you mean simply match on compatible string and supply the
> name from within the driver, that's closer to the mark (as then we can
> at least keep it in-house [kernel]), but it's still not particularly
> practical for the aforementioned reasons mentioned by Peter earlier.
> 
> Why not just create a new 'firmware' property?  Simples! [0]
> 
> [0] http://www.oxforddictionaries.com/definition/english/simples

My main thought was that loading a different firmware practically
always means that the device behaves in a (sometimes more, sometimes
less) different way, and we want to reflect that with a different
compatible string. Having a 1:1 relation between the two strings
enforces this.

	Arnd