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

[Grant Likely]

[cc'd David Gibson]

On Thu, Mar 25, 2010 at 8:42 AM, Timur Tabi <timur at freescale.com> wrote:
> 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.

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:
>
> 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?

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 at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.