[PATCH] powerpc/fsl: add device tree binding for QE firmware

Timur Tabi timur at freescale.com
Fri Mar 26 01:42:24 EST 2010


On Wed, Mar 24, 2010 at 8:49 PM, Segher Boessenkool
<segher at kernel.crashing.org> wrote:

> I do; I consider that indirection thing (and putting firmware blobs
> in the device tree at all, but to a lesser extent) as making a mess
> of your device binding.

I guess we'll just have to agree to disagree.

> Let's forget that I do not like putting a firmware blob in the
> device tree if you can at all avoid that; Grant is on that already.

The initrd thing is a good idea, but it doesn't help non-Linux
operating systems.  Then again, those OS's might not have any GPL
issues, so it could be a moot point.

> As far as I can see, you want that indirection node so that you
> safe space in the DTB.

No, I want the indirection node so that I can have multiple QE nodes
point to the same binary data in the DTB.  I don't want to have to do
this:

qe at e8000000 {
    fsl,firmware = /incbin/("firmware-file-name.bin");
    ...
}

qe at e9000000 {
    fsl,firmware = /incbin/("firmware-file-name.bin");
    ...
}

In this case, I have an SOC with two QE devices, so it has two QE
nodes.  Each needs to be initialized by uploading the same microcode
to it.

> With real OF it is trivial to not have
> multiple copies of the data if you want a few properties with
> the same data.  There is no reason this could not be done in DTB
> as well (and some way in DTS to express that, or maybe the tools
> could auto-detect it, whatever).

So you're suggesting a change to DTC to support an enhanced syntax?

> Or you could just zip the DTB.

Sorry, I don't understand how that would help me.

> Can't you link it into the kernel then?  Seems a better place for
> it to me.  Of course you said something about GPL, heh.

Yes, the firmware is not GPL, so I can't link it into the kernel.
Believe me, it would have solved a lot of problems if we could.

-- 
Timur Tabi
Linux kernel developer at Freescale


More information about the Linuxppc-dev mailing list