Hello Vitaly,
Vitaly Bordug wrote:
> On Tue, 18 Mar 2008 09:04:14 +0100
> Heiko Schocher wrote:
[...]
>> OK. Another thought about this. Shouldnt this table go in the dts?
>> A device node like
>>
>> cpm_pin {
>> pins = ;
>> };
>>
>> would be nice, or?
>>
> This has been a disputable question
On Tuesday 18 March 2008, Segher Boessenkool wrote:
> > + L2C0: [EMAIL PROTECTED] {
> > + compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
> > + dcr-reg = <20 8 /* Internal SRAM DCR's */
> > + 30 8>; /* L2 cache DCR's */
>
>
On Wednesday 19 March 2008, David Gibson wrote:
> On Tue, Mar 18, 2008 at 02:37:46PM +0100, Stefan Roese wrote:
> > This patch adds the L2 cache node to the Taishan 440GX dts file.
> >
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/dts/taishan.dts | 10
On Wed, 2008-03-19 at 17:10 +1100, Michael Ellerman wrote:
> The PCI bridge representing the PCIE root complex on Axon, contains device
> BARs for a memory range and ROM that define inbound accesses. This confuses
> the kernel resource management code, the resources need to be hidden when
> Axon i
The PCI bridge representing the PCIE root complex on Axon, contains device
BARs for a memory range and ROM that define inbound accesses. This confuses
the kernel resource management code, the resources need to be hidden when
Axon is a host bridge.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]
Forwarded Message
From: Michael Ellerman <[EMAIL PROTECTED]>
To: Paul Mackerras <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: [Cbe-oss-dev] [PATCH] Fix cell IOMMU code to cope with empty
dma-ranges, and non-PCI devices
Date: Fri, 14 Mar 2008 16:47:39 +1100 (EST)
The cell IOM
Sudhir Kumar writes:
> Unable to handle kernel paging request for data at address
> 0xd82e
Looks like some driver tried to access I/O port 0x2e without checking
whether there was possibly anything there first.
> Faulting instruction address: 0xc074ded8
> cpu 0x0: Vector: 300
On Tue, Mar 18, 2008 at 10:32 PM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hmm... interesting points. I guess my feeling was that XILINX_DRIVERS could
> be a more broadly configurable option, with some of these ideas in mind.
> Currently, it's hidden by default, but we could easil
Hmm... interesting points. I guess my feeling was that XILINX_DRIVERS could be
a more broadly configurable option, with some of these ideas in mind.
Currently, it's hidden by default, but we could easily change this to be
visible by default, or selected by a broader number of architectures.
On Tue, Feb 12, 2008 at 3:31 PM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
> In the future, this will be used to provide similar configuration for
> PowerPC and Microblaze. It may also be convenient for those using
> Xilinx cores as peripherals for external processors, rather than
> expli
On Tue, Mar 18, 2008 at 02:37:46PM +0100, Stefan Roese wrote:
> This patch adds the L2 cache node to the Taishan 440GX dts file.
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/taishan.dts | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
+ L2C0: [EMAIL PROTECTED] {
+ compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
+ dcr-reg = <20 8 /* Internal SRAM DCR's */
+ 30 8>;/* L2 cache DCR's */
The unit address is based on the _first_ entry in
On Wed, Mar 19, 2008 at 07:31:25AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-03-18 at 09:45 -0500, Nathan Lynch wrote:
> > The ibm,drc-names property of the root node should have "HEA" strings
> > in it on systems where EHEA can potentially be present.
>
> Ah good, I didn't know. That wi
Anton Vorontsov wrote:
On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
+arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(),
"If" isn't possible, order is guaranteed.
You use arch_initcall for both, so you're relying on link order. I
thin
On Tue, 2008-03-18 at 09:45 -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote:
> > > On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
> > > > Currently HEA requires 4K pages for IO resources. Just set the pages
On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
> >>>+arch_initcall(qe_init_gtm);
> >>If this happens before the gtm_init_gtm(),
> >
> >"If" isn't possible, order is guaranteed.
>
> You use arch_initcall for both, so you're relying on link order. I
> think th
Anton Vorontsov wrote:
+arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(),
"If" isn't possible, order is guaranteed.
You use arch_initcall for both, so you're relying on link order. I
think this at least merits a comment.
then np->data will not be set.
It's a bug i
On Tue, Mar 18, 2008 at 12:43:29PM -0500, Scott Wood wrote:
> On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
> > +Required properties:
> > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> > + GTMs).
> > + - reg : should cont
On Tue, Mar 11, 2008 at 08:24:13PM +0300, Anton Vorontsov wrote:
> qe_muram_offset is the reverse of the qe_muram_addr, will be
> used for the Freescale QE USB Host Controller driver.
>
> This patch also moves qe_muram_addr into the qe.h header, plus
> adds __iomem hints to use with sparse.
We sh
On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
> +Required properties:
> + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> + GTMs).
> + - reg : should contain gtm registers location and length (0x40).
> + - interrupts :
From: Grant Likely <[EMAIL PROTECTED]>
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.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
This has been tested on a Xilinx Vir
On Fri, Mar 07, 2008 at 05:59:03PM -0600, Andy Fleming wrote:
> Not all e300 cores support the performance monitors, and the ones
> that don't will be confused by the mf/mtpmr instructions. This
> allows the support to be optional, so the 8349 can turn it off
> while the 8379 can turn it on. Sadl
Wolfgang Denk wrote:
Dear Scott,
in message <[EMAIL PROTECTED]> you wrote:
Well, the device tree is a mechanism for communicating from the firmware
to the kernel, and if we could control the firmware better we'd just make
it set the pins properly to begin with. :-)
Is this just a comment, or
On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> I don't mind having a specific driver but I don't know anything about
> the hardware its creating the interface for so I need the community's
> help with that
Grant Likely schrieb:
On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
<[EMAIL PROTECTED]> wrote:
I've read some discussions about the "interrupt-map" attribute of the pci
node. I tried to follow Ben and David in their explanations - obviously I
didn't really get it.
Looks like there are a lo
On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
> > Grant,
> >
> > Yes, the Motion-PRO LED driver has been reworked and posted:
> > http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>
> Okay, I'
Currently fsl_elbc_nand doesn't initialize mtd->name, and this causes
nand_get_flash_type() to assign name that is equal to chip type, like
this:
[EMAIL PROTECTED]:~# cat /proc/mtd
dev:size erasesize name
mtd0: 0080 0001 "fe00.flash"
mtd1: 0200 4000 "NAND 32M
On Tue, 18 Mar 2008 10:46:55 +0100
Joakim Tjernlund wrote:
> The new Fixed PHY method, fixed-link property, isn't
> impl. for ucc_geth which makes fixed PHYs non functional.
> Add support for the new method to restore the Fixed PHY
> functionality.
>
Makes sense to me, but let's cc linuxppc-devel
On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
<[EMAIL PROTECTED]> wrote:
> I've read some discussions about the "interrupt-map" attribute of the pci
> node. I tried to follow Ben and David in their explanations - obviously I
> didn't really get it.
> Looks like there are a lot of people outside
Dear Scott,
in message <[EMAIL PROTECTED]> you wrote:
>
> Well, the device tree is a mechanism for communicating from the firmware
> to the kernel, and if we could control the firmware better we'd just make
> it set the pins properly to begin with. :-)
Is this just a comment, or do you oppose Hei
On Tue, 18 Mar 2008 09:04:14 +0100
Heiko Schocher wrote:
> Hello Stephen,
>
> Stephen Rothwell wrote:
> > On Tue, 18 Mar 2008 08:13:06 +0100 Heiko Schocher <[EMAIL PROTECTED]>
> > wrote:
> >> Stephen Rothwell wrote:
> >>> On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher <[EMAIL PROTECTED]>
> >>>
On Tue, Mar 18, 2008 at 06:58:14PM +0300, Anton Vorontsov wrote:
> Oops, forgot the NULL checking.
[snip]
> + if (priv->mtd.name)
> + kfree(priv->mtd.name);
> +
Not needed; kfree(NULL) is a no-op.
-Scott
___
Linuxppc-dev mailing list
Li
In message <[EMAIL PROTECTED]> you wrote:
> Hi,
> I found the following bug at kernel boot up on my power machine
> with 2.6.25-rc6 kernel.
>
> USB Mass Storage support registered.
> mice: PS/2 mouse device common for all mice
> Unable to handle kernel paging request for data at address
> 0xd8
Currently fsl_elbc_nand doesn't initialize mtd->name, and this causes
nand_get_flash_type() to assign name that is equal to chip type, like
this:
[EMAIL PROTECTED]:~# cat /proc/mtd
dev:size erasesize name
mtd0: 0080 0001 "fe00.flash"
mtd1: 0200 4000 "NAND 32M
On Tue, Mar 18, 2008 at 06:43:44PM +0300, Anton Vorontsov wrote:
> With this patch applied fsl_elbc_nand chip will have proper name:
>
>[EMAIL PROTECTED]:~# cat /proc/mtd
>dev:size erasesize name
>mtd0: 0080 0001 "fe00.flash"
>mtd1: 0200 4000 "e060.fl
This is needed to probe nor and nand flashes on the localbus.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c
b/arch/powerpc/platfor
Currently fsl_elbc_nand doesn't initialize mtd->name, and this causes
nand_get_flash_type() to assign name that is equal to chip type, like
this:
[EMAIL PROTECTED]:~# cat /proc/mtd
dev:size erasesize name
mtd0: 0080 0001 "fe00.flash"
mtd1: 0200 4000 "NAND 32M
Joakim Tjernlund wrote:
> I fixed it by adding a counter which aborts after 100 loops. If you
> could move along the 2 patches I sent today, "Add Fixed PHY support for
> ucc_geth" and "ucc_geth: Add 8 bytes to max TX frame for VLANs" into
> 2.6.25 that would be great :)
I have no control over tha
On Tue, 2008-03-18 at 09:32 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > Found it, the eth1 i/f on this board isn't working and does not generate
> > any clocks which makes ugeth_graceful_stop_tx() hang forever.
>
> Well, that doesn't make it very graceful, does it? :-)
Nope, :)
>
Grant Likely schrieb:
On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz
<[EMAIL PROTECTED]> wrote:
Grant,
sorry for having troubled you. Looks like the build system has been in an
invalid state...
After doing a git-pull and "make distclean" + "make mpc5200_defconfig" the
system is finally u
On Tue, Mar 18, 2008 at 09:04:14AM +0100, Heiko Schocher wrote:
> OK. Another thought about this. Shouldnt this table go in the dts?
> A device node like
>
> cpm_pin {
> pins = ;
> };
>
> would be nice, or?
Well, the device tree is a mechanism for communicating from the firmware
to the ker
On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
> Grant,
>
> Yes, the Motion-PRO LED driver has been reworked and posted:
> http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>
>
>
> > I need to look at it again,
> > but it is a lot of code for a ver
Benjamin Herrenschmidt wrote:
>
> On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote:
> > On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
> > > Currently HEA requires 4K pages for IO resources. Just set the pages
> > > size to
> > > IO to 4K.
> >
> > Well, that's too bad. Why
Joakim Tjernlund wrote:
> Found it, the eth1 i/f on this board isn't working and does not generate
> any clocks which makes ugeth_graceful_stop_tx() hang forever.
Well, that doesn't make it very graceful, does it? :-)
Can you fix this yourself, or do you want me to file an internal bug report?
On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz
<[EMAIL PROTECTED]> wrote:
>
> Grant,
>
> sorry for having troubled you. Looks like the build system has been in an
> invalid state...
>
> After doing a git-pull and "make distclean" + "make mpc5200_defconfig" the
> system is finally up and running.
Benjamin Herrenschmidt wrote:
http://marc.info/?l=linux-netdev&m=120449748701492&w=2
I sent it to Ben with netdev on CC because you asked the various people
sending NEWEMAC patches to you to find a single person.
So from now on, what are we going to do? It seems we're playing net
maintainer ru
This patch adds the L2 cache node to the Taishan 440GX dts file.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/taishan.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts
b/arch/powerpc/boot/dts/
This patch adds support for the 256k L2 cache found on some IBM/AMCC
4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
which currently "only" adds the L2 cache init code. Other common 4xx
stuff can be added later here.
The L2 cache handling code is just a copy of Eugene's code i
On Mon, 17 Mar 2008 20:42:14 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> > Dear Grant,
> >
> >
> > in message <[EMAIL PROTECTED]> you wrote:
> > >
> > > However, I have declined (for now) to pick up the defconfigs
Grant,
sorry for having troubled you. Looks like the build system has been in
an invalid state...
After doing a git-pull and "make distclean" + "make mpc5200_defconfig"
the system is finally up and running.
Using mpc5200-simple-platform machine description
Linux version 2.6.25-rc6-00978-
On Tue, 2008-03-18 at 09:29 +0100, Bartlomiej Sieka wrote:
> Grant Likely wrote:
> > The LED code just hasn't been picked up. IIRC, it was reworked to
> > make it a proper driver in drivers/leds.
>
> Yes, the Motion-PRO LED driver has been reworked and posted:
> http://patchwork.ozlabs.org/linuxp
On Mon, 2008-03-17 at 18:08 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f
> > that fixed that bug?
>
> Yep. Unfortunately, I don't really know enough about the ucc_geth driver to
> know what could be wrong. I ju
Grant,
I've pulled the latest git and built a mpc5200_simple system with a
minimal dts.
There's not a single char put on the console
Grant Likely schrieb:
On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
<[EMAIL PROTECTED]> wrote:
All,
I'm quite stuck in getting our MPC5200B based
Grant Likely wrote:
On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
[...]
It may be argued that this code should be moved somewhere else, but I
don't remeber to have seen any such review comments.
The LED code just hasn't been picked up. IIRC, it was reworked to
m
Grant Likely wrote:
On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
[...]
we were hoping that the changes would go upstream (in 2.6.25). I can see
that the .dts files for those boards are in the mainline already, but I
see no trace of for example _defconfig files
Hello,
Add support for the MPC852 based mgsuvd board from keymile
to arch/powerpc. Supported SMC1 (serial console),
SCC3 Ethernet (10Mbps hdx)
Signed-off-by: Heiko Schocher <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mgsuvd.dts | 158 +++
arch/powerpc/configs/mgsuvd_defconfig | 827
Hello Stephen,
Stephen Rothwell wrote:
> On Tue, 18 Mar 2008 08:13:06 +0100 Heiko Schocher <[EMAIL PROTECTED]> wrote:
>> Stephen Rothwell wrote:
>>> On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher <[EMAIL PROTECTED]> wrote:
>> [...]
+struct cpm_pin {
+ int port, pin, flags;
>>
Hi Heiko,
On Tue, 18 Mar 2008 08:13:06 +0100 Heiko Schocher <[EMAIL PROTECTED]> wrote:
>
> Stephen Rothwell wrote:
> > On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher <[EMAIL PROTECTED]> wrote:
> [...]
> >> +struct cpm_pin {
> >> + int port, pin, flags;
> >> +};
> >
> > I wish someone
Hello Stephen,
Stephen Rothwell wrote:
> On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher <[EMAIL PROTECTED]> wrote:
[...]
>> +struct cpm_pin {
>> +int port, pin, flags;
>> +};
>
> I wish someone would consolidate all these definitions of cpm_pin.
Hmm... do you mean something like,
59 matches
Mail list logo
