Thanks, I applied Tony's patch and sent a pull request to Linus.
Cheers,
Ben.
On Wed, 2009-03-04 at 14:59 +1100, Tony Breeds wrote:
> On Tue, Mar 03, 2009 at 08:22:29PM -0500, Kyle McMartin wrote:
> > From: Kyle McMartin
> >
> > Bug #486511 in Fedora, this is getting applied to any machine with
Hi Linus !
Here's a fix for a USB related regression on some PowerPC machines.
The following changes since commit fec6c6fec3e20637bee5d276fb61dd8b49a3f9cc:
Linus Torvalds (1):
Linux 2.6.29-rc7
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh
Hi,
Can the ext2_* definitions in arch/powerpc/include/asm/bitops.h be
replaced with:
#include
#include
?
Also, can the bitop swizzling (starting at line 351) be removed by
including include/asm-generic/bitops/le.h? It looks very similar if not
identical.
I'm afraid I don't have a ppc
Holler if something is wrong...
Here's what I just stick in "test", to hit "next" one of these days.
Arnd Bergmann (1):
powerpc/spufs: Initialize ctx->stats.tstamp correctly
Benjamin Herrenschmidt (6):
powerpc: Wire up /proc/vmallocinfo to our ioremap()
powerpc/kconfig: Kill PP
On Tue, 2009-03-03 at 21:27 -0800, Andy Grover wrote:
> Hi,
>
> Can the ext2_* definitions in arch/powerpc/include/asm/bitops.h be
> replaced with:
>
> #include
> #include
>
> ?
>
> Also, can the bitop swizzling (starting at line 351) be removed by
> including include/asm-generic/bitops/le.h
Here's an update on this issue.
After verifying the device tree was OK, the OF traces led us to the root
cause.
powerpc irq.c irq_alloc_virt() assigns a virtual IRQ as a function of the
input hardware IRQ hint, AND NUM_ISA_INTERRUPTS. it turns out that
asm-ppc/irq.h defines NUM_ISA_INTERRUP
We need to offset by *pos bytes, not *pos words.
Signed-off-by: Jeremy Kerr
---
arch/powerpc/platforms/cell/spufs/file.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/cell/spufs/file.c
b/arch/powerpc/platforms/cell/spufs/file.c
index 83ef889..6b1
after UART interrupt handler is installed and rx is enabled, if an rx
interrupt comes before hardware init, rx->cur will be updated. Then the
hardware init will reset BD and make rx->cur out of sync, move the hardware
init code before request_irq.
Signed-off-by: Xiaotian Feng
---
diff --git a/dri
Based on an original patch from Roel Kluin .
The write size calculated during regs and fpcr writes may currently
go negative. Because size is unsigned, this will wrap, and our
check for EFBIG will fail.
Instead, do the check for EFBIG before subtracting from size.
Signed-off-by: Jeremy Kerr
--
This updates the 32-bit headers to use the same definitions for the RPN
shift inside the PTE as 64-bit, and thus updates _PAGE_CHG_MASK to
become identical.
This does introduce a runtime visible difference, which is that now,
_PAGE_HASHPTE will be part of _PAGE_CHG_MASK and thus preserved. However
On Thu, 2009-02-19 at 14:49 -0600, Kumar Gala wrote:
> Since a number of powerpc chips are SoCs we end up having dma-able
> devices that are registered as platform or of_platform devices. We need
> to hook the archdata to setup proper dma_ops for these devices.
>
> In the short term the majority
On Tue, 2009-01-06 at 14:55 +0200, Octavian Purdila wrote:
> Signed-off-by: Octavian Purdila
So I'm going to merge 1/2 but this one should really be changed to
advertise ppc/750 in oprofile_cpu_type (ie. to userspace).
Cheers,
Ben.
> arch/powerpc/kernel/cputable.c |6 ++
> 1 files cha
On Thu, 2009-02-19 at 18:21 +0100, Nick Piggin wrote:
> OK, here is this patch again. You didn't think I'd let a 2% performance
> improvement be forgotten? :)
>
> Anyway, patch won't work well on architecture without lwsync, but I won't
> bother fixing that kind of thing and making it merge worthy
Allright, sorry for the delay, I had those stored into my "need more
than half a brain cell for review" list and only got to them today :-)
On Thu, 2009-02-19 at 18:12 +0100, Nick Piggin wrote:
> Using lwsync, isync sequence in a microbenchmark is 5 times faster on my G5
> than
> using sync for s
On Tue, Mar 03, 2009 at 08:22:29PM -0500, Kyle McMartin wrote:
> From: Kyle McMartin
>
> Bug #486511 in Fedora, this is getting applied to any machine with a NEC
> USB pci device if this CONFIG_GEF_SBC610 is on (as it was in Fedora.)
> Obviously this isn't appropriate to do in any more than the S
On Wed, Mar 4, 2009 at 3:38 AM, Anton Vorontsov
wrote:
> Currently it doesn't matter where the mdio nodes are placed, but with
> power management support (i.e. when sleep = <> properties will take
> effect), mdio nodes placement will become important: mdio controller
> is a part of the ethernet bl
From: Kyle McMartin
Bug #486511 in Fedora, this is getting applied to any machine with a NEC
USB pci device if this CONFIG_GEF_SBC610 is on (as it was in Fedora.)
Obviously this isn't appropriate to do in any more than the SBC610
case..., so flag that we're a sbc610 board, and skip the fixup if w
On Mar 04 2009, Guennadi Liakhovetski wrote:
> Yes, linkstation and storcenter have to migrate to the "physmap-flash"
> platform driver. For now you can define in your .config
>
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_COMPAT=y
> CONFIG_MTD_PHYSMAP_START=0xffc0
> CONFIG_MTD_PHYSMAP_LEN=0x4
On Wed, Mar 4, 2009 at 11:29, Sean MacLennan wrote:
> On Tue, 3 Mar 2009 16:09:06 -0800
> "Andrew Morton" wrote:
>
>> afacit that interface is powerpc-only.
>
> Yes it is. You might want a CONFIG_PPC with that.
>
> It has been. u carry the two... longer than I want to admit
> since I work
From: Sean MacLennan
Date: Tue, 3 Mar 2009 19:29:32 -0500
> It has been. u carry the two... longer than I want to admit
> since I worked on a sparc. Would GPIO based LEDS make sense on a sparc
> platform? Is sparc used much in the embedded world?
>
> If yes, the of_register_platform_driv
On Tue, 3 Mar 2009 16:09:06 -0800
"Andrew Morton" wrote:
> afacit that interface is powerpc-only.
Yes it is. You might want a CONFIG_PPC with that.
It has been. u carry the two... longer than I want to admit
since I worked on a sparc. Would GPIO based LEDS make sense on a sparc
platform
On Tue, 3 Mar 2009 17:15:58 -0700
Grant Likely wrote:
> On Tue, Mar 3, 2009 at 5:09 PM, Andrew Morton
> wrote:
> >
> > linux-next's dc0f6e94d7f487c624254597a0b86ef41c525673 (which I don't
> > seem to be able to find on any mailing lists to which I subscribe)
> > breaks the sparc64 allmodconfig
On Tue, Mar 3, 2009 at 5:09 PM, Andrew Morton wrote:
>
> linux-next's dc0f6e94d7f487c624254597a0b86ef41c525673 (which I don't
> seem to be able to find on any mailing lists to which I subscribe)
> breaks the sparc64 allmodconfig build:
Hmm, I don't see that one either. Which tree did it go in vi
linux-next's dc0f6e94d7f487c624254597a0b86ef41c525673 (which I don't
seem to be able to find on any mailing lists to which I subscribe)
breaks the sparc64 allmodconfig build:
drivers/leds/leds-gpio.c: In function `gpio_led_init':
drivers/leds/leds-gpio.c:286: error: implicit declaration of functi
On Mon, 2 Mar 2009, Rogério Brito wrote:
> Hi there.
>
> I tried to compile a new kernel for my (powerpc) Kurobox HD (an embedded
> system that has a Freescale processor), but it seems that the
> compilation fails, with both my usual config file and with the shipped
> linkstation_defconfig file.
Stefan Roese wrote:
>
> On Wednesday 25 February 2009, Stefan Roese wrote:
>
>
> You can find a driver for this Synopsys DWC OTG controller in our
> linux-2.6-denx repository:
>
> http://git.denx.de/?p=linux-2.6-denx.git;a=tree;f=drivers/usb/gadget/dwc_otg;h=526d515e4764a0c92cebbf909c245d6a
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = <> properties will take
effect), mdio nodes placement will become important: mdio controller
is a part of the ethernet block, so the mdio nodes should be placed
correctly. Otherwise we
On Tue, Mar 03, 2009 at 11:41:23AM +0100, Geert Uytterhoeven wrote:
> So would you accept a patch series that:
> 1. Adds the missing module aliases to rtc-parisc (which is a bugfix),
> 2. Moves the platform device creation out of rtc-ppc and into arch-specific
> code (which is also a bugfi
On Tue, 2009-03-03 at 08:56 -0800, Andrew Morton wrote:
> On Tue, 3 Mar 2009 11:14:04 +0100 (CET) Geert Uytterhoeven
> wrote:
>
> > > > let us know if that works :-)
> > >
> > > didn't. Oh well.
> >
> > Does allnoconfig work if you force the compiler to be 32-bit, like
> >
> > make CC="p
When stored in size_t size, the test 'size <= 0' does no longer work.
Signed-off-by: Roel Kluin
---
diff --git a/arch/powerpc/platforms/cell/spufs/file.c
b/arch/powerpc/platforms/cell/spufs/file.c
index 0da7f2b..05dba47 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/pla
Anton Vorontsov wrote:
On Tue, Mar 03, 2009 at 11:57:46AM -0600, Scott Wood wrote:
On Tue, Mar 03, 2009 at 07:02:01PM +0300, Anton Vorontsov wrote:
m...@24520 {
@@ -226,6 +244,8 @@
interrupt-parent = <&ipic>;
tbi-handle = <&tbi0>;
From: roel kluin
Change the ps3av_auto_videomode() mode id argument type from unsigned to
signed so a negative id can be detected and reported as an -EINVAL failure.
Signed-off-by: Roel Kluin
Signed-off-by: Geoff Levand
---
arch/powerpc/include/asm/ps3av.h |2 +-
drivers/ps3/ps3av.c
Hi Ben,
This is a small set of patches for your 2.6.30 next branch.
[patch 1/3] powerpc: Add missing DABR flags
[patch 2/3] powerpc/ps3: Print memory hotplug errors
[patch 3/3] powerpc/ps3: Make ps3av_set_video_mode mode ID signed
-Geoff
--
___
The powerpc 64 bit architecture defines three flags for the
DABR (Data Address Breakpoint Register). Add definitions
for the currently missing DABR_DATA_WRITE and DABR_DATA_READ
flags to the powerpc reg.h file.
Signed-off-by: Geoff Levand
---
arch/powerpc/include/asm/reg.h |2 ++
1 file cha
To help users diagnose hotpug memory problems, change the
printing of memory hotplug errors from DBG() to pr_err().
Signed-off-by: Geoff Levand
---
arch/powerpc/platforms/ps3/mm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/power
On Tue, Mar 03, 2009 at 11:57:46AM -0600, Scott Wood wrote:
> On Tue, Mar 03, 2009 at 07:02:01PM +0300, Anton Vorontsov wrote:
> > m...@24520 {
> > @@ -226,6 +244,8 @@
> > interrupt-parent = <&ipic>;
> > tbi-handle = <&tbi0>;
> >
On Tue, Mar 03, 2009 at 07:02:01PM +0300, Anton Vorontsov wrote:
> m...@24520 {
> @@ -226,6 +244,8 @@
> interrupt-parent = <&ipic>;
> tbi-handle = <&tbi0>;
> phy-handle = <&phy2>;
> + sleep = <&pmc 0
On Tue, 3 Mar 2009 11:14:04 +0100 (CET) Geert Uytterhoeven
wrote:
> > > let us know if that works :-)
> >
> > didn't. Oh well.
>
> Does allnoconfig work if you force the compiler to be 32-bit, like
>
> make CC="powerpc64-unknown-linux-gnu-gcc -m32"
Nope:
scripts/mod/empty.c:1: error: -
Hi all,
In my continued search to stop tx-babbling-errors, I grabbed the latest
blobs for gianfar.c and gianfar.h from http://git.kernel.org. The
history says that the following changes were made since the driver
version I was using (Freescale December 2008 LTIB release for 8572):
2009-02-09 Ja
Add macros for the GS (guest state) bit to the list of MSR bit definitions.
On PowerPC cores that support embedded hypervisor mode, GS is cleared if
the system is running in hypervisor state (and MSR[PR] is cleared), and set
if it's running in guest state. See the Power ISA 2.06 specification for
This patch adds pmc nodes to the device tree files so that the boards
will able to use standby capability of MPC837x processors. The MPC837x
PMC controllers are compatible with MPC8349 ones (i.e. no deep sleep).
sleep = <> properties are used to specify SCCR masks as described
in "Specifying Devic
On Tue, Mar 3, 2009 at 2:49 AM, Michael Guntsche wrote:
> On Tue, 03 Mar 2009 08:35:02 +0100, Michael Guntsche
> wrote:
>> As for adding additional information to the tree, can I also use libfdt
>> functions in platform/83xx/rbppc.c or is it better to do this via a
>> dedicated platform_init that
On Tue, 3 Mar 2009 11:41:23 +0100 (CET)
Geert Uytterhoeven wrote:
> rtc-generic is already in the kernel, it's just called rtc-parisc ;-)
Really? I never saw it :)
> > But I'd strongly suggest to plan and execute a conversion process.
>
> So would you accept a patch series that:
> 1. Adds
Hello,
I'am looking for an image to boot a embedded device with a single image.
I though the generated uImage in arch/powerpc/boot should work, but u-boot
cannot but this,
because the addresses of initrd and dtb not found.
Now I'am creating the image by hand with mkimage:
mkimage -A ppc -n F302
On Tue, Mar 03, 2009 at 03:11:23PM +1100, Dushara Jayasinghe wrote:
> Hi All,
>
> > Linus' tree is still lacking few patches for spi_mpc83xx driver, the
> > patches makes spi_mpc83xx work with the device tree directly.
>
> I modified the spi_mpc83xx to work with the device tree using
> mpc52xx_ps
Sachin,
2450cf51a1bdba7037e91b1bcc494b01c58aaf66 fixes this. Already upstream.
Mikey
In message <49acfd4e.8060...@in.ibm.com> you wrote:
> 2.6.29-rc6-git6 ppc64_defconfig build fails with
>
> arch/powerpc/kernel/built-in.o: In function `.of_pci_phb_probe':
> of_platform.c:(.devinit.text+0xe0)
On Mon, 2 Mar 2009, Alessandro Zummo wrote:
> On Mon, 2 Mar 2009 11:28:01 +0100 (CET)
> Geert Uytterhoeven wrote:
> > So I can solve my problem (autoloading the RTC driver on PS3 by udev) by
> > converting the old genrtc driver into a platform device driver and creating
> > platform devices where
On Mon, 2 Mar 2009, Andrew Morton wrote:
> On Tue, 3 Mar 2009 14:19:05 +1100 Stephen Rothwell
> wrote:
> > On Mon, 2 Mar 2009 18:55:14 -0800 Andrew Morton
> > wrote:
> > > Using built-in specs.
> > > Target: powerpc64-unknown-linux-gnu
> > > Configured with:
> > > /home/axboe/crosstool-0.43/bu
2.6.29-rc6-git6 ppc64_defconfig build fails with
arch/powerpc/kernel/built-in.o: In function `.of_pci_phb_probe':
of_platform.c:(.devinit.text+0xe0): undefined reference to
`.pcibios_claim_one_bus'
arch/powerpc/platforms/built-in.o: In function `.remove_phb_dynamic':
(.text+0x120fc): undefined
On Tue, 03 Mar 2009 08:35:02 +0100, Michael Guntsche
wrote:
> As for adding additional information to the tree, can I also use libfdt
> functions in platform/83xx/rbppc.c or is it better to do this via a
> dedicated platform_init that simpleboot then uses?
Sorry, please forget this quesiton. Of c
On Sun, Mar 01, 2009 at 09:33:16PM -0700, Grant Likely wrote:
> On Sun, Mar 1, 2009 at 7:19 PM, Jon Smirl wrote:
> > Would it be easier to get Pengutronix to release a new u-boot for
> > the pcm030? I'm using U-Boot 1.2.0-mpc5200b-tiny-2 (Apr 17 2007 -
> > 11:49:20).
>
> Only if it is a chip IO se
51 matches
Mail list logo
