From: Zhao Chenhui
Make a single PCIe MSI bank shareable through CAMP OSes. The number of
MSI used by each core can be configured by dts file.
Signed-off-by: Zhao Chenhui
Signed-off-by: Li Yang
---
arch/powerpc/sysdev/fsl_msi.c|8 +++-
arch/powerpc/sysdev/msi_bitmap.c |4 ++--
From: Zhao Chenhui
Put all fsl_msi banks in a linked list. The list of banks then can be
traversed when allocating new msi interrupts.
Signed-off-by: Zhao Chenhui
Signed-off-by: Li Yang
---
arch/powerpc/sysdev/fsl_msi.c | 29 ++---
arch/powerpc/sysdev/fsl_msi.h |
From: Zhao Chenhui
In fsl_of_msi_probe(), the virt_msir's chip_data have been stored
the pointer to struct mpic. We add a struct fsl_msi_cascade_data
to store the pointer to struct fsl_msi and msir_index. Otherwise,
the pointer to struct mpic will be over-written, and will cause
problem when cal
Hello Bill,
On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:
> I would love it if you posted your code! Thanks!!
In this source file I just added my own routines:
Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
===
-
Hello Bill,
On Thursday 15 April 2010 22:14:09 Bill Gatliff wrote:
> I'm not sure what the *Weak stuff is doing. Can I just hack
> shadowUpdatePacked() itself?
I think so. But take care if you want to use that code on other
systems or without shadowfb. If I search for shadowUpdatePacked, then
I'
On Thu, Apr 15, 2010 at 03:05:08PM -0500, Scott Wood wrote:
> Kumar Gala wrote:
> >On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote:
> >>Kumar,
> >>
> >>According to patchwork, this is now delegated to you. Do you
> >>have any objections to merge this?
> >
> >Would like Scott's Ack.
>
> I think
Roman Fietze wrote:
> Yes. I added a routine like
>
> /* Swap frame buffer bytes in 32 bit value. */
> static __inline unsigned int
> fbbits_swap32(unsigned int __bsx)
> {
> return __bsx) & 0xff00) >> 8) | (((__bsx) & 0x00ff) << 8) |
> (((__bsx) & 0xff00) >> 8) | (((_
On Wed, 2010-04-14 at 23:55 -0700, David Miller wrote:
> From: Ingo Molnar
> Date: Thu, 15 Apr 2010 08:49:40 +0200
>
> > Btw., WARN_ON trapping on PowerPC is clearly a PowerPC bug - there's a good
> > reason we have WARN_ON versus BUG_ON - it should be fixed.
>
> I disagree, an implementation s
On Thu, 2010-04-15 at 09:32 +0200, Ingo Molnar wrote:
> It trades robustness for slightly better space/code efficiency.
>
> Such a trap based mechanism exists on x86 as well and we use it for BUG_ON().
> We intentionally dont use it to generate warnings and dont override __WARN(),
> because it w
a recent fc11 udev update on an 83xx board made root console login
disappear:
Updating : udev-141-8.fc11.ppc32/83
udev: starting version 141
udev: deprecated sysfs layout; update the kernel or disable
CONFIG_SYSFS_DEPRECATED; some udev features will not
to enable the storage controller on earlier rev. mpc834x itx boards.
Signed-off-by: Kim Phillips
---
arch/powerpc/configs/mpc83xx_defconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/configs/mpc83xx_defconfig
b/arch/powerpc/configs/mpc83xx_defconfig
i
What is the recommended git repository for active MPC5121 development?
I pulled the tag "DENX-v2.6.33.1" from git.denx.de, and, unless I'm
overlooking something, it seems to be lacking some driver support such
as NAND, RTC, etc. I also notice an older head called
"mpc512x-v2.6.33-devel". Should I
Update the PS3 entries in the MAINTAINERS file.
Signed-off-by: Geoff Levand
---
MAINTAINERS |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4482,17 +4482,17 @@ S: Maintained
F: drivers/ata/sata_promise.*
PS3 NETWORK SUPPORT
-
Refresh ps3_defconfig to latest kernel sources and change
these kernel config options:
o CONFIG_USB_ANNOUNCE_NEW_DEVICES: n -> y
o CONFIG_USB_EHCI_TT_NEWSCHED: n -> y
o CONFIG_CMDLINE_BOOL: n -> y
o CONFIG_CMDLINE: n -> ""
Signed-off-by: Geoff Levand
---
arch/powerpc/configs/ps3_defconf
This patch adds support for eTSEC 2.0 as found in P1020.
The changes include introduction of the group nodes for
the etsec nodes.
Signed-off-by: Sandeep Gopalpet
Signed-off-by: Anton Vorontsov
---
This is based on
http://www.bitshrine.org/gpp/kernel-2.6.32-rc3-P1020RDB-DTS-Support-for-eTSEC-2.0
Scott Wood wrote:
Kumar Gala wrote:
On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote:
Kumar,
According to patchwork, this is now delegated to you. Do you
have any objections to merge this?
Would like Scott's Ack.
I think we need to save IACn, DACn, DBCRn, PID0, and USPRG0.
Might want to
Roman Fietze wrote:
> Then I added void shadowUpdatePackedSwapped16() and
> shadowUpdatePackedSwapped32() which I was using instead of the
> original *Weak functions, which in turn uses the above swap routine
> when copying from shadow to the device.
>
I'm not sure what the *Weak stuff is doing
Kumar Gala wrote:
On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote:
Kumar,
According to patchwork, this is now delegated to you. Do you
have any objections to merge this?
Would like Scott's Ack.
I think we need to save IACn, DACn, DBCRn, PID0, and USPRG0.
Might want to also save TLB1 con
On Thu, Apr 15, 2010 at 02:20:23PM -0500, Kumar Gala wrote:
[...]
> > Kumar,
> >
> > According to patchwork, this is now delegated to you. Do you
> > have any objections to merge this?
>
> Would like Scott's Ack.
Cc'ing.
___
Linuxppc-dev mailing list
L
On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 12:38:02AM +0300, Anton Vorontsov wrote:
>> This is started as swsusp_32.S modifications, but the amount of #ifdefs
>> made the whole file horribly unreadable, so let's put the support into
>> its own separate file.
>>
On Thu, Feb 25, 2010 at 12:38:02AM +0300, Anton Vorontsov wrote:
> This is started as swsusp_32.S modifications, but the amount of #ifdefs
> made the whole file horribly unreadable, so let's put the support into
> its own separate file.
>
> The code should be relatively easy to modify to support 4
* Frederic Weisbecker wrote:
> On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote:
> > >
> > >
> > > diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> > > index 78325f8..65d4336 100644
> > > --- a/kernel/lockdep.c
> > > +++ b/kernel/lockdep.c
> > > @@ -2298,7 +2298,11 @@ void trace_h
On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote:
> >
> >
> > diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> > index 78325f8..65d4336 100644
> > --- a/kernel/lockdep.c
> > +++ b/kernel/lockdep.c
> > @@ -2298,7 +2298,11 @@ void trace_hardirqs_on_caller(unsigned long ip)
> >
On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote:
> > In this case, I guess the following fix should be sufficient?
> > I'm going to test it and provide a sane changelog.
> >
> >
> > diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> > index 78325f8..65d4336 100644
> > --- a/kernel/loc
I would love it if you posted your code! Thanks!!
b.g.
On Apr 15, 2010 8:53 AM, "Roman Fietze" wrote:
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
> Are you talking about this code here?
>
...
Yes. I added a routine like
/* Swap frame buffer bytes in 32 bit value. */
Ian Munsie wrote:
> From: Ian Munsie
>
> This patch adds mappings from the register numbers from DWARF to the
> register names used in the PowerPC Regs and Stack Access API. This
> allows perf probe to be used to record variable contents on PowerPC.
>
> This patch depends on functionality in the
Ian Munsie wrote:
> From: Ian Munsie
>
> The perf userspace tool included some architecture specific code to map
> registers from the DWARF register number into the names used by the regs
> and stack access API.
>
> This patch moves the architecture specific code out into a separate
> arch/x86 d
* Frederic Weisbecker wrote:
> On Thu, Apr 15, 2010 at 08:49:40AM +0200, Ingo Molnar wrote:
> >
> > * Stephen Rothwell wrote:
> >
> > > Hi all,
> > >
> > > Yesterday's (and today's) linux-next boot (PowerPC) failed like this:
> > >
> > > [ cut here ]
> > > Badness at
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
> Are you talking about this code here?
>
> void
> shadowUpdatePacked (ScreenPtr pScreen,
> shadowBufPtr pBuf)
> {
> ...
> while (i--)
> *win++ =
Roman Fietze wrote:
> Hallo Bill,
>
> On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:
>
>
>> Actually, I *have* Debian squeeze's xorg running on the platform just
>> fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single
>> diagonal line is very blocky--- not smooth at all
On Thu, Apr 15, 2010 at 08:49:40AM +0200, Ingo Molnar wrote:
>
> * Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Yesterday's (and today's) linux-next boot (PowerPC) failed like this:
> >
> > [ cut here ]
> > Badness at kernel/lockdep.c:2301
> > NIP: c00a35c8 LR:
Hi Ben,
On Thursday 15 April 2010 00:25:23 Benjamin Herrenschmidt wrote:
> It should be possible to get that working, but I suspect not without
> some code changes. I know the current PCIe hotswap driver has ACPI hooks
> that would need to be replaced by appropriate hooks into the powerpc
> code t
Hi Ingo,
On Thu, 15 Apr 2010 08:49:40 +0200 Ingo Molnar wrote:
>
> Ok, we'll fix the warning.
Thanks.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpGux6Rr8FG8.pgp
Description: PGP signature
__
* Stephen Rothwell wrote:
> Hi all,
>
> Yesterday's (and today's) linux-next boot (PowerPC) failed like this:
>
> [ cut here ]
> Badness at kernel/lockdep.c:2301
> NIP: c00a35c8 LR: c00084c4 CTR:
> REGS: c0bf77e0 TRAP: 0700 Not
On Wed, 14 Apr 2010 22:07:08 -0500
Bill Gatliff wrote:
> Put simply, I have an MPC5200b platform with a Fujitsu "Lime" GDC, and
> I'm trying to run Debian squeeze's xorg on it.
>
> Actually, I *have* Debian squeeze's xorg running on the platform just
> fine, with a 2.6.34-rc1 kernel (kernel.org)
* David Miller wrote:
> From: Ingo Molnar
> Date: Thu, 15 Apr 2010 08:49:40 +0200
>
> > Btw., WARN_ON trapping on PowerPC is clearly a PowerPC bug - there's a good
> > reason we have WARN_ON versus BUG_ON - it should be fixed.
>
> I disagree, an implementation should be allowed to use the mo
Hallo Bill,
On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:
> Actually, I *have* Debian squeeze's xorg running on the platform just
> fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single
> diagonal line is very blocky--- not smooth at all.
I'm 95% sure it's an endianess
37 matches
Mail list logo
