On Sun, Mar 21, 2010 at 4:32 PM, John Williams
wrote:
> Grant,
>
> On Sun, Mar 21, 2010 at 3:35 AM, Grant Likely
> wrote:
>> On Thu, Mar 11, 2010 at 6:42 AM, Michal Simek wrote:
>>> Hi Linus,
>>>
>>> Please pull Microblaze changes to your tree. There is support for PCI and
>>> new DMA interface
On Fri, Mar 26, 2010 at 01:52:24PM -0600, Grant Likely wrote:
> I could change the statement to something like, "virtually tagged or
> indexed data cache(s) must be off", or drop the statement entirely
> since it is implied by the requirement that the MMU must be off.
1. We're not going down the p
On Fri, Mar 26, 2010 at 07:43:20AM -1000, Mitch Bradley wrote:
> What is the reason for turning off the data caches? Leaving all caches
> turned on and coherent with one another has always worked well for me at
> the interface from firmware to a booted program.
With the data caches on, you ne
On Fri, Mar 26, 2010 at 4:42 PM, Timur Tabi wrote:
> Define a binding for embedding a QE firmware blob into the device tree. Also
> define a new property for the QE node that links to a firmware node.
>
> Signed-off-by: Timur Tabi
> ---
> .../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 5
Define a binding for embedding a QE firmware blob into the device tree. Also
define a new property for the QE node that links to a firmware node.
Signed-off-by: Timur Tabi
---
.../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 54
1 files changed, 54 insertions(+), 0 de
On Fri, 26 Mar 2010, Grant Likely wrote:
> On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley wrote:
> > Catalin Marinas wrote:
> >> On Thu, 2010-03-25 at 21:04 +, Russell King - ARM Linux wrote:
> >>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> *IRQs disabled
> *MM
On Fri, Mar 26, 2010 at 1:50 PM, Timur Tabi wrote:
> Grant Likely wrote:
>> The node must be a child of a QE node. A QE node can reference the
>> firmware from another QE node by using the fsl,firmware-phandle
>> property.
>
> Ok.
>
> I'll post a V3 once everyone else has a chance to comment.
Al
On Fri, Mar 26, 2010 at 1:30 PM, Nicolas Pitre wrote:
> On Fri, 26 Mar 2010, Grant Likely wrote:
>
>> On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley wrote:
>> > Catalin Marinas wrote:
>> >> On Thu, 2010-03-25 at 21:04 +, Russell King - ARM Linux wrote:
>> >>> On Wed, Mar 24, 2010 at 09:11:56
Grant Likely wrote:
> The node must be a child of a QE node. A QE node can reference the
> firmware from another QE node by using the fsl,firmware-phandle
> property.
Ok.
I'll post a V3 once everyone else has a chance to comment.
--
Timur Tabi
Linux kernel developer at Freescale
__
On Fri, Mar 26, 2010 at 1:35 PM, Timur Tabi wrote:
> Define a binding for embedding a QE firmware blob into the device tree. Also
> define a new property for the QE node that links to a firmware node.
>
> Signed-off-by: Timur Tabi
> ---
> .../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 5
Define a binding for embedding a QE firmware blob into the device tree. Also
define a new property for the QE node that links to a firmware node.
Signed-off-by: Timur Tabi
---
.../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 54
1 files changed, 54 insertions(+), 0 de
On Fri, Mar 26, 2010 at 12:58 PM, Mitch Bradley wrote:
> a) Firmware blob in some random place - requires strong naming of either
> firmware blob property or node containing it.
BTW, this exactly the reason for all the bikesheding earlier; but I
don't care at all if it is under a QE node.
g.
___
Timur Tabi wrote:
Grant Likely wrote:
Nah. That looks totally fine. Not having the firmware under a qe
node would look bad to me.
You don't think it weird to have one QE node reference data from another QE
node, or that the DTS implies that the firmware belongs to one QE more than
On Fri, Mar 26, 2010 at 12:48 PM, Timur Tabi wrote:
> Grant Likely wrote:
>
>> Nah. That looks totally fine. Not having the firmware under a qe
>> node would look bad to me.
>
> You don't think it weird to have one QE node reference data from another QE
> node, or that the DTS implies that the
Grant Likely wrote:
> Nah. That looks totally fine. Not having the firmware under a qe
> node would look bad to me.
You don't think it weird to have one QE node reference data from another QE
node, or that the DTS implies that the firmware belongs to one QE more than it
belongs to the other?
Timur Tabi wrote:
Grant Likely wrote:
Without the compatible property, the only way I'd know that the child node
contains a firmware is to look at the actual name of the child node, which (as
Scott and I believe) is not better than a compatible property.
If it is always a child of a
On Fri, Mar 26, 2010 at 12:39 PM, Timur Tabi wrote:
> Grant Likely wrote:
>>> Without the compatible property, the only way I'd know that the child node
>>> contains a firmware is to look at the actual name of the child node, which
>>> (as Scott and I believe) is not better than a compatible pro
Grant Likely wrote:
>> Without the compatible property, the only way I'd know that the child node
>> contains a firmware is to look at the actual name of the child node, which
>> (as Scott and I believe) is not better than a compatible property.
> If it is always a child of a qe node, then I've g
On 2010-03-25, at 17:46, Timur Tabi wrote:
> The more I think about it, the more I believe that this is how we're going to
> have to do it. Whether or not Freescale can embed a non-GPL firmware into a
> device tree is still undecided. It may require relicensing all of our device
> trees as d
On Fri, Mar 26, 2010 at 9:23 AM, Timur Tabi wrote:
> I'm seeing this error with this patch applied, when building for an
> mpc8641_hpcn
>
> CC drivers/net/gianfar.o
> drivers/net/gianfar.c: In function 'gfar_of_init':
> drivers/net/gianfar.c:606: error: 'struct platform_device' has no
> mem
On Fri, Mar 26, 2010 at 9:17 AM, Timur Tabi wrote:
> Grant Likely wrote:
>
>> +- fsl,firmware:
>> + Usage: Optional.
>> + Value type: , encoded array of bytes
>> + Definition: Contains the QUICC engine firmware blob.
>> [plus any other properties needed for firmware metadata]
>
> This wou
On Fri, Mar 26, 2010 at 11:43 AM, Mitch Bradley wrote:
> Catalin Marinas wrote:
>> On Thu, 2010-03-25 at 21:04 +, Russell King - ARM Linux wrote:
>>> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
*IRQs disabled
*MMU off
*Instruction cache either on or off
*D
Catalin Marinas wrote:
On Thu, 2010-03-25 at 21:04 +, Russell King - ARM Linux wrote:
On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
===Required System State===
[...]
*IRQs disabled
*MMU off
*Instruction cache either on or off
*Data cache turned off
I'm seeing this error with this patch applied, when building for an mpc8641_hpcn
CC drivers/net/gianfar.o
drivers/net/gianfar.c: In function 'gfar_of_init':
drivers/net/gianfar.c:606: error: 'struct platform_device' has no
member named 'node'
drivers/net/gianfar.c:644: error: 'struct platfo
Grant Likely wrote:
> +- fsl,firmware:
> +Usage: Optional.
> +Value type: , encoded array of bytes
> +Definition: Contains the QUICC engine firmware blob.
> [plus any other properties needed for firmware metadata]
This would place the firmware metadata properties inside the QE node it
On Thu, 2010-03-25 at 21:04 +, Russell King - ARM Linux wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> > ===Required System State===
[...]
> > *IRQs disabled
> > *MMU off
> > *Instruction cache either on or off
> > *Data cache turned off
>
> Would recommend saying "Da
26 matches
Mail list logo
