* Re: powerpc: Fix fallout from sg_page() changes
From: Jens Axboe @ 2007-10-23 7:13 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, mingo, torvalds, linux-kernel
In-Reply-To: <20071023040948.GA19699@lixom.net>
On Mon, Oct 22 2007, Olof Johansson wrote:
> Fix fallout from 18dabf473e15850c0dbc8ff13ac1e2806d542c15:
>
> In file included from include/linux/dma-mapping.h:52,
> from drivers/base/dma-mapping.c:10:
> include/asm/dma-mapping.h: In function 'dma_map_sg':
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:289: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:290: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h: In function 'dma_sync_sg_for_cpu':
> include/asm/dma-mapping.h:331: error: 'struct scatterlist' has no member named 'page'
>
> drivers/scsi/ps3rom.c: In function 'fetch_to_dev_buffer':
> drivers/scsi/ps3rom.c:150: error: 'struct scatterlist' has no member named 'page'
Applied.
--
Jens Axboe
^ permalink raw reply
* Re: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Michal Simek @ 2007-10-23 7:34 UTC (permalink / raw)
To: David Gibson; +Cc: microblaze-uclinux, Wolfgang Reissnegger, linuxppc-dev
In-Reply-To: <20071023043443.GM31839@localhost.localdomain>
Hi David,
I remove some labels from my generator. I created fake system with some peripherals.
There are 3 buses and 3 bridges.
Can you check it and tell me what is wrong?
Thanks,
Michal Simek
/ {
model = "mONStR";
chosen {
bootargs = "root=/dev/xsysace/disc0/part2";
} ;
cpus {
#size-cells = <0>;
#cpus = < 0 >;
#address-cells = <1>;
microblaze_0,5.00.c@0 {
device_type = "cpu";
reg = <0>;
clock-frequency = <5f5e1000>;
timebase-frequency = <1FCA055>;
i-cache-line-size = <2000>;
i-cache-size = <10>;
d-cache-line-size = <2000>;
d-cache-size = <10>;
xilinx,pvr = <0>;
xilinx,debug-enabled = <1>;
xilinx,fsl-links = <0>;
} ;
} ;
ethernet@10060000 {
compatible = "opb_ethernet_1.04.a","opb_ethernet";
interrupts = < 3 0 >;
reg = < 10060000 10000 >;
device_type = "network";
xilinx,cam-exist = <0>;
xilinx,dev-blk-id = <1>;
xilinx,dev-mir-enable = <1>;
xilinx,dma-present = <1>;
xilinx,include-dev-pencoder = <1>;
xilinx,ipif-rdfifo-depth = <8000>;
xilinx,ipif-wrfifo-depth = <8000>;
xilinx,mii-exist = <1>;
} ;
memory@20000000 {
memreg:reg = < 20000000 10000000 >;
device_type = "memory";
} ;
serial@10030000 {
compatible = "opb_uart16550_1.00.d","opb_uart16550";
reg = < 10030000 10000 >;
device_type = "serial";
} ;
opb_timer@10020000 {
compatible = "opb_timer_1.00.b","opb_timer";
interrupts = < 0 0 >;
reg = < 10020000 10000 >;
xilinx,count-width = <20>;
xilinx,one-timer-only = <0>;
} ;
opb_opb_lite@30000000 {
ranges = < 0 30000000 10000000 >;
opb_gpio@30020000 {
compatible = "opb_gpio_3.01.b","opb_gpio";
reg = < 30020000 10000 >;
xilinx,gpio-width = <4>;
xilinx,is-dual = <0>;
} ;
i2c@30030000 {
compatible = "opb_iic_1.02.a","opb_iic";
reg = < 30030000 10000 >;
device_type = "i2c";
} ;
opb_gpio@30010000 {
compatible = "opb_gpio_3.01.b","opb_gpio";
reg = < 30010000 10000 >;
xilinx,gpio-width = <20>;
xilinx,is-dual = <0>;
} ;
ethernet@30040000 {
compatible = "opb_ethernetlite_1.01.b","opb_ethernetlite";
reg = < 30040000 10000 >;
device_type = "network";
xilinx,duplex = <1>;
xilinx,rx-ping-pong = <0>;
xilinx,tx-ping-pong = <0>;
} ;
opb_sysace@30050000 {
compatible = "opb_sysace_1.00.c","opb_sysace";
reg = < 30050000 10000 >;
xilinx,mem-width = <10>;
} ;
opb_ps2_dual_ref@30060000 {
compatible = "opb_ps2_dual_ref_1.00.a","opb_ps2_dual_ref";
interrupts = < 2 0 >;
interrupts = < 1 0 >;
reg = < 30060000 10000 >;
} ;
};
opb_intc@10010000 {
compatible = "opb_intc_1.00.c","opb_intc";
reg = < 10010000 10000 >;
} ;
opb_mdm@10050000 {
compatible = "opb_mdm_2.00.a","opb_mdm";
reg = < 10050000 10000 >;
xilinx,mb-dbg-ports = <1>;
xilinx,uart-width = <8>;
xilinx,use-uart = <1>;
} ;
serial@10040000 {
compatible = "opb_uartlite_1.00.b","opb_uartlite";
interrupts = < 4 0 >;
reg = < 10040000 10000 >;
device_type = "serial";
xilinx,baudrate = <2580>;
xilinx,data-bits = <8>;
xilinx,clk-freq = <5f5e100>;
xilinx,odd-parity = <0>;
xilinx,use-parity = <0>;
} ;
opb2plb_bridge@80000000 {
ranges = < 0 80000000 80000000 >;
serial@a0020000 {
compatible = "plb_uart16550_1.00.c","plb_uart16550";
reg = < a0020000 10000 >;
device_type = "serial";
} ;
plb_gpio@a0010000 {
compatible = "plb_gpio_1.00.b","plb_gpio";
reg = < a0010000 10000 >;
xilinx,gpio-width = <20>;
xilinx,is-dual = <0>;
} ;
ethernet@a0000000 {
compatible = "plb_ethernet_1.01.a","plb_ethernet";
reg = < a0000000 10000 >;
device_type = "network";
} ;
plb2opb_bridge@10000000 {
ranges = < 0 10000000 10000000 >;
ranges = < 1 20000000 10000000 >;
};
cpus {
#size-cells = <0>;
#cpus = < 1 >;
#address-cells = <1>;
ppc405_0,405@1 {
device_type = "cpu";
reg = <0>;
clock-frequency = <5f5e1000>;
timebase-frequency = <1FCA055>;
} ;
} ;
};
} ;
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Michael Ellerman @ 2007-10-23 7:36 UTC (permalink / raw)
To: Linas Vepstas
Cc: Stephen Rothwell, linuxppc-dev, Paul Mackerras, sparclinux,
David S. Miller
In-Reply-To: <20071018190939.GE29903@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On Thu, 2007-10-18 at 14:09 -0500, Linas Vepstas wrote:
> On Thu, Oct 18, 2007 at 11:27:23AM +1000, Michael Ellerman wrote:
> >
> > It does what pci_device_to_OF_node() does, but in the right way.
> >
> > The plan is to remove pci_device_to_OF_node() once all the callers have
> > been converted to properly handle the refcounting.
>
> Oh. Yes. well, of course, then. Excellent reason. I didn't get
> that from the patch commit comments. So, FWIW:
>
> Ack'ed-by: Linas Vepstas <linas@austin.ibm.com>
Thanks for the ACK. But on further consideration I'm going to NACK my
own patch :)
The reasoning being that a lot of the code that uses
pci_device_to_OF_node() only uses the device_node while it also holds a
reference to the pci_dev - so there's no possibility of the device_node
going away.
So Ben suggested what we really want is two routines,
of_get_pci_dev_node() and of_peek_pci_dev_node() - the former returning
a refcounted copy and the latter allowing you to "peek" at the
device_node as long as you own the pci_dev.
I'm not sure it's worth the churn really, so we should probably just
document that pci_device_to_OF_node() is contrary, and any users that
need a reference can take one explicitly.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Benjamin Herrenschmidt @ 2007-10-23 7:40 UTC (permalink / raw)
To: michael
Cc: Stephen Rothwell, linuxppc-dev, Paul Mackerras, sparclinux,
David S. Miller
In-Reply-To: <1193125016.20274.4.camel@concordia>
> So Ben suggested what we really want is two routines,
> of_get_pci_dev_node() and of_peek_pci_dev_node() - the former returning
> a refcounted copy and the latter allowing you to "peek" at the
> device_node as long as you own the pci_dev.
>
> I'm not sure it's worth the churn really, so we should probably just
> document that pci_device_to_OF_node() is contrary, and any users that
> need a reference can take one explicitly.
Yeah, I pretty much made the same decision a couple of years ago which
is why it's still the way it is now :-)
Cheers,
Ben.
^ permalink raw reply
* DMA problem - mpc8xx
From: raul.moreno @ 2007-10-23 7:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <f8f856500709130705t2109e559v19f0ffac318a4756@mail.gmail.com>
Hi everybody,
I am having problems with the serial cpm driver in a mpc866. But I've f=
ound
out that my problem comes from the DMA and not really from the driver. =
The
Rx and Tx buffers use the DMA and then the sytem hangs. However, if I s=
et
these buffers to internal ram memory (DPRAM), it works. The DMA address=
is
configured with a kernel parameter in advance setup:
CONFIG_CONSISTENT_START (and the size in CONFIG_CONSISTENT_SIZE), but I=
don't know what they are exactly and I could not find a right documenta=
tion
about it.
I saw a pair of mailing list where some guys set the
CONFIG_CONSISTENT_START to 0xff100000, but my driver continues failing =
(and
an error about dma-mapping appears in the boot).
Did anyone have a similar problem?
Could anyone help me?
Thanks in advance,
Ra=FAl Moreno=
^ permalink raw reply
* Re: Audio codec device tree entries
From: Segher Boessenkool @ 2007-10-23 8:06 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list
In-Reply-To: <fa686aa40710222057y58202c8ev4610e045e5e389df@mail.gmail.com>
> Isn't this the ac97 bus node? Can't the ac97 codecs simply be
> children of this bus?
They should be, yes.
>> pseudo-sound@0 { // use to trigger loading platform specific fabric
>> driver
>> device_type = "pseudo-sound"
>> };
>
> I don't think this is a good idea. The device tree is for describing
> your hardware; so the layout should reflect that. Make the platform
> code do the right thing with the real nodes.
There _can_ be good reasons for using a "pseudo-device" node,
but I don't see any such reasons here. The main reason for
doing a "pseudo" is if there is some hardware you need to
describe, but it doesn't fit anywhere in the device tree; one
example is certain weird interrupt routings.
> I think this is what you want:
>
> ac97@2000 { // PSC1
> compatible = "fsl,mpc5200b-psc-ac97","fsl,mpc5200-psc-ac97";
>
> // The following codec stuff could be a little off; It has been
> a while since I've looked
> // at ac97 codec interfacing, but if I remember correctly you
> can have multiple
> // codecs on an ac97 bus; an audio codec and a modem codec. The
> following
> // reflects that understanding...
You can have more than two, and then there is the weird stuff where
"hd" codecs have more than one address. But this all can be neatly
described with "reg", so no problem.
> ac97-codec@0 {
"sound@0", says the generic naming doc.
> ac97-codec@1 {
> // This could be the modem codec
So "modem@1".
> i2s@2000 { // PSC1
> codec-handle = <&codec0 &codec2>;
I would really do it the other way around: have the codec node point
to the I2S bus.
> codec0: i2s-codec@0 {
> codec1: i2s-codec@1 {
> codec2: i2s-codec@2 {
0, 1, 2 aren't valid I2C addresses. But this was only an example ;-)
> So, this scheme describes the hardware, but it does not describe 2 of
> your questions:
>
> 1. How does the device tree describe the myriad of possible circuits
> that an audio codec can get dropped into, and
> 2. How do the drivers get probed
>
> For question #1, I think the answer is simple... it doesn't try. :-)
>
> As was described in the previous thread, trying to describe the
> circuit is very complex and figuring out what software would do with
> such a description is even worse. Instead, I propose the following:
> - as much as possible, make the board firmware and the platform setup
> code configure the GPIOs, port_config, and other 'fixed' configuration
Certainly agreed.
> - make the driver code look at either the board model/compatible
> properties or add a board-unique value to the codec's compatible list.
Make the _platform_ code look at the board version properties, and have
_it_ instantiate the correct fabric driver, with the correct
configuration
for it. Some of that configuration could be probed from the device tree
("codec gpio pin 0 is used as a level-low headphone detect switch") but
I wouldn't go over the top with it, there are just way way too many
different ways all of this is put together.
> Either way the driver can apply board specific tweaks to its
> behavious. (I think the better solution is to add a value to the
> front of the codec's compatible list because the same circuit can be
> used on a different board and it can then claim compatibility with the
> older board for just that part of the circuit).
The "fabric" stuff isn't really a codec property, but a board-global
property. So that's how this should be described in the device tree
as well: board-global.
> As for question #2, I think you make the i2s driver probe on the i2s
> bus node and the ac97 driver probe on the ac97 bus node. In both
> cases, the driver can find the link to the codec; determine what kind
> of system it is running on, and instantiate the appropriate ASoC
> fabric driver.
In the i2s case, if the i2s driver has to know about the codecs at all,
it should get references to the codecs passed in by the platform driver.
Same goes for the fabric driver.
Or, that's the only sane way of doing things I can imagine, anyway :-)
Segher
^ permalink raw reply
* Re: Problems with allyesconfig kernel build
From: Segher Boessenkool @ 2007-10-23 9:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Andrew Morton, amodra
In-Reply-To: <20071023140231.12698d1c.sfr@canb.auug.org.au>
> This was first noted with the -mm tree, but has now migrated into
> Linus'
> tree. An allyesconfig build dies in the link stage like this:
>
> /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call
> optimization to `.text.init.refok' does not allow automatic multiple
> TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or
> make `.text.init.refok' extern
> /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x8160): sibling call
> optimization to `.text.init.refok' does not allow automatic multiple
> TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or
> make `.text.init.refok' extern
> /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x81c4): sibling call
> optimization to `.text.init.refok' does not allow automatic multiple
> TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or
> make `.text.init.refok' extern
> /usr/bin/ld: final link failed: Bad value
I just tried, and it works fine for me.
> Intuiting the obvious, I changed all the _INIT_STATIC and _INIT_GLOBAL
> uses in head_64.S back to _STATIC and _GLOBAL (which just moves the
> code
> from .text.init.refok to .text). Now the linker segfaults instead.
> :-)
Tried that, too, and no segfault, everything happy.
> $ ld --version
> GNU ld (GNU Binutils for Debian) 2.18
I'm using CVS HEAD of binutils. Could you try that, with the same
GCC version you are currently using? Just to narrow things down...
Segher
^ permalink raw reply
* Re: Difference between ioremap() and phy_to_virt() Kernel function
From: Arnd Bergmann @ 2007-10-23 9:11 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <13357088.post@talk.nabble.com>
On Tuesday 23 October 2007, Misbah khan wrote:
> But i wish to know that could i use phy_to_virt() function in place io
> ioremap() ?????
Sorry to disappoint you there, but you can't.
> And could you give me an example where we could use phy_to_virt().
Not really, I can't think of any correct use of phys_to_virt on powerpc.
Arnd <><
^ permalink raw reply
* [help]about amcc440
From: x he @ 2007-10-23 9:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 168 bytes --]
hi,everyone!
i've got a amcc440ep,and i buy a pci video-card, but it doesn't work.i want
to know which card is well supported by amcc440,does anyone knows? thank you
!
[-- Attachment #2: Type: text/html, Size: 183 bytes --]
^ permalink raw reply
* Re: Problems with allyesconfig kernel build
From: Alan Modra @ 2007-10-23 10:19 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Andrew Morton
In-Reply-To: <20071023140231.12698d1c.sfr@canb.auug.org.au>
On Tue, Oct 23, 2007 at 02:02:31PM +1000, Stephen Rothwell wrote:
> Anyone have any ideas?
The segfault with --emit-relocs and complaints about .fixup are linker
bugs. I'm about the commit fixes for both of these problems.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Kernel function having physical address. how?
From: Barisa Kisku @ 2007-10-23 10:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
hi,
I have ported linux-2.6.20 in cutom board based on MPC860.Kernel with the
KERNELBASE as default 0xc00000000.
uImage is downloaded at some address and booted with "bootm"
command.Kernelis uncompressed and loaded at
0x00000000.All the kernel function is now having physical address (e.g.
0x000020c8 instead of 0xc00020c8, which
is given by compiler).I think this required, to run kernel before MMU is on,
but how this change in assembled code happens.
Does u-boot do this when uncompressing and loading the kernel. Please
comment.
thanks in advance.
Barisa
[-- Attachment #2: Type: text/html, Size: 694 bytes --]
^ permalink raw reply
* Re: Please pull from 'for-2.6.24' branch of 4xx tree
From: Josh Boyer @ 2007-10-23 12:06 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071019163119.62eec6f0@weaponx.rchland.ibm.com>
On Fri, 19 Oct 2007 16:31:19 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> Hi Paul,
>
> Please pull from
>
> master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
>
> to pick up a handful of fixes for 4xx. These are mostly to enable the
> ibm_newemac driver for the various boards. Since a few patches to the
> driver are needed from Linus' tree, the branch is based off of his
> latest tree as of this morning.
Ping on this? I'd like to get these into Linus' tree before the merge
window closes so we have somewhat usable 4xx support in arch/powerpc.
josh
^ permalink raw reply
* Please pull powerpc.git merge branch again
From: Paul Mackerras @ 2007-10-23 12:27 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Since the pull request I sent earlier today, I have added some more
commits to the powerpc.git merge branch, so if you have already done
the pull, please do another
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
There are 7 commits from Josh Boyer and Valentine Barshak that fix
some bugs on the 4xx embedded powerpc boards, and allow them to use
the ibm_newemac driver that has gone in recently via Jeff Garzik's
tree.
Thanks,
Paul.
arch/powerpc/Kconfig.debug | 1
arch/powerpc/boot/dts/bamboo.dts | 10 ++-
arch/powerpc/boot/dts/sequoia.dts | 14 +++-
arch/powerpc/boot/dts/walnut.dts | 12 +++
arch/powerpc/boot/treeboot-walnut.c | 6 +-
arch/powerpc/configs/bamboo_defconfig | 114 +++++++++++++++++++-------------
arch/powerpc/configs/ebony_defconfig | 115 +++++++++++++++++++-------------
arch/powerpc/configs/walnut_defconfig | 94 +++++++++++++++-----------
arch/powerpc/platforms/40x/Kconfig | 1
arch/powerpc/platforms/44x/Kconfig | 8 +-
arch/powerpc/platforms/Kconfig.cputype | 1
11 files changed, 230 insertions(+), 146 deletions(-)
Josh Boyer (4):
[POWERPC] 4xx: Enable EMAC on the PPC 440GP Ebony board
[POWERPC] 4xx: Fix timebase clock selection on Walnut
[POWERPC] 4xx: Enable EMAC for PPC405 Walnut board
[POWERPC] 4xx: Enable EMAC on Bamboo board
Valentine Barshak (3):
[POWERPC] 4xx: Add RGMII support for Sequoia 440EPx
[POWERPC] 4xx: Enable NEW EMAC support for Sequoia 440EPx.
[POWERPC] 4xx: Split early debug output and early boot console for 44x
^ permalink raw reply
* Re: [PATCH 3/4] Device tree bindings for Xilinx devices
From: Josh Boyer @ 2007-10-23 12:36 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <20071023042741.30309.52869.stgit@trillian.cg.shawcable.net>
On Mon, 22 Oct 2007 22:27:41 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Acked-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
This looks pretty good to me.
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
> ---
>
> Documentation/powerpc/booting-without-of.txt | 261 ++++++++++++++++++++++++++
> 1 files changed, 261 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index a96e853..59df69d 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -52,6 +52,7 @@ Table of Contents
> i) Freescale QUICC Engine module (QE)
> j) CFI or JEDEC memory-mapped NOR flash
> k) Global Utilities Block
> + l) Xilinx IP cores
>
> VII - Specifying interrupt information for devices
> 1) interrupts property
> @@ -2242,6 +2243,266 @@ platforms are moved over to use the flattened-device-tree model.
> available.
> For Axon: 0x0000012a
>
> + l) Xilinx IP cores
> +
> + The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
> + in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
> + of standard device types (network, serial, etc.) and miscellanious
> + devices (gpio, LCD, spi, etc). Also, since these devices are
> + implemented within the fpga fabric every instance of the device can be
> + synthesised with different options that change the behaviour.
> +
> + Each IP-core has a set of parameters which the FPGA designer can use to
> + control how the core is synthesized. Historically, the EDK tool would
> + extract the device parameters relevant to device drivers and copy them
> + into an 'xparameters.h' in the form of #define symbols. This tells the
> + device drivers how the IP cores are configured, but it requres the kernel
> + to be recompiled every time the FPGA bitstream is resynthesized.
> +
> + The new approach is to export the parameters into the device tree and
> + generate a new device tree each time the FPGA bitstream changes. The
> + parameters which used to be exported as #defines will now become
> + properties of the device node. In general, device nodes for IP-cores
> + will take the following form:
> +
> + (name)@(base-address) {
> + compatible = "xlnx,(ip-core-name)-(HW_VER)"
> + [, (list of compatible devices), ...];
> + reg = <(baseaddr) (size)>;
> + interrupt-parent = <&interrupt-controller-phandle>;
> + interrupts = < ... >;
> + xlnx,(parameter1) = "(string-value)";
> + xlnx,(parameter2) = <(int-value)>;
> + };
> +
> + (ip-core-name): the name of the ip block (given after the BEGIN
> + directive in system.mhs). Should be in lowercase
> + and all underscores '_' converted to dashes '-'.
> + (name): is derived from the "PARAMETER INSTANCE" value.
> + (parameter#): C_* parameters from system.mhs. The C_ prefix is
> + dropped from the parameter name, the name is converted
> + to lowercase and all underscore '_' characters are
> + converted to dashes '-'.
> + (baseaddr): the C_BASEADDR parameter.
> + (HW_VER): from the HW_VER parameter.
> + (size): equals C_HIGHADDR - C_BASEADDR + 1
> +
> + Typically, the compatible list will include the exact IP core version
> + followed by an older IP core version which implements the same
> + interface or any other device with the same interface.
> +
> + 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
> +
> + For example, the following block from system.mhs:
> +
> + BEGIN opb_uartlite
> + PARAMETER INSTANCE = opb_uartlite_0
> + PARAMETER HW_VER = 1.00.b
> + PARAMETER C_BAUDRATE = 115200
> + PARAMETER C_DATA_BITS = 8
> + PARAMETER C_ODD_PARITY = 0
> + PARAMETER C_USE_PARITY = 0
> + PARAMETER C_CLK_FREQ = 50000000
> + PARAMETER C_BASEADDR = 0xEC100000
> + PARAMETER C_HIGHADDR = 0xEC10FFFF
> + BUS_INTERFACE SOPB = opb_7
> + PORT OPB_Clk = CLK_50MHz
> + PORT Interrupt = opb_uartlite_0_Interrupt
> + PORT RX = opb_uartlite_0_RX
> + PORT TX = opb_uartlite_0_TX
> + PORT OPB_Rst = sys_bus_reset_0
> + END
> +
> + becomes the following device tree node:
> +
> + opb-uartlite-0@ec100000 {
> + device_type = "serial";
> + compatible = "xlnx,opb-uartlite-1.00.b";
> + reg = <ec100000 10000>;
> + interrupt-parent = <&opb-intc>;
> + interrupts = <1 0>; // got this from the opb_intc parameters
> + current-speed = <d#115200>; // standard serial device prop
> + clock-frequency = <d#50000000>; // standard serial device prop
> + xlnx,data-bits = <8>;
> + xlnx,odd-parity = <0>;
> + xlnx,use-parity = <0>;
> + };
> +
> + Some IP cores actually implement 2 or more logical devices. In this case,
> + the device should still describe the whole IP core with a single node
> + and add a child node for each logical device. The ranges property can
> + be used to translate from parent IP-core to the registers of each device.
> + (Note: this makes the assumption that both logical devices have the same
> + bus binding. If this is not true, then separate nodes should be used for
> + each logical device). The 'cell-index' property can be used to enumerate
> + logical devices within an IP core. For example, the following is the
> + system.mhs entry for the dual ps2 controller found on the ml403 reference
> + design.
> +
> + BEGIN opb_ps2_dual_ref
> + PARAMETER INSTANCE = opb_ps2_dual_ref_0
> + PARAMETER HW_VER = 1.00.a
> + PARAMETER C_BASEADDR = 0xA9000000
> + PARAMETER C_HIGHADDR = 0xA9001FFF
> + BUS_INTERFACE SOPB = opb_v20_0
> + PORT Sys_Intr1 = ps2_1_intr
> + PORT Sys_Intr2 = ps2_2_intr
> + PORT Clkin1 = ps2_clk_rx_1
> + PORT Clkin2 = ps2_clk_rx_2
> + PORT Clkpd1 = ps2_clk_tx_1
> + PORT Clkpd2 = ps2_clk_tx_2
> + PORT Rx1 = ps2_d_rx_1
> + PORT Rx2 = ps2_d_rx_2
> + PORT Txpd1 = ps2_d_tx_1
> + PORT Txpd2 = ps2_d_tx_2
> + END
> +
> + It would result in the following device tree nodes:
> +
> + opb_ps2_dual_ref_0@a9000000 {
> + ranges = <0 a9000000 2000>;
> + // If this device had extra parameters, then they would
> + // go here.
> + ps2@0 {
> + compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
> + reg = <0 40>;
> + interrupt-parent = <&opb-intc>;
> + interrupts = <3 0>;
> + cell-index = <0>;
> + };
> + ps2@1000 {
> + compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
> + reg = <1000 40>;
> + interrupt-parent = <&opb-intc>;
> + interrupts = <3 0>;
> + cell-index = <0>;
> + };
> + };
> +
> + Also, the system.mhs file defines bus attachments from the processor
> + to the devices. The device tree structure should reflect the bus
> + attachments. Again an example; this system.mhs fragment:
> +
> + BEGIN ppc405_virtex4
> + PARAMETER INSTANCE = ppc405_0
> + PARAMETER HW_VER = 1.01.a
> + BUS_INTERFACE DPLB = plb_v34_0
> + BUS_INTERFACE IPLB = plb_v34_0
> + END
> +
> + BEGIN opb_intc
> + PARAMETER INSTANCE = opb_intc_0
> + PARAMETER HW_VER = 1.00.c
> + PARAMETER C_BASEADDR = 0xD1000FC0
> + PARAMETER C_HIGHADDR = 0xD1000FDF
> + BUS_INTERFACE SOPB = opb_v20_0
> + END
> +
> + BEGIN opb_uart16550
> + PARAMETER INSTANCE = opb_uart16550_0
> + PARAMETER HW_VER = 1.00.d
> + PARAMETER C_BASEADDR = 0xa0000000
> + PARAMETER C_HIGHADDR = 0xa0001FFF
> + BUS_INTERFACE SOPB = opb_v20_0
> + END
> +
> + BEGIN plb_v34
> + PARAMETER INSTANCE = plb_v34_0
> + PARAMETER HW_VER = 1.02.a
> + END
> +
> + BEGIN plb_bram_if_cntlr
> + PARAMETER INSTANCE = plb_bram_if_cntlr_0
> + PARAMETER HW_VER = 1.00.b
> + PARAMETER C_BASEADDR = 0xFFFF0000
> + PARAMETER C_HIGHADDR = 0xFFFFFFFF
> + BUS_INTERFACE SPLB = plb_v34_0
> + END
> +
> + BEGIN plb2opb_bridge
> + PARAMETER INSTANCE = plb2opb_bridge_0
> + PARAMETER HW_VER = 1.01.a
> + PARAMETER C_RNG0_BASEADDR = 0x20000000
> + PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
> + PARAMETER C_RNG1_BASEADDR = 0x60000000
> + PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
> + PARAMETER C_RNG2_BASEADDR = 0x80000000
> + PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
> + PARAMETER C_RNG3_BASEADDR = 0xC0000000
> + PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
> + BUS_INTERFACE SPLB = plb_v34_0
> + BUS_INTERFACE MOPB = opb_v20_0
> + END
> +
> + Gives this device tree (some properties removed for clarity):
> +
> + plb-v34-0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "ibm,plb";
> + ranges; // 1:1 translation
> +
> + plb-bram-if-cntrl-0@ffff0000 {
> + reg = <ffff0000 10000>;
> + }
> +
> + opb-v20-0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <20000000 20000000 20000000
> + 60000000 60000000 20000000
> + 80000000 80000000 40000000
> + c0000000 c0000000 20000000>;
> +
> + opb-uart16550-0@a0000000 {
> + reg = <a00000000 2000>;
> + };
> +
> + opb-intc-0@d1000fc0 {
> + reg = <d1000fc0 20>;
> + };
> + };
> + };
> +
> + That covers the general approach to binding xilinx IP cores into the
> + device tree. The following are bindings for specific devices:
> +
> + i) Xilinx ML300 Framebuffer
> +
> + Simple framebuffer device from the ML300 reference design (also on the
> + ML403 reference design as well as others).
> +
> + Optional properties:
> + - resolution = <xres yres> : pixel resolution of framebuffer. Some
> + implementations use a different resolution.
> + Default is <d#640 d#480>
> + - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
> + Default is <d#1024 d#480>.
> + - rotate-display (empty) : rotate display 180 degrees.
> +
> + ii) Xilinx SystemACE
> +
> + The Xilinx SystemACE device is used to program FPGAs from an FPGA
> + bitstream stored on a CF card. It can also be used as a generic CF
> + interface device.
> +
> + Optional properties:
> + - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
> +
> + iii) Xilinx EMAC and Xilinx TEMAC
> +
> + Xilinx Ethernet devices. In addition to general xilinx properties
> + listed above, nodes for these devices should include a phy-handle
> + property, and may include other common network device properties
> + like local-mac-address.
> +
> + iv) Xilinx Uartlite
> +
> + Xilinx uartlite devices are simple fixed speed serial ports.
> +
> + Requred properties:
> + - current-speed : Baud rate of uartlite
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
>
^ permalink raw reply
* [PATCH] [POWERPC] Update prpmc2800_defconfig
From: Dale Farnsworth @ 2007-10-23 13:21 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
This gets the prpmc2800 booting again.
arch/powerpc/configs/prpmc2800_defconfig | 147 ++++++++++++++++--------------
1 files changed, 78 insertions(+), 69 deletions(-)
diff --git a/arch/powerpc/configs/prpmc2800_defconfig b/arch/powerpc/configs/prpmc2800_defconfig
index 3e87faf..92bca4f 100644
--- a/arch/powerpc/configs/prpmc2800_defconfig
+++ b/arch/powerpc/configs/prpmc2800_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc4
-# Tue Aug 28 21:24:45 2007
+# Linux kernel version: 2.6.23
+# Tue Oct 23 04:56:05 2007
#
# CONFIG_PPC64 is not set
@@ -15,6 +15,7 @@ CONFIG_6xx=y
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
@@ -22,8 +23,13 @@ CONFIG_PPC_STD_MMU_32=y
CONFIG_NOT_COHERENT_CACHE=y
CONFIG_CHECK_CACHE_COHERENCY=y
CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -66,6 +72,10 @@ CONFIG_POSIX_MQUEUE=y
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_CGROUPS is not set
+CONFIG_FAIR_GROUP_SCHED=y
+CONFIG_FAIR_USER_SCHED=y
+# CONFIG_FAIR_CGROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
@@ -85,7 +95,6 @@ CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
-CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
@@ -119,16 +128,21 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Platform support
#
-# CONFIG_PPC_MULTIPLATFORM is not set
-CONFIG_EMBEDDED6xx=y
+CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_PPC_82xx is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_86xx is not set
+CONFIG_CLASSIC32=y
+# CONFIG_PPC_CHRP is not set
# CONFIG_PPC_MPC52xx is not set
# CONFIG_PPC_MPC5200 is not set
+# CONFIG_PPC_EFIKA is not set
+# CONFIG_PPC_LITE5200 is not set
+# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PQ2ADS is not set
+CONFIG_EMBEDDED6xx=y
# CONFIG_LINKSTATION is not set
# CONFIG_MPC7448HPC2 is not set
# CONFIG_PPC_HOLLY is not set
@@ -144,6 +158,7 @@ CONFIG_MV64X60=y
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
+# CONFIG_TAU is not set
# CONFIG_CPM2 is not set
# CONFIG_FSL_ULI1575 is not set
@@ -151,6 +166,10 @@ CONFIG_MV64X60=y
# Kernel options
#
CONFIG_HIGHMEM=y
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
@@ -172,6 +191,7 @@ CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
+# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
@@ -180,6 +200,8 @@ CONFIG_VIRT_TO_BUS=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
+CONFIG_SUSPEND_UP_POSSIBLE=y
+CONFIG_HIBERNATION_UP_POSSIBLE=y
# CONFIG_SECCOMP is not set
CONFIG_WANT_DEVICE_TREE=y
CONFIG_DEVICE_TREE="prpmc2800.dts"
@@ -197,10 +219,6 @@ CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
-
-#
-# PCCARD (PCMCIA/CardBus) support
-#
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
@@ -215,7 +233,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
-CONFIG_TASK_SIZE=0x80000000
+CONFIG_TASK_SIZE=0xc0000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x00800000
@@ -257,6 +275,7 @@ CONFIG_SYN_COOKIES=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
+# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
@@ -282,10 +301,6 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
-
-#
-# QoS and/or fair queueing
-#
# CONFIG_NET_SCHED is not set
#
@@ -314,6 +329,7 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
#
# Generic Driver Options
#
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
@@ -337,6 +353,7 @@ CONFIG_MTD_BLOCK=y
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
#
# RAM/ROM/Flash chip drivers
@@ -369,6 +386,7 @@ CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set
#
@@ -438,6 +456,11 @@ CONFIG_IDE_PROC_FS=y
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
+# CONFIG_BLK_DEV_PLATFORM is not set
+
+#
+# PCI IDE chipsets support
+#
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_SHARE_IRQ is not set
CONFIG_IDEPCI_PCIBUS_ORDER=y
@@ -445,8 +468,6 @@ CONFIG_IDEPCI_PCIBUS_ORDER=y
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
-# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
-# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
@@ -474,7 +495,7 @@ CONFIG_BLK_DEV_PDC202XX_NEW=y
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
-# CONFIG_IDEDMA_IVB is not set
+CONFIG_IDE_ARCH_OBSOLETE_INIT=y
# CONFIG_BLK_DEV_HD is not set
#
@@ -512,6 +533,7 @@ CONFIG_BLK_DEV_SD=y
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
+# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
@@ -523,6 +545,7 @@ CONFIG_SCSI_LOWLEVEL=y
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
+# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
@@ -590,6 +613,7 @@ CONFIG_SATA_MV=y
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
+# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
@@ -603,14 +627,7 @@ CONFIG_SATA_MV=y
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_MD is not set
-
-#
-# Fusion MPT device support
-#
# CONFIG_FUSION is not set
-# CONFIG_FUSION_SPI is not set
-# CONFIG_FUSION_FC is not set
-# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
@@ -628,6 +645,8 @@ CONFIG_NETDEVICES=y
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
+# CONFIG_VETH is not set
+# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y
@@ -644,6 +663,7 @@ CONFIG_PHYLIB=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_FIXED_PHY is not set
+# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
@@ -652,13 +672,16 @@ CONFIG_MII=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
+# CONFIG_IBM_NEW_EMAC_ZMII is not set
+# CONFIG_IBM_NEW_EMAC_RGMII is not set
+# CONFIG_IBM_NEW_EMAC_TAH is not set
+# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
-# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
@@ -682,6 +705,7 @@ CONFIG_NETDEV_1000=y
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
+# CONFIG_E1000E is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
@@ -689,6 +713,7 @@ CONFIG_E1000=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
+# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
@@ -698,11 +723,14 @@ CONFIG_MV643XX_ETH=y
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
+# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
+# CONFIG_NIU is not set
# CONFIG_MLX4_CORE is not set
+# CONFIG_TEHUTI is not set
# CONFIG_TR is not set
#
@@ -748,7 +776,6 @@ CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
-# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
@@ -795,15 +822,12 @@ CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
-# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
-# CONFIG_AGP is not set
-# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
@@ -873,8 +897,6 @@ CONFIG_I2C_MV64XXX=y
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
-# CONFIG_SENSORS_ABITUGURU is not set
-# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
@@ -882,12 +904,12 @@ CONFIG_HWMON=y
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
-# CONFIG_SENSORS_ASB100 is not set
+# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
-# CONFIG_SENSORS_FSCHER is not set
-# CONFIG_SENSORS_FSCPOS is not set
+# CONFIG_SENSORS_F71882FG is not set
+# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
@@ -923,6 +945,13 @@ CONFIG_HWMON=y
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
+# CONFIG_WATCHDOG is not set
+
+#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+# CONFIG_SSB is not set
#
# Multifunction device drivers
@@ -939,16 +968,17 @@ CONFIG_HWMON=y
#
# Graphics support
#
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+# CONFIG_VGASTATE is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=y
+# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
-# CONFIG_VGASTATE is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=y
-# CONFIG_FB is not set
-# CONFIG_FB_IBM_GXT4500 is not set
#
# Console display driver support
@@ -964,6 +994,7 @@ CONFIG_DUMMY_CONSOLE=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
+# CONFIG_HIDRAW is not set
#
# USB Input Devices
@@ -1091,6 +1122,7 @@ CONFIG_RTC_INTF_DEV=y
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
+# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
CONFIG_RTC_DRV_MAX6900=y
# CONFIG_RTC_DRV_RS5C372 is not set
@@ -1120,19 +1152,6 @@ CONFIG_RTC_DRV_MAX6900=y
#
#
-# DMA Engine support
-#
-# CONFIG_DMA_ENGINE is not set
-
-#
-# DMA Clients
-#
-
-#
-# DMA Devices
-#
-
-#
# Userspace I/O
#
# CONFIG_UIO is not set
@@ -1149,7 +1168,6 @@ CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
-# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
@@ -1190,7 +1208,6 @@ CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
-CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set
#
@@ -1210,10 +1227,7 @@ CONFIG_RAMFS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
-
-#
-# Network File Systems
-#
+CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
@@ -1253,15 +1267,7 @@ CONFIG_MSDOS_PARTITION=y
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
-
-#
-# Native Language Support
-#
# CONFIG_NLS is not set
-
-#
-# Distributed Lock Manager
-#
# CONFIG_DLM is not set
# CONFIG_UCC_SLOW is not set
@@ -1279,11 +1285,9 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
-
-#
-# Instrumentation Support
-#
+CONFIG_INSTRUMENTATION=y
# CONFIG_PROFILING is not set
+# CONFIG_MARKERS is not set
#
# Kernel hacking
@@ -1295,7 +1299,10 @@ CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
+# CONFIG_SLUB_DEBUG_ON is not set
CONFIG_DEBUG_BUGVERBOSE=y
+# CONFIG_SAMPLES is not set
+# CONFIG_BOOTX_TEXT is not set
# CONFIG_PPC_EARLY_DEBUG is not set
#
@@ -1303,4 +1310,6 @@ CONFIG_DEBUG_BUGVERBOSE=y
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
+# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_CRYPTO is not set
+# CONFIG_PPC_CLOCK is not set
--
1.5.3.4
^ permalink raw reply related
* [PATCH] windfarm: fix windfarm thread freezer interaction
From: Johannes Berg @ 2007-10-23 12:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Rafael J. Wysocki, linuxppc-dev list
When I fixed the windfarm freezer interaction first in commit
1ed2ddf380e19dafeec2150ca709ef7f4a67cd21, an earlier patch than the one
I came up with after comments was committed. This has come back to haunt
us now because commit d5d8c5976d6adeddb8208c240460411e2198b393 changed
the freezer to no long send signals. Fix it by removing the windfarm
thread's signal logic and restoring the original try_to_freeze().
We could simply revert 1ed2ddf380e19dafeec2150ca709ef7f4a67cd21 now
but I feel that the assertion that no signal is delivered to the
windfarm thread needs not be there.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/macintosh/windfarm_core.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
--- linux-2.6-git.orig/drivers/macintosh/windfarm_core.c 2007-10-23 14:23:02.406437623 +0200
+++ linux-2.6-git/drivers/macintosh/windfarm_core.c 2007-10-23 14:25:28.745447695 +0200
@@ -94,7 +94,9 @@ static int wf_thread_func(void *data)
DBG("wf: thread started\n");
set_freezable();
- while(!kthread_should_stop()) {
+ while (!kthread_should_stop()) {
+ try_to_freeze();
+
if (time_after_eq(jiffies, next)) {
wf_notify(WF_EVENT_TICK, NULL);
if (wf_overtemp) {
@@ -116,12 +118,6 @@ static int wf_thread_func(void *data)
delay = next - jiffies;
if (delay <= HZ)
schedule_timeout_interruptible(delay);
-
- /* there should be no non-suspend signal, but oh well */
- if (signal_pending(current) && !try_to_freeze()) {
- printk(KERN_WARNING "windfarm: thread got sigl !\n");
- break;
- }
}
DBG("wf: thread stopped\n");
^ permalink raw reply
* [PATCH] [PPC/POWERPC] i8259: Add disable method
From: Aurelien Jarno @ 2007-10-23 13:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Since commit 76d2160147f43f982dfe881404cfde9fd0a9da21, the NE2000 card
is not working anymore on PPC and POWERPC and produces WATCHDOG
timeouts.
The patch below fixes that the same way it has been done on x86, x86_64
and MIPS.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
diff --git a/arch/powerpc/sysdev/i8259.c b/arch/powerpc/sysdev/i8259.c
index 7c1b27a..216c0f5 100644
--- a/arch/powerpc/sysdev/i8259.c
+++ b/arch/powerpc/sysdev/i8259.c
@@ -137,6 +137,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
static struct irq_chip i8259_pic = {
.typename = " i8259 ",
.mask = i8259_mask_irq,
+ .disable = i8259_mask_irq,
.unmask = i8259_unmask_irq,
.mask_ack = i8259_mask_and_ack_irq,
};
diff --git a/arch/ppc/syslib/i8259.c b/arch/ppc/syslib/i8259.c
index 1e5a00a..559f27c 100644
--- a/arch/ppc/syslib/i8259.c
+++ b/arch/ppc/syslib/i8259.c
@@ -127,6 +127,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
static struct irq_chip i8259_pic = {
.typename = " i8259 ",
.mask = i8259_mask_irq,
+ .disable = i8259_mask_irq,
.unmask = i8259_unmask_irq,
.mask_ack = i8259_mask_and_ack_irq,
};
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply related
* Re: libfdt: Make fdt_string() return a const pointer
From: Jon Loeliger @ 2007-10-23 13:54 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071023032126.GL31839@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> >
> > Applied.
>
> But apparently not pushed out to the public tree...
Oh, sorry. I got side-tracked...
Coming up...
jdl
^ permalink raw reply
* Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
From: Segher Boessenkool @ 2007-10-23 13:59 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200710222012.20316.yur@emcraft.com>
>>>> The following patch adds support for 256KB PAGE_SIZE on ppc44x-
>>>> based boards.
>>>> The applications to be run on the kernel with 256KB PAGE_SIZE have
>>>> to be
>>>> built using the modified version of binutils, where the MAXPAGESIZE
>>>> definition is set to 0x40000 (as opposite to standard 0x10000).
>>>
>>> Have you measured the performance using a 64kB page size? If so, how
>>> does it compare with the 256kB page size?
>>
>> I was wondering about this as well? Isn't this technically in
>> violation of the ABI?
>
> No it isn't the violation.
>
> As stated in "System V ABI. PowerPC processor supplement"
> (on which the "Linux Standard Base Core Specification for PPC32"
> is based): " ... Virtual addresses and file offsets for the PowerPC
> processor family
> segments are congruent modulo 64 Kbytes (0x10000) or larger powers of
> 2...".
>
> So, 256 Kbytes is just a larger case.
If I understand you correctly, the only problem with existing binaries
is that the ELF segments are aligned to 64kB, but not necessarily to
256kB. Couldn't you handle this as a special case, for example by
mapping the "ends" of such an unaligned segment with normal 4kB pages?
That way, a new binutils isn't required to get a big part of the
benefit,
and importantly, existing shared library binaries will work with your
apps.
Segher
^ permalink raw reply
* Re: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-23 14:01 UTC (permalink / raw)
To: Michal Simek
Cc: microblaze-uclinux, linuxppc-dev, Wolfgang Reissnegger,
David Gibson
In-Reply-To: <1815.2979-14673-964852328-1193124877@seznam.cz>
On 10/23/07, Michal Simek <Monstr@seznam.cz> wrote:
> Hi David,
> I remove some labels from my generator. I created fake system with some peripherals.
> There are 3 buses and 3 bridges.
> Can you check it and tell me what is wrong?
>
> Thanks,
> Michal Simek
>
> / {
> model = "mONStR";
You should have a board-level compatible property here
> chosen {
> bootargs = "root=/dev/xsysace/disc0/part2";
> } ;
> cpus {
> #size-cells = <0>;
> #cpus = < 0 >;
> #address-cells = <1>;
> microblaze_0,5.00.c@0 {
Simply microblaze@0 will do.
> device_type = "cpu";
> reg = <0>;
> clock-frequency = <5f5e1000>;
> timebase-frequency = <1FCA055>;
> i-cache-line-size = <2000>;
> i-cache-size = <10>;
> d-cache-line-size = <2000>;
> d-cache-size = <10>;
> xilinx,pvr = <0>;
use 'xlnx,' for the prefix; this is a comment that I received on the
binding document that the stock ticker is an appropriate appreviation.
> xilinx,debug-enabled = <1>;
> xilinx,fsl-links = <0>;
> } ;
> } ;
>
You should have a parent 'plb' bus node for all these devices to be children of.
> ethernet@10060000 {
> compatible = "opb_ethernet_1.04.a","opb_ethernet";
- add manufacture prefix
- convert underscores to dashes
- drop "opb_ethernet"; there's no such thing
Just "xlnx,opb-ethernet-1.04.a" will do; or something like
"xlnx,opb-ethernet-1.04b","xlnx,opb-ethernet-1.04a" works too.
> interrupts = < 3 0 >;
> reg = < 10060000 10000 >;
> device_type = "network";
> xilinx,cam-exist = <0>;
> xilinx,dev-blk-id = <1>;
> xilinx,dev-mir-enable = <1>;
> xilinx,dma-present = <1>;
> xilinx,include-dev-pencoder = <1>;
> xilinx,ipif-rdfifo-depth = <8000>;
> xilinx,ipif-wrfifo-depth = <8000>;
> xilinx,mii-exist = <1>;
use 'xlnx,' for prefix.
> } ;
> memory@20000000 {
> memreg:reg = < 20000000 10000000 >;
> device_type = "memory";
> } ;
> serial@10030000 {
> compatible = "opb_uart16550_1.00.d","opb_uart16550";
'opb_uart16550' is bogus non-device; Always specify a version for IP
core compatible fields. There was some talk about defining a
'sparse16550' or some such value to reflect things that were almost a
16550 but had a different register layout; but in the mean time leave
it out.
- change '_' to '-', add 'xlnx,'; etc.
> reg = < 10030000 10000 >;
> device_type = "serial";
> } ;
> opb_timer@10020000 {
> compatible = "opb_timer_1.00.b","opb_timer";
ditto
> interrupts = < 0 0 >;
> reg = < 10020000 10000 >;
> xilinx,count-width = <20>;
> xilinx,one-timer-only = <0>;
> } ;
> opb_opb_lite@30000000 {
- change '_' to '-'
> ranges = < 0 30000000 10000000 >;
> opb_gpio@30020000 {
Since you're bus uses the ranges property value to translate; the
device address should reflect the offset off the base of the bus:
opb_gpio@20000
If instead your ranges property was empty then the full address still
works. Address translation makes sense for the opb-opb-lite because
it's only got one translation range. However, the plb-opb bridge
covers multiple ranges so it's probably easier to leave out the
translation.
> compatible = "opb_gpio_3.01.b","opb_gpio";
> reg = < 30020000 10000 >;
Same comment as above; reg = <20000 10000>; These comments go for all
the nodes below.
> xilinx,gpio-width = <4>;
> xilinx,is-dual = <0>;
> } ;
> i2c@30030000 {
> compatible = "opb_iic_1.02.a","opb_iic";
> reg = < 30030000 10000 >;
> device_type = "i2c";
> } ;
>
> opb_gpio@30010000 {
> compatible = "opb_gpio_3.01.b","opb_gpio";
> reg = < 30010000 10000 >;
> xilinx,gpio-width = <20>;
> xilinx,is-dual = <0>;
> } ;
> ethernet@30040000 {
> compatible = "opb_ethernetlite_1.01.b","opb_ethernetlite";
> reg = < 30040000 10000 >;
> device_type = "network";
> xilinx,duplex = <1>;
> xilinx,rx-ping-pong = <0>;
> xilinx,tx-ping-pong = <0>;
> } ;
> opb_sysace@30050000 {
> compatible = "opb_sysace_1.00.c","opb_sysace";
> reg = < 30050000 10000 >;
> xilinx,mem-width = <10>;
> } ;
> opb_ps2_dual_ref@30060000 {
> compatible = "opb_ps2_dual_ref_1.00.a","opb_ps2_dual_ref";
> interrupts = < 2 0 >;
> interrupts = < 1 0 >;
> reg = < 30060000 10000 >;
> } ;
> };
> opb_intc@10010000 {
> compatible = "opb_intc_1.00.c","opb_intc";
> reg = < 10010000 10000 >;
> } ;
> opb_mdm@10050000 {
> compatible = "opb_mdm_2.00.a","opb_mdm";
> reg = < 10050000 10000 >;
> xilinx,mb-dbg-ports = <1>;
> xilinx,uart-width = <8>;
> xilinx,use-uart = <1>;
> } ;
> serial@10040000 {
> compatible = "opb_uartlite_1.00.b","opb_uartlite";
> interrupts = < 4 0 >;
> reg = < 10040000 10000 >;
> device_type = "serial";
> xilinx,baudrate = <2580>;
> xilinx,data-bits = <8>;
> xilinx,clk-freq = <5f5e100>;
> xilinx,odd-parity = <0>;
> xilinx,use-parity = <0>;
My patch to booting-without-of says that you should have a
'current-speed' property (instead of xlnx,baudrate) because it's a
standard property; but 'xlnx,baudrate' might be a suitable alternative
because this is a fixed speed device. Segher, David; what say you?
> } ;
> opb2plb_bridge@80000000 {
> ranges = < 0 80000000 80000000 >;
> serial@a0020000 {
> compatible = "plb_uart16550_1.00.c","plb_uart16550";
> reg = < a0020000 10000 >;
> device_type = "serial";
> } ;
> plb_gpio@a0010000 {
> compatible = "plb_gpio_1.00.b","plb_gpio";
> reg = < a0010000 10000 >;
> xilinx,gpio-width = <20>;
> xilinx,is-dual = <0>;
> } ;
> ethernet@a0000000 {
> compatible = "plb_ethernet_1.01.a","plb_ethernet";
> reg = < a0000000 10000 >;
> device_type = "network";
> } ;
> plb2opb_bridge@10000000 {
> ranges = < 0 10000000 10000000 >;
> ranges = < 1 20000000 10000000 >;
> };
There are no nodes on this bus. What is the intended usage? Also,
you cannot have two properties with the same name, I think the syntax
you want is:
ranges = <0 10000000 10000000 2 20000000 10000000>;
Also, these values won't work. They state that you've got two address
range translations. The first translates from address 10000000 to
address 0 (which makes sense). The second translates from address
20000000 to address 1 (which overlaps the first region, only offset by
1 byte).
> cpus {
> #size-cells = <0>;
> #cpus = < 1 >;
> #address-cells = <1>;
> ppc405_0,405@1 {
> device_type = "cpu";
> reg = <0>;
> clock-frequency = <5f5e1000>;
> timebase-frequency = <1FCA055>;
> } ;
> } ;
This is weird. Is this representing a design with both a ppc and a
microblaze? If so; I would generate 2 device trees. One for each
processor.
> };
> } ;
>
BTW, Thanks for all this work
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
From: Segher Boessenkool @ 2007-10-23 14:00 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071018070139.339e2efb@weaponx.rchland.ibm.com>
> Requiring a modified binutils makes me a bit nervous though.
As long as those binutils modifications are sent upstream, I don't
see the problem? If not, this would be a blocker IMHO.
Segher
^ permalink raw reply
* Re: [PATCH] DTC: Remove the need for the GLR Parser.
From: Jon Loeliger @ 2007-10-23 14:24 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071023025412.GI31839@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> On Mon, Oct 22, 2007 at 04:13:54PM -0500, Jon Loeliger wrote:
> > Previously, there were a few shift/reduce and reduce/reduce
> > errors in the grammar that were being handled by the not-so-popular
> > GLR Parser technique.
>
> I haven't actually heard anyone whinge about glr-parser...
I have. :-)
> > Flip a right-recursive stack-abusing rule into a left-recursive
> > stack-friendly rule and clear up three messes in one shot: No more
> > conflicts, no need for the GLR parser, and friendlier stackness.
>
> Ouch. I'm feeling a bit stupid now,
Absolutely no need for that.
> I really thought our conflicts
> were somewhere else. Specifically I thought the problem was that we
> needed to look ahead more tokens that we were able to differentiate
> between property and subnode definitions, i.e. between:
> label propname =
> and
> label propname {
Yes, it was. When you compute the closure of the propdef with
the rule as a right-recursive, that's when you get the conflict.
> Well, regardless of that, I have a few concerns.
>
> First, a trivial one: I remember leaving this as a right-recursion,
> despite the stack-nastiness, because that way the properties end up in
> the same order as in the source. I think that behaviour is worth
> preserving, but of course we can do it with left-recursion by changing
> chain_property() to add to the end of the list instead of the
> beginning.
Understood. And I wrestled with that as well. In fact, I even
wrote the reverse_properties() function, which I will include,
and used it initially. However, several test failed. So I
removed it, and it all started happily working again.
> Also, if we're going to avoid right-recursion here, we
> should do so for the 'subnodes' productions as well, which is
> completely analogous.
Well, isn't _that_ an interesting observation... :-)
I'll add it to the grand "DTC To Do" list.
> More significantly, I don't know that we want to burn our bridges with
> glr-parser. glr-parser is a beautiful algorithm which means we can
> use essentially whatever form of grammar is the easiest to work with
> without having to fiddle about to ensure it's LALR(1). This could
> still be useful if we encounter some less easily finessable grammar
> construct in future.
I'm not saying we can't use it in the future, as needed! I'm just
saying it isn't strictly necessary now.
> And even without glr-parser, I'm still uncomfortable with the
> lexer<->parser execution ordering issues with the current
> /dts-version/ proposal. It may now be true that the order is
> guaranteed to be correct, but it's still not exactly obvious.
I'm fine with it, and though I read your words, I'm not really
sure why you are not.... In the long term, maybe think of it
as a temporary hack then. We'll convert the existing DTS files
over to the new version, and then deprecate the "dts-version 0"
files and support and it will all go away relatively soon.
> It seems to me that the version change introduces a lexical change to
> the input format, and should therefore be handled at the lexical
> level. And I think there are other potential advantages to parsing
> the version identifier as a token, rather than as an integer (such as
> being able to define entirely different grammars for different
> versions, if we have to).
Version symbol or number, that's still not precluded, I don't think.
jdl
^ permalink raw reply
* Re: [PATCH] DTC: Remove the need for the GLR Parser.
From: Segher Boessenkool @ 2007-10-23 14:41 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1IkKge-00060g-2l@jdl.com>
>>> Flip a right-recursive stack-abusing rule into a left-recursive
>>> stack-friendly rule and clear up three messes in one shot: No more
>>> conflicts, no need for the GLR parser, and friendlier stackness.
>>
>> Ouch. I'm feeling a bit stupid now,
>
> Absolutely no need for that.
If you haven't had "exp := aexp | exp aexp" beaten into you with
a big stick, maybe you should be happy about that ("'s got a nail
in it!") :-)
>> And even without glr-parser, I'm still uncomfortable with the
>> lexer<->parser execution ordering issues with the current
>> /dts-version/ proposal. It may now be true that the order is
>> guaranteed to be correct, but it's still not exactly obvious.
If you require /dts-version/ (and similar global dtc-control stmts)
to be at the start of the file, can't you avoid this ordering problem
by starting to parse the file with a simple (hand-written) parser
(which would handle these statements) and only when you cannot parse
any more switch to the "normal" parser (which won't handle them)?
Or is this a stupid suggestion :-)
Segher
^ permalink raw reply
* Re: [PATCH] DTC: Remove the need for the GLR Parser.
From: Jon Loeliger @ 2007-10-23 14:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <cace68e0fe3e4e257b7c63d18c805f18@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
>
> >> And even without glr-parser, I'm still uncomfortable with the
> >> lexer<->parser execution ordering issues with the current
> >> /dts-version/ proposal. It may now be true that the order is
> >> guaranteed to be correct, but it's still not exactly obvious.
>
> If you require /dts-version/ (and similar global dtc-control stmts)
> to be at the start of the file, can't you avoid this ordering problem
> by starting to parse the file with a simple (hand-written) parser
> (which would handle these statements) and only when you cannot parse
> any more switch to the "normal" parser (which won't handle them)?
> Or is this a stupid suggestion :-)
My concern here is that I think we are attempting to make
this significantly more complex than it needs to be.
We have a pretty good KISS opportunity here, and I've shown
it to be working so far. Longer term, all this cruft will
go away and it will become a moot point anyway.
jdl
^ permalink raw reply
* Root file system for powerpc 74xx board
From: mahendra varman @ 2007-10-23 14:51 UTC (permalink / raw)
To: XFree86, xorg, linuxppc-embedded, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
Hi All
Iam a beginner/Learner in this field.
I have Linux running on an intel x86 machine with cross development
environment.
I want to host 74xx file system with Xfree86 and library support on the
intel machine.
I will boot the file system using NFS to the 74xx system.
How to create/extract the file system with xfree86 support from fedora file
system ?
Please help me on the above
Thanks in advance
Mahendra
[-- Attachment #2: Type: text/html, Size: 505 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox