On Tue, 2008-03-18 at 00:06 -0400, Jeff Garzik wrote:
> 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.
> >>
> >>
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
0xd82e
Faulting instruction address: 0xc074ded
From: Paul Gortmaker <[EMAIL PROTECTED]>
The wrapper script didn't have entries for the TQM8540 board and the
SBC8548 or SBC8560 boards. I've assumed that the TQM8540 console is
8250 based and not CPM based by looking at its defconfig. There was
also a trailing * on the TQM8555 entry that I remo
On Mon, Mar 17, 2008 at 5:22 PM, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 4:46 PM, Paul Gortmaker
> > The wrapper script didn't have entries for the TQM8540 board and the
> > SBC8548 or SBC8560 boards. I've assumed that the TQM8540 console is
> > 8250 based
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
On Tue, 18 Mar 2008 13:41:40 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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.
> >
> > S
If dtc's command line arguments are invalid, it prints a usage message
and returns exit code 2. That's the same exit code as for a failed
check, which is potentially confusing if running dtc from an automated
harness. Therefore this patch changes the usage exit code to 3.
Signed-off-by: David Gi
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 penalize all platforms for it?
>
> I.e.: Nack
> 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 russian roulette fo
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 for those
> > boards and instead merged in the config features they require into the
> >
On Mon, Mar 17, 2008 at 03:19:45PM +0300, Alexandr Smirnov wrote:
> David,
>>> + /* Unfortunately, the specific model number is encoded in the
>>> +* soc node name in existing dts files -- once that is fixed,
>>> +* this can do a simple path lookup.
>>> +*/
>>>
>>
>> Since this i
On Mon, 17 Mar 2008 18:31:53 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt wrote:
> >> There's also the section mismatch patch I sent you. I don't care who's
> >> tree they go through, but I'd need to know either way so keep me in the
> >> loop please.
> >
> > Jeff, do yo
On Sun, Mar 16, 2008 at 11:27:09PM -0500, Anton Blanchard wrote:
>
> Since the PMU is an NMI now, it can come at any time we are only soft
> disabled. We must hard disable around the two places we allow the kernel
> stack SLB and r1 to go out of sync. Otherwise the PMU exception can
> force a kern
On Mon, 17 Mar 2008 17:38:21 -0500
Scott Wood wrote:
> On Sun, Mar 09, 2008 at 07:59:14PM +0300, Vitaly Bordug wrote:
> > I would like all the comments to be consistent C style (because
> > that's it for the most other dts'es).
>
> $ fgrep -rI // arch/powerpc/boot/dts/ | wc -l
> 539
>
So, we sho
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 penalize all platforms for it?
I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
waste tlb and erat
Dear Grant,
in message <[EMAIL PROTECTED]> you wrote:
>
> However, I have declined (for now) to pick up the defconfigs for those
> boards and instead merged in the config features they require into the
> mpc5200 defconfig. My primary reason for doing so is to increase the
> likelyhood that full
On Mon, Mar 17, 2008 at 11:46:39AM -0700, Dan Williams wrote:
> Looks good, makes me want to go back and cleanup iop-adma a bit. A
> few fyi's below, but no other review comments.
>
> > Note that this still needs to go on top of the powerpc.git tree due to the
> > pasemi_dma.h updates that this
Hi,
On Mon, Mar 17, 2008 at 01:34:05PM -0700, Nelson, Shannon wrote:
> In the future please copy Maciej as one of "the DMA guys" as he has
> taken over ioatdma for me. Beyond that, one little picky comment
> below...
Time to set up a list, or have everyone monitor lkml, I'd say. I'd
prefer the
On Mon, 2008-03-17 at 18:31 -0400, Jeff Garzik wrote:
> > Jeff, do you mind if we get those patches through the powerpc tree ?
> > EMAC is very powerpc specific and these are mostly internal driver
> > cuisine.
>
> Fine with me in concept, though I haven't seen the patches in
> question.
Yup, I'
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
On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>
> * The TQM5200 configuration as provided is intended for shipping as
> default configuration for this board. The "engineer responsible"
> already *did* the tailoring an
On Mon, 17 Mar 2008 11:36:26 +0200 S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
>
> The functions time_before, time_before_eq, time_after, and time_after_eq are
> more robust for comparing jiffies against other values.
>
> So following patch implements usage of the time_after() macro, defined at
> l
On Mon, Mar 17, 2008 at 4:46 PM, Paul Gortmaker
<[EMAIL PROTECTED]> wrote:
> In message: Re: powerpc: cuImage.* creation error
>
>
> on 17/03/2008 Grant Likely wrote:
>
> > On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker
> > <[EMAIL PROTECTED]> wrote:
> > > In message: powerpc: cuImage.* creatio
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 just noticed your message and remembered that old
bug.
--
Timur Tab
On Fri, Mar 14, 2008 at 10:24:30AM +0100, Heiko Schocher wrote:
> + setbits16(&mpc8xx_immr->im_ioport.iop_pcso, 0x300);
> + cpm1_clk_setup(CPM_CLK_SCC3, CPM_CLK5, CPM_CLK_RX);
> + cpm1_clk_setup(CPM_CLK_SCC3, CPM_CLK6, CPM_CLK_TX);
> + setbits32(&mpc8xx_immr->im_cpm.cp_pbpar, 0x300)
In message: Re: powerpc: cuImage.* creation error
on 17/03/2008 Grant Likely wrote:
> On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker
> <[EMAIL PROTECTED]> wrote:
> > In message: powerpc: cuImage.* creation error
> >
> > @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) +=
> > cuIm
On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker
<[EMAIL PROTECTED]> wrote:
> In message: powerpc: cuImage.* creation error
>
> @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) +=
> cuImage.tqm8540
> image-$(CONFIG_TQM8541)+= cuImage.tqm8541
> image-$(CON
On Mon, Mar 17, 2008 at 1:36 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
> them fail to build, and all with similar problems:
>
Looks like I added a bogus target (no dts file for the board yet) and
didn't match correctly the ini
On Sun, Mar 09, 2008 at 07:59:14PM +0300, Vitaly Bordug wrote:
> I would like all the comments to be consistent C style (because that's it
> for the most other dts'es).
$ fgrep -rI // arch/powerpc/boot/dts/ | wc -l
539
-Scott
___
Linuxppc-dev mailing li
Benjamin Herrenschmidt wrote:
There's also the section mismatch patch I sent you. I don't care who's
tree they go through, but I'd need to know either way so keep me in the
loop please.
Jeff, do you mind if we get those patches through the powerpc tree ?
EMAC is very powerpc specific and these
On Mon, 2008-03-17 at 16:46 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > Trying to add fixed-link support for ucc_geth as this is broken too. I
> > noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
> > my board once I got the ucc_geth driver to recognize fixed-link.
>
In message <[EMAIL PROTECTED]> you wrote:
>
> b) defconfigs is more about testing and a known working configuration
> than it is about a distribution configuration. It's not intended to
> be the deployed config. For a distribution/deployable image it is
> expected that the engineer responsible wi
On Mon, Mar 17, 2008 at 04:07:55PM -0400, Paul Gortmaker wrote:
> In message: powerpc: cuImage.* creation error
> on 17/03/2008 Adrian Bunk wrote:
>
> > When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
> > them fail to build, and all with similar problems:
> >
> > <-- snip -
On Mon, 2008-03-17 at 16:46 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > Trying to add fixed-link support for ucc_geth as this is broken too. I
> > noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
> > my board once I got the ucc_geth driver to recognize fixed-link.
>
> There's also the section mismatch patch I sent you. I don't care who's
> tree they go through, but I'd need to know either way so keep me in the
> loop please.
Jeff, do you mind if we get those patches through the powerpc tree ?
EMAC is very powerpc specific and these are mostly internal drive
Joakim Tjernlund wrote:
> Trying to add fixed-link support for ucc_geth as this is broken too. I
> noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
> my board once I got the ucc_geth driver to recognize fixed-link.
> Does it work for you?
A long time ago there was a bug where "if
On Tue, 18 Mar 2008 08:26:45 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-03-18 at 08:25 +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > Signed-off-by: Pravin M. Bathija <[EMAIL PROTECTED]>
> > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > > > ---
> > >
On Mon, Mar 17, 2008 at 2:59 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > > What is the status of the various MPC5200-related patches (support for
> > > TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
> > > time ago by
> >
> > Signed-off-by: Pravin M. Bathija <[EMAIL PROTECTED]>
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > ---
> > drivers/net/ibm_newemac/core.c |7 +++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
>
> applied
Thanks. There's also a couple of patches from Valentine t
On Tue, 2008-03-18 at 08:25 +1100, Benjamin Herrenschmidt wrote:
> > >
> > > Signed-off-by: Pravin M. Bathija <[EMAIL PROTECTED]>
> > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > > ---
> > > drivers/net/ibm_newemac/core.c |7 +++
> > > 1 files changed, 7 insertions(+), 0 deletio
In message <[EMAIL PROTECTED]> you wrote:
>
> > What is the status of the various MPC5200-related patches (support for
> > TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
> > time ago by Marian Balakowicz? There's been some comments to the patches
> > on the list, which wer
>From: Olof Johansson [mailto:[EMAIL PROTECTED]
>Sent: Sunday, March 16, 2008 2:30 PM
>
>pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
>
>DMA copy offload driver for PA Semi PWRficient. It uses the
>platform-specific functions to allocate channels, etc.
>
>Signed-off-by: Olof Johans
On Mon, 2008-03-17 at 17:13 +0100, Laurent Pinchart wrote:
> The PIC I am working with is linked to a falling-edge external irq on the
> CPM2. When the first PIC interrupt was generated the kernel called the PIC
> chained irq handler endlessly.
>
> After some investigation it turned out the ex
Sorry, guess I missed it...
Steve
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Monday, March 17, 2008 1:25 PM
> To: Stephen Neuendorffer
> Cc: John Linn; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fi
On Mon, Mar 17, 2008 at 2:17 PM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
> Grant,
>
> If you have working platform code using libfdt, can you publish it?
Yes,
I've actually already published it once. I'll post v2 this afternoon.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technolog
On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
> Both the buffer-based and fifo-based icap cores have a status
> register. Previously, this was only used internally to check whether
> transactions have completed. However, the status can be useful to the
> mai
On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
> Major 259 has been assigned by lanana. Use it. Also, publish
> /dev/icap[0-k] as the device entries, and register platform devices
> named 'icap' to be consistent.
>
> Signed-off-by: Stephen Neuendorffer <[EMAI
In message: powerpc: cuImage.* creation error
on 17/03/2008 Adrian Bunk wrote:
> When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
> them fail to build, and all with similar problems:
>
> <-- snip -->
>
>
> sbc8548_defconfig:
>
> <-- snip -->
>
> ...
> Entry Point: 0x0
On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
> It appears that in some cases, the sync word might not be recognized
> by the hardware correctly. If this happens, then attempting to read
> from the port results in an unrecoverable error because of the design
>
Grant,
If you have working platform code using libfdt, can you publish it?
Steve
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of Grant
Likely
> Sent: Monday, March 17, 2008 1:08 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org
> Subje
On Mon, Mar 17, 2008 at 2:10 PM, John Linn <[EMAIL PROTECTED]> wrote:
> Great, I'll do that.
>
> Does this also apply to my other patch, Adding 8250 console support to
> OF serial, as it's not clear to me when to assume the UART is already
> setup or not?
I haven't reviewed that one yet. I'll
Great, I'll do that.
Does this also apply to my other patch, Adding 8250 console support to
OF serial, as it's not clear to me when to assume the UART is already
setup or not?
Thanks,
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
Sent
On Mon, Mar 17, 2008 at 1:57 PM, John Linn <[EMAIL PROTECTED]> wrote:
> That makes sense. Since I'm not using a boot loader I didn't realize
> that.
>
> I'm not sure how hard it will be to get the data from the device tree at
> that time.
You should be good. It is now possible to read data fr
That makes sense. Since I'm not using a boot loader I didn't realize
that.
I'm not sure how hard it will be to get the data from the device tree at
that time.
I'll look into the details more.
What about checking to see if it's setup assuming that's possible by
looking at registers, and then not
I cant reproduce this bug on my board, but:
The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
ipic_init() fails. init_ipic_sysfs() will crash in that case.
Something like this may fix it:
Index: linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
=
On Mon, Mar 17, 2008 at 10:41 AM, John Linn <[EMAIL PROTECTED]> wrote:
> The UART 16550 initialization was not setting up the registers
> correctly. Code was added to pull the frequency and speed from
> the device tree and initialize the registers using those values.
>
> The boot code was not an
On Mon, 2008-03-17 at 20:52 +0300, Anton Vorontsov wrote:
> MDIO-less PHYs should use CONFIG_FIXED_PHY driver and appropriate
> fixed-link property in the device tree.
>
> If not, ethernet will not work:
> e0024520:03 not found
> eth1: Could not attach to PHY
> IP-Config: Failed to open eth
On Mon, Mar 17, 2008 at 1:36 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
> them fail to build, and all with similar problems:
>
> powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No
> such file or directory
When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
them fail to build, and all with similar problems:
mpc85xx_defconfig:
<-- snip -->
...
WRAParch/powerpc/boot/cuImage.tqm8540
DTC: dts->dtb on file
"/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8
On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > Paul, here is a bug fix that needs to go in for 2.6.25.
>
> Hi Grant,
>
> What is the status of the various MPC5200-related patches (support for
> TQM5200, CM5200 and Motion-PRO boards, few dr
This change adds code to serial_of.c to support the 8250 console.
Initialization was added to get the UART data from the device tree
and setup the UART and console for the 8250.
The cmd line was not being used for the baud rate and is still not
being used as the speed for the uart is being pulled
On Sun, Mar 16, 2008 at 2:30 PM, Olof Johansson <[EMAIL PROTECTED]> wrote:
> pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
>
> DMA copy offload driver for PA Semi PWRficient. It uses the
>
> platform-specific functions to allocate channels, etc.
>
> Signed-off-by: Olof Johansson <[
MDIO-less PHYs should use CONFIG_FIXED_PHY driver and appropriate
fixed-link property in the device tree.
If not, ethernet will not work:
e0024520:03 not found
eth1: Could not attach to PHY
IP-Config: Failed to open eth1
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/b
Both the buffer-based and fifo-based icap cores have a status
register. Previously, this was only used internally to check whether
transactions have completed. However, the status can be useful to the
main driver as well. This patch exposes these status functions to the
main driver along with so
Major 259 has been assigned by lanana. Use it. Also, publish
/dev/icap[0-k] as the device entries, and register platform devices
named 'icap' to be consistent.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 43 +
The following sequence of patches makes the icap driver more robust,
by making better use of the status information from the cores. In
addition, Lanana has assigned Major 259 for FPGA configuration
interfaces, so we now use it, rather than dynamically finding a major
number.
Grant: please pick th
It appears that in some cases, the sync word might not be recognized
by the hardware correctly. If this happens, then attempting to read
from the port results in an unrecoverable error because of the design
of the FPGA core. This patch updates the code to check the status of
the device before rea
The UART 16550 initialization was not setting up the registers
correctly. Code was added to pull the frequency and speed from
the device tree and initialize the registers using those values.
The boot code was not and is still not using the cmd line
to setup up the uart. The frequency of the clock
On Thursday 13 March 2008 14:56, Laurent Pinchart wrote:
> Hi Michael,
>
> On Wednesday 12 March 2008 01:51, Michael Ellerman wrote:
> > On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
> > > Hi everybody,
> > >
> > > is there any documentation describing interrupt handling for the
> > >
On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> On Friday 07 March 2008 17:21, Scott Wood wrote:
> > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > (unlike cpm1). This should probably be fixed, though then we'd have to
> > deal with assigning SMC par
On Mon, 17 Mar 2008 14:48:23 +0100, Imre Kaloz <[EMAIL PROTECTED]> wrote:
Sorry, forgot to note that this version removes the "kozio" and extends
the "user" partition accordingly, as Stefan asked.
Imre
___
Linuxppc-dev mailing list
Linuxppc-dev@o
Signed-off-by: Imre Kaloz <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/taishan.dts | 29 +++-
arch/powerpc/configs/taishan_defconfig | 79 +++-
2 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts
b/arch/p
David,
+ /* Unfortunately, the specific model number is encoded in the
+* soc node name in existing dts files -- once that is fixed,
+* this can do a simple path lookup.
+*/
Since this is a new board, couldn't you name the soc node /soc and
dispense with this
Stefan Roese wrote:
Add "ibm,tah" to the compatible matching table of the ibm_newemac
tah driver. The type "tah" is still preserved for compatibility reasons.
New dts files should use the compatible property though.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/tah
Stefan Roese wrote:
From: Pravin M. Bathija <[EMAIL PROTECTED]>
Problem Description and Fix
---
When a pause packet(with destination as reserved Multicast address) is
received by the EMAC hardware to control the flow of frames being
transmitted by it, it is dropped by the
This patch fixes a potential bug at drivers/char/hvc_beat.c.
- hvc_put_term_char routine will decrement "rest" variable twice,
and forget to advance "buf" pointer by "nlen" bytes.
This bug was not hit because the output handler in
drivers/char/hvc_console.c splits given output into 16 bytes
at
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: linuxppc-dev@ozlabs.org
Cc: Pau
Grant Likely wrote:
On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
<[EMAIL PROTECTED]> wrote:
All,
I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+
... maybe someone could give me some hints.
Up to now the systems have been running on 2.6.19 without any problems.
Th
On Sun, 2008-03-16 at 23:27 -0500, Anton Blanchard wrote:
> Since the PMU is an NMI now, it can come at any time we are only soft
> disabled. We must hard disable around the two places we allow the kernel
> stack SLB and r1 to go out of sync. Otherwise the PMU exception can
> force a kernel stack
79 matches
Mail list logo
