lock-name and tx-clock-name device tree
properties
(dated 12/3)
[PATCH v2] qe: add ability to upload QE firmware
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Arnd Bergmann wrote:
> Ok, looks you were right from the start (again), thanks for your patience
> explaining this to me.
No problem. No all I need is for Kumar to apply the patches!
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev
Timur Tabi wrote:
> I think these patches are final:
>
> [PATCH 1/2] qe: add function qe_clock_source (dated 12/3)
> [PATCH 2/2] ucc_geth: use rx-clock-name and tx-clock-name device tree
> properties (dated 12/3)
> [PATCH v2] qe: add ability to upload QE firmware
I lied.
On Dec 6, 2007, at 9:59 AM, Timur Tabi wrote:
> Arnd Bergmann wrote:
>
>> Ok, looks you were right from the start (again), thanks for your
>> patience
>> explaining this to me.
>
> No problem. No all I need is for Kumar to apply the patches!
When I wait you come up with a new version.. so I'm
On Thursday 06 December 2007, Timur Tabi wrote:
> In reality, having the boot loader load the firmware will usually be the
> preferred approach, because that's simpler. Having it in both U-Boot and the
> kernel covers all situations, though. There would be no need for the
> bootloader
> to pa
Arnd Bergmann wrote:
> My point is that you could have some extra code that calls your
> qe_upload_firmware() when the device tree contains the blob but the boot
> loader did not already load it.
The current design of the 'firmware' node is such that if present, that means
that the firmware has
On Thursday 06 December 2007, Timur Tabi wrote:
> > I'm not trying to convince you of this if it's completely pointless for
> > all your systems, just want to make sure you're aware of this option,
> > because spending a few extra code lines on it now may save you some trouble
> > if you need this
Arnd Bergmann wrote:
> On Thursday 06 December 2007, Timur Tabi wrote:
>>> In that case, I think it
>>> would really be better to just put the blob into the tree and only
>>> have the fw loading code in the kernel instead of duplicating it in the boot
>>> loader.
>> That would require the firmware
On Thursday 06 December 2007, Timur Tabi wrote:
> > In that case, I think it
> > would really be better to just put the blob into the tree and only
> > have the fw loading code in the kernel instead of duplicating it in the boot
> > loader.
>
> That would require the firmware to present in RAM for
Arnd Bergmann wrote:
> What does the firmware node contain then? The way I read it, you only put
> metadata about the uploaded firmware in there, but not the blob itself, right?
That's correct. The meta-data is only the information that a device driver
would need to identify and interact with t
On Thursday 06 December 2007, Timur Tabi wrote:
> Arnd Bergmann wrote:
>
> > Of course, that approach does not help you if the blob is not GPL compatible
> > and you are relying on the dts file to be linked into the kernel,
>
> Well, the blobs will never be GPL compatible, which is why I created
Arnd Bergmann wrote:
> Of course, that approach does not help you if the blob is not GPL compatible
> and you are relying on the dts file to be linked into the kernel,
Well, the blobs will never be GPL compatible, which is why I created the
firmware binary format. Previously, the firmware was
On Wednesday 05 December 2007, Timur Tabi wrote:
> Define the layout of a binary blob that contains a QE firmware and
> instructions
> on how to upload it. Add function qe_upload_firmware() to parse the blob
> and perform the actual upload. Fully define 'struct rsp' in immap_qe.h to
> include th
Define the layout of a binary blob that contains a QE firmware and instructions
on how to upload it. Add function qe_upload_firmware() to parse the blob
and perform the actual upload. Fully define 'struct rsp' in immap_qe.h to
include the actual RISC Special Registers.
Signed-off-by: Timur Tabi
14 matches
Mail list logo
