On 5 Sep, Stefan Richter wrote:
> On 5 Sep, Andrew Morton wrote:
>>> >>> Trying to free already-free IRQ 40
>>> >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> >>> firewire_ohci: pci_set_power_state failed with
>>> >>> -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firew
>> Is anybody working on the device-tree-aware ppc 44x NAND flash
>> controller (ndfc) driver?
>
> Not to my knowledge. We sort of need a decent binding for NAND flash
> in general first.
Not really. You can put the NAND controller in the device
tree without describing the NAND flash itself --
On Thu, 6 Sep 2007 15:06:03 +0200
Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> >> Is anybody working on the device-tree-aware ppc 44x NAND flash
> >> controller (ndfc) driver?
> >
> > Not to my knowledge. We sort of need a decent binding for NAND flash
> > in general first.
>
> Not really.
>> That's wrong if lock is assigned to r0, you should use
>> a "b" constraint to avoid this. Same for atomic_dec below.
>
> GCC should really have removed r0 from the "r" class (it isn't truly a
> general-purpose register), and had a different class meaning
> "r"-plus-r0.
Nah, GPR0 _is_ a general
>>> + - bank-width : Width (in bytes) of the flash bank. Equal to
>>> the
>>> + device width times the number of interleaved chips.
>>> + - device-width : (optional) Width of a single flash chip. If
>>> + omitted, assumed to be equal to 'bank-width'.
>>
>> Let's have bank-wid
Josh Boyer wrote:
> On Thu, 6 Sep 2007 15:06:03 +0200
> Segher Boessenkool <[EMAIL PROTECTED]> wrote:
>
Is anybody working on the device-tree-aware ppc 44x NAND flash
controller (ndfc) driver?
>>> Not to my knowledge. We sort of need a decent binding for NAND flash
>>> in general firs
> Hrm.. IIRC, it is permissible under Linux to only include device nodes
> for those PCI devices where something must be specified which can't be
> proved via PCI.
It is. It isn't clear (to me, at least) which properties are
required in a PCI node that exists for e.g. interrupt reasons
only; or h
>> PCI memory space sits on the PCI bus, not on the PCI host bridge,
>> so is not part of "reg" but is part of "ranges" here, since it is
>> direct mapped into the host's address space.
> That's right, but what about this example here (from a Pegasos II):
>
> /proc/device-tree/[EMAIL PROTECTED]:
>
On Thu, 06 Sep 2007 17:30:08 +0400
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> AFAIK, NAND flash is autodetected by reading it's ID at runtime, so
> there should be no need for flash bindings.
Well, I'm not really sure. CFI and JEDEC can both be probed as well,
and we're working on a binding
> BTW: It looks like the Pegasos II device tree defines device_type =
> "spi"
> for the IDE controller. Is that correct?
There is no standard binding for an "spi" device type. I have no
idea which of various "SPI" kind of devices is meant here; and none
of the ones I know of have anything to do
On Thu, Sep 06, 2007 at 03:21:36PM +0200, Segher Boessenkool wrote:
> >>That's wrong if lock is assigned to r0, you should use
> >>a "b" constraint to avoid this. Same for atomic_dec below.
> >
> >GCC should really have removed r0 from the "r" class (it isn't truly a
> >general-purpose register), a
> That looks totally bogus. Unlike Segher, I think there are a few
> cases where overlapping reg and ranges can make sense
That's not unlike me -- I may have lower tolerance for it though :-)
> (PCI bridges
> where config space is accessed indirectly via MMIO registers which lie
> in the legacy
>> The node should have a compatible
>> property which is sufficient to select the right bridge driver.
> Yeah, I defined a compatible = "mai,articias"; property in the pci
> node.
> Are there any naming conventions (maybe lower case only)?
It's conventional for the part behind the comma to be lo
> +/ {
> + model = "Analogue & Micro Adder MPC875";
This should probably be just "MPC875".
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> Either way, it's a bit late to change this, no?
>
> Sure, I was just whining due to having been bitten by this sort of bug
> in
> the past. :-)
Write a song about it, it's therapeutical it seems!
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@o
>> AFAIK, NAND flash is autodetected by reading it's ID at runtime, so
>> there should be no need for flash bindings.
>
> Well, I'm not really sure. CFI and JEDEC can both be probed as well,
> and we're working on a binding there.
JEDEC cannot be reliably probed. CFI can be _almost_ probed,
you
>> This kind of thing is typically hardcoded into the firmware (just like
>> the device tree is) -- just put it somewhere _next to_ the device
>> tree,
>> not _in_ it.
>
> What is next to the device tree?
"Anywhere else in the firmware".
> AFAIK, there is no other standard data structure that co
On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > Err... huh? The legacy IO space is assigned a block of addresses in
> > 3-word "OF-PCI-space by the PCI binding. When that is translated into
> > an MMIO range by the bridge, there's no reason that can't be encoded
> > into t
On Thu, Sep 06, 2007 at 04:08:43PM +0200, Segher Boessenkool wrote:
> >+/ {
> >+model = "Analogue & Micro Adder MPC875";
>
> This should probably be just "MPC875".
There's more than one board with an MPC875 on it.
-Scott
___
Linuxppc-dev mailing li
On Thu, Sep 06, 2007 at 04:13:56PM +0200, Segher Boessenkool wrote:
> > AFAIK, there is no other standard data structure that could take place
> > of the par_io nodes in the DTS.
>
> The device tree is not a dumping ground for all your "I need some
> standard data structure" stuff. Use an XML fi
>> _and system GPIOs_ :-)
>
> Yup, firmware should set up gpios, to make initial kernel boot.
> After that, kernel can and should manage GPIOs.
Sure. But only the GPIOs it _does_ need to toggle, not the ones
that have to be fixed to a certain value (like everything that is
described in the par_io
>> The kernel is of course welcome to do so -- and this may be a valid
>> reason to attach pin information to specific device nodes, if it
>> actually
>> saves a non-negligible amount of power -- but it's not a reason to
>> force
>> the kernel to have to care by not setting things up in the firmw
>>> AFAIK, there is no other standard data structure that could take
>>> place
>>> of the par_io nodes in the DTS.
>>
>> The device tree is not a dumping ground for all your "I need some
>> standard data structure" stuff. Use an XML file if you have to ;-)
>
> Bah. How about we just remove the n
Hi
Is it possible to configure chipselect to use UPM A and UPM B in an MPC8270
chip using the new CPM device bindings patches from Scott?
I need to pass in the 3 bits for MS (machine select to the relevant MRx
register).
Best regards,
Esben Haabendal
___
Segher Boessenkool wrote:
>>> _and system GPIOs_ :-)
>>
>> Yup, firmware should set up gpios, to make initial kernel boot.
>> After that, kernel can and should manage GPIOs.
>
> Sure. But only the GPIOs it _does_ need to toggle, not the ones
> that have to be fixed to a certain value (like everyt
On Thu, Sep 06, 2007 at 04:00:45PM +0200, Segher Boessenkool wrote:
> >> The node should have a compatible
> >> property which is sufficient to select the right bridge driver.
> > Yeah, I defined a compatible = "mai,articias"; property in the pci
> > node.
> > Are there any naming conventions (may
The node should have a compatible
property which is sufficient to select the right bridge driver.
>>> Yeah, I defined a compatible = "mai,articias"; property in the pci
>>> node.
>>> Are there any naming conventions (maybe lower case only)?
>>
>> It's conventional for the part behind the
This changes PowerPC to use the generic time infrastructure for
gettimeofday et al. We register a clocksource which uses the timebase
register, or the RTC on the 601.
It also gets rid of the RTC update stuff. IIRC we discussed removing
this some time ago but never actually did it.
This is based
This creates a clockevent for the PowerPC decrementer and registers it
with the generic clock/timer system, and implements the dynamic ticks
(no idle HZ) option for PowerPC.
This is based largely on an earlier patch by Tony Breeds. It could
still use more cleanup. This and the previous patch see
On Wed Sep 5 12:44:17 EST 2007, Olof Johansson wrote:
> diff --git a/arch/powerpc/platforms/Kconfig
> b/arch/powerpc/platforms/Kconfig
> index 041df77..b9f1efa 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -137,6 +137,10 @@ config MPIC_U3_HT_IRQS
>
Zhang Wei-r63237 wrote:
> Oops!
>
> Could you give us a live show version? :D
Sorry, I'm booked up for the rest of the year.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/ma
Hello all.
What are the steps to configure an MPC500B-Board to react on an IRQ (2)?
I have written a test-driver with this code-snippets, but the prozessor
hangs when loading the driver.
my __init-function looks like:
static int __init mod_init( void )
{
volatile static struct mpc52xx_intr
On Thu, Sep 06, 2007 at 04:23:49PM +0200, Esben Haabendal wrote:
> Is it possible to configure chipselect to use UPM A and UPM B in an
> MPC8270 chip using the new CPM device bindings patches from Scott?
>
> I need to pass in the 3 bits for MS (machine select to the relevant MRx
> register).
The
PS3: A storage device may show up in the repository before the hypervisor has
finished probing:
- If its type is not yet known, it shows up as PS3_DEV_TYPE_STOR_DUMMY,
- If its regions are being probed, it shows up as having zero regions.
If any of these happen, consider the device not yet pres
On Thu, Sep 06, 2007 at 10:21:43AM -0500, Timur Tabi wrote:
> Zhang Wei-r63237 wrote:
> > Oops!
> >
> > Could you give us a live show version? :D
>
> Sorry, I'm booked up for the rest of the year.
Hmm. Maybe someone could sneak a videocam into one of the
venues, and, you know, post a pirated,
On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> This changes PowerPC to use the generic time infrastructure for
> gettimeofday et al. We register a clocksource which uses the timebase
> register, or the RTC on the 601.
>
> It also gets rid of the RTC update stuff. IIRC we discu
On Thu, Sep 06, 2007 at 11:51:33AM -0500, Linas Vepstas wrote:
> On Thu, Sep 06, 2007 at 10:21:43AM -0500, Timur Tabi wrote:
> > Zhang Wei-r63237 wrote:
> > > Oops!
> > >
> > > Could you give us a live show version? :D
> >
> > Sorry, I'm booked up for the rest of the year.
>
> Hmm. Maybe someo
On Thu, Sep 06, 2007 at 06:55:35PM +0200, Gabriel Paubert wrote:
> On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> > This changes PowerPC to use the generic time infrastructure for
> > gettimeofday et al. We register a clocksource which uses the timebase
> > register, or the RTC
On Thu, Sep 06, 2007 at 12:01:23PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 06:55:35PM +0200, Gabriel Paubert wrote:
> > On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> > > This changes PowerPC to use the generic time infrastructure for
> > > gettimeofday et al. We regi
On Thu, Sep 06, 2007 at 07:05:47PM +0200, Gabriel Paubert wrote:
> On Thu, Sep 06, 2007 at 12:01:23PM -0500, Scott Wood wrote:
> > On Thu, Sep 06, 2007 at 06:55:35PM +0200, Gabriel Paubert wrote:
> > > So who will be in charge of updating the RTC now? The update
> > > every 11 min is there to stay
These popped out at me while I was reading code.
Its all janitorial.
--linas
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Whitespace cleanup: badly indented lines.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/kernel/prom.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/prom.c
===
Whitespace cleanup: badly indented lines.
Typo in comment.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/kernel/prom_init.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/prom_init.c
==
>>> + model = "Analogue & Micro Adder MPC875";
>>
>> This should probably be just "MPC875".
>
> There's more than one board with an MPC875 on it.
"model" is the model name the vendor uses. It isn't supposed to
be unique globally, nor does it say what CPU is on the board.
Segher
_
Gramatical corrections to comments.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/kernel/prom.c |8 +---
arch/powerpc/kernel/setup_64.c |6 +++---
2 files changed, 8 insertions(+), 6 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/setup_64.c
On Thu, Sep 06, 2007 at 07:50:32PM +0200, Segher Boessenkool wrote:
> >>>+ model = "Analogue & Micro Adder MPC875";
> >>
> >>This should probably be just "MPC875".
> >
> >There's more than one board with an MPC875 on it.
>
> "model" is the model name the vendor uses. It isn't supposed to
> be un
Gabriel Paubert writes:
> On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> > This changes PowerPC to use the generic time infrastructure for
> > gettimeofday et al. We register a clocksource which uses the timebase
> > register, or the RTC on the 601.
> >
> > It also gets rid of
> + model = "Analogue & Micro Adder MPC875";
This should probably be just "MPC875".
>>>
>>> There's more than one board with an MPC875 on it.
>>
>> "model" is the model name the vendor uses. It isn't supposed to
>> be unique globally, nor does it say what CPU is on the board.
>
> The
On Thu, Sep 06, 2007 at 08:48:12PM +0200, Segher Boessenkool wrote:
> >+model = "Analogue & Micro Adder MPC875";
>
> This should probably be just "MPC875".
> >>>
> >>>There's more than one board with an MPC875 on it.
> >>
> >>"model" is the model name the vendor uses. It isn't
Hi,
Nice! I've been looking forward to these patches. Should help keep power
consumption down on machines with powersavings support for idle.
On Fri, Sep 07, 2007 at 12:44:46AM +1000, Paul Mackerras wrote:
> @@ -749,6 +805,8 @@ void __init clocksource_init(void)
> printk(KERN_INFO "clockso
On Thu, Sep 06, 2007 at 02:12:55PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 08:48:12PM +0200, Segher Boessenkool wrote:
> > So it should be "Adder MPC875", then :-)
>
> Any particular reason to leave out potentially useful information in a
> field that is for human consumption?
>
> Othe
>>> + model = "Analogue & Micro Adder MPC875";
>>
>> This should probably be just "MPC875".
>
> There's more than one board with an MPC875 on it.
"model" is the model name the vendor uses. It isn't supposed to
be unique globally, nor does it say what CPU is
On Thu, Sep 06, 2007 at 09:36:07PM +0200, Segher Boessenkool wrote:
> >BTW, IEEE1275 seems to disagree:
>
> No it doesn't.
"...in conventional usage the string begins with the name of the device's
manufacturer". Even if you want to quibble about the manner in which the
manufacturer is specified,
> BTW, IEEE1275 seems to disagree:
No it doesn't.
> A manufacturer-dependent string that generally specifies the model
> name
> and number (including revision level) for this device. The format of
> the text string is arbitrary, although in conventional usage the
> string
> begins with
Hi again,
On Thu, Sep 06, 2007 at 02:15:16PM -0500, Olof Johansson wrote:
> I don't think that set_dec() is needed any more. I get a very long
> delay during "Calibrating delay loop..." with it there.
>
> Looks like decrementer_set_next_event() already sets a reasonable
> decementer value, it's
Original-Nachricht
> Datum: Thu, 6 Sep 2007 09:15:01 -0500
> Von: Scott Wood <[EMAIL PROTECTED]>
> An: Segher Boessenkool <[EMAIL PROTECTED]>
> CC: linuxppc-dev@ozlabs.org, David Gibson <[EMAIL PROTECTED]>
> Betreff: PCI I/O space -- reg or ranges?
> > Sure, it can be encoded li
>>> BTW, IEEE1275 seems to disagree:
>>
>> No it doesn't.
>
> "...in conventional usage the string begins with the name of the
> device's
> manufacturer".
You cut that sentence short here, it continues: "as with the name
property."
> Even if you want to quibble about the manner in which the
> ma
>>> Sure, it can be encoded like that. But does it make sense?
>>> You cannot use legacy I/O space as normal memory space.
>>
>> Why does it not make sense? I'm not sure what you mean by using it as
>> "normal memory space", but if the PCI bridge does a straightforward
>> linear mapping of I/O in
Original-Nachricht
> Datum: Thu, 6 Sep 2007 15:36:30 +0200
> Von: Segher Boessenkool <[EMAIL PROTECTED]>
> An: "Gerhard Pircher" <[EMAIL PROTECTED]>
> CC: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
> Betreff: Re: [RFC] AmigaOne device tree source v2
> >> PCI legacy I/O is not di
On Thu, Sep 06, 2007 at 10:57:28PM +0200, Segher Boessenkool wrote:
> >>>BTW, IEEE1275 seems to disagree:
> >>
> >>No it doesn't.
> >
> >"...in conventional usage the string begins with the name of the
> >device's
> >manufacturer".
>
> You cut that sentence short here, it continues: "as with the
On Thu, Sep 06, 2007 at 03:36:30PM +0200, Segher Boessenkool wrote:
[snip]
> >> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >> PowerPC system bus. So, it can not be mentioned in the "ranges"
> >> property, but the PHB registers used to access it should be shown
> >> in the "
On Wed, Sep 05, 2007 at 02:21:10PM -0500, Scott Wood wrote:
> This will be needed by PlanetCore firmware support.
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
--
David Gibson| I'll have my music baroque, and my code
david AT gi
On Wed, Sep 05, 2007 at 02:21:18PM -0500, Scott Wood wrote:
> Some firmwares (such as PlanetCore) only provide a base MAC address, and
> expect the kernel to set certain bits to generate the addresses for the
> other ports. As such, MAC addresses are generated that may not correspond
> to actual h
On Wed, Sep 05, 2007 at 02:21:14PM -0500, Scott Wood wrote:
> It will be needed for PlanetCore firmware support.
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
I still have a patch that already does this, plus strchr() as well,
pending...
--
David Gibson| I'll have my mus
On Wed, Sep 05, 2007 at 02:21:12PM -0500, Scott Wood wrote:
> This will be used by the PlanetCore firmware support to construct
> a linux,stdout-path from the serial node that it finds.
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
Although I'm plan
Hi all,
I am working on MPC8313ERDB Eval board, and want to use SD Memory card
to store Linux OS and file system.
The SD card controller is connected directly with the SPI bus.
I simply don't know how to use MMC-over-SPI technology to make SD card
usable.
It would be a great help if anybody
On Thu, 2007-09-06 at 12:47 -0500, Linas Vepstas wrote:
> Gramatical corrections to comments.
>
> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
>
>
>
> arch/powerpc/kernel/prom.c |8 +---
> arch/powerpc/kernel/setup_64.c |6 +++---
> 2 files changed, 8 insertions(+), 6 d
On Wed, Sep 05, 2007 at 02:21:04PM -0500, Scott Wood wrote:
> 1. ft_create_node was returning the internal pointer rather than a phandle.
> 2. ft_find_device_rel was treating a "top" phandle of NULL as an error,
> rather than as the root of the tree. The old, absolute ft_find_device
> is removed,
Arnd Bergmann wrote:
> On Tuesday 04 September 2007, Geoff Levand wrote:
>>
>> From: Masato Noguchi <[EMAIL PROTECTED]>
>>
>> Add platform specific SPU run control routines.
>>
>> The current spufs_run_spu() implementation uses the SPU master
>> run control bit (MFC_SR1[S]) to control SPE execut
Subject: Cell: Wrap master run control bit
From: Masato Noguchi <[EMAIL PROTECTED]>
Add platform specific SPU run control routines to the spufs. The current
spufs implementation uses the SPU master run control bit (MFC_SR1[S]) to
control SPE execution, but the PS3 hypervisor does not support the
On Wed, Sep 05, 2007 at 11:33:17AM -0500, Josh Boyer wrote:
> Updated DTS below
>
> Device tree source file for the PPC405 Walnut evaluation board.
>
> Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
--
David Gibson| I'll have my mus
On Wed, Sep 05, 2007 at 12:53:54AM -0500, Josh Boyer wrote:
> On Wed, 2007-09-05 at 15:46 +1000, David Gibson wrote:
> > > > > > There must surely be a way to get the MAC addresses out of
> > > > > > OpenBIOS...
> > > > >
> > > > > Probably. I just need to find out where they are stored.
> > > >
On Wed, Sep 05, 2007 at 08:21:06AM -0500, Scott Wood wrote:
> On Wed, Sep 05, 2007 at 03:40:23PM +0400, Anton Vorontsov wrote:
> > On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote:
> > > The kernel is of course welcome to do so -- and this may be a valid
> > > reason to attach pin informa
On Wed, Sep 05, 2007 at 11:42:43AM -0500, Josh Boyer wrote:
> Updated patch below. NOTE: This relies on Scott Wood's strtoull patch
> as PIBS stores the MAC addresses as ASCII strings in flash.
>
>
> Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> linker declaratio
This patch replaces the binding for flash chips in
booting-without-of.txt with an clarified and improved version. It
also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
Finally it revises the Ebony device tree source to use the new binding
as an example.
Signed-off-by: David Gibs
On Thu, Sep 06, 2007 at 04:13:56PM +0200, Segher Boessenkool wrote:
> >> This kind of thing is typically hardcoded into the firmware (just like
> >> the device tree is) -- just put it somewhere _next to_ the device
> >> tree,
> >> not _in_ it.
> >
> > What is next to the device tree?
>
> "Anywher
On Wed, Sep 05, 2007 at 11:36:04AM -0500, Josh Boyer wrote:
> Updated patch below
>
> Add zImage wrapper for walnut board
>
> Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
--
David Gibson| I'll have my music baroque, and my code
da
David Gibson wrote:
> Firmwares are, more often than not, crap, and that's unlikely to
> change. For a lot of things, having the kernel or bootwrapper cope as
> a special case with a handful of crap firmwares which don't set things
> up properly isn't actually any easier than having it set them u
On Wed, Sep 05, 2007 at 02:21:19PM -0500, Scott Wood wrote:
> fsl_get_immr() is equivalent to the kernel's get_immrbase() function.
>
> mpc885_get_clock() transforms a crystal frequency into a system frequency
> according to the PLL register settings.
>
> pq2_get_clocks() does the same as the abo
On Thu, Sep 06, 2007 at 03:28:35PM +0200, Segher Boessenkool wrote:
> >>> + - bank-width : Width (in bytes) of the flash bank. Equal to
> >>> the
> >>> + device width times the number of interleaved chips.
> >>> + - device-width : (optional) Width of a single flash chip. If
> >>> +
On Thu, Sep 06, 2007 at 04:30:23PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 10:57:28PM +0200, Segher Boessenkool wrote:
> > >>>BTW, IEEE1275 seems to disagree:
> > >>
> > >>No it doesn't.
> > >
> > >"...in conventional usage the string begins with the name of the
> > >device's
> > >manuf
On Wed, Sep 05, 2007 at 02:21:16PM -0500, Scott Wood wrote:
> This target produces a flat binary rather than an ELF file,
> fixes the entry point at the beginning of the image, and takes
> a complete device tree with no fixups needed.
>
> The device tree must have labels on /#address-cells, the ti
On Wed, Sep 05, 2007 at 02:21:15PM -0500, Scott Wood wrote:
> This is a library that board code can use to extract information from the
> PlanetCore configuration keys. PlanetCore is used on various boards from
> Embedded Planet.
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
[snip]
> +void p
On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > That looks totally bogus. Unlike Segher, I think there are a few
> > cases where overlapping reg and ranges can make sense
>
> That's not unlike me -- I may have lower tolerance for it though :-)
I see. Can't imagine how I
84 matches
Mail list logo
