[cc'd David Gibson]
On Thu, Mar 25, 2010 at 8:42 AM, Timur Tabi <ti...@freescale.com> wrote:
> 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.
The more I think about it, the more I think that the initrd is the
better approach. Non-GPL firmware blobs are not a new problem, other
drivers have the same issue and the kernel already has a facility for
handling them. Consistency is worth something here. As you say, the
ideal solution would be to link the blob into the kernel and be done
with it. <grumble>
>> 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?
It isn't a problem to change dtc if we've got a good use-case for
doing so. I've cc'd David Gibson. He's probably got some insight on
the best way to handle this without an incompatible .dtb file format
change.
>
>> 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
>
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
