Re: st_fdma: Firmware filename in DT?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux