On Mon, 2009-03-16 at 14:46 +1030, Rusty Russell wrote:
> Makes code futureproof against the impending change to mm->cpu_vm_mask.
>
> It's also a chance to use the new cpumask_ ops which take a pointer
> (the older ones are deprecated, but there's no hurry for arch code).
Boom :-)
In file includ
On Thu, 2009-03-19 at 22:30 +0900, TOMARI Hisanobu wrote:
> Thanks for helpful advices.
> This patch adds an option to drivers/ide/Kconfig and adds
> some lines to drivers/ide/pmac.c . Now the driver checks
> if the model is prefixed with "PowerBook" and the entire hack
> can be toggled in the Kco
On Wed, 2009-03-11 at 10:18 -0500, Kumar Gala wrote:
> CoreInt provides a mechansim to deliver the IRQ vector directly
> into the core on an interrupt (via the SPR EPR) rather than having
> to go IACK on the PIC. This is suppose to provide an improvment
> in interrupt latency by reducing the time
On Thu, 2009-03-19 at 17:10 -0400, Masami Hiramatsu wrote:
> Add kernel_trap_sp() on powerpc, based on systemtap's runtime/regs.h.
>
> Signed-off-by: Masami Hiramatsu
I haven't looked at the usage of it, but it's weird to have something
call "kernel_trap_sp" that returns the -user- stack pointer
On Wed, 2009-03-11 at 22:20 +0800, Liu Dave-R63238 wrote:
> --- a/arch/powerpc/include/asm/mpic.h
> +++ b/arch/powerpc/include/asm/mpic.h
> @@ -22,6 +22,7 @@
> #define MPIC_GREG_FEATURE_10x00010
> #define MPIC_GREG_GLOBAL_CONF_00x00020
> #defineMPIC_GR
On Tue, 2009-03-10 at 20:32 +0200, Mikhail Zolotaryov wrote:
> Hi,
>
> not critical problem here.
>
> IBM EMAC driver performs device reset (drivers/net/ibm_newemac/core.c:
> emac_probe() -> emac_init_phy() -> emac_reset()) before registering
> appropriate net_device (emac_probe() -> register_n
This moves some MMU related init code out of setup_64.c into hash_utils_64.c
and calls it early_init_mmu() and early_init_mmu_secondary(). This will
make it easier to plug in a new MMU type.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/mmu-hash64.h |2 -
arch/powerpc/i
ppc32 has it already, add it to ppc64 as a preliminary for adding
support for Book3E 64-bit support
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/pgtable-ppc64.h | 12 +++-
arch/powerpc/include/asm/pte-hash64.h|2 ++
2 files changed, 13 insertions(+), 1 de
We need to use %zu instead of %d when printing a sizeof()
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/mm/mmu_context_nohash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/mm/mmu_context_nohash.c2009-03-11
11:51:05.0 +1100
This file is only useful on 64-bit, so we name it accordingly.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/mm/Makefile |2
arch/powerpc/mm/mmap.c| 109 --
arch/powerpc/mm/mmap_64.c | 109 +
Now that they are almost identical, we can merge some of the definitions
related to the PTE format into common files.
This creates a new pte-common.h which is included by both 32 and 64-bit
right after the CPU specific pte-*.h file, and which defines some
bits to "default" values if they haven't b
This patch tweaks the way some PTE bit combinations are defined, in such a
way that the 32 and 64-bit variant become almost identical and that will
make it easier to bring in a new common pte-* file for the new variant
of the Book3-E support.
The combination of bits defining access to kernel pages
On Tue, 2009-03-17 at 19:40 -0500, Kumar Gala wrote:
> Please pull from 'test' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git test
Don't base your test branch on top of mine. Nothing should be based on
top of my test branch, it's volatile. Base your stuff on top
I agree 100% with David's comments, and I have some additional ones below.
On Thu, Mar 19, 2009 at 9:26 AM, Wolfgang Grandegger
wrote:
> + soc8...@e000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
Drop device_typ
On Mar 19, 2009, at 10:26 AM, Wolfgang Grandegger wrote:
+ m...@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x24520 0x20>;
+
+
On Thu, Mar 19, 2009 at 04:26:44PM +0100, Wolfgang Grandegger wrote:
> This patch adds support for the "socrates" board based on the MPC8544.
> Supported are Ethernet, serial console, I2C, I2C-based RTC and
> temperature sensors, NOR and NAND flash, PCI, USB, CAN and Lime
> display controller.
>
>
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, March 20, 2009 12:11 AM
> To: Li Yang-R58472
> Cc: Soohyung Cho; linuxppc-dev@ozlabs.org
> Subject: Re: suspend-to-mem on the mpc8349e-mitx-gp?
>
> On Thu, Mar 19, 2009 at 12:24:26AM -0700, Li Yang-R58472 wrote:
> > > -Ori
Currently, we will report a page fault as a segment fault, and report
a segment fault as both a page and segment fault.
Fix the SPF_P definition to be correct according to the iommu docs, and
mask before comparing.
Signed-off-by: Jeremy Kerr
---
arch/powerpc/platforms/cell/iommu.c |9 +
Add kernel_trap_sp() on powerpc, based on systemtap's runtime/regs.h.
Signed-off-by: Masami Hiramatsu
---
arch/powerpc/include/asm/ptrace.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h
b/arch/powerpc/include/asm/ptrace.h
index c9c678
On Thu, Mar 19, 2009 at 7:32 PM, Daniel Ng wrote:
>
> So, I tried to call spidev_probe() directly from the probe() function
> of my SPI Controller driver. However in this case spidev_probe()
> failed because its call to device_create_drvdata() failed with error
> code ENODEV. Why would this be?
>
I have no experience with ELDK.
Have you used it ? Do you like it ?
When I started I mostly did a roll my own environment using crosstool.
I would have stuck to that except I can not get uclibc and it has
not been updated in a long time.
Crosstool-ng did not support the ppc las
On Thu, Mar 19, 2009 at 5:59 PM, David H. Lynch Jr. wrote:
> Does anyone have experience sugestions for building ppc/linux apps
> or even ppc kernels under windows.
I hear rumors that there is a Windows version of ELDK.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
Does anyone have experience sugestions for building ppc/linux apps
or even ppc kernels under windows.
I work (and live) under Linux. I am very happy to work under Linux.
I only spend about 20 minutes a week in windows anymore.
But I have coworkers, and clients that live under windows
Hi all,
I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
I have to write the driver of SDHCI driver(using R5C807 RICOH).
But I could not find it.
Then I found the good sample of this.
I tried to the patch to kernel 2.6.28.7,but I did not succeed.
Please tell me how to get the kernei for
I have been using the mainline c67x00 driver on our boards for a while.
I am running 2.6.26-rc4 - basically the last arch/ppc version.
I can only detect devices on the first port of the first host but
otherwise it has been working.
Grant Likely wrote:
> Unfortunately, the 2.6.24-r
Hi Ingo,
On Thu, 19 Mar 2009 12:53:42 +0100 Ingo Molnar wrote:
>
> I've applied it.
Thanks.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgp6UOySbPFDp.pgp
Description: PGP signature
___
Linu
On Thu, 2009-03-19 at 16:41 +0300, Anton Vorontsov wrote:
>
> The other option is to enable BLK_DEV_IDE_PMAC_SHORTCABLE by default,
> but I'm not sure if it's safe thing to do (most probably not).
It should be allright for powerbooks. If the firmware says 80 pin cable,
then it probably is, and in
On Thu, Mar 19, 2009 at 03:57:10AM -0500, Kumar Gala wrote:
> On Mar 18, 2009, at 2:21 PM, Anton Vorontsov wrote:
[...]
>> Signed-off-by: Anton Vorontsov
>> ---
>>
>> This is for 2.6.30 since we don't use ranges = <> yet.
>>
>> David, I believe Kumar would like to pick this patch into his tree
>>
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
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
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 Wed, Mar 18, 2009 at 03:27:22PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> On Wed, Mar 18, 2009 at 03:05:51PM -0500, Scott Wood wrote:
>>> Hmm, would that imply that the mdio underneath it is disabled as well?
>>
>> Technically, yes. In practice, MDIO and MAC drivers are probed
>> sepa
On Thu, Mar 19, 2009 at 04:16:07PM +0100, Wolfgang Grandegger wrote:
> +Optional properties:
> +- fsl,upm-mar-offset : use the UPM machine address register to drive a
> +custom chip select logic using the specified
> +offset.
Your example uses the name fsl,u
Currently the driver just read "reg" property for constructing MDIO
bus IDs, but this won't work when we'll start using "ranges = <>" in
the device tree, so this will pop up:
Freescale PowerQUICC MII Bus: probed
sysfs: duplicate filename 'm...@520' can not be created
[ cut here ]--
On Thursday 19 March 2009 05:23:07 Madhusudhan J wrote:
> Hi,
>
> this is Madhusudhan J from KPITCummins Bangalore India .
> I have issue with uart driver in linux kernel 2.6.24
> (drivers\serial\Mpc52xx_uart.c)
> I am using platform mpc5121e to communicating to modem through serial
> driver. i
On Mar 10, 2009, at 10:53 PM, Benjamin Herrenschmidt wrote:
+
+/* Conversion functions: convert a page and protection to a page
entry,
+ * and a page entry and page directory to the page they refer to.
+ *
+ * Even if PTEs can be unsigned long long, a PFN is always an
unsigned
+ * long fo
On Thu, Mar 19, 2009 at 12:24:26AM -0700, Li Yang-R58472 wrote:
> > -Original Message-
> > From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org
> > [mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org]
> > On Behalf Of Soohyung Cho
> > Sent: Thursday, March 19, 2009 1:47 PM
>
On Mar 19, 2009, at 10:52 AM, Anton Vorontsov wrote:
commit 1577ecef766650a57fceb171acee2b13cbfaf1d3 ("netdev: Merge UCC
and gianfar MDIO bus drivers") broke the TSEC TBI PHY support: the
driver now refuses to probe TBI MDIO buses as it doesn't know about
"fsl,gianfar-tbi" compatible entry, and
commit 1577ecef766650a57fceb171acee2b13cbfaf1d3 ("netdev: Merge UCC
and gianfar MDIO bus drivers") broke the TSEC TBI PHY support: the
driver now refuses to probe TBI MDIO buses as it doesn't know about
"fsl,gianfar-tbi" compatible entry, and thus _probe() fails with
-ENODEV status.
Fix this by ad
The NAND flash on the TQM8548_BE modules requires a short delay after
running the UPM pattern. The TQM8548_BE requires a further short delay
after writing out a buffer. Normally the R/B pin should be checked, but
it's not connected on the TQM8548_BE. The existing driver uses similar
fixed delay poi
This patch adds support for multi-chip NAND devices to the FSL-UPM
driver. This requires support for multiple GPIOs for the RNB pins.
Signed-off-by: Wolfgang Grandegger
---
drivers/mtd/nand/fsl_upm.c | 88 +--
1 files changed, 67 insertions(+), 21 deleti
For the NAND chips on the TQM8548 modules, a special chip-select logic is
used. It uses dedicated address lines to be set via UPM machine address
register (mar). This patch also adds that support to the FSL-UPM driver.
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/sysdev/fsl_lbc.c |2 +
This patch adds documentation for the new NAND FSL UPM bindings for:
NAND: FSL-UPM: add multi chip support
NAND: FSL-UPM: Add wait flags to support board/chip specific delays
NAND: FSL-UPM: add support for selecting chips via MAR
Signed-off-by: Wolfgang Grandegger
---
.../powerpc/dts-binding
This patch adds multi-chip support for the Micron MT29F8G08FAB NAND
flash memory on the TQM8548 modules.
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts |7 ++-
arch/powerpc/boot/dts/tqm8548.dts |7 ++-
2 files changed, 12 insertions(+),
This is the 2nd version of the patch series adding generic support for
multi-chip NAND devices to the FSL-UPM driver and support for the
Micron MT29F8G08FAB NAND flash memory on the TQM8548 modules. It
addresses the issues reported on the mailing list, e.g. the new
bindings are now documented:
[PA
On Mar 19, 2009, at 10:12 AM, Anton Vorontsov wrote:
commit 4826857f1bf07f9c0f1495e9b05d125552c88a85 ("gianfar: pass the
proper dev to DMA ops") introduced this build breakage:
CC drivers/net/gianfar.o
drivers/net/gianfar.c: In function 'gfar_suspend':
drivers/net/gianfar.c:552: error: '
commit 4826857f1bf07f9c0f1495e9b05d125552c88a85 ("gianfar: pass the
proper dev to DMA ops") introduced this build breakage:
CC drivers/net/gianfar.o
drivers/net/gianfar.c: In function 'gfar_suspend':
drivers/net/gianfar.c:552: error: 'struct gfar_private' has no member named
'dev'
drivers/
Hi,
i'm porting the linux 2.6.27 kernel to the custom board with PowerPC 7448 &
Marvell 64560. In DTS file the PCI ranges are configured as follows:
system-control...@fbe0 { /* Marvell Discovery mv64560 (Discovery
V)*/
#address-cells = <1>;
#size-cell
Complete workaround for DTLB errata in e300c2/c3/c4 processors.
Due to the bug, the hardware-implemented LRU algorythm always goes to way
1 of the TLB. This fix implements the proposed software workaround in
form of a LRW table for chosing the TLB-way.
Based on patch from David Jander
Signed-of
Now that r0 is free we can keep the value of I/DMISS in r3 and not reload
it before doing the tlbli/d. This saves us a few cycles in the fast path
case.
Signed-off-by: Kumar Gala
---
arch/powerpc/kernel/head_32.S | 51 +++-
1 files changed, 24 insertions(+)
Long ago we had some code that actually used the CTR in the SW TLB
miss handlers (603/e300). Since we don't use it no reason to waste
cycles saving it off and restoring it (we actually didn't restore it
in the fast path case).
Signed-off-by: Kumar Gala
---
arch/powerpc/kernel/head_32.S | 11 +
On Thu, Mar 19, 2009 at 10:30:01PM +0900, TOMARI Hisanobu wrote:
> Thanks for helpful advices.
> This patch adds an option to drivers/ide/Kconfig and adds
> some lines to drivers/ide/pmac.c .
I think it would be better to make it a kernel command line option
instead of Kconfig knob.
The reason i
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.
Rather than having to add a bus_notify to each platform we add a default
one at the highest pr
Now that we set archdata for of_platform and platform devices via
platform_notify() we no longer need to special case having a NULL device
pointer or NULL archdata. It should be a driver error if this condition
shows up and the driver should be fixed.
Signed-off-by: Kumar Gala
---
arch/powerpc/
This will allow us to remove the ppc32 specific checks in get_dma_ops()
that defaults to dma_direct_ops if the archdata is NULL. We really
should always have archdata set to something going forward.
Signed-off-by: Kumar Gala
---
arch/powerpc/kernel/pci-common.c |2 +-
1 files changed, 1 ins
Thanks for helpful advices.
This patch adds an option to drivers/ide/Kconfig and adds
some lines to drivers/ide/pmac.c . Now the driver checks
if the model is prefixed with "PowerBook" and the entire hack
can be toggled in the Kconfig.
Again, the patch is against linux 2.6.28.8.
Best regards,
TO
Commit-ID: 17ad6ea621b1c7952ebd7330ce65de26b6ee9cca
Gitweb: http://git.kernel.org/tip/17ad6ea621b1c7952ebd7330ce65de26b6ee9cca
Author: Stephen Rothwell
AuthorDate: Thu, 19 Mar 2009 22:03:22 +1100
Committer: Ingo Molnar
CommitDate: Thu, 19 Mar 2009 12:51:25 +0100
numa, cpumask: move num
* Rusty Russell wrote:
> On Thursday 19 March 2009 21:23:00 Stephen Rothwell wrote:
> > From: Stephen Rothwell
> > Date: Thu, 19 Mar 2009 21:35:24 +1100
> > Subject: [PATCH] powerpc: mmzone.h needs cpumask_t to be defined
> >
> > Commit 082edb7bf443eb8eda15b482d16ad9dd8137ad24 ("numa,cpumask:
On Thu, Mar 19, 2009 at 11:44:54AM +0530, Manish D wrote:
>Hi all,
>
>please bear these probably newbie questions.
>
>I am trying to port a BSP from 2.4 to 2.6 for a mpc834x based platform.
>I am building and working on the device tree now.
>Is there a way build this bsp, without taking the device
On Thursday 19 March 2009 21:23:00 Stephen Rothwell wrote:
> From: Stephen Rothwell
> Date: Thu, 19 Mar 2009 21:35:24 +1100
> Subject: [PATCH] powerpc: mmzone.h needs cpumask_t to be defined
>
> Commit 082edb7bf443eb8eda15b482d16ad9dd8137ad24 ("numa,cpumask: move
> numa_node_id default implementa
Hi again,
On Thu, 19 Mar 2009 21:53:00 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> In file included from include/linux/mmzone.h:776,
> from include/linux/gfp.h:5,
> from include/linux/kmod.h:23,
>
Hi all,
Today's linux-next build (powerpc allyesconfig) failed like this:
In file included from include/linux/mmzone.h:776,
from include/linux/gfp.h:5,
from include/linux/kmod.h:23,
from include/linux/module.h:14,
from init/versi
Am Mittwoch 18 März 2009 00:05:00 schrieb Benjamin Herrenschmidt:
> On Tue, 2009-03-17 at 16:30 +0100, Eduard Fuchs wrote:
> > Hi all,
> >
> > since several days I'm trying to run an ATI 9250 (PCI) graphic card under
> > Linux Kernel 2.6.27.19. Nevertheless without success. The kernel shows
> > the
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
arch/powerpc/Makefile |4
arch/powerpc/boot/dts/gef_ppc9a.dts| 364
arch/powerpc/boot/dts/mpc8572ds_camp_
On Mar 18, 2009, at 11:21 PM, Grant Likely wrote:
From: Grant Likely
Building the fs_enet driver as a modules fails because it cannot
access the global cpm2_immr symbol.
Signed-off-by: Grant Likely
---
Hey Ben and Kumar,
Just found this while testing some unrelated changes. Technically
t
On Mar 19, 2009, at 3:54 AM, Martyn Welch wrote:
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the default config file for GE Fanuc's PPC9A, a 6U single
board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch
---
applied to
On Mar 19, 2009, at 3:54 AM, Martyn Welch wrote:
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the basic board support for GE Fanuc's PPC9A, a 6U single
board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch
---
arch/powerpc
On Mar 13, 2009, at 6:35 AM, Martyn Welch wrote:
Patch to limit NEC fixup to SBC310, following similar patch to
SBC610 by Tony Breeds: 368a12117dd8abf6eaefa37c21ac313b517128b9
Signed-off-by: Martyn Welch
---
Hi Kumar,
The sbc310 patches have been added to your next tree. This patch is
nee
On Mar 18, 2009, at 2:21 PM, Anton Vorontsov wrote:
Currently the drivers just read "reg" property for constructing MDIO
bus IDs, but this won't work when we'll start using "ranges = <>" in
the device tree, so this will pop up:
Gianfar MII Bus: probed
sysfs: duplicate filename 'm...@520' can n
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the default config file for GE Fanuc's PPC9A, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch
---
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1889 ++
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the basic board support for GE Fanuc's PPC9A, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_ppc9a.dts | 364
The following series implements basic support for the GE Fanuc PPC9A, a
6U single board computer, based on the Freescale MPC8641D.
This series provides:
- The ability to boot the board with a serial console.
- Ethernet support.
- Sata and USB.
- Support for one of the 2 available watchdog time
Hi Sergej,
On Wed, Mar 18, 2009 at 7:30 PM, Stepanov, Sergej
wrote:
> in the attachment i send a spi driver (little bit "of") done by myself
Thanks for your driver. I've already got a SPI Controller driver, I
just want to hook it up to spidev.c so that it is has a Userspace
interface via /dev/sp
> -Original Message-
> From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org]
> On Behalf Of Soohyung Cho
> Sent: Thursday, March 19, 2009 1:47 PM
> To: linuxppc-dev@ozlabs.org; Wood Scott-B07421
> Subject: suspend-to-mem o
Hello.
I need to enable suspend-to-mem(deep sleep) on my mpc8349e-mitx-gp box.
When I send "mem" message to /sys/power/state, the box seems to get stop.
I think the box get stop when it executes suspend-asm.S codes.
I know that the latest linux supports suspend-to-mem on the mpc8313erdb box
well.
Hi,
this is Madhusudhan J from KPITCummins Bangalore India .
I have issue with uart driver in linux kernel 2.6.24
(drivers\serial\Mpc52xx_uart.c)
I am using platform mpc5121e to communicating to modem through serial
driver. i am not able to communicate with UART
driver(drivers\serial\Mp
76 matches
Mail list logo
