Re: st_fdma: Firmware filename in DT?

[Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

Hi Lee,

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.

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

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. Presumably to test this driver you have to rename the
firmwares locally on your machine?

> 
> > > 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.

regards,

Peter.