On Wed, Mar 24, 2010 at 8:49 PM, Segher Boessenkool
<seg...@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:
q...@e8000000 {
fsl,firmware = /incbin/("firmware-file-name.bin");
...
}
q...@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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
