On Tue, Jun 17, 2008 at 05:44:43PM -0500, Sonny Rao wrote:
> On Tue, Jun 17, 2008 at 05:39:52PM -0500, Nathan Lynch wrote:
> > Hi, mainly a couple of coding style things, but one minor bug (I
> > think).
>
> Ok Will fix and send out again
From: Sonny Rao <[EMAIL PROTECTED]>
Adds a character dri
On Mon, Jun 16, 2008 at 01:53:44PM -0500, [EMAIL PROTECTED] wrote:
> From: Sonny Rao <[EMAIL PROTECTED]>
>
> Adds a character driver for BSR support on IBM POWER systems including
> Power5 and Power6. The BSR is an optional processor facility not currently
> implemented by any other processors.
Hello,
changes since the last patch:
update the Portpin initialization.
[powerpc] Added support for the MPC8247 based board MGCOGE
from Keymile.
Signed-off-by: Heiko Schocher <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mgcoge.dts | 174 +++
arch/powerpc/configs/mgcoge_d
On Tue, Jun 17, 2008 at 05:39:52PM -0500, Nathan Lynch wrote:
> Hi, mainly a couple of coding style things, but one minor bug (I
> think).
>
> [EMAIL PROTECTED] wrote:
> > From: Sonny Rao <[EMAIL PROTECTED]>
> >
> > +static int bsr_mmap(struct file *filp, struct vm_area_struct *vma)
> > +{
> > +
Hi,
I've tried to renew the fixes of ALSA issues about non-coherent DMA
memories. The last patch worked for SG-buffers somehow but would
result in a problem if many pages are allocated because of
dma_alloc_coherent() handling. Now, I chose a more simpler
workaround: the SG-buffers are handled as
A very lazy version of dma_mmap_coherent() implementation for ppc32.
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
---
include/asm-powerpc/dma-mapping.h | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/include/asm-powerpc/dma-mapping.h
b/include/asm-po
The DMA buffers allocated via dma_alloc_coherent() aren't easily mmappable
for many architectures. This is a quick fix for some known archs that
don't work properly with the current code.
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
---
sound/core/Kconfig |7 +++
sound/core/pcm_n
Using SG-buffers with dma_alloc_coherent() is messy for non-coherent
architectures. So, simply disable SG-buffers but just allocate normal
continuous buffers instead.
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
---
include/sound/memalloc.h | 19 +++
include/sound/pcm.
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart [mailto:[EMAIL PROTECTED]
> Sent: Monday, 16 June 2008 18:53
> To: linuxppc-dev@ozlabs.org
> Cc: Mark Ware
> Subject: Re: CPM2 mii-bitbang: Allowing mdio on port pins
> other than port C
>
> Hi Mark,
>
> On Monday 16 June 2008
On Jun 17, 2008, at 7:47 PM, Michael Neuling wrote:
The following set of patches adds Vector Scalar Extentions (VSX)
support for POWER7. Includes context switch, ptrace and signals
support.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
This series is on top of the POWER7 cputable
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get two more small bug-fixes for powerpc, as listed below.
Thanks,
Paul.
arch/powerpc/kernel/head_44x.S |7 ++-
arch/powerpc/mm/hash_low_64.S |4
2 files c
I agree, I'll separate the fec_t -> struct fec changes out.
On Tue, Jun 17, 2008 at 11:20 PM, Grant Likely <[EMAIL PROTECTED]>
wrote:
> On Tue, Jun 17, 2008 at 5:03 PM, John Rigby <[EMAIL PROTECTED]> wrote:
> > Fixed all errors and warnings that checkpatch.pl
> > reports if this was a new submiss
Hi Mark,
On Wednesday 18 June 2008 14:21, Mark Ware wrote:
> Hi Laurent,
> > Hi Mark,
> >
> > On Monday 16 June 2008 08:19, Mark Ware wrote:
> > > Hello,
> > >
> > > I am preparing a board port (from 2.4.18!) for a proprietary board
> > > which has it's mdio on a different port than mdc. The c
Hi Scott,
On Monday 16 June 2008 18:34, Scott Wood wrote:
> On Mon, Jun 16, 2008 at 10:57:02AM +0200, Laurent Pinchart wrote:
> > On Monday 26 May 2008 11:53, Laurent Pinchart wrote:
> > > Port the fs_enet driver to support the MDIO on GPIO driver for PHY
> > > access in addition to the mii-bitban
On Jun 17, 2008, at 7:47 PM, Michael Neuling wrote:
If we set the SPE MSR bit in save_user_regs we can blow away the VEC
bit. This will never happen in reality, but it looks bad.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/signal_32.c | 10 ++
1 file c
Laurent Pinchart wrote:
Hi Scott,
On Monday 16 June 2008 18:34, Scott Wood wrote:
On Mon, Jun 16, 2008 at 10:57:02AM +0200, Laurent Pinchart wrote:
On Monday 26 May 2008 11:53, Laurent Pinchart wrote:
Port the fs_enet driver to support the MDIO on GPIO driver for PHY
access in addition to the
The restart() function is called when the link state changes and resets
multicast and promiscous settings. This patch restores those settings at the
end of restart().
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/mac-fcc.c |3 +++
2 files changed, 4 insertion
On Jun 17, 2008, at 11:12 PM, John Rigby wrote:
Sorry, I thought I was doing the right thing to base the patch on
Kumar's patch that removes the CONFIG_PPC_CPM_NEW_BINDING stuff.
That is likely why it did not apply.
It is the right thing, we just need to work out the logistics here.
Je
On Wednesday 18 June 2008 17:00, Jeff Garzik wrote:
> Laurent Pinchart wrote:
> > Hi Scott,
> >
> > On Monday 16 June 2008 18:34, Scott Wood wrote:
> >> On Mon, Jun 16, 2008 at 10:57:02AM +0200, Laurent Pinchart wrote:
> >>> On Monday 26 May 2008 11:53, Laurent Pinchart wrote:
> Port the fs_e
Hi David,
Looks like your device tree is based on the beta ltib bsp. There were
some changes in release 1 that you may want to incorporate:
First as a convention I changed all the interrupt numbers in the
tuples to be decimal. I like this better because the interrupts are
decimal in the referen
On Tue, Jun 17, 2008 at 04:52:25PM -0700, Trent Piepho wrote:
> Why is FS_ENET_HAS_SCC a bool, and not tristate?
That was an oversight on my part -- they should be tristate.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org
On Tue, Jun 17, 2008 at 05:03:13PM -0600, John Rigby wrote:
> static int __devinit find_phy(struct device_node *np,
> - struct fs_platform_info *fpi)
> + struct fs_platform_info *fpi)
Please don't make this sort of change. Spaces were used d
Changes since last patch set:
This patch no longer assmues Kumar's patch that
removes CONFIG_PPC_CPM_NEW_BINDING stuff. That was just
confusing.
No checkpatch.pl fixes.
Addresses all comments to previous patch.
Does not rework the Kconfig logic. More work is need than w
This is in preparation of adding support for
MPC5121 FEC. The 5121 patch needs to add a different
struct fec because it has a different register layout.
This patch allows the 5121 patch to not include a typedef
fec_t which checkpatch complains about.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
Eric Witcher wrote:
The answer is that mpic_assign_isu(mpic, 1, paddr + 0x11000) places the initial
base register
for isu 1 on a reserved location in the PIC register map (see *). I guess you
can infer from this
that no badness occurs when you write to a reserved location on the PIC.
See? S
Hi everybody,
I have to configure a CPM2 baud rate generator to use an external clock in a
device driver. To avoid code duplication I'd like to reorganize the CPM2 baud
rate configuration functions as proposed in the attached patch. Would this be
acceptable ?
--
The CPM2 BRG setup functions c
I'll send out some additional entries in a minute when I rebase what I
have on this. I think a couple of those lines were originally authored
by me so...
Signed-off-by: Joel Schopp <[EMAIL PROTECTED]>
Michael Neuling wrote:
Add a cputable entry for the POWER7 processor.
Also tell firmware
A couple of these lines originated with me.
Signed-off-by: Joel Schopp <[EMAIL PROTECTED]>
Michael Neuling wrote:
Add a VSX CPU feature. Also add code to detect if VSX is available
from the device tree.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/prom.c |
On Jun 18, 2008, at 11:10 AM, Jon Loeliger wrote:
Eric Witcher wrote:
The answer is that mpic_assign_isu(mpic, 1, paddr + 0x11000) places
the initial base register
for isu 1 on a reserved location in the PIC register map (see *).
I guess you can infer from this
that no badness occurs when
Hi Laurent,
Agreed. Jochen, will you resubmit or should I do it ?
Please do as i'm currently away and won't be back until next week.
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxp
Based on earlier work by Jochen Friedrich.
This patch implement GPIO LIB support for the CPM2 GPIOs.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
Cc: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +
arch/powerpc/sysdev/cpm2.c | 11
arch/powe
I'm glad that you have corrected it. Half a year ago I pointed out
that there was such a mistake:
http://patchwork.ozlabs.org/linuxppc/patch?id=10700
Thanks.
2008/6/18 Laurent Pinchart <[EMAIL PROTECTED]>:
> The restart() function is called when the link state changes and resets
> multicast and p
On Jun 17, 2008, at 7:47 PM, Michael Neuling wrote:
The layout of the new VSR registers and how they overlap on top of the
legacy FPR and VR registers is:
VSR doubleword 0 VSR doubleword 1
--
Unlike other SOCs with e300 cores the 5121 is not cache coherent. The
problem is an internal bridge that the processor can not snoop across.
On Wed, Jun 18, 2008 at 1:29 PM, Kenneth Johansson <[EMAIL PROTECTED]> wrote:
> I have tried to speed up u-boot by turning on I/D cache during boot.
>
> It
I have tried to speed up u-boot by turning on I/D cache during boot.
It sort of works and gives quite a boost but I'm having problems with
the ethernet driver that no longer works.
What I'm seeing is that the cpu do not notice the ethernet hardwares
updates that is located in DRAM. Basically w
The patches following add some additional cputable, architecture-vec, etc bits
for Power7. Specifically the bits for running in 2.06 architected mode.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-de
Add support for MPC512x to fs_enet driver
MPC5121 has an FEC core that is nearly identical to the FEC
in 8xx. The only problem is that the registers locations have
been shuffled. Because of this shuffling of registers, one needs
a different structure to describe the 5121 FEC. This is not a huge
Add an entry for Power7 architected mode and add "(raw)" to Power7 raw mode to
distinguish it more clearly.
Signed-off-by: Joel Schopp <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 48 +
arch/powerpc/platforms/pseries/cpu_setup.S |6 +++
i
Add the bits to the architecture-vec so that ibm,client-architecture
lets the firmware know we support the 2.06 architecture.
Signed-off-by: Joel Schopp <[EMAIL PROTECTED]>
Index: 2.6.26-rc6/arch/powerpc/kernel/prom_init.c
===
--- 2.
I'm adding a new defconfig file to the new configs/44x directory and
make doesn't seem to find it.
I must be missing something as this seems simple.
Should I have to specify 44x in the path (make ARCH=powerpc
44x/defconfig) as this does work?
Thanks,
John
This email and any attachments are int
On Wed, 18 Jun 2008 14:36:37 -0600
"John Linn" <[EMAIL PROTECTED]> wrote:
> Should I have to specify 44x in the path (make ARCH=powerpc
> 44x/defconfig) as this does work?
Yes. At least I have to now.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linux
On Jun 18, 2008, at 3:18 PM, [EMAIL PROTECTED] wrote:
Add an entry for Power7 architected mode and add "(raw)" to Power7
raw mode to
distinguish it more clearly.
Signed-off-by: Joel Schopp <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 48 +++
On Jun 18, 2008, at 3:36 PM, John Linn wrote:
I'm adding a new defconfig file to the new configs/44x directory and
make doesn't seem to find it.
I must be missing something as this seems simple.
Should I have to specify 44x in the path (make ARCH=powerpc
44x/defconfig) as this does work?
i
Currently when a 32 bit process is exec'd on a powerpc 64 bit host the value
in the top three bytes of the personality is clobbered. This patch adds a
check in the SET_PERSONALITY macro that will carry all the values in the top
three bytes across the exec.
These three bytes currently carry flags
On Wed, 2008-06-18 at 13:38 -0600, John Rigby wrote:
> Unlike other SOCs with e300 cores the 5121 is not cache coherent. The
> problem is an internal bridge that the processor can not snoop across.
I do not have access to the manuals right now but I search all over an
this was not something I fou
Hello,
I have an mpc8540 target board with a BSP - linux-2.6.11. I have a host
machine where I have ppc-target configured gdb obtained from gdb-6.8.tar.gz.
I am able to debug userspace files by running gdbserver in target machine.
Now I want to debug kernel files of my target machine. I have
CONFIG
Olof Johansson wrote:
On Jun 18, 2008, at 3:18 PM, [EMAIL PROTECTED] wrote:
Add an entry for Power7 architected mode and add "(raw)" to Power7
raw mode to
distinguish it more clearly.
Signed-off-by: Joel Schopp <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 48
++
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for val
Andrew,
The first patch in this series hits architecture independent code, but the
rest is contained in the powerpc subtree. Could you pick up the first
patch into -mm? I can send the rest of them through the powerpc git tree.
The first patch and the rest of the set are independent and can be me
This patch applies on top of the patches posted today to linuxppc-dev by
Michael Neuling and Joel Schopp.
Signed-off-by: Joel Schopp <[EMAIL PROTECTED]>
Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]>
Index: linux-2.6.26-rc5/include/asm-powerpc/cputable.h
Allow an application to enable Strong Access Ordering on specific pages of
memory on Power 7 hardware. Currently, power has a weaker memory model than
x86. Implementing a stronger memory model allows an emulator to more
efficiently translate x86 code into power code, resulting in faster code
execut
Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/lpar.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.26-rc5/arch/powerpc/platforms/pseries/lpar.c
=
This patch defines:
- PROT_SAO, which is passed into mmap() and mprotect() in the prot field
- VM_SAO in vma->vm_flags, and
- _PAGE_SAO, the combination of WIMG bits in the pte that enables strong
access ordering for the page.
NOTE: There doesn't seem to be a precedent for architecture-dependent
Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]>
Cc: Jon Tollefson <[EMAIL PROTECTED]>
Cc: Adam Litke <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux-2.6.26-rc5/arch/po
Kumar Gala writes:
> Is VSX mutually exclusive with altivec/fp? is there a MSR bit for it?
It's not exclusive, it's an extension of altivec/fp, and yes it has
its own MSR bit to enable it.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
ht
On Wed, 18 Jun 2008 09:15:53 -0600 John Rigby <[EMAIL PROTECTED]> wrote:
>
> This is in preparation of adding support for
> MPC5121 FEC. The 5121 patch needs to add a different
> struct fec because it has a different register layout.
>
> This patch allows the 5121 patch to not include a typedef
>
> On Jun 17, 2008, at 7:47 PM, Michael Neuling wrote:
>
> > The following set of patches adds Vector Scalar Extentions (VSX)
> > support for POWER7. Includes context switch, ptrace and signals
> > support.
> >
> > Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> > ---
> > This series is on
In message <[EMAIL PROTECTED]> you wrote:
>
> On Jun 17, 2008, at 7:47 PM, Michael Neuling wrote:
>
> > If we set the SPE MSR bit in save_user_regs we can blow away the VEC
> > bit. This will never happen in reality, but it looks bad.
> >
> > Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
>
There is an "interesting" quality of POWER6 cores, which each have 2
hardware threads: assuming one thread on the core is idle, the primary
thread is a little "faster" than the secondary thread. To illustrate:
for cpumask in 0x1 0x2 ; do
taskset $cpumask /usr/bin/time -f "%e elapsed, %U user,
Add a cpu_power() call to machdep_calls, which will allow platforms to
override the scheduler's default cpu power calculation. If the
platform does not provide a cpu_power() method, the scheduler's
default value is used.
Copy the default SD_SIBLING_INIT to powerpc's topology.h and add the
SD_ASYM
Add a new sched domain flag, SD_ASYM_CPU_POWER, which signifies that
the architecture may override the cpu power for a cpu via a hook in
init_sched_groups_power(). Add a dummy definition of arch_cpu_power()
which conforms with the existing behavior.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
On POWER6 processors, cpu-bound programs generally perform better on
the primary thread when the secondary thread is idle than they do on
the secondary thread while the primary thread is idle. This
difference can be observed by timing a simple shell loop:
for cpumask in 0x1 0x2 ; do
tasks
Hi,
+static unsigned int pseries_cpu_power(int cpu, unsigned int
default_power)
+{
+ struct device_node *np;
+ unsigned int thread, power;
+
+ if (!cpu_has_feature(CPU_FTR_ASYM_POWER))
+ return default_power;
+
+ power = default_power;
Why not just NULL
On Jun 18, 2008, at 9:58 PM, Olof Johansson wrote:
Why not just NULL out the cpu_power function pointers on platforms
that don't have the feature bit instead? (or the other way around:
NULL by default, and set only on platforms that have imbalanced
threads.
Nevermind; bogus optimization.
On Jun 18, 2008, at 5:58 PM, Paul Mackerras wrote:
Kumar Gala writes:
Is VSX mutually exclusive with altivec/fp? is there a MSR bit for
it?
It's not exclusive, it's an extension of altivec/fp, and yes it has
its own MSR bit to enable it.
what MSR bit does it use... I'm not seeing the co
Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/processor.h
+++ linux-2.6-ozlabs/include/asm-powerpc/processor.h
@@ -78,6 +78,7 @@ extern long kernel_thread(int (*fn)(void
/*
In message <[EMAIL PROTECTED]> you wrote:
>
> On Jun 18, 2008, at 5:58 PM, Paul Mackerras wrote:
>
> > Kumar Gala writes:
> >
> >> Is VSX mutually exclusive with altivec/fp? is there a MSR bit for
> >> it?
> >
> > It's not exclusive, it's an extension of altivec/fp, and yes it has
> > its own
In message <[EMAIL PROTECTED]> you wrote
:
> >
> >
> > Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h
> > ===
> > --- linux-2.6-ozlabs.orig/include/asm-powerpc/processor.h
> > +++ linux-2.6-ozlabs/include/asm-powerpc/processor
On Jun 18, 2008, at 11:35 PM, Michael Neuling wrote:
In message <5AEB0769-1394-4924-803D-
[EMAIL PROTECTED]> you wrote
:
Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/
In message <[EMAIL PROTECTED]> you wrote
:
>
> On Jun 18, 2008, at 11:35 PM, Michael Neuling wrote:
>
> > In message <5AEB0769-1394-4924-803D-
> > [EMAIL PROTECTED]> you wrote
> > :
> >>>
> >>>
> >>> Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h
> >>> ==
+ } fpvsr __attribute__((aligned(16)));
Do we really need a union here? what would happen if you just
changed
the type of fpr[32] from double to vector if #CONFIG_VSX?
I really dont like the union and think we can just make the storage
look opaque which is the key. I doubt we every real
In message <[EMAIL PROTECTED]> you wrote
:
> > + } fpvsr __attribute__((aligned(16)));
>
> Do we really need a union here? what would happen if you just
> changed
> the type of fpr[32] from double to vector if #CONFIG_VSX?
>
> I really dont like the union an
On Jun 19, 2008, at 1:01 AM, Michael Neuling wrote:
In message [EMAIL PROTECTED]> you wrote
:
+ } fpvsr __attribute__((aligned(16)));
Do we really need a union here? what would happen if you just
changed
the type of fpr[32] from double to vector if #CONFIG_VSX?
I really dont like the
On May 29, 2008, at 1:20 AM, Michael Ellerman wrote:
We currently have a few routines for patching code in asm/system.h,
because
they didn't fit anywhere else. I'd like to clean them up a little
and add
some more, so first move them into a dedicated C file - they don't
need to
be inlined.
On Wed, 2008-06-18 at 10:47 +1000, Michael Neuling wrote:
> {"ibm,vmx", 1, CPU_FTR_ALTIVEC, PPC_FEATURE_HAS_ALTIVEC},
> #endif /* CONFIG_ALTIVEC */
> +#ifdef CONFIG_VSX
> + {"ibm,vmx", 2, CPU_FTR_VSX, PPC_FEATURE_HAS_VSX},
> +#endif /* CONFIG_VSX */
Should that be "ibm,vsx"?
--
dw
On Thu, 2008-06-19 at 01:15 -0500, Kumar Gala wrote:
> On May 29, 2008, at 1:20 AM, Michael Ellerman wrote:
>
> > We currently have a few routines for patching code in asm/system.h,
> > because
> > they didn't fit anywhere else. I'd like to clean them up a little
> > and add
> > some more, so
76 matches
Mail list logo
