Re: st_fdma: Firmware filename in DT?

[Daniel Thompson <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On 04/09/15 11:21, Lee Jones wrote:
>>> 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.

Hmnnn... That default looks really inappropriate for the ST platforms!

Different generations of the hardware have co-processors with similar 
roles (and hence all with names like st231-gp0) but its very rare for 
the co-processors to have the same firmware binary.

Thus if the default were applied naively we will end up with a bizarre 
situation where the kernel is multi-platform but because the kernel does 
not select a unique name for the different firmwares, it becomes 
needlessly difficult for the userspace to support multiple platforms.

If there was a generic firmware property for this kind of situation it 
is fairly natural to note in the bindings docs the importance of 
uniqueness through the generations regarding of the choice of name.

There are other ways a driver can generate a unique name as the 
generations of chip develop (compatible strings actually very good for 
this) but I don't see it fitting quite so naturally into the binding 
docs where it can help future adventurers.


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

Both for fdma and co-processors, it is important that the kernel (or 
kernel informed by DT properties/compatible strings) is "assertive" 
enough to choose names that are sufficiently unique.

That is far more important than honoring vendor filenames.

Vendor filenames could easily be both too simple ("firmware.bin") or too 
detailed ("fdma-foo+bar-v1.8_20140811.fw"; the DT should not be encoding 
the version number of a firmware loaded from userspace since its not a 
fixed property of the platform).


Daniel.