Re: [PATCH] Add kernstart_addr to list of allowed symbols in prom_init

[Kamalesh Babulal]

Michael Ellerman wrote:
> Since commit "85xx: Add support for relocatable kernel (and
> booting at non-zero)" (37dd2badcfcec35f5e21a0926968d77a404f03c3),
> PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE
> and FLATMEM is enabled.
> 
> PHYSICAL_START is used in prom_init.c and so kernstart_addr
> needs to be added to the list of allowed symbols that
> prom_init.c can access.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> ---
> 
> Not sure if anyone is building this config in practice, but it
> is broken in 26 without this patch.
> 
>  arch/powerpc/kernel/prom_init_check.sh |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/prom_init_check.sh 
> b/arch/powerpc/kernel/prom_init_check.sh
> index 8e24fc1..31729a9 100644
> --- a/arch/powerpc/kernel/prom_init_check.sh
> +++ b/arch/powerpc/kernel/prom_init_check.sh
> @@ -20,7 +20,7 @@ WHITELIST="add_reloc_offset __bss_start __bss_stop 
> copy_and_flush
>  _end enter_prom memcpy memset reloc_offset __secondary_hold
>  __secondary_hold_acknowledge __secondary_hold_spinloop __start
>  strcmp strcpy strlcpy strlen strncmp strstr logo_linux_clut224
> -reloc_got2"
> +reloc_got2 kernstart_addr"
> 
>  NM="$1"
>  OBJ="$2"
Hi Michael,

Thanks, the patch fixes the build failure.

Tested-by: Kamalesh Babulal <[EMAIL PROTECTED]>

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] [POWERPC] mpic: cope with non mpic irqs

[Stephen Rothwell]

Compiling ppc64_defconfig with gcc 4.3 gives thes warnings:

arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_get_priority':
arch/powerpc/sysdev/mpic.c:1351: warning: 'is_ipi' may be used uninitialized in 
this function
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority':
arch/powerpc/sysdev/mpic.c:1328: warning: 'is_ipi' may be used uninitialized in 
this function

It turns out that in the cases where is_ipi is uninitialized, another
variable (mpic) will be NULL and it is dereferenced.  Protect against
this by returning if mpic is NULL in mpic_irq_set_priority and removing
mpic_irq_get_priority completely as it has no in tree callers.

This has the nice side effect of making the warning go away.

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 arch/powerpc/sysdev/mpic.c |   20 +++-
 include/asm-powerpc/mpic.h |3 +--
 2 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..7680001 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1331,6 +1331,9 @@ void mpic_irq_set_priority(unsigned int irq, unsigned int 
pri)
unsigned long flags;
u32 reg;
 
+   if (!mpic)
+   return;
+
spin_lock_irqsave(&mpic_lock, flags);
if (is_ipi) {
reg = mpic_ipi_read(src - mpic->ipi_vecs[0]) &
@@ -1346,23 +1349,6 @@ void mpic_irq_set_priority(unsigned int irq, unsigned 
int pri)
spin_unlock_irqrestore(&mpic_lock, flags);
 }
 
-unsigned int mpic_irq_get_priority(unsigned int irq)
-{
-   unsigned int is_ipi;
-   struct mpic *mpic = mpic_find(irq, &is_ipi);
-   unsigned int src = mpic_irq_to_hw(irq);
-   unsigned long flags;
-   u32 reg;
-
-   spin_lock_irqsave(&mpic_lock, flags);
-   if (is_ipi)
-   reg = mpic_ipi_read(src = mpic->ipi_vecs[0]);
-   else
-   reg = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
-   spin_unlock_irqrestore(&mpic_lock, flags);
-   return (reg & MPIC_VECPRI_PRIORITY_MASK) >> MPIC_VECPRI_PRIORITY_SHIFT;
-}
-
 void mpic_setup_this_cpu(void)
 {
 #ifdef CONFIG_SMP
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 943c5a3..a4d0f87 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -428,12 +428,11 @@ extern void mpic_init(struct mpic *mpic);
  */
 
 
-/* Change/Read the priority of an interrupt. Default is 8 for irqs and
+/* Change the priority of an interrupt. Default is 8 for irqs and
  * 10 for IPIs. You can call this on both IPIs and IRQ numbers, but the
  * IPI number is then the offset'ed (linux irq number mapped to the IPI)
  */
 extern void mpic_irq_set_priority(unsigned int irq, unsigned int pri);
-extern unsigned int mpic_irq_get_priority(unsigned int irq);
 
 /* Setup a non-boot CPU */
 extern void mpic_setup_this_cpu(void);
-- 
1.5.5.1

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board

[Jin Zhengxiong]

 

> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, May 21, 2008 11:39 AM
> To: Jin Zhengxiong
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board
> 
> 
> On May 20, 2008, at 10:29 PM, Jin Zhengxiong wrote:
> 
> >
> >
> >> -Original Message-
> >> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> >> Sent: Tuesday, May 20, 2008 9:24 PM
> >> To: Jin Zhengxiong
> >> Cc: linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH 3/4 V4] Enable MSI support for 
> MPC8610HPCD board
> >>
> >>> diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/ 
> >>> powerpc/platforms/86xx/mpc8610_hpcd.c
> >>> index dea1320..290d717 100644
> >>> --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> >>> +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> >>> @@ -71,9 +71,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
> >>>   /* Alloc mpic structure and per isu has 16 INT entries. */
> >>>   mpic1 = mpic_alloc(np, res.start,
> >>>   MPIC_PRIMARY | MPIC_WANTS_RESET |
> >> MPIC_BIG_ENDIAN,
> >>> - 0, 256, " MPIC ");
> >>> + 64, 256, " MPIC ");
> >>>   BUG_ON(mpic1 == NULL);
> >>>
> >>> + mpic_assign_isu(mpic1, 0, res.start + 0x1);
> >>> + mpic_assign_isu(mpic1, 1, res.start + 0x10800);
> >>> + mpic_assign_isu(mpic1, 2, res.start + 0x11600);
> >>> +
> >>
> >> I don't understand why you are breaking the interrupts up 
> like this.
> >>
> >> If you leave as it was, the MSIs would start at hw irq 176
> >
> > If the ISU size is 0, mpic will only initialize the 
> interrupt source 
> > num reading from Feature Reporting Register(FRR), For 8610 
> it's 104, 
> > for 8572 it is 108, As the address space of the interrupt source 
> > configuration register is not continuous(between 
> 0xa00-0x1600), with 
> > ISU=0, actually only the 16 externel interrupts and 64 internal 
> > interrupts were initialized.
> > the Messaging interrupts and MSI interrupts were not intialized.
> >
> > With the original code. the Messaging interrupts would 
> start at hwirq
> > 176 and the MSIs would
> > start at hwirq 224.
> > By setting the ISU=64, the Messaging interrupts would start 
> at 128 and 
> > the MSIs start at 176.
> > And all the interrupt sources will be initialized.
> 
> Yeah, I remember this now.  What about something like:
> 
> diff --git a/arch/powerpc/sysdev/mpic.c 
> b/arch/powerpc/sysdev/mpic.c index 8619f2a..90de869 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -1251,6 +1251,8 @@ void __init mpic_init(struct mpic *mpic)
>  if (mpic->irq_count == 0)
>  mpic->irq_count = mpic->num_sources;
> 
> +   mpic->num_sources = max(mpic->num_sources, mpic->irq_count);
> +
>  /* Do the HT PIC fixups on U3 broken mpic */
>  DBG("MPIC flags: %x\n", mpic->flags);
>  if ((mpic->flags & MPIC_U3_HT_IRQS) && (mpic->flags &
> MPIC_PRIMARY)) {
> 

Moving this code earlier to mpic_alloc like following patch, can make
mpic
initialize all the "irq_count" interrupt sources, although a little
difficult to understand
for those did not know the background. 
On the other side, IF the reserved space was somewhat enlarged in the
source
configuration register, We need to enlarge the irq-count for those
unexist interrupts.

Jason

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..baa9df1 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1143,11 +1143,14 @@ struct mpic * __init mpic_alloc(struct
device_node *node,
greg_feature = mpic_read(mpic->gregs,
MPIC_INFO(GREG_FEATURE_0));
mpic->num_cpus = ((greg_feature &
MPIC_GREG_FEATURE_LAST_CPU_MASK)
  >> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
-   if (isu_size == 0)
+   if (isu_size == 0) {
mpic->num_sources =
((greg_feature &
MPIC_GREG_FEATURE_LAST_SRC_MASK)
 >> MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
 
+   mpic->num_sources = max(mpic->num_sources,
mpic->irq_count);
+   }
+
/* Map the per-CPU registers */
for (i = 0; i < mpic->num_cpus; i++) {
mpic_map(mpic, paddr, &mpic->cpuregs[i],
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Uniformly use memstart_addr variable as the start address of physical memory in powerpc branch

[Paul Mackerras]

Andrew Liu writes:

> You know we can't make sure in future the start address of all incoming 
> boards' RAM is 0, especially, in AMP system, different cpu uses the different 
> RAM area, 
> definitely, the start address of some is not 0.

Any processor that uses ppc_mmu_32.c will have interrupt vectors in
the 0 - 0x3000 region of memory and hence *must* have RAM starting at
zero.  In other words, that file is only used for "classic" 32-bit
PowerPC processors, not for anything based on Book E or Power
architecture v2.04 or later.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board

[Kumar Gala]

On May 20, 2008, at 10:29 PM, Jin Zhengxiong wrote:





-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 20, 2008 9:24 PM
To: Jin Zhengxiong
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board


diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/
powerpc/platforms/86xx/mpc8610_hpcd.c
index dea1320..290d717 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -71,9 +71,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
/* Alloc mpic structure and per isu has 16 INT entries. */
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET |

MPIC_BIG_ENDIAN,

-   0, 256, " MPIC ");
+   64, 256, " MPIC ");
BUG_ON(mpic1 == NULL);

+   mpic_assign_isu(mpic1, 0, res.start + 0x1);
+   mpic_assign_isu(mpic1, 1, res.start + 0x10800);
+   mpic_assign_isu(mpic1, 2, res.start + 0x11600);
+


I don't understand why you are breaking the interrupts up like this.

If you leave as it was, the MSIs would start at hw irq 176


If the ISU size is 0, mpic will only initialize the interrupt source  
num

reading from
Feature Reporting Register(FRR), For 8610 it's 104, for 8572 it is  
108,

As the address
space of the interrupt source configuration register is not
continuous(between 0xa00-0x1600),
with ISU=0, actually only the 16 externel interrupts and 64 internal
interrupts were initialized.
the Messaging interrupts and MSI interrupts were not intialized.

With the original code. the Messaging interrupts would start at hwirq
176 and the MSIs would
start at hwirq 224.
By setting the ISU=64, the Messaging interrupts would start at 128 and
the MSIs start at 176.
And all the interrupt sources will be initialized.


Yeah, I remember this now.  What about something like:

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..90de869 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1251,6 +1251,8 @@ void __init mpic_init(struct mpic *mpic)
if (mpic->irq_count == 0)
mpic->irq_count = mpic->num_sources;

+   mpic->num_sources = max(mpic->num_sources, mpic->irq_count);
+
/* Do the HT PIC fixups on U3 broken mpic */
DBG("MPIC flags: %x\n", mpic->flags);
if ((mpic->flags & MPIC_U3_HT_IRQS) && (mpic->flags &  
MPIC_PRIMARY)) {



- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board

[Jin Zhengxiong]

 

> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, May 20, 2008 9:24 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board
> 
> > diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/ 
> > powerpc/platforms/86xx/mpc8610_hpcd.c
> > index dea1320..290d717 100644
> > --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> > +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> > @@ -71,9 +71,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
> > /* Alloc mpic structure and per isu has 16 INT entries. */
> > mpic1 = mpic_alloc(np, res.start,
> > MPIC_PRIMARY | MPIC_WANTS_RESET | 
> MPIC_BIG_ENDIAN,
> > -   0, 256, " MPIC ");
> > +   64, 256, " MPIC ");
> > BUG_ON(mpic1 == NULL);
> >
> > +   mpic_assign_isu(mpic1, 0, res.start + 0x1);
> > +   mpic_assign_isu(mpic1, 1, res.start + 0x10800);
> > +   mpic_assign_isu(mpic1, 2, res.start + 0x11600);
> > +
> 
> I don't understand why you are breaking the interrupts up like this.
> 
> If you leave as it was, the MSIs would start at hw irq 176

If the ISU size is 0, mpic will only initialize the interrupt source num
reading from
Feature Reporting Register(FRR), For 8610 it's 104, for 8572 it is 108,
As the address
space of the interrupt source configuration register is not
continuous(between 0xa00-0x1600),
 with ISU=0, actually only the 16 externel interrupts and 64 internal
interrupts were initialized.
the Messaging interrupts and MSI interrupts were not intialized. 

With the original code. the Messaging interrupts would start at hwirq
176 and the MSIs would 
start at hwirq 224. 
By setting the ISU=64, the Messaging interrupts would start at 128 and
the MSIs start at 176. 
And all the interrupt sources will be initialized.

Jason  
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Uniformly use memstart_addr variable as the start address of physical memory in powerpc branch

[Andrew Liu]

Kumar Gala wrote:


On May 20, 2008, at 8:38 PM, Andrew Liu wrote:


[POWERPC]: Uniformly use memstart_addr as the start address of RAM

The variable: memstart_addr whose initial value is got from dts file
is used as the start address of physical memory in PowerPC ARCH,
although it is used in functions: mapin_ram(pgtable_32.c) and
cam_mapin_ram(fsl_booke_mmu.c), however, in function: mmu_mapin_ram
(ppc_mmu_32.c), use 0 as the start address of physical memory, so
it is necessary to unify them: in mmu_mapin_ram, use memstart_addr
as the start address of physical memory, instead of 0.

Signed-off-by: Andrew Liu <[EMAIL PROTECTED]>
---


Do you have a case where this is non-zero for ppc_mmu_32?  I left these 
alone because I wasn't aware of one (or if its reasonable).




No.
I submitted this patch just because in ppc branch, PPC_MEMSTART is used as 
the start address of physical memory uniformly, however, in powerpc branch, 
use memstart_addr and 0, although, almost for all boards which are in powerpc,

they are equal, from the aspect of code consistency, I think it is necessary to
unify them.

You know we can't make sure in future the start address of all incoming 
boards' RAM is 0, especially, in AMP system, different cpu uses the different RAM area, 
definitely, the start address of some is not 0.


BRs,
Andrew



- k



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Uniformly use memstart_addr variable as the start address of physical memory in powerpc branch

[Kumar Gala]

On May 20, 2008, at 8:38 PM, Andrew Liu wrote:


[POWERPC]: Uniformly use memstart_addr as the start address of RAM

The variable: memstart_addr whose initial value is got from dts file
is used as the start address of physical memory in PowerPC ARCH,
although it is used in functions: mapin_ram(pgtable_32.c) and
cam_mapin_ram(fsl_booke_mmu.c), however, in function: mmu_mapin_ram
(ppc_mmu_32.c), use 0 as the start address of physical memory, so
it is necessary to unify them: in mmu_mapin_ram, use memstart_addr
as the start address of physical memory, instead of 0.

Signed-off-by: Andrew Liu <[EMAIL PROTECTED]>
---


Do you have a case where this is non-zero for ppc_mmu_32?  I left  
these alone because I wasn't aware of one (or if its reasonable).


- k

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] [POWERPC] Uniformly use memstart_addr variable as the start address of physical memory in powerpc branch

[Andrew Liu]

[POWERPC]: Uniformly use memstart_addr as the start address of RAM

The variable: memstart_addr whose initial value is got from dts file
is used as the start address of physical memory in PowerPC ARCH,
although it is used in functions: mapin_ram(pgtable_32.c) and
cam_mapin_ram(fsl_booke_mmu.c), however, in function: mmu_mapin_ram
(ppc_mmu_32.c), use 0 as the start address of physical memory, so
it is necessary to unify them: in mmu_mapin_ram, use memstart_addr
as the start address of physical memory, instead of 0.

Signed-off-by: Andrew Liu <[EMAIL PROTECTED]>
---

b/arch/powerpc/mm/ppc_mmu_32.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index cef9f15..f133c6e 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -98,7 +98,7 @@ unsigned long __init mmu_mapin_ram(void)
break;
}

-   setbat(2, KERNELBASE, 0, bl, _PAGE_RAM);
+   setbat(2, KERNELBASE, memstart_addr, bl, _PAGE_RAM);
done = (unsigned long)bat_addrs[2].limit - KERNELBASE + 1;
if ((done < tot) && !bat_addrs[3].limit) {
/* use BAT3 to cover a bit more */
@@ -106,7 +106,7 @@ unsigned long __init mmu_mapin_ram(void)
for (bl = 128<<10; bl < max_size; bl <<= 1)
if (bl * 2 > tot)
break;
-   setbat(3, KERNELBASE+done, done, bl, _PAGE_RAM);
+   setbat(3, KERNELBASE+done, memstart_addr+done, bl, _PAGE_RAM);
done = (unsigned long)bat_addrs[3].limit - KERNELBASE + 1;
}

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Trent Piepho]

On Wed, 21 May 2008, Andreas Schwab wrote:

Trent Piepho <[EMAIL PROTECTED]> writes:


It's the _le versions that have a problem, since we can't get gcc to just use
the register indexed mode.  It seems like an obvious thing to have a
constraint for, but I guess there weren't enough instructions that only come
in 'x' versions to bother with it.  There is a 'Z' constraint, "Memory operand
that is an indexed or indirect from a register", but I tried it and it can use
both "rb,ri" and "disp(rb)" forms.  Actually, I'm not sure how 'Z' is any
different than "m"?


'Z' will never emit a non-zero constant displacement.


It's too bad gas doesn't appear to be smart enough to turn:
stwbrx 0, 0(3)   -or-   stwbr 0, 0(3)

into the desired:
stwbrx 0, 0, 3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Trent Piepho]

On Tue, 20 May 2008, Scott Wood wrote:

Alan Cox wrote:
>  It looks like we rely on -fno-strict-aliasing to prevent reordering 
>  ordinary memory accesses (such as to DMA descriptors) past the I/O


 DMA descriptors in main memory are dependant on cache behaviour anyway
 and the dma_* operators should be the ones enforcing the needed behaviour.


What about memory obtained from dma_alloc_coherent()?  We still need a sync 
and a compiler barrier.  The current I/O accessors have the former, but not 
the latter.


There doesn't appear to be any barriers to use for coherent dma other than
mb() and wmb().

Correct me if I'm wrong, but I think the sync isn't actually _required_ (by
memory-barriers.txt's definitions), and it would be enough to use eieio,
except there is code that doesn't use mmiowb() between I/O access and
unlocking.

So, as I understand it, the minimum needed is eieio.  To provide strict
ordering w.r.t. spin locks without using mmiowb(), you need sync.  To provide
strict ordering w.r.t. normal memory, you need sync and a compiler barrier.

Right now no archs provide the last option.  powerpc is currently the middle
option.  I don't know if anything uses the first option, maybe alpha?  I'm
almost certain x86 is the middle option (the first isn't possible, the arch
already has more ordering than that), which is probably why powerpc used that
option and not the first.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Alan Cox]

> It looks like we rely on -fno-strict-aliasing to prevent reordering 
> ordinary memory accesses (such as to DMA descriptors) past the I/O 

DMA descriptors in main memory are dependant on cache behaviour anyway
and the dma_* operators should be the ones enforcing the needed behaviour.

Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[David Miller]

From: Scott Wood <[EMAIL PROTECTED]>
Date: Tue, 20 May 2008 17:43:58 -0500

> David Miller wrote:
> > The __volatile__ in the asm construct disallows movement of the
> > inline asm relative to statements surrounding it.
> > 
> > The only reason barrier() in kernel.h needs a memory clobber is
> > because of a bug in ancient versions of gcc.  In fact, I think
> > that memory clobber might even be removable.
> 
> Current versions of GCC seem quite happy to move non-asm memory accesses 
> around a volatile asm without a memory clobber; see the test Trent posted.

Indeed, and even the GCC manual is clear about this.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Andreas Schwab]

Trent Piepho <[EMAIL PROTECTED]> writes:

> It's the _le versions that have a problem, since we can't get gcc to just use
> the register indexed mode.  It seems like an obvious thing to have a
> constraint for, but I guess there weren't enough instructions that only come
> in 'x' versions to bother with it.  There is a 'Z' constraint, "Memory operand
> that is an indexed or indirect from a register", but I tried it and it can use
> both "rb,ri" and "disp(rb)" forms.  Actually, I'm not sure how 'Z' is any
> different than "m"?

'Z' will never emit a non-zero constant displacement.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Scott Wood]

David Miller wrote:

From: Scott Wood <[EMAIL PROTECTED]>
Date: Tue, 20 May 2008 17:35:56 -0500


Alan Cox wrote:
It looks like we rely on -fno-strict-aliasing to prevent reordering 
ordinary memory accesses (such as to DMA descriptors) past the I/O 

DMA descriptors in main memory are dependant on cache behaviour anyway
and the dma_* operators should be the ones enforcing the needed behaviour.
What about memory obtained from dma_alloc_coherent()?  We still need a 
sync and a compiler barrier.  The current I/O accessors have the former, 
but not the latter.


The __volatile__ in the asm construct disallows movement of the
inline asm relative to statements surrounding it.

The only reason barrier() in kernel.h needs a memory clobber is
because of a bug in ancient versions of gcc.  In fact, I think
that memory clobber might even be removable.


Current versions of GCC seem quite happy to move non-asm memory accesses 
around a volatile asm without a memory clobber; see the test Trent posted.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[David Miller]

From: Scott Wood <[EMAIL PROTECTED]>
Date: Tue, 20 May 2008 17:35:56 -0500

> Alan Cox wrote:
> >> It looks like we rely on -fno-strict-aliasing to prevent reordering 
> >> ordinary memory accesses (such as to DMA descriptors) past the I/O 
> > 
> > DMA descriptors in main memory are dependant on cache behaviour anyway
> > and the dma_* operators should be the ones enforcing the needed behaviour.
> 
> What about memory obtained from dma_alloc_coherent()?  We still need a 
> sync and a compiler barrier.  The current I/O accessors have the former, 
> but not the latter.

The __volatile__ in the asm construct disallows movement of the
inline asm relative to statements surrounding it.

The only reason barrier() in kernel.h needs a memory clobber is
because of a bug in ancient versions of gcc.  In fact, I think
that memory clobber might even be removable.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Scott Wood]

Alan Cox wrote:
It looks like we rely on -fno-strict-aliasing to prevent reordering 
ordinary memory accesses (such as to DMA descriptors) past the I/O 


DMA descriptors in main memory are dependant on cache behaviour anyway
and the dma_* operators should be the ones enforcing the needed behaviour.


What about memory obtained from dma_alloc_coherent()?  We still need a 
sync and a compiler barrier.  The current I/O accessors have the former, 
but not the latter.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Trent Piepho]

On Tue, 20 May 2008, Benjamin Herrenschmidt wrote:

On Tue, 2008-05-20 at 16:38 -0500, Scott Wood wrote:

It looks like we rely on -fno-strict-aliasing to prevent reordering
ordinary memory accesses (such as to DMA descriptors) past the I/O
access.  It won't prevent reordering of memory reads around an I/O
read,
though, which could be a problem if the I/O read result determines
the
validity of the DMA buffer.  IMHO, a memory clobber would be better.


We probably want a full "memory" clobber then...


As far as I could tell, no other arch has a full memory clobber.  I can see
the argument for changing the Linux model to be stricter and less efficient,
but easier to program for.  Not that I entirely agree with it.

But I don't see a good reason for why powerpc should be different than
everything else.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Trent Piepho]

On Wed, 21 May 2008, Andreas Schwab wrote:

Trent Piepho <[EMAIL PROTECTED]> writes:


For the LE versions, eventually they boil down to an asm that will look
something like this:
asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));

While not perfect, this appears to be the best one can do.  The issue is
that the "stwbrx" instruction only comes in an indexed, or 'x', version, in
which the address is represented by the sum of two registers (the "0,%2").
Unfortunately, gcc doesn't have a constraint for an indexed memory
reference.


There is the "Z" constraint, which matches either an indirect or an
indexed memory address.  That should fit here.


This came up on the Freescale list.  I should have put what I wrote there into
my patch descrition:

It's the _le versions that have a problem, since we can't get gcc to just use
the register indexed mode.  It seems like an obvious thing to have a
constraint for, but I guess there weren't enough instructions that only come
in 'x' versions to bother with it.  There is a 'Z' constraint, "Memory operand
that is an indexed or indirect from a register", but I tried it and it can use
both "rb,ri" and "disp(rb)" forms.  Actually, I'm not sure how 'Z' is any
different than "m"?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Trent Piepho]

On Tue, 20 May 2008, Benjamin Herrenschmidt wrote:

On Tue, 2008-05-20 at 13:40 -0700, Trent Piepho wrote:

There was some discussion on a Freescale list if the powerpc I/O accessors
should be strictly ordered w.r.t.  normal memory.  Currently they are not.  It
does not appear as if any other architecture's I/O accessors are strictly
ordered in this manner.  memory-barriers.txt explicitly states that the I/O
space (inb, outw, etc.) are NOT strictly ordered w.r.t. normal memory
accesses and it's implied the other I/O accessors (e.g., writel) are the same.

However, it is somewhat harder to program for this model, and there are almost
certainly a number of drivers using coherent DMA which have subtle bugs because
the do not include the necessary barriers.

But clearly and change to this would be a subject for a different patch.


The current accessors should provide all the necessary ordering
guarantees...


Depends on what you define as "necessary".  It's seem clear that I/O accessors
_no not_ need to be strictly ordered with respect to normal memory accesses,
by what's defined in memory-barriers.txt.  So if by "necessary" you mean what
the Linux standard for I/O accessors requires (and what other archs provide),
then yes, they have the necessary ordering guarantees.

But, if you want them to be strictly ordered w.r.t to normal memory, that's
not the case.

For example, in something like:

u32 *dmabuf = kmalloc(...);
...
dmabuf[0] = 1;
out_be32(®s->dmactl, DMA_SEND_BUFFER);
dmabuf[0] = 2;
out_be32(®s->dmactl, DMA_SEND_BUFFER);

gcc might decide to optimize this code to:

out_be32(®s->dmactl, DMA_SEND_BUFFER);
out_be32(®s->dmactl, DMA_SEND_BUFFER);
dmabuf[0] = 2;

gcc will often not do this optimization, because there might be aliasing
between "®s->dmact" and "dmabuf", but it _can_ do it.  gcc can't optimize
the two identical out_be32's into one, or re-order them if they were to
different registers, but it can move the normal memory accesses around them.

Here's a quick hack I stuck in a driver to test.  compile with -save-temps and
check the resulting asm.  gcc will do the optimization I described above.

static void __iomem *baz = (void*)0x1234;
static struct bar {
u32 bar[256];
} bar;

void foo(void) {
bar.bar[0] = 44;
out_be32(baz+100, 200);
bar.bar[0] = 45;
out_be32(baz+101, 201);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Benjamin Herrenschmidt]

On Tue, 2008-05-20 at 16:38 -0500, Scott Wood wrote:
> It looks like we rely on -fno-strict-aliasing to prevent reordering 
> ordinary memory accesses (such as to DMA descriptors) past the I/O 
> access.  It won't prevent reordering of memory reads around an I/O
> read, 
> though, which could be a problem if the I/O read result determines
> the 
> validity of the DMA buffer.  IMHO, a memory clobber would be better.

We probably want a full "memory" clobber then...

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Andreas Schwab]

Trent Piepho <[EMAIL PROTECTED]> writes:

> For the LE versions, eventually they boil down to an asm that will look
> something like this:
> asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
>
> While not perfect, this appears to be the best one can do.  The issue is
> that the "stwbrx" instruction only comes in an indexed, or 'x', version, in
> which the address is represented by the sum of two registers (the "0,%2").
> Unfortunately, gcc doesn't have a constraint for an indexed memory
> reference.

There is the "Z" constraint, which matches either an indirect or an
indexed memory address.  That should fit here.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Scott Wood]

Benjamin Herrenschmidt wrote:

On Tue, 2008-05-20 at 13:40 -0700, Trent Piepho wrote:

There was some discussion on a Freescale list if the powerpc I/O accessors
should be strictly ordered w.r.t.  normal memory.  Currently they are not.  It
does not appear as if any other architecture's I/O accessors are strictly
ordered in this manner.  memory-barriers.txt explicitly states that the I/O
space (inb, outw, etc.) are NOT strictly ordered w.r.t. normal memory
accesses and it's implied the other I/O accessors (e.g., writel) are the same.

However, it is somewhat harder to program for this model, and there are almost
certainly a number of drivers using coherent DMA which have subtle bugs because
the do not include the necessary barriers.

But clearly and change to this would be a subject for a different patch.


The current accessors should provide all the necessary ordering
guarantees...


It looks like we rely on -fno-strict-aliasing to prevent reordering 
ordinary memory accesses (such as to DMA descriptors) past the I/O 
access.  It won't prevent reordering of memory reads around an I/O read, 
though, which could be a problem if the I/O read result determines the 
validity of the DMA buffer.  IMHO, a memory clobber would be better.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Benjamin Herrenschmidt]

On Tue, 2008-05-20 at 13:40 -0700, Trent Piepho wrote:
> There was some discussion on a Freescale list if the powerpc I/O accessors
> should be strictly ordered w.r.t.  normal memory.  Currently they are not.  It
> does not appear as if any other architecture's I/O accessors are strictly
> ordered in this manner.  memory-barriers.txt explicitly states that the I/O
> space (inb, outw, etc.) are NOT strictly ordered w.r.t. normal memory
> accesses and it's implied the other I/O accessors (e.g., writel) are the same.
> 
> However, it is somewhat harder to program for this model, and there are almost
> certainly a number of drivers using coherent DMA which have subtle bugs 
> because
> the do not include the necessary barriers.
> 
> But clearly and change to this would be a subject for a different patch.

The current accessors should provide all the necessary ordering
guarantees...

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 2/5 v3] powerpc: boot code for the C2K

[Remi Machet]

Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
All features of the board are not supported yet, but the board
boots, flash works, all Ethernet ports are working and PCI 
devices are all found (USB and SATA on PCI1 do not work yet).

Part 2 of 5: support for the board in arch/powerpc/boot.

Signed-off-by: Remi Machet <[EMAIL PROTECTED]>
---
Changes:
v1: original patch
v2: changed stack size to be 4kB instead of 16kB (per
David Gibson suggestion). Also changed the way PCI buses
are detected, now the code is looking for an alias pciN
where N is the bus number.
v3: after removing the boot command from the DTS file I realized
that U-Boot was not transferring the command line properly. To have
the kernel and U-boot be able to exchange info I must use the cuImage
target.

 Makefile |3
 cuboot-c2k.c |  190 +++
 2 files changed, 192 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 7822d25..8c10fa3 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -63,7 +63,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c 
cuboot-85xx.c holly.c
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
-   fixed-head.S ep88xc.c ep405.c \
+   fixed-head.S ep88xc.c ep405.c cuboot-c2k.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c 
\
virtex405-head.S
@@ -263,6 +263,7 @@ image-$(CONFIG_KSI8560) += 
cuImage.ksi8560
 # Board ports in arch/powerpc/platform/embedded6xx/Kconfig
 image-$(CONFIG_STORCENTER) += cuImage.storcenter
 image-$(CONFIG_MPC7448HPC2)+= cuImage.mpc7448hpc2
+image-$(CONFIG_PPC_C2K)+= cuImage.c2k
 
 # For 32-bit powermacs, build the COFF and miboot images
 # as well as the ELF images.
diff --git a/arch/powerpc/boot/cuboot-c2k.c b/arch/powerpc/boot/cuboot-c2k.c
new file mode 100644
index 000..e435949
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-c2k.c
@@ -0,0 +1,190 @@
+/*
+ * GEFanuc C2K platform code.
+ *
+ * Author: Remi Machet <[EMAIL PROTECTED]>
+ *
+ * Originated from prpmc2800.c
+ *
+ * 2008 (c) Stanford University
+ * 2007 (c) MontaVista, Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "types.h"
+#include "stdio.h"
+#include "io.h"
+#include "ops.h"
+#include "elf.h"
+#include "gunzip_util.h"
+#include "mv64x60.h"
+#include "cuboot.h"
+#include "ppcboot.h"
+
+static u8 *bridge_base;
+
+static void c2k_bridge_setup(u32 mem_size)
+{
+   u32 i, v[30], enables, acc_bits;
+   u32 pci_base_hi, pci_base_lo, size, buf[2];
+   unsigned long cpu_base;
+   int rc;
+   void *devp, *mv64x60_devp;
+   u8 *bridge_pbase, is_coherent;
+   struct mv64x60_cpu2pci_win *tbl;
+   int bus;
+
+   bridge_pbase = mv64x60_get_bridge_pbase();
+   is_coherent = mv64x60_is_coherent();
+
+   if (is_coherent)
+   acc_bits = MV64x60_PCI_ACC_CNTL_SNOOP_WB
+   | MV64x60_PCI_ACC_CNTL_SWAP_NONE
+   | MV64x60_PCI_ACC_CNTL_MBURST_32_BYTES
+   | MV64x60_PCI_ACC_CNTL_RDSIZE_32_BYTES;
+   else
+   acc_bits = MV64x60_PCI_ACC_CNTL_SNOOP_NONE
+   | MV64x60_PCI_ACC_CNTL_SWAP_NONE
+   | MV64x60_PCI_ACC_CNTL_MBURST_128_BYTES
+   | MV64x60_PCI_ACC_CNTL_RDSIZE_256_BYTES;
+
+   mv64x60_config_ctlr_windows(bridge_base, bridge_pbase, is_coherent);
+   mv64x60_devp = find_node_by_compatible(NULL, "marvell,mv64360");
+   if (mv64x60_devp == NULL)
+   fatal("Error: Missing marvell,mv64360 device tree node\n\r");
+
+   enables = in_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE));
+   enables |= 0x007ffe00; /* Disable all cpu->pci windows */
+   out_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE), enables);
+
+   /* Get the cpu -> pci i/o & mem mappings from the device tree */
+   devp = NULL;
+   for (bus = 0; ; bus++) {
+   char name[] = "pci ";
+
+   name[strlen(name)-1] = bus+'0';
+
+   devp = find_node_by_alias(name);
+   if (devp == NULL)
+   break;
+
+   if (bus >= 2)
+   fatal("Error: Only 2 PCI controllers are supported at" \
+   " this time.\n");
+
+   mv64x60_config_pci_windows(bridge_base, bridge_pbase, bus, 0,
+  

[PATCH] [POWERPC] Improve (in|out)_beXX() asm code

[Trent Piepho]

Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated
for the in_beXX() and out_beXX() mmio functions has been sub-optimal.

The out_leXX() family of functions are created with the macro
DEF_MMIO_OUT_LE() while the out_beXX() family are created with
DEF_MMIO_OUT_BE().  In what was perhaps a bit too much macro use, both of
these macros are in turn created via the macro DEF_MMIO_OUT().

For the LE versions, eventually they boil down to an asm that will look
something like this:
asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));

While not perfect, this appears to be the best one can do.  The issue is
that the "stwbrx" instruction only comes in an indexed, or 'x', version, in
which the address is represented by the sum of two registers (the "0,%2").
Unfortunately, gcc doesn't have a constraint for an indexed memory
reference.  The "m" constraint allows both indexed and offset, i.e.
register plus constant, memory references and there is no "stwbr" version
for offset references.

The unused first operand to the asm is just to tell gcc that *addr is an
output of the asm.  The address used is passed in a single register via the
third asm operand, and the index register is just hard coded as 0.  This
means gcc is forced to put the address in a single register and can't use
index addressing, e.g. if one has the data in register 9, a base address in
register 3 and an index in register 4, gcc must emit code like "add 11,4,3;
stwbrx 9,0,11" instead of just "stwbrx 9,4,3".  This costs an extra add
instruction and another register.

This brings us the to problem with the BE version.  In this case, the "stw"
instruction does have both indexed and non-indexed versions.  The final asm
ends up looking like this:
asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr));

The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory
reference should be a auto-updating one, and an 'x' if the memory reference
is indexed, respectively.  The third operand is unused, it's just there
because asm the code is reused from the LE version.  However, gcc does not
know this, and generates unnecessary code to stick addr in a register!  To
use the example from the LE version, gcc will generate "add 11,4,3; stwx
9,4,3".  It is able to use the indexed address "4,3" for the "stwx", but
still thinks it needs to put 4+3 into register 11, which will never be
used.

This also ends up happening a lot for the offset addressing mode, where
common code like this:  out_be32(&device_registers->some_register, data);
uses an instruction like "stw 9, 42(3)", where register 3 has the pointer
device_registers and 42 is the offset of some_register in that structure.
gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42"
to put the address into a single (unused) register.

The in_* versions end up having these exact same problems as well.

Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
CC: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
CC: Scott Wood <[EMAIL PROTECTED]>
---
There was some discussion on a Freescale list if the powerpc I/O accessors
should be strictly ordered w.r.t.  normal memory.  Currently they are not.  It
does not appear as if any other architecture's I/O accessors are strictly
ordered in this manner.  memory-barriers.txt explicitly states that the I/O
space (inb, outw, etc.) are NOT strictly ordered w.r.t. normal memory
accesses and it's implied the other I/O accessors (e.g., writel) are the same.

However, it is somewhat harder to program for this model, and there are almost
certainly a number of drivers using coherent DMA which have subtle bugs because
the do not include the necessary barriers.

But clearly and change to this would be a subject for a different patch.

 include/asm-powerpc/io.h |   44 +---
 1 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index e0062d7..795b5d4 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -95,33 +95,39 @@ extern resource_size_t isa_mem_base;
 #define IO_SET_SYNC_FLAG()
 #endif
 
-#define DEF_MMIO_IN(name, type, insn)  \
-static inline type name(const volatile type __iomem *addr) \
+#define DEF_MMIO_IN_LE(name, size, insn)   \
+static inline u##size name(const volatile u##size __iomem *addr)   \
 {  \
-   type ret;   \
-   __asm__ __volatile__("sync;" insn ";twi 0,%0,0;isync"   \
-   : "=r" (ret) : "r" (addr), "m" (*addr));\
+   u##size ret;\
+   __asm__ __volatile__("sync;"#insn" %0,0,%1;twi 0,%0,0;isync"\
+   : "=r" (ret) : "r" (addr), "m" (*addr));\
return ret;  

[PATCH v4][POWERPC] Update defconfig for MPC8610 HPCD

[Timur Tabi]

Update the defconfig for the Freescale MPC8610 HPCD board.  Enable module
support.  Disable support for all NICs except for the on-board ULI526x.
Enable support for the Freescale DIU driver.  Increase the maximum zone order
to 12, so that the DIU driver can allocate physically-contiguous 5MB buffers.
Enable SYSV IPC and OSS plugin support, which are needed for some OSS apps.

Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---

v4: turn on CONFIG_SND_PCM_OSS_PLUGINS, which apparently works now

Support for the Freescale generic DMA driver will have to wait until 2.6.27
because the current audio driver for the 8610 is incompatible with it.

 arch/powerpc/configs/mpc8610_hpcd_defconfig |  316 +++
 1 files changed, 180 insertions(+), 136 deletions(-)

diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig 
b/arch/powerpc/configs/mpc8610_hpcd_defconfig
index 7e5b9ce..389ff8d 100644
--- a/arch/powerpc/configs/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.25-rc6
-# Mon Mar 24 08:48:33 2008
+# Linux kernel version: 2.6.26-rc2
+# Tue May 20 15:12:10 2008
 #
 # CONFIG_PPC64 is not set
 
@@ -31,6 +31,8 @@ CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_HARDIRQS=y
 # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
 CONFIG_IRQ_PER_CPU=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
 CONFIG_RWSEM_XCHGADD_ALGORITHM=y
 CONFIG_ARCH_HAS_ILOG2_U32=y
 CONFIG_GENERIC_HWEIGHT=y
@@ -60,9 +62,10 @@ CONFIG_EXPERIMENTAL=y
 CONFIG_BROKEN_ON_SMP=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
 CONFIG_LOCALVERSION=""
-# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_LOCALVERSION_AUTO=y
 # CONFIG_SWAP is not set
-# CONFIG_SYSVIPC is not set
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
 # CONFIG_POSIX_MQUEUE is not set
 # CONFIG_BSD_PROCESS_ACCT is not set
 # CONFIG_TASKSTATS is not set
@@ -86,6 +89,7 @@ CONFIG_INITRAMFS_SOURCE=""
 CONFIG_SYSCTL=y
 CONFIG_EMBEDDED=y
 CONFIG_SYSCTL_SYSCALL=y
+CONFIG_SYSCTL_SYSCALL_CHECK=y
 CONFIG_KALLSYMS=y
 # CONFIG_KALLSYMS_ALL is not set
 CONFIG_KALLSYMS_EXTRA_PASS=y
@@ -110,14 +114,22 @@ CONFIG_SLUB=y
 # CONFIG_PROFILING is not set
 # CONFIG_MARKERS is not set
 CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
 CONFIG_HAVE_KPROBES=y
 CONFIG_HAVE_KRETPROBES=y
+# CONFIG_HAVE_DMA_ATTRS is not set
 CONFIG_PROC_PAGE_MONITOR=y
 CONFIG_SLABINFO=y
 CONFIG_RT_MUTEXES=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
-# CONFIG_MODULES is not set
+CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
 CONFIG_BLOCK=y
 # CONFIG_LBD is not set
 # CONFIG_BLK_DEV_IO_TRACE is not set
@@ -151,6 +163,7 @@ CONFIG_PPC_86xx=y
 # CONFIG_PPC_CELL_NATIVE is not set
 # CONFIG_PQ2ADS is not set
 # CONFIG_MPC8641_HPCN is not set
+# CONFIG_SBC8641D is not set
 CONFIG_MPC8610_HPCD=y
 CONFIG_MPC8610=y
 # CONFIG_IPIC is not set
@@ -199,11 +212,13 @@ CONFIG_FLATMEM=y
 CONFIG_FLAT_NODE_MEM_MAP=y
 # CONFIG_SPARSEMEM_STATIC is not set
 # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
+CONFIG_PAGEFLAGS_EXTENDED=y
 CONFIG_SPLIT_PTLOCK_CPUS=4
 # CONFIG_RESOURCES_64BIT is not set
 CONFIG_ZONE_DMA_FLAG=1
 CONFIG_BOUNCE=y
 CONFIG_VIRT_TO_BUS=y
+CONFIG_FORCE_MAX_ZONEORDER=12
 CONFIG_PROC_DEVICETREE=y
 # CONFIG_CMDLINE_BOOL is not set
 # CONFIG_PM is not set
@@ -223,12 +238,14 @@ CONFIG_PCI_DOMAINS=y
 CONFIG_PCI_SYSCALL=y
 CONFIG_PCIEPORTBUS=y
 CONFIG_PCIEAER=y
+# CONFIG_PCIEASPM is not set
 CONFIG_ARCH_SUPPORTS_MSI=y
 # CONFIG_PCI_MSI is not set
 CONFIG_PCI_LEGACY=y
 CONFIG_PCI_DEBUG=y
 # CONFIG_PCCARD is not set
 # CONFIG_HOTPLUG_PCI is not set
+# CONFIG_HAS_RAPIDIO is not set
 
 #
 # Advanced setup
@@ -238,11 +255,11 @@ CONFIG_PCI_DEBUG=y
 #
 # Default settings for advanced configuration options are used
 #
-CONFIG_HIGHMEM_START=0xfe00
 CONFIG_LOWMEM_SIZE=0x3000
+CONFIG_PAGE_OFFSET=0xc000
 CONFIG_KERNEL_START=0xc000
+CONFIG_PHYSICAL_START=0x
 CONFIG_TASK_SIZE=0xc000
-CONFIG_BOOT_LOAD=0x0080
 
 #
 # Networking
@@ -303,8 +320,10 @@ CONFIG_INET6_XFRM_MODE_TUNNEL=y
 CONFIG_INET6_XFRM_MODE_BEET=y
 # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
 CONFIG_IPV6_SIT=y
+CONFIG_IPV6_NDISC_NODETYPE=y
 # CONFIG_IPV6_TUNNEL is not set
 # CONFIG_IPV6_MULTIPLE_TABLES is not set
+# CONFIG_IPV6_MROUTE is not set
 # CONFIG_NETWORK_SECMARK is not set
 # CONFIG_NETFILTER is not set
 # CONFIG_IP_DCCP is not set
@@ -446,6 +465,7 @@ CONFIG_MTD_NAND_FSL_ELBC=y
 #
 # CONFIG_MTD_UBI is not set
 CONFIG_OF_DEVICE=y
+CONFIG_OF_I2C=y
 # CONFIG_PARPORT is not set
 CONFIG_BLK_DEV=y
 # CONFIG_BLK_DEV_FD is not set
@@ -504,6 +524,7 @@ CONFIG_CHR_DEV_SG=y
 # CONFIG_SCSI_CONSTANTS is not set
 # CONFIG_SCSI_LOGGING is not set
 # CONFIG_SCSI_SCAN_ASYNC is not set
+CONFIG_SCSI_WAIT_SCAN=m
 
 #
 # SCSI Transports
@@ -553,7 +574,11 @@ CONFIG_SCSI_LOWLEVEL=y
 #

Re: [PATCH] Fix cpm uart corruption with PREEMPT_RT

[Scott Wood]

Rune Torgersen wrote:

Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others 
toes.
Also only take lock if not in an oops.

Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>


Acked-by: Scott Wood <[EMAIL PROTECTED]>

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] Fix cpm uart corruption with PREEMPT_RT

[Rune Torgersen]

Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others 
toes.
Also only take lock if not in an oops.

Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>

diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c 
b/drivers/serial/cpm_uart/cpm_uart_core.c
index fb93403..11bee62 100755
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1214,6 +1214,14 @@ static void cpm_uart_console_write(struct console *co, 
const char *s,
unsigned int i;
cbd_t __iomem *bdp, *bdbase;
unsigned char *cp;
+   unsigned long flags;
+   int nolock = oops_in_progress;
+
+   if (unlikely(nolock)) {
+   local_irq_save(flags);
+   } else {
+   spin_lock_irqsave(&pinfo->port.lock, flags);
+   }
 
/* Get the address of the host memory buffer.
 */
@@ -1282,6 +1290,12 @@ static void cpm_uart_console_write(struct console *co, 
const char *s,
;
 
pinfo->tx_cur = bdp;
+
+   if (unlikely(nolock)) {
+   local_irq_restore(flags);
+   } else {
+   spin_unlock_irqrestore(&pinfo->port.lock, flags);
+   }
 }
 
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH] Fix cpm uart corruption with PREEMPT_RT

[Rune Torgersen]

Scott Wood wrote:
> On Tue, May 20, 2008 at 02:28:16PM -0500, Rune Torgersen wrote:
>> Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
>> Userland usage of console, and kernel printf's were stepping on each
>> others toes. 
>> 
> 
> We should bypass the lock when oops_in_progress is set, something
> like: 
> 

Ok, will respin.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v3][POWERPC] Update defconfig for MPC8610 HPCD

[Timur Tabi]

Update the defconfig for the Freescale MPC8610 HPCD board.  Enable module
support.  Disable support for all NICs except for the on-board ULI526x.
Enable support for the Freescale DIU driver.  Increase the maximum zone order
to 12, so that the DIU driver can allocate physically-contiguous 5MB buffers.

Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---

v3: enabled CONFIG_SYSVIPC.  It was disabled for some reason

Support for the Freescale generic DMA driver will have to wait until 2.6.27
because the current audio driver for the 8610 is incompatible with it.

 arch/powerpc/configs/mpc8610_hpcd_defconfig |  314 +++
 1 files changed, 179 insertions(+), 135 deletions(-)

diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig 
b/arch/powerpc/configs/mpc8610_hpcd_defconfig
index 7e5b9ce..c13b424 100644
--- a/arch/powerpc/configs/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.25-rc6
-# Mon Mar 24 08:48:33 2008
+# Linux kernel version: 2.6.26-rc2
+# Tue May 20 13:25:39 2008
 #
 # CONFIG_PPC64 is not set
 
@@ -31,6 +31,8 @@ CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_HARDIRQS=y
 # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
 CONFIG_IRQ_PER_CPU=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
 CONFIG_RWSEM_XCHGADD_ALGORITHM=y
 CONFIG_ARCH_HAS_ILOG2_U32=y
 CONFIG_GENERIC_HWEIGHT=y
@@ -60,9 +62,10 @@ CONFIG_EXPERIMENTAL=y
 CONFIG_BROKEN_ON_SMP=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
 CONFIG_LOCALVERSION=""
-# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_LOCALVERSION_AUTO=y
 # CONFIG_SWAP is not set
-# CONFIG_SYSVIPC is not set
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
 # CONFIG_POSIX_MQUEUE is not set
 # CONFIG_BSD_PROCESS_ACCT is not set
 # CONFIG_TASKSTATS is not set
@@ -86,6 +89,7 @@ CONFIG_INITRAMFS_SOURCE=""
 CONFIG_SYSCTL=y
 CONFIG_EMBEDDED=y
 CONFIG_SYSCTL_SYSCALL=y
+CONFIG_SYSCTL_SYSCALL_CHECK=y
 CONFIG_KALLSYMS=y
 # CONFIG_KALLSYMS_ALL is not set
 CONFIG_KALLSYMS_EXTRA_PASS=y
@@ -110,14 +114,22 @@ CONFIG_SLUB=y
 # CONFIG_PROFILING is not set
 # CONFIG_MARKERS is not set
 CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
 CONFIG_HAVE_KPROBES=y
 CONFIG_HAVE_KRETPROBES=y
+# CONFIG_HAVE_DMA_ATTRS is not set
 CONFIG_PROC_PAGE_MONITOR=y
 CONFIG_SLABINFO=y
 CONFIG_RT_MUTEXES=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
-# CONFIG_MODULES is not set
+CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
 CONFIG_BLOCK=y
 # CONFIG_LBD is not set
 # CONFIG_BLK_DEV_IO_TRACE is not set
@@ -151,6 +163,7 @@ CONFIG_PPC_86xx=y
 # CONFIG_PPC_CELL_NATIVE is not set
 # CONFIG_PQ2ADS is not set
 # CONFIG_MPC8641_HPCN is not set
+# CONFIG_SBC8641D is not set
 CONFIG_MPC8610_HPCD=y
 CONFIG_MPC8610=y
 # CONFIG_IPIC is not set
@@ -199,11 +212,13 @@ CONFIG_FLATMEM=y
 CONFIG_FLAT_NODE_MEM_MAP=y
 # CONFIG_SPARSEMEM_STATIC is not set
 # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
+CONFIG_PAGEFLAGS_EXTENDED=y
 CONFIG_SPLIT_PTLOCK_CPUS=4
 # CONFIG_RESOURCES_64BIT is not set
 CONFIG_ZONE_DMA_FLAG=1
 CONFIG_BOUNCE=y
 CONFIG_VIRT_TO_BUS=y
+CONFIG_FORCE_MAX_ZONEORDER=12
 CONFIG_PROC_DEVICETREE=y
 # CONFIG_CMDLINE_BOOL is not set
 # CONFIG_PM is not set
@@ -223,12 +238,14 @@ CONFIG_PCI_DOMAINS=y
 CONFIG_PCI_SYSCALL=y
 CONFIG_PCIEPORTBUS=y
 CONFIG_PCIEAER=y
+# CONFIG_PCIEASPM is not set
 CONFIG_ARCH_SUPPORTS_MSI=y
 # CONFIG_PCI_MSI is not set
 CONFIG_PCI_LEGACY=y
 CONFIG_PCI_DEBUG=y
 # CONFIG_PCCARD is not set
 # CONFIG_HOTPLUG_PCI is not set
+# CONFIG_HAS_RAPIDIO is not set
 
 #
 # Advanced setup
@@ -238,11 +255,11 @@ CONFIG_PCI_DEBUG=y
 #
 # Default settings for advanced configuration options are used
 #
-CONFIG_HIGHMEM_START=0xfe00
 CONFIG_LOWMEM_SIZE=0x3000
+CONFIG_PAGE_OFFSET=0xc000
 CONFIG_KERNEL_START=0xc000
+CONFIG_PHYSICAL_START=0x
 CONFIG_TASK_SIZE=0xc000
-CONFIG_BOOT_LOAD=0x0080
 
 #
 # Networking
@@ -303,8 +320,10 @@ CONFIG_INET6_XFRM_MODE_TUNNEL=y
 CONFIG_INET6_XFRM_MODE_BEET=y
 # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
 CONFIG_IPV6_SIT=y
+CONFIG_IPV6_NDISC_NODETYPE=y
 # CONFIG_IPV6_TUNNEL is not set
 # CONFIG_IPV6_MULTIPLE_TABLES is not set
+# CONFIG_IPV6_MROUTE is not set
 # CONFIG_NETWORK_SECMARK is not set
 # CONFIG_NETFILTER is not set
 # CONFIG_IP_DCCP is not set
@@ -446,6 +465,7 @@ CONFIG_MTD_NAND_FSL_ELBC=y
 #
 # CONFIG_MTD_UBI is not set
 CONFIG_OF_DEVICE=y
+CONFIG_OF_I2C=y
 # CONFIG_PARPORT is not set
 CONFIG_BLK_DEV=y
 # CONFIG_BLK_DEV_FD is not set
@@ -504,6 +524,7 @@ CONFIG_CHR_DEV_SG=y
 # CONFIG_SCSI_CONSTANTS is not set
 # CONFIG_SCSI_LOGGING is not set
 # CONFIG_SCSI_SCAN_ASYNC is not set
+CONFIG_SCSI_WAIT_SCAN=m
 
 #
 # SCSI Transports
@@ -553,7 +574,11 @@ CONFIG_SCSI_LOWLEVEL=y
 # CONFIG_SCSI_SRP is not set
 CONFIG_ATA=y
 # CONFIG_ATA_NONSTANDARD is not set
+CO

Re: [PATCH] Fix cpm uart corruption with PREEMPT_RT

[Scott Wood]

On Tue, May 20, 2008 at 02:28:16PM -0500, Rune Torgersen wrote:
> Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
> Userland usage of console, and kernel printf's were stepping on each others 
> toes.
> 
> Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
> 
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c 
> b/drivers/serial/cpm_uart/cpm_uart_core.c
> index fb93403..79c109d 100755
> --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -1214,7 +1214,9 @@ static void cpm_uart_console_write(struct console *co, 
> const char *s,
>   unsigned int i;
>   cbd_t __iomem *bdp, *bdbase;
>   unsigned char *cp;
> + unsigned long flags;
>  
> + spin_lock_irqsave(&pinfo->port.lock, flags);
>   /* Get the address of the host memory buffer.
>*/
>   bdp = pinfo->tx_cur;
> @@ -1282,6 +1284,8 @@ static void cpm_uart_console_write(struct console *co, 
> const char *s,
>   ;
>  
>   pinfo->tx_cur = bdp;
> +
> + spin_unlock_irqrestore(&pinfo->port.lock, flags);
>  }

We should bypass the lock when oops_in_progress is set, something like:

diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c 
b/drivers/serial/cpm_uart/cpm_uart_core.c
index a19dc7e..bc45f8a 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1178,6 +1178,14 @@ static void cpm_uart_console_write(struct console *co, 
const char *s,
unsigned int i;
cbd_t __iomem *bdp, *bdbase;
unsigned char *cp;
+   unsigned long flags;
+   int nolock = oops_in_progress;
+
+   if (unlikely(nolock)) {
+   local_irq_save(flags);
+   } else {
+   spin_lock_irqsave(&pinfo->port.lock, flags);
+   }
 
/* Get the address of the host memory buffer.
 */
@@ -1239,8 +1247,13 @@ static void cpm_uart_console_write(struct console *co, 
const char *s,
;
 
pinfo->tx_cur = bdp;
-}
 
+   if (unlikely(nolock)) {
+   local_irq_restore(flags);
+   } else {
+   spin_unlock_irqrestore(&pinfo->port.lock, flags);
+   }
+}
 
 static int __init cpm_uart_console_setup(struct console *co, char *options)
 {

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Fix pq2fads irq handling with PREEMPT_RT

[Scott Wood]

Rune Torgersen wrote:

Fix interrupt threading issue on pq2fads when running with CONFIG_PREEMPT_RT

Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>

diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c 
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
index a801381..9876d7e 100644
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -109,7 +109,7 @@ static int pci_pic_host_map(struct irq_host *h, unsigned 
int virq,
 {
get_irq_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_data(virq, h->host_data);
-   set_irq_chip(virq, &pq2ads_pci_ic);
+   set_irq_chip_and_handler(virq, &pq2ads_pci_ic, handle_level_irq);
return 0;
 }


Acked-by: Scott Wood <[EMAIL PROTECTED]>

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] Fix pq2fads irq handling with PREEMPT_RT

[Rune Torgersen]

Fix interrupt threading issue on pq2fads when running with CONFIG_PREEMPT_RT

Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>

diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c 
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
index a801381..9876d7e 100644
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -109,7 +109,7 @@ static int pci_pic_host_map(struct irq_host *h, unsigned 
int virq,
 {
get_irq_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_data(virq, h->host_data);
-   set_irq_chip(virq, &pq2ads_pci_ic);
+   set_irq_chip_and_handler(virq, &pq2ads_pci_ic, handle_level_irq);
return 0;
 }
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] Fix cpm uart corruption with PREEMPT_RT

[Rune Torgersen]

Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others 
toes.

Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>

diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c 
b/drivers/serial/cpm_uart/cpm_uart_core.c
index fb93403..79c109d 100755
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1214,7 +1214,9 @@ static void cpm_uart_console_write(struct console *co, 
const char *s,
unsigned int i;
cbd_t __iomem *bdp, *bdbase;
unsigned char *cp;
+   unsigned long flags;
 
+   spin_lock_irqsave(&pinfo->port.lock, flags);
/* Get the address of the host memory buffer.
 */
bdp = pinfo->tx_cur;
@@ -1282,6 +1284,8 @@ static void cpm_uart_console_write(struct console *co, 
const char *s,
;
 
pinfo->tx_cur = bdp;
+
+   spin_unlock_irqrestore(&pinfo->port.lock, flags);
 }
 
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Oops in fs_enet driver with preempt-rt

[Rune Torgersen]

Kumar Gala wrote:
>> Rune Torgersen wrote:
>> That worked. Console output is sane again.
> 
> I'm hoping to see some patches related to these fixes :)

Working on it.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Oops in fs_enet driver with preempt-rt

[Kumar Gala]

On May 20, 2008, at 11:31 AM, Rune Torgersen wrote:


Scott Wood wrote:

Rune Torgersen wrote:

Hmm ttyCPM1 output seems to be kinda garbled... Any ideas?
Incomplete locking between printk and userland use of ttyCPM1 as
console?


s/incomplete/nonexistent/ :-P

Try acquiring port->lock in cpm_uart_console_write.

-Scott


That worked. Console output is sane again.


I'm hoping to see some patches related to these fixes :)

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/5 v4] powerpc: DTS file for the C2K

[Remi Machet]

Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
All features of the board are not supported yet, but the board
boots, flash works, all Ethernet ports are working and PCI 
devices are all found (USB and SATA on PCI1 do not work yet).

Part 1 of 5: DTS file describing the board peripherals. As far as I know
all peripherals except the FPGA are listed in there (I did not included
the FPGA because a lot of work is needed there).

Signed-off-by: Remi Machet <[EMAIL PROTECTED]>
---
Changes:
v1: original patch
v2: cleaned up the file: removed i2c device_type, changed the name of
the cpu node and added aliases for the pci buses.
v3: removed the mdio entry because the PHY are handled by the Ethernet
driver on this board. Re-prganized the device controller entry to look
similar to other boards static buses (thanks to David Gibson for pointing
that out).
v4: reverted v3 changes because it was putting 2 reg attributes with the same
value in the ethernet-group group. Instead added a reg property to mdio.

 c2k.dts |  371 
 1 files changed, 371 insertions(+)

diff --git a/arch/powerpc/boot/dts/c2k.dts b/arch/powerpc/boot/dts/c2k.dts
new file mode 100644
index 000..607686c
--- /dev/null
+++ b/arch/powerpc/boot/dts/c2k.dts
@@ -0,0 +1,371 @@
+/* Device Tree Source for GEFanuc C2K
+ *
+ * Author: Remi Machet <[EMAIL PROTECTED]>
+ * 
+ * Originated from prpmc2800.dts
+ *
+ * 2008 (c) Stanford University
+ * 2007 (c) MontaVista, Software, Inc.  
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   model = "C2K";
+   compatible = "GEFanuc,C2K";
+   coherency-off;
+
+   aliases {
+   pci0 = &PCI0;
+   pci1 = &PCI1;
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   [EMAIL PROTECTED] {
+   device_type = "cpu";
+   compatible = "PowerPC,7447";
+   reg = <0>;
+   clock-frequency = <99600>;  /* 996 MHz */
+   bus-frequency = <16667>;/* 166. MHz */
+   timebase-frequency = <4167>;/* 166./4 
MHz */
+   i-cache-line-size = <32>;
+   d-cache-line-size = <32>;
+   i-cache-size = <32768>;
+   d-cache-size = <32768>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x4000>;  /* 1GB */
+   };
+
+   [EMAIL PROTECTED] { /* Marvell Discovery */
+   #address-cells = <1>;
+   #size-cells = <1>;
+   model = "mv64460";
+   compatible = "marvell,mv64360";
+   clock-frequency = <16667>;  /* 166.66... MHz */
+   reg = <0xd800 0x0001>;
+   virtual-reg = <0xd800>;
+   ranges = <0xd400 0xd400 0x0100  /* PCI 0 I/O 
Space */
+ 0x8000 0x8000 0x0800  /* PCI 0 MEM 
Space */
+ 0xd000 0xd000 0x0100  /* PCI 1 I/O 
Space */
+ 0xa000 0xa000 0x0800  /* PCI 1 MEM 
Space */
+ 0xd810 0xd810 0x0001  /* FPGA */
+ 0xd811 0xd811 0x0001  /* FPGA USARTs 
*/
+ 0xf800 0xf800 0x0800  /* User FLASH */
+ 0x 0xd800 0x0001  /* Bridge's 
regs */
+ 0xd814 0xd814 0x0004>;/* Integrated 
SRAM */
+
+   [EMAIL PROTECTED] {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "marvell,mv64360-mdio";
+   reg = <0x2000 4>;
+   PHY0: [EMAIL PROTECTED] {
+   device_type = "ethernet-phy";
+   interrupts = <76>;  /* GPP 12 */
+   interrupt-parent = <&PIC>;
+   reg = <0>;
+   };
+   PHY1: [EMAIL PROTECTED] {
+   device_type = "ethernet-phy";
+   interrupts = <76>;  /* GPP 12 */
+   interrupt-parent = <&PIC>;
+   reg = <1>;
+   };
+   PHY2: [EMAIL PROTECTED] {
+   device_type = "ethernet-phy";
+   

Re: .dtb file for mpc8641_hpcn failing on recent kernel/u-boot.

[Timur Tabi]

Scott Wood wrote:

> How about fixing u-boot's deficiencies in u-boot?  It knows better than 
> dtc how much extra space it's going to need.

Then what's the point of the -R and -S options if U-boot doesn't really need 
them?

This sounds like another example of a bug in U-Boot that everyone knows about
but no one is fixing.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers

[Boris Shteinbock]

I am currently doing port for already working PQ2 board (MPC8270) from "ppc" to 
"powerpc" architecture.
When initial port took place, the driver i2c-cpm that appeared on linuxppc list 
in the beginning of 2006 was used,
and it is working perfectly all this time.

However, when I am trying to use  the driver in your patch, I encountered the 
following  problem :
Your driver loads and probes perfectly well, however any attempt to read 
anything from the bus times out.
Receive never takes place. To make things works, If a user-space program is 
interrupted by ctrl-c while waiting for data, the driver enters an endless 
loop, that effectively kills the kernel.
can you suggest any solution for this problem?

I, also, suggest  moving BRG setup values  to the device tree instead of 
hard-coding them into the driver.


  
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: .dtb file for mpc8641_hpcn failing on recent kernel/u-boot.

[Scott Wood]

Timur Tabi wrote:

Kim Phillips wrote:

On Mon, 19 May 2008 22:57:29 + (UTC)
Gary Hannon <[EMAIL PROTECTED]> wrote:



Am I missing a flag on the dtc?

try adding -R 8 -S 0x3000 to the dtc command line.


Maybe we should be making this the default for dtc?  After all, it's needed for
any modern U-boot.


How about fixing u-boot's deficiencies in u-boot?  It knows better than 
dtc how much extra space it's going to need.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/5 v3] powerpc: DTS file for the C2K

[Remi Machet]

On Tue, 2008-05-20 at 11:13 +1000, David Gibson wrote:
> On Mon, May 19, 2008 at 05:00:23PM -0700, Remi Machet wrote:
> > Support for the C2K cPCI Single Board Computer from GEFanuc
> > (PowerPC MPC7448 with a Marvell MV64460 chipset)
> > All features of the board are not supported yet, but the board
> > boots, flash works, all Ethernet ports are working and PCI 
> > devices are all found (USB and SATA on PCI1 do not work yet).
> > 
> > Part 1 of 5: DTS file describing the board peripherals. As far as I know
> > all peripherals except the FPGA are listed in there (I did not included
> > the FPGA because a lot of work is needed there).
> 
> [snip]
> > +   [EMAIL PROTECTED] {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   compatible = "marvell,mv64360-eth-group";
> > +   reg = <0x2000 0x2000>;
> > +   PHY0: [EMAIL PROTECTED] {
> > +   device_type = "ethernet-phy";
> > +   interrupts = <76>;  /* GPP 12 */
> > +   interrupt-parent = <&PIC>;
> > +   reg = <0>;
> > +   };
> > +   [EMAIL PROTECTED] {
> > +   device_type = "network";
> > +   compatible = "marvell,mv64360-eth";
> > +   reg = <0>;
> > +   interrupts = <32>;
> > +   interrupt-parent = <&PIC>;
> > +   phy = <&PHY0>;
> > +   local-mac-address = [ 00 00 00 00 00 00 ];
> > +   };
> 
> Not sure if this is new, or I just didn't notice it before.  Also not
> sure if this is your mistake, or a mistake in the binding for the
> marvell device here.
> 
> The address in "reg" should be unique within the bus the device
> appears on.  So having both the PHY and the MAC devices with the same
> "reg" and same unit address here is bad.
> 
> Having both the PHYs and the MACs as children of the ethernet-group
> node is possible, but the addresses must be encoded to distinguish
> them (e.g. MACs are 0x0, 0x1, 0x2, PHYS are 0x1000 0x1001 0x1002).
> 
It was an attempt at getting rid of the mdio group since the PHY is
effectively managed by the Ethernet hardware. The problem is that the
reg field must contain those values ... if I change this, I must change
the driver and other boards DTS files that depend on it which I would
rather not do at the same time I am pushing this patch through.

I will put back the mdio group and add a reg field to it as you
suggested previously.

Remi



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: .dtb file for mpc8641_hpcn failing on recent kernel/u-boot.

[Timur Tabi]

Kim Phillips wrote:
> On Mon, 19 May 2008 22:57:29 + (UTC)
> Gary Hannon <[EMAIL PROTECTED]> wrote:
> 
> 
>> Am I missing a flag on the dtc?
> 
> try adding -R 8 -S 0x3000 to the dtc command line.

Maybe we should be making this the default for dtc?  After all, it's needed for
any modern U-boot.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Oops in fs_enet driver with preempt-rt

[Rune Torgersen]

Scott Wood wrote:
> Rune Torgersen wrote:
>> Hmm ttyCPM1 output seems to be kinda garbled... Any ideas?
>> Incomplete locking between printk and userland use of ttyCPM1 as
>> console?
> 
> s/incomplete/nonexistent/ :-P
> 
> Try acquiring port->lock in cpm_uart_console_write.
> 
> -Scott

That worked. Console output is sane again.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Oops in fs_enet driver with preempt-rt

[Scott Wood]

Rune Torgersen wrote:

Hmm ttyCPM1 output seems to be kinda garbled... Any ideas?
Incomplete locking between printk and userland use of ttyCPM1 as
console?


s/incomplete/nonexistent/ :-P

Try acquiring port->lock in cpm_uart_console_write.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Oops in fs_enet driver with preempt-rt

[Rune Torgersen]

Scott Wood wrote:
> Rune Torgersen wrote:
>> 0xc0196d84 is in fs_enet_interrupt
>> (drivers/net/fs_enet/fs_enet-main.c:473).
>> 468 if (fpi->use_napi)
>> 469 int_clr_events &= ~fep->ev_napi_rx;
>> 470 471 (*fep->ops->clear_int_events)(dev,
>> int_clr_events); 472
>> 473 if (int_events & fep->ev_err)
>> 474 (*fep->ops->ev_error)(dev,
>> int_events); 475 476 if (int_events &
>> fep->ev_rx) { 477 if (!fpi->use_napi)
>> (gdb)
> 
> Do you have shared interrupt debugging turned on?  That breaks this
> driver, and a patch to remove the shared flag was nacked in favor of
> actually fixing the driver, which I haven't gotten around to.
> 
> -Scott

Hmm ttyCPM1 output seems to be kinda garbled... Any ideas?
Incomplete locking between printk and userland use of ttyCPM1 as
console?

kjour[  OK  ]   nal
 stdrtiag. nCom it mnteivalr5 s cones
dXT3EFS  n soa7,dint rnae jolrnau
ElT3-Xs: founmed tilefystsm weth irdeoed ratadmod .
ek/*[  Removing /var/run/* and /var/locp... [  OK  ]
Creating new /var/run/utmlogin /fastboot and /forcefsck...  OK  ]
Removing possible /etc/noBringing up the loopback interface...  [  OK  ]
OK  ]
OK  ] Entering runlevel: 3 hostname to 9919_unit1_c
Starting the i2c_8266 driver: i2
_82c6: 6odume llcenie 'snspucifeed'itai ts nernkl.
  e[ OK ]


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Oops in fs_enet driver with preempt-rt

[Rune Torgersen]

Scott Wood wrote:
> Rune Torgersen wrote:
>> 0xc0196d84 is in fs_enet_interrupt
>> (drivers/net/fs_enet/fs_enet-main.c:473).
>> 468 if (fpi->use_napi)
>> 469 int_clr_events &= ~fep->ev_napi_rx;
>> 470 471 (*fep->ops->clear_int_events)(dev,
>> int_clr_events); 472
>> 473 if (int_events & fep->ev_err)
>> 474 (*fep->ops->ev_error)(dev,
>> int_events); 475 476 if (int_events &
>> fep->ev_rx) { 477 if (!fpi->use_napi)
>> (gdb)
> 
> Do you have shared interrupt debugging turned on?  That breaks this
> driver, and a patch to remove the shared flag was nacked in favor of
> actually fixing the driver, which I haven't gotten around to.
> 
> -Scott

Thanks!!
That worked. Now I just have to get highmem support...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: USB on MPC8641D

[Kumar Gala]

On May 20, 2008, at 10:56 AM, John Marc wrote:


Hi Mr Kumar

Sorry for replying so late.

I have tested the USB on the linux kernel 2.6.25 , but its not  
working.



Please suggest, Is this beacause of the PCI-Express Bug ??


With Regards

John



Can you describe again, what doesn't work means?

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: USB on MPC8641D

[John Marc]

Hi Mr Kumar
Sorry for replying so late. 
I have tested the USB on the linux kernel 2.6.25 , but its not working.
 
Please suggest, Is this beacause of the PCI-Express Bug ??
 
With Regards
John--- On Thu, 4/17/08, John Marc <[EMAIL PROTECTED]> wrote:
From: John Marc <[EMAIL PROTECTED]>Subject: Re: USB on MPC8641DTo: "Kumar Gala" <[EMAIL PROTECTED]>Cc: linuxppc-dev@ozlabs.orgDate: Thursday, April 17, 2008, 5:53 PM

Okie Friend ,
I will try the latest kernel 2.6.24, and let you know the results.
 
With Regards
JohnKumar Gala <[EMAIL PROTECTED]> wrote:
On Apr 17, 2008, at 3:36 AM, John Marc wrote:> Hi> I Have the kernel patches , but no one for the USB.> The changes for the USB are integrated in the Kernel.> I am currently looking into the linux BSP for usb> changes , but unfortunately don't find any major> chages.>> MPC8641 board have one EHCI controller and 3 OHCI> conroller.>> As I am also new to USB , it would be great help, if> someone give me any idea about the changes in new> MPC8641 BSP ?>> Does freescale fix the PCI Express issue , that makes> USB works.>> I have lots of hope with this forum :-)>>> With Regards> JohnThis forum is about the open source kernel and not BSPs kernels from Freescale or any other provider.Have
 you tried a 2.6.24 or 2.6.25 open source kernel for the 8641 and see if it works w/regards to USB. If not we can help try and figure out why not.There have been a number of fixes made to PCIe support on 8641 that are in the 2.6.24 kernel, I'm guessing some of those might address whatever issue you're seeing with USB.- k


Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

  

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/4] spi: Add OF binding support for SPI busses

[Grant Likely]

On Tue, May 20, 2008 at 9:26 AM, Guennadi Liakhovetski
<[EMAIL PROTECTED]> wrote:
> On Mon, 19 May 2008, Grant Likely wrote:
>
>> I'm not so fond of this approach.  cs-parent doesn't seem to make much
>> sense to me.  It might be better to have a cs-handler property on the
>> SPI bus node instead of on the SPI slave nodes, but even then it
>> leaves a number of questions about what it really means.  In some
>> cases it would be overkill.  For example, if the SPI node simply had
>> multiple GPIO lines then an extra cs-parent node wouldn't be needed at
>> all.
>
> Right, it is optional.
>
>> Then there are the complex arrangements.  When setting CS
>> requires inserting a special 'set cs' SPI message at the right time.
>> Or worse; when setting CS requires /modifying/ the sent SPI message.
>
> Hm, are there actually such SPI _controllers_ that use SPI data to toggle
> chipselects? I.e., you would have to send your SPI client data (for the
> RTC or whatever) plus some extra bytes or with some modifications, and
> this extra information would then be intercepted by the SPI _controller_
> itself and only client data would be sent out?

Yes!  There really are!!!  One case I've been told of is an SPI bridge
that uses the first byte of the transfer to obtain the chip select.

> Isn't what you're
> describing really a case of an SPI bridge, as you also call it below? In
> which case, I think, it might make sense to cleanly differentiate these
> two cases:
>
> 1. SPI chipselect. Either controlled by an external (typically a GPIO)
> signal or by the controller itself, in the latter case the controller has
> to be configured with the required address
>
> 2. SPI bridge. I don't know such configurations, so, I can only guess: the
> SPI controller has a single SPI client, which acts like a bridge. It
> receives data from the primary host, and in this data the target client
> data and its address are encoded.

Yes, this is probably appropriate.

> Now, I can also imagine case 2 where the bridge is actually a part of the
> host controller... Even though this doesn't make any sense to me.

Hmmm, yeah, I suppose it is possible; but if it is internal to the bus
controller then it can also be handled internally by the bus
controller driver and probably won't need to be reflected in the
device tree layout.

>> Essentially, the binding would need to describe the ability to
>> completely intercept and rewrite all SPI messages going through the CS
>> scheme.

It also needs to describe layouts which require SPI transfers in a
particular order.  For example, if you're doing 2 SPI messages (M1 and
M2) to 2 different SPI devices (S1 and S2), and the CS lines are on a
GPIO expander which is a third SPI device (S3).  In which case 5 or 6
SPI messages need to be transmitted:

ctrl msg -> S3// To set the CS to S1
M1 -> S1
ctrl msg -> S3// To clear the CS to S1
ctrl msg -> S3// To set the CS to S2
M2 -> S2
ctrl msg -> S3// To clear the CS to S2

An important subtlety to note here is that the GPIO device (S3) cannot
simply enqueue the control message to the SPI device when it is time
to send M1 or M2.  Normal enqueuing would add the messages to the end
of the queue; too late to actually activate the relevant CS line.
Granted, the is mostly a driver issue; not a device tree issue; but it
has some impact on the layout.  It could be handled with the
spi_bridge construct, but S1 and S2 aren't really children of S3.  On
the other hand; the spi_bridge is really more of a board level
construct.  The spi_bridge could be considered the board wireup and
S1, S2 and S3 are all children of the spi_bridge.  The spi_bridge
would have to be knowledgeable enough to handle control messages to S3
in a special order.

>> I'm not saying it's not possible to do, but I am saying that I'd like
>> to have a better feel for all the use cases before it is defined.  I'm
>> not convinced that adding a cs-parent phandle will do that
>> appropriately.  That being said, my gut feel is that the solution will
>> be to support spi-bridge nodes that handle the complex CS
>> configuration settings; the spi-bridge would be a child of the
>> spi-master and the parent of the spi devices; and simple CS settings
>> being handled with regular old GPIO bindings.  (Much like the last
>> suggestion you make; except that I think that it *does* looks
>> elegant.)  :-)
>
> Ok, elegance apart:-) You can use the SPI-bridge construct to also
> describe simple SPI-chipselect configurations. But is it really a good
> idea? Wouldn't it be better to handle these two cases separately? Using
> "bridge" to describe CS's seems also confusing - imagine someone
> implementing a new DTS, having to describe a bridge not having one doesn't
> seem very intuitive:-)

... and it must be said that I got rather lazy in my example below.  I
really covered both layouts (simple GPIO and an SPI bridge in the same
example without documenting it sufficiently.  I'll hash out my
thoughts some more and

Re: Oops in fs_enet driver with preempt-rt

[Scott Wood]

Rune Torgersen wrote:

0xc0196d84 is in fs_enet_interrupt
(drivers/net/fs_enet/fs_enet-main.c:473).
468 if (fpi->use_napi)
469 int_clr_events &= ~fep->ev_napi_rx;
470
471 (*fep->ops->clear_int_events)(dev,
int_clr_events);
472
473 if (int_events & fep->ev_err)
474 (*fep->ops->ev_error)(dev, int_events);
475
476 if (int_events & fep->ev_rx) {
477 if (!fpi->use_napi)
(gdb) 


Do you have shared interrupt debugging turned on?  That breaks this 
driver, and a patch to remove the shared flag was nacked in favor of 
actually fixing the driver, which I haven't gotten around to.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Configuring virtual memory layout

[Hommel, Thomas (GE EntSol, Intelligent Platforms)]

Hello,
I am trying to figure out how to configure the virtual memory layout in
the kernel.
To increase the size of the Vmalloc area, I have set KERNEL_START to
0xa000 and have left LOWMEM_SIZE at 0x3000. The other parameters
in 'Advanced setup' are unchanged.
This works fine with 512 MB of RAM. However, with 1 GB of RAM installed,
the system shows odd behavior, crashes, faults, ... This seems to be due
to the fact that it then uses 256 MB of high memory.

I played around with HIGHMEM_START, but couldn't get a working setting.

How do these parameters have to be configured correctly? Is there any
documentation for that?

Thanks for your help
Thomas
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/4] spi: Add OF binding support for SPI busses

[Guennadi Liakhovetski]

On Mon, 19 May 2008, Grant Likely wrote:

> I'm not so fond of this approach.  cs-parent doesn't seem to make much
> sense to me.  It might be better to have a cs-handler property on the
> SPI bus node instead of on the SPI slave nodes, but even then it
> leaves a number of questions about what it really means.  In some
> cases it would be overkill.  For example, if the SPI node simply had
> multiple GPIO lines then an extra cs-parent node wouldn't be needed at
> all.

Right, it is optional.

> Then there are the complex arrangements.  When setting CS
> requires inserting a special 'set cs' SPI message at the right time.
> Or worse; when setting CS requires /modifying/ the sent SPI message.

Hm, are there actually such SPI _controllers_ that use SPI data to toggle 
chipselects? I.e., you would have to send your SPI client data (for the 
RTC or whatever) plus some extra bytes or with some modifications, and 
this extra information would then be intercepted by the SPI _controller_ 
itself and only client data would be sent out? Isn't what you're 
describing really a case of an SPI bridge, as you also call it below? In 
which case, I think, it might make sense to cleanly differentiate these 
two cases:

1. SPI chipselect. Either controlled by an external (typically a GPIO) 
signal or by the controller itself, in the latter case the controller has 
to be configured with the required address

2. SPI bridge. I don't know such configurations, so, I can only guess: the 
SPI controller has a single SPI client, which acts like a bridge. It 
receives data from the primary host, and in this data the target client 
data and its address are encoded.

Now, I can also imagine case 2 where the bridge is actually a part of the 
host controller... Even though this doesn't make any sense to me.

> Essentially, the binding would need to describe the ability to
> completely intercept and rewrite all SPI messages going through the CS
> scheme.
> 
> I'm not saying it's not possible to do, but I am saying that I'd like
> to have a better feel for all the use cases before it is defined.  I'm
> not convinced that adding a cs-parent phandle will do that
> appropriately.  That being said, my gut feel is that the solution will
> be to support spi-bridge nodes that handle the complex CS
> configuration settings; the spi-bridge would be a child of the
> spi-master and the parent of the spi devices; and simple CS settings
> being handled with regular old GPIO bindings.  (Much like the last
> suggestion you make; except that I think that it *does* looks
> elegant.)  :-)

Ok, elegance apart:-) You can use the SPI-bridge construct to also 
describe simple SPI-chipselect configurations. But is it really a good 
idea? Wouldn't it be better to handle these two cases separately? Using 
"bridge" to describe CS's seems also confusing - imagine someone 
implementing a new DTS, having to describe a bridge not having one doesn't 
seem very intuitive:-)

> example; here's an SPI bus that has 2 GPIOs for two bus CS lines and
> an SPI bridge that uses both CSes; one address for accessing the
> bridge's CS register and one CS to access the downstream devices.
> 
> +SPI example for an MPC5200 SPI bus:
> +   [EMAIL PROTECTED] {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
> +   reg = <0xf00 0x20>;
> +   interrupts = <2 13 0 2 14 0>;
> +   interrupt-parent = <&mpc5200_pic>;
> +   gpios = <&gpio1 0 0 &gpio1 1 0>;
> +   [EMAIL PROTECTED] {
> +   compatible = "oem,spi-bridge-type";
> +   reg = < 0 1 >;  // note: 2 SPI CS addresses; first 
> one to access bridge registers
> +
> +   [EMAIL PROTECTED] {
> +   compatible = "micrel,ks8995m";
> +   linux,modalias = "ks8995";
> +   max-speed = <100>;
> +   reg = <0>;
> +   };
> ... // and more SPI child nodes here...
> +   };
> +   };
> 
> But even this doesn't reflect the hardware layout well.  What if the
> SS lines are on SPI GPIO expanders on the same bus?  Then does it make
> sense for them to be layed out as spi bridges?

Well, in this case - yes, because addressing clients "behind" the expander 
and the expander itself is done differently.

On the whole, I think, it begins to look good - I think, it is better to 
implement an imperfect but complete and consistent scheme and modify or 
extend it in the future, than a perfect, but incomplete, and have to use 
auxiliary means (platform bindings) to fill in the gaps.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
___
Linuxppc-dev mailing list
Linuxp

RE: Oops in fs_enet driver with preempt-rt

[Rune Torgersen]

Rune Torgersen wrote:
> Hi
> I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
> 8280 CPU (arch/powerpc) 
> 
> I get the follwing oops when trying to enable ethernet:
> (looks like a null pointer dereference in
> drivers/net/fs_enet/fs_enet-main.c:106)

And if I disable NAPI I get this one instead:

Bringing up the eth1 interface...Unable to handle kernel paging request
for data at address 0x
Faulting instruction address: 0xc019706c
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c019706c LR: c0196d84 CTR: c0198790
REGS: ef2c3cb0 TRAP: 0300   Not tainted  (2.6.25.4-rt1)
MSR: 9032   CR: 42004222  XER: 
DAR: , DSISR: 2000
TASK = ef2ac590[114] 'ifconfig' THREAD: ef2c2000
GPR00:  ef2c3d60 ef2ac590 ef37f000 0008  ef2c3d5c
008c
GPR08: ef2c3d38 0008 ef2c3d40 0001 22000222 10021454 
100a37b0
GPR16: 1009 ef3e71e0 ef3e71e0  1007 0008 100192c0
8914
GPR24: ef37f000 ef37f5a0  c0196d34  ef37f5a0 fff4
ef2973a0
NIP [c019706c] fs_enet_interrupt+0x338/0x5f4
LR [c0196d84] fs_enet_interrupt+0x50/0x5f4
Call Trace:
[ef2c3d60] [c024a270] __spin_unlock_irqrestore+0x20/0x4c (unreliable)
[ef2c3db0] [c0049a04] request_irq+0xb8/0xfc
[ef2c3de0] [c0198044] fs_enet_open+0x8c/0x210
[ef2c3e00] [c01d9b4c] dev_open+0x80/0xe8
[ef2c3e10] [c01d89ac] dev_change_flags+0xc8/0x19c
[ef2c3e30] [c021bfb0] devinet_ioctl+0x284/0x6f0
[ef2c3e90] [c021c8fc] inet_ioctl+0xc0/0xf4
[ef2c3ea0] [c01cbec4] sock_ioctl+0x200/0x23c
[ef2c3ec0] [c00810c0] vfs_ioctl+0x44/0xa8
[ef2c3ee0] [c0081520] do_vfs_ioctl+0x3fc/0x440
[ef2c3f10] [c00815a4] sys_ioctl+0x40/0x70
[ef2c3f40] [c000fcf0] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff6a37c
LR = 0xffecd58
Instruction dump:
7c0004ac b01c 72e02000 3b9c0008 41820008 839d00bc 813d00a0 7f03c378
81290034 7d2903a6 4e800421 7c0004ac  0c00 4c00012c
5417043e
---[ end trace 61ff5e5c97ddf707 ]---

Seems to be caused by line 471 in fs_enet_main:

0xc0196d84 is in fs_enet_interrupt
(drivers/net/fs_enet/fs_enet-main.c:473).
468 if (fpi->use_napi)
469 int_clr_events &= ~fep->ev_napi_rx;
470
471 (*fep->ops->clear_int_events)(dev,
int_clr_events);
472
473 if (int_events & fep->ev_err)
474 (*fep->ops->ev_error)(dev, int_events);
475
476 if (int_events & fep->ev_rx) {
477 if (!fpi->use_napi)
(gdb) 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] ftrace: support for PowerPC

[Steven Rostedt]

On Tue, 20 May 2008, Benjamin Herrenschmidt wrote:

> > Why do we not want to trace early boot? Just because it's not useful?
>
> Not running at the linked address... might be causing trouble.

I figured it was something like that, so I didn't look too deep into it,
and decided that it was best just not to trace it.

-- Steve

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Broken highmem support with preempt-rt

[Rune Torgersen]

Hi
When booting v2.6.25.4-rt1 (PREEMPT-RT) on my 8280 CPU with 1 GB RAM, I
get the following oopses.
They both are caused by a BUG_ON in kmap_atomic
(include/asm-powerpc/highmem.h).

If I boot with mem=512M or mem=768M they do not appear.

Any help is greatly appreciated.


Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c005e780 LR: c005e758 CTR: 
REGS: ef2c1d20 TRAP: 0700   Not tainted  (2.6.25.4-rt1)
MSR: 00029032   CR: 48222482  XER: 2000
TASK = ef2a1a90[98] 'S21initenv' THREAD: ef2c
GPR00: 3ffcf581 ef2c1dd0 ef2a1a90  c02cae8c 0002 0001
3ffcf580
GPR08:  c037  c037000c 28222484 1009ecc0 
100a5838
GPR16: 1009 1009   1009 ef2a7100 3ee38385
100955ac
GPR24:  ef2a4ef0  c27dc700 c27dcb80 0003 ef359040
c0334f88
NIP [c005e780] do_wp_page+0x650/0xc2c
LR [c005e758] do_wp_page+0x628/0xc2c
Call Trace:
[ef2c1dd0] [c005e758] do_wp_page+0x628/0xc2c (unreliable)
[ef2c1e10] [c0012420] do_page_fault+0x338/0x4b4
[ef2c1f40] [c0010120] handle_page_fault+0xc/0x80
--- Exception: 301 at 0x100322e0
LR = 0x100322dc
Instruction dump:
409e0594 4810f2e1 3d20c035 1fa3000f 8129b140 3bbd0003 57ab103a 7c0b482e
7d6b4a14 540007fa 30e0 7cc70110 <0f06> 3d20c035 3d40c035
8129b480
Oops: Exception in kernel mode, sig: 5 [#2]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c005db0c LR: c005dae4 CTR: 
REGS: ef29fd00 TRAP: 0700   Tainted: G  D   (2.6.25.4-rt1)
MSR: 00029032   CR: 48002482  XER: 2000
TASK = ef26e070[102] 'sed' THREAD: ef29e000
GPR00: 3ee2d581 ef29fdb0 ef26e070  c02cae8c  0001
3ee2d580
GPR08:  c037  c037000c 0722 1009ecc0 4802dfa4
4802d878
GPR16: 0014f73c   0003 4802cce0  0001
0200
GPR24: ef3592e0 0ffece1c ef3592e0 ef2a50fc ef2a4df4 0003 c27dcfe0
c27ff4c0
NIP [c005db0c] __do_fault+0x1e0/0x804
LR [c005dae4] __do_fault+0x1b8/0x804
Call Trace:
[ef29fdb0] [c005dae4] __do_fault+0x1b8/0x804 (unreliable)
[ef29fe10] [c0012420] do_page_fault+0x338/0x4b4
[ef29ff40] [c0010120] handle_page_fault+0xc/0x80
--- Exception: 301 at 0x48017b10
LR = 0x48007ac8
Instruction dump:
409e060c 4810ff55 3d20c035 1fa3000f 8129b140 3bbd0003 57ab103a 7c0b482e
7d6b4a14 540007fa 30e0 7cc70110 <0f06> 3d20c035 3d40c035
8129b480

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Oops in fs_enet driver with preempt-rt

[Rune Torgersen]

Hi
I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
8280 CPU (arch/powerpc)

I get the follwing oops when trying to enable ethernet:
(looks like a null pointer dereference in
drivers/net/fs_enet/fs_enet-main.c:106)

Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0197efc
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c0197efc LR: c0197c48 CTR: c01986c4
REGS: df84de90 TRAP: 0300   Not tainted  (2.6.25.4-rt1)
MSR: 9032   CR: 42004022  XER: 
DAR: , DSISR: 2000
TASK = df82ea70[7] 'sirq-net-rx/0' THREAD: df84c000
GPR00: e105a350 df84df40 df82ea70 df37f000 0011 c034ed90 c034ed70

GPR08:  e105a340  0009 df80  0fffd000
0028
GPR16: 00400558 0080  df3e71e0 0011  

GPR24: df37f000    fffb9e82 012c 0011
df37f5a0
NIP [c0197efc] fs_enet_rx_napi+0x2f0/0x3ac
LR [c0197c48] fs_enet_rx_napi+0x3c/0x3ac
Call Trace:
[df84df40] [c024a1b4] __spin_unlock+0x18/0x3c (unreliable)
[df84df80] [c01d9d28] net_rx_action+0x84/0x1ac
[df84dfa0] [c0022f18] ksoftirqd+0x158/0x25c
[df84dfd0] [c0033fa0] kthread+0x4c/0x88
[df84dff0] [c000fb34] kernel_thread+0x44/0x60
Instruction dump:
73202000 3b7b0008 41820008 837f00bc 813f00a0 7f03c378 81290034 7d2903a6
4e800421 7f96a000 409c00a8 7c0004ac  0c00 4c00012c
5419043e
---[ end trace c548f7dabfe5b3de ]---


0xc0197efc is in fs_enet_rx_napi (include/asm/io.h:124).
119 DEF_MMIO_OUT(name, u##size, __stringify(insn)"%U0%X0
%1,%0")
120 #define DEF_MMIO_OUT_LE(name, size, insn) \
121 DEF_MMIO_OUT(name, u##size, __stringify(insn)" %1,0,%2")
122
123 DEF_MMIO_IN_BE(in_8, 8, lbz);
124 DEF_MMIO_IN_BE(in_be16, 16, lhz);
125 DEF_MMIO_IN_BE(in_be32, 32, lwz);
126 DEF_MMIO_IN_LE(in_le16, 16, lhbrx);
127 DEF_MMIO_IN_LE(in_le32, 32, lwbrx);
128

0xc0197c48 is in fs_enet_rx_napi
(drivers/net/fs_enet/fs_enet-main.c:106).
101  * These get messed up if we get called due to a busy
condition.
102  */
103 bdp = fep->cur_rx;
104
105 /* clear RX status bits for napi*/
106 (*fep->ops->napi_clear_rx_event)(dev);
107
108 while (((sc = CBDR_SC(bdp)) & BD_ENET_RX_EMPTY) == 0) {
109 curidx = bdp - fep->rx_bd_base;
110
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Timur Tabi]

Anton Vorontsov wrote:

> Btw, this is silent config, selected by the board's Kconfig
> (same as QE block, for example). So "depends on" here is just
> no-op, since select disregards dependencies. Still want this?

FYI, I have plans to modify the Kconfigs so that CONFIG_QUICC_ENGINE is
user-selectable.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Anton Vorontsov]

On Tue, May 20, 2008 at 06:32:34PM +0400, Anton Vorontsov wrote:
> On Tue, May 20, 2008 at 09:20:50AM -0500, Kumar Gala wrote:
> > This is explained in the .c file with a kernel doc. Basically the
>  difference is that timer16 could silently crop the precision, while
>  utimer16 could not thus explicitly accepts u16 argument (max. timer
>  interval with usec precision fits in u16).
> >>>
> >>> Maybe I'm confused what the utility is of cropping the precision in  
> >>> this
> >>> way is.  I'd also say that _timer16 is poorly named to convey the
> >>> behavior. I'm not sure what to call it because I still dont get  
> >>> exactly
> >>> why you'd want the precision cropped.
> >>
> >> Precision matters for FHCI-like drivers, when driver, for example,
> >> schedule transactions via the GTM timers, and there timings matters
> >> a lot.
> >>
> >> Though, timer16 crops the precision _only_ if usecs > 65535, so FHCI
> >> _can_ still use the _timer16 (because FHCI does not request intervals
> >>> 65535). But I implemented two function because:
> >>
> >> 1. I think we don't need unnecessary stuff in the ISRs (this is weak
> >>   argument since I didn't measure the impact).
> >> 2. I wanted to make the API clear (seem to fail this undertaking :-),
> >>   which functions will behave exactly the way you asked it (utimer16),
> >>   and which functions will _silently_ crop the precision (timer16)
> >>   (if asked for 1001000 usecs, it will give you ~~1001000, depending
> >>   on the GTM frequency).
> >
> > I'm fine w/having both. I think they are poorly named.  I'd also call  
> > them _set_timer but that's just me.
> >
> > Maybe something w/the term _exact_ in the name.  Is it the case w/the  
> > precise form we'd have no prescaling (if so maybe a comment in the API  
> > about that would help clarity)?
> 
> We're always prescale [to 100 MHz for usec precision].

-MHz
+Hz

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: .dtb file for mpc8641_hpcn failing on recent kernel/u-boot.

[ghannon]

Thank-You Kim,

 That got me beyond where I was.

 It's now having problems with the SATA setup, but I will stare at
that for a while, and see if there is anything on the mailing list about
it.

 It actually made it past the PCI Scan which was one of the
key things I needed to see anyway.

Gary






Kim Phillips <[EMAIL PROTECTED]> on 05/19/2008 06:03:37 PM

To:   Gary Hannon/CSP
cc:   linuxppc-dev@ozlabs.org
Subject:  Re: .dtb file for mpc8641_hpcn failing on recent kernel/u-boot.




On Mon, 19 May 2008 22:57:29 + (UTC)
Gary Hannon <[EMAIL PROTECTED]> wrote:


> Am I missing a flag on the dtc?

try adding -R 8 -S 0x3000 to the dtc command line.

Kim





___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Anton Vorontsov]

On Tue, May 20, 2008 at 09:20:50AM -0500, Kumar Gala wrote:
> This is explained in the .c file with a kernel doc. Basically the
 difference is that timer16 could silently crop the precision, while
 utimer16 could not thus explicitly accepts u16 argument (max. timer
 interval with usec precision fits in u16).
>>>
>>> Maybe I'm confused what the utility is of cropping the precision in  
>>> this
>>> way is.  I'd also say that _timer16 is poorly named to convey the
>>> behavior. I'm not sure what to call it because I still dont get  
>>> exactly
>>> why you'd want the precision cropped.
>>
>> Precision matters for FHCI-like drivers, when driver, for example,
>> schedule transactions via the GTM timers, and there timings matters
>> a lot.
>>
>> Though, timer16 crops the precision _only_ if usecs > 65535, so FHCI
>> _can_ still use the _timer16 (because FHCI does not request intervals
>>> 65535). But I implemented two function because:
>>
>> 1. I think we don't need unnecessary stuff in the ISRs (this is weak
>>   argument since I didn't measure the impact).
>> 2. I wanted to make the API clear (seem to fail this undertaking :-),
>>   which functions will behave exactly the way you asked it (utimer16),
>>   and which functions will _silently_ crop the precision (timer16)
>>   (if asked for 1001000 usecs, it will give you ~~1001000, depending
>>   on the GTM frequency).
>
> I'm fine w/having both. I think they are poorly named.  I'd also call  
> them _set_timer but that's just me.
>
> Maybe something w/the term _exact_ in the name.  Is it the case w/the  
> precise form we'd have no prescaling (if so maybe a comment in the API  
> about that would help clarity)?

We're always prescale [to 100 MHz for usec precision]. Otherwise
these functions would be non-deterministic (will purely depend on the GTM
frequency, so "usec" argument would not have defined boundaries).

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] ftrace: support for PowerPC

[Steven Rostedt]

On Wed, 21 May 2008, Michael Ellerman wrote:

> On Wed, 2008-05-14 at 23:49 -0400, Steven Rostedt wrote:
> > plain text document attachment (ftrace-powerpc-port.patch)
> > This patch adds full support for ftrace for PowerPC (both 64 and 32 bit).
> > This includes dynamic tracing and function filtering.
>
> Hi Steven,
>
> Just a few comments inline ..

Hi Michael,

I really appreciate this. It's been a few years since I did any real PPC
programming, so any comments are most definitely welcome.


>
> > Index: linux-sched-devel.git/arch/powerpc/kernel/Makefile
> > ===
> > --- linux-sched-devel.git.orig/arch/powerpc/kernel/Makefile 2008-05-14 
> > 19:30:53.0 -0700
> > +++ linux-sched-devel.git/arch/powerpc/kernel/Makefile  2008-05-14 
> > 19:31:56.0 -0700
> > @@ -12,6 +12,18 @@ CFLAGS_prom_init.o  += -fPIC
> >  CFLAGS_btext.o += -fPIC
> >  endif
> >
> > +ifdef CONFIG_FTRACE
> > +# Do not trace early boot code
> > +CFLAGS_REMOVE_cputable.o = -pg
> > +CFLAGS_REMOVE_prom_init.o = -pg
>
> Why do we not want to trace early boot? Just because it's not useful?

The -pg flag makes calls to the mcount code. I didn't look too deeply, but
at least in my first prototypes the early boot up code would crash when
calling mcount. I found that simply keeping them from calling mcount made
things OK. Perhaps I'm just hiding the problem, but the tracing wont
happen anyway that early. We need to set up memory before tracing starts.

>
> > Index: linux-sched-devel.git/arch/powerpc/kernel/entry_32.S
> > ===
> > --- linux-sched-devel.git.orig/arch/powerpc/kernel/entry_32.S   
> > 2008-05-14 19:30:50.0 -0700
> > +++ linux-sched-devel.git/arch/powerpc/kernel/entry_32.S2008-05-14 
> > 19:31:56.0 -0700
> > @@ -1035,3 +1035,133 @@ machine_check_in_rtas:
> > /* XXX load up BATs and panic */
> >
> ... snip
>
> > +_GLOBAL(mcount)
> > +_GLOBAL(_mcount)
> > +   stwur1,-48(r1)
> > +   stw r3, 12(r1)
> > +   stw r4, 16(r1)
> > +   stw r5, 20(r1)
> > +   stw r6, 24(r1)
> > +   mflrr3
> > +   lwz r4, 52(r1)
> > +   mfcrr5
> > +   stw r7, 28(r1)
> > +   stw r8, 32(r1)
> > +   stw r9, 36(r1)
> > +   stw r10,40(r1)
> > +   stw r3, 44(r1)
> > +   stw r5, 8(r1)
> > +
> > +   LOAD_REG_ADDR(r5, ftrace_trace_function)
> > +#if 0
> > +   mtctr   r3
> > +   mr  r1, r5
> > +   bctrl
> > +#endif
> > +   lwz r5,0(r5)
> > +#if 1
> > +   mtctr   r5
> > +   bctrl
> > +#else
> > +   bl  ftrace_stub
> > +#endif
>
> #if 0, #if 1 ?

Ouch! Thanks, that's leftover from debugging.

>
> > Index: linux-sched-devel.git/arch/powerpc/kernel/ftrace.c
> > ===
> > --- /dev/null   1970-01-01 00:00:00.0 +
> > +++ linux-sched-devel.git/arch/powerpc/kernel/ftrace.c  2008-05-14 
> > 19:31:56.0 -0700
> > @@ -0,0 +1,165 @@
> > +/*
> > + * Code for replacing ftrace calls with jumps.
> > + *
> > + * Copyright (C) 2007-2008 Steven Rostedt <[EMAIL PROTECTED]>
> > + *
> > + * Thanks goes out to P.A. Semi, Inc for supplying me with a PPC64 box.
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#define CALL_BACK  4
>
> I don't grok what you're doing with CALL_BACK, you add it in places and
> subtract in others - and it looks like you could do neither, but I haven't
> gone over it in detail.

I tried hard to make most of the complex logic stay in generic code.

What dynamic ftrace does is at start up the code is simply a nop. Then
after initialization of ftrace, it calls kstop-machine that will call into
the arch code to convert the nop to a call to a "record_ip" function.
That record_ip function will start recording the return address of the
mcount function (__builtin_return_address(0)).

Then later, once a second the ftraced wakes up and checks if any new
functions have been recorded. If they have been, then it calls
kstop_machine againg and for each recorded function, it passes in the
address that was recorded.

The arch is responsible for knowning how to translate the
__builtin_return_address(0) into the address of the location of the call,
to be able to modify that code.

On boot up, all functions call "mcount". The ftraced daemon will convert
those calls to nop, and when tracing is enabled, then they will be
converted to point directly to the tracing function.

This helps tremondously in making ftrace efficient.

>
> > +static unsigned int ftrace_nop = 0x6000;
>
> I should really add a #define for that.
>
> > +#ifdef CONFIG_PPC32
> > +# define GET_ADDR(addr) addr
> > +#else
> > +/* PowerPC64's functions are data that points to the functions */
> > +# define GET_ADDR(addr) *(unsigned long *)addr
> > +#endif
>
> And that.
>
> ... snip
>

Patches added to 4xx next branch

[Josh Boyer]

Hi All,

The following patches have been added to the next branch of the 4xx
tree.  I plan on letting them sit in there for a few days and then
asking Paul to pull into his tree.  That way if I've screwed something
up only poor Stephen will get hit by it and I can fix things without
causing major problems for others.

I have a few more patches to add, but nothing really major.  If the
outstanding questions on sam440ep are answered/fixed then that will
likely go in too.  If there are things I've missed, please let me know.

josh

David Gibson (1):
  [POWERPC] Convert remaining dts-v0 files to v1

Josh Boyer (2):
  [POWERPC] 4xx: Fix PCI mem in rainier DTS
  [POWERPC] 4xx: Fix compiler warning on DCR_NATIVE only builds

Sean MacLennan (2):
  [POWERPC] PIKA Warp: Update DTS to support Rev B boards
  [POWERPC] PIKA Warp: Update platform code to support Rev B boards

Stephen Neuendorffer (1):
  [POWERPC] Refactor DCR code
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Grant Likely]

On Tue, May 20, 2008 at 7:15 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>> There (and in the QE GPIO) was an arch_initcall, but based on
>> Grant Likely's review it was removed in favour of platform-specific
>> machine_initcalls.
>>
>> See http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg16469.html
>> There I was trying to argue, but quickly gave up. ;-) I don't have any
>> strong preference for this anyway. I can do either way, just tell which
>> you prefer.
>
> I'd prefer the arch_initcall().  If its the board that is going to do the
> Kconfig select on this that seems sufficient to say do "init" for me w/o an
> explicit call to it.

That's only true if the assumption is that you are not building a
multiplatform kernel.  I'd rather see platform code in control of
registering devices.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Kumar Gala]

This is explained in the .c file with a kernel doc. Basically the

difference is that timer16 could silently crop the precision, while
utimer16 could not thus explicitly accepts u16 argument (max. timer
interval with usec precision fits in u16).


Maybe I'm confused what the utility is of cropping the precision in  
this

way is.  I'd also say that _timer16 is poorly named to convey the
behavior. I'm not sure what to call it because I still dont get  
exactly

why you'd want the precision cropped.


Precision matters for FHCI-like drivers, when driver, for example,
schedule transactions via the GTM timers, and there timings matters
a lot.

Though, timer16 crops the precision _only_ if usecs > 65535, so FHCI
_can_ still use the _timer16 (because FHCI does not request intervals

65535). But I implemented two function because:


1. I think we don't need unnecessary stuff in the ISRs (this is weak
  argument since I didn't measure the impact).
2. I wanted to make the API clear (seem to fail this undertaking :-),
  which functions will behave exactly the way you asked it (utimer16),
  and which functions will _silently_ crop the precision (timer16)
  (if asked for 1001000 usecs, it will give you ~~1001000, depending
  on the GTM frequency).


I'm fine w/having both. I think they are poorly named.  I'd also call  
them _set_timer but that's just me.


Maybe something w/the term _exact_ in the name.  Is it the case w/the  
precise form we'd have no prescaling (if so maybe a comment in the API  
about that would help clarity)?


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] ftrace: support for PowerPC

[Benjamin Herrenschmidt]

> 
> Why do we not want to trace early boot? Just because it's not useful? 

Not running at the linked address... might be causing trouble.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Anton Vorontsov]

On Tue, May 20, 2008 at 08:15:15AM -0500, Kumar Gala wrote:
[...]
 +  for_each_compatible_node(np, NULL, "fsl,gtm") {
 +  int i;
 +  struct gtm *gtm;
 +  const u32 *clock;
 +  int size;
 +
 +  gtm = kzalloc(sizeof(*gtm), GFP_KERNEL);
 +  if (!gtm) {
 +  pr_err("%s: unable to allocate memory\n",
 +  np->full_name);
 +  continue;
 +  }
>>>
>>> why bother with making this a dynamic alloc?
>>
>> Because different platforms have different number of GTMs
>> blocks. For QE machines this could be up to three GTMs, and QE-less
>> usually implement two GTMs. Not sure about CPM2.
>
> ok, that makes sense.
>
 +
 +  spin_lock_init(>m->lock);
 +
 +  clock = of_get_property(np, "clock-frequency", &size);
 +  if (!clock || size != sizeof(*clock)) {
 +  pr_err("%s: no clock-frequency\n", np->full_name);
 +  goto err;
 +  }
 +  gtm->clock = *clock;
 +
 +  for (i = 0; i < ARRAY_SIZE(gtm->timers); i++) {
 +  int ret;
 +  struct resource irq;
 +
 +  ret = of_irq_to_resource(np, i, &irq);
 +  if (ret == NO_IRQ) {
 +  pr_err("%s: not enough interrupts specified\n",
 + np->full_name);
 +  goto err;
 +  }
 +  gtm->timers[i].irq = irq.start;
 +  gtm->timers[i].gtm = gtm;
 +  }
 +
 +  gtm->regs = of_iomap(np, 0);
 +  if (!gtm->regs) {
 +  pr_err("%s: unable to iomap registers\n",
 + np->full_name);
 +  goto err;
 +  }
 +
 +  gtm_set_shortcuts(np, gtm->timers, gtm->regs);
 +  list_add(>m->list_node, >ms);
 +
 +  /* We don't want to lose the node and its ->data */
 +  np->data = gtm;
 +  of_node_get(np);
 +
 +  continue;
 +err:
 +  kfree(gtm);
 +  }
 +}
>>>
>>> Shouldn't we have an arch_initcall(fsl_gtm_init);
>>
>> There (and in the QE GPIO) was an arch_initcall, but based on
>> Grant Likely's review it was removed in favour of platform-specific
>> machine_initcalls.
>>
>> See http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg16469.html
>> There I was trying to argue, but quickly gave up. ;-) I don't have any
>> strong preference for this anyway. I can do either way, just tell  
>> which
>> you prefer.
>
> I'd prefer the arch_initcall().  If its the board that is going to do  
> the Kconfig select on this that seems sufficient to say do "init" for me 
> w/o an explicit call to it.

IIRC, the argument was that we don't need unnecessary initcalls for the
multi-platform kernels. With arch_initcall() GTM/QE GPIOs will be probed
regardless of a board the kernel currently running at. With
machine_initcalls we only probe the GTMs/QE GPIOs on the boards which
actually use it.

Once again, I see pros and cons of both ways, and I don't have preference,
so.. ok, I will revert the arch_initcall() for GTM and QE GPIO.

 diff --git a/include/asm-powerpc/fsl_gtm.h b/include/asm-powerpc/
 fsl_gtm.h
 new file mode 100644
 index 000..49f1240
 --- /dev/null
 +++ b/include/asm-powerpc/fsl_gtm.h
 @@ -0,0 +1,47 @@
 +/*
 + * Freescale General-purpose Timers Module
 + *
 + * Copyright (c) Freescale Semicondutor, Inc. 2006.
 + *   Shlomi Gridish <[EMAIL PROTECTED]>
 + *   Jerry Huang <[EMAIL PROTECTED]>
 + * Copyright (c) MontaVista Software, Inc. 2008.
 + *   Anton Vorontsov <[EMAIL PROTECTED]>
 + *
 + * This program is free software; you can redistribute  it and/or
 modify it
 + * under  the terms of  the GNU General  Public License as  
 published
 by the
 + * Free Software Foundation;  either version 2 of the  License, or
 (at your
 + * option) any later version.
 + */
 +
 +#ifndef __ASM_FSL_GTM_H
 +#define __ASM_FSL_GTM_H
 +
 +#include 
 +
 +struct gtm;
 +
 +struct gtm_timer {
 +  unsigned int irq;
 +
 +  struct gtm *gtm;
 +  bool requested;
 +  u8 __iomem *gtcfr;
 +  __be16 __iomem *gtmdr;
 +  __be16 __iomem *gtpsr;
 +  __be16 __iomem *gtcnr;
 +  __be16 __iomem *gtrfr;
 +  __be16 __iomem *gtevr;
 +};
 +
 +extern void __init fsl_gtm_init(void);
 +extern struct gtm_timer *gtm_get_timer(int width);
 +extern struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm,  
 int
 timer,
 +  int width);
 +extern void gtm_put_timer(struct g

Re: powerpc + i2c/rtc : where is the 11 min update ?

[Philippe De Muyter]

CCing lkml

On Tue, May 20, 2008 at 09:10:25PM +1000, Paul Mackerras wrote:
> Philippe De Muyter writes:
> 
> > I have a ARCH=powerpc linux-2.6.25-rc6 linux running with an i2c rtc chip,
> > and synchronized to a ntp server.
> > 
> > I noticed that my rtc chip does not get updated by the kernel, just like
> > it would be on all other architectures (included ppc).
> 
> That is now supposed to be done by the code inside #ifdef
> CONFIG_GENERIC_CMOS_UPDATE in kernel/time/ntp.c.
> 
> Paul.

Thanks.  I agree that is a good place.

But, here CONFIG_GENERIC_CMOS_UPDATE is defined and an i2c clock also,
and my rtc clock is not updated.  I see kernel/time/ntp.c::sync_cmos_clock
calling arch/powerpc/kernel/time.c::update_persistent_clock, where
ppc_md.set_rtc_time is NULL.

Who is supposed to initialize ppc_md.set_rtc_time to use an i2c clock and
when in the boot process may that happen ?

Or alternatively, should update_persistent_clock not be part of the rtc
subsystem ?

Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] ftrace: support for PowerPC

[Michael Ellerman]

On Wed, 2008-05-14 at 23:49 -0400, Steven Rostedt wrote:
> plain text document attachment (ftrace-powerpc-port.patch)
> This patch adds full support for ftrace for PowerPC (both 64 and 32 bit).
> This includes dynamic tracing and function filtering.

Hi Steven,

Just a few comments inline ..

> Index: linux-sched-devel.git/arch/powerpc/kernel/Makefile
> ===
> --- linux-sched-devel.git.orig/arch/powerpc/kernel/Makefile   2008-05-14 
> 19:30:53.0 -0700
> +++ linux-sched-devel.git/arch/powerpc/kernel/Makefile2008-05-14 
> 19:31:56.0 -0700
> @@ -12,6 +12,18 @@ CFLAGS_prom_init.o  += -fPIC
>  CFLAGS_btext.o   += -fPIC
>  endif
>  
> +ifdef CONFIG_FTRACE
> +# Do not trace early boot code
> +CFLAGS_REMOVE_cputable.o = -pg
> +CFLAGS_REMOVE_prom_init.o = -pg

Why do we not want to trace early boot? Just because it's not useful? 

> Index: linux-sched-devel.git/arch/powerpc/kernel/entry_32.S
> ===
> --- linux-sched-devel.git.orig/arch/powerpc/kernel/entry_32.S 2008-05-14 
> 19:30:50.0 -0700
> +++ linux-sched-devel.git/arch/powerpc/kernel/entry_32.S  2008-05-14 
> 19:31:56.0 -0700
> @@ -1035,3 +1035,133 @@ machine_check_in_rtas:
>   /* XXX load up BATs and panic */
>  
.. snip

> +_GLOBAL(mcount)
> +_GLOBAL(_mcount)
> + stwur1,-48(r1)
> + stw r3, 12(r1)
> + stw r4, 16(r1)
> + stw r5, 20(r1)
> + stw r6, 24(r1)
> + mflrr3
> + lwz r4, 52(r1)
> + mfcrr5
> + stw r7, 28(r1)
> + stw r8, 32(r1)
> + stw r9, 36(r1)
> + stw r10,40(r1)
> + stw r3, 44(r1)
> + stw r5, 8(r1)
> +
> + LOAD_REG_ADDR(r5, ftrace_trace_function)
> +#if 0
> + mtctr   r3
> + mr  r1, r5
> + bctrl
> +#endif
> + lwz r5,0(r5)
> +#if 1
> + mtctr   r5
> + bctrl
> +#else
> + bl  ftrace_stub
> +#endif

#if 0, #if 1 ?

> Index: linux-sched-devel.git/arch/powerpc/kernel/ftrace.c
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-sched-devel.git/arch/powerpc/kernel/ftrace.c2008-05-14 
> 19:31:56.0 -0700
> @@ -0,0 +1,165 @@
> +/*
> + * Code for replacing ftrace calls with jumps.
> + *
> + * Copyright (C) 2007-2008 Steven Rostedt <[EMAIL PROTECTED]>
> + *
> + * Thanks goes out to P.A. Semi, Inc for supplying me with a PPC64 box.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define CALL_BACK4

I don't grok what you're doing with CALL_BACK, you add it in places and
subtract in others - and it looks like you could do neither, but I haven't
gone over it in detail.

> +static unsigned int ftrace_nop = 0x6000;

I should really add a #define for that.

> +#ifdef CONFIG_PPC32
> +# define GET_ADDR(addr) addr
> +#else
> +/* PowerPC64's functions are data that points to the functions */
> +# define GET_ADDR(addr) *(unsigned long *)addr
> +#endif

And that.

.. snip

> +notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long 
> addr)
> +{
> + static unsigned int op;
> +
> + addr = GET_ADDR(addr);
> +
> + /* Set to "bl addr" */
> + op = 0x4801 | (ftrace_calc_offset(ip, addr) & 0x03fe);

0x03fe should be 0x03fc, if you set bit 1 you'll end with a "bla" 
instruction,
ie. branch absolute and link. That shouldn't happen as long as ip and addr are
properly aligned, but still.

In fact I think you should just use create_function_call() or create_branch() 
from
include/asm-powerpc/system.h

> +#ifdef CONFIG_PPC64
> +# define _ASM_ALIGN  " .align 3 "
> +# define _ASM_PTR" .llong "
> +#else
> +# define _ASM_ALIGN  " .align 2 "
> +# define _ASM_PTR" .long "
> +#endif

We already have a #define for .long, it's called PPC_LONG (asm/asm-compat.h)

Perhaps we should add one for .align, PPC_LONG_ALIGN or something?

> +notrace int
> +ftrace_modify_code(unsigned long ip, unsigned char *old_code,
> +unsigned char *new_code)
> +{
> + unsigned replaced;
> + unsigned old = *(unsigned *)old_code;
> + unsigned new = *(unsigned *)new_code;
> + int faulted = 0;
> +
> + /* move the IP back to the start of the call */
> + ip -= CALL_BACK;
> +
> + /*
> +  * Note: Due to modules and __init, code can
> +  *  disappear and change, we need to protect against faulting
> +  *  as well as code changing.
> +  *
> +  * No real locking needed, this code is run through
> +  * kstop_machine.
> +  */
> + asm volatile (
> + "1: lwz %1, 0(%2)\n"
> + "   cmpw%1, %5\n"
> + "   bne 2f\n"
> + "   stwu%3, 0(%2)\n"
> + "2:\n"
> + ".section .fixup, \"ax\"\n"
> +   

Re: [PATCH 1/1] ibmvscsi: Non SCSI error status fixup

[Brian King]

Michael Ellerman wrote:
> On Mon, 2008-05-19 at 10:56 -0500, Dave Boutcher wrote:
>> On Mon, 19 May 2008 10:27:56 -0500, Brian King <[EMAIL PROTECTED]> said:
>>> Some versions of the Virtual I/O Server on Power
>>> return 0x99 in the non-SCSI error status field as success,
>>> rather than 0. This fixes the ibmvscsi driver to treat this
>>> response as success.
>> Yeah0x99...that's an intuitive value for success.
> 
> Hopefully there are no versions that return 0x99 for an error? :)

There shouldn't be. 0x99 is actually not defined as a valid value for
that field, but it is what the ibmvscsis VIOS that is included in
SLES 9 and SLES 10 return on success, due to a bug in that driver.
We plan to fix the ibmvscsis driver as well, but it will take a while
for that fix to propagate. Until very recently, the status field was not
checked, which is why we are only recently running into this problem.

-Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Sam440ep support

[Josh Boyer]

On Tue, 20 May 2008 07:50:28 -0500
Josh Boyer <[EMAIL PROTECTED]> wrote:

> On Mon, 19 May 2008 17:20:47 +0200
> Giuseppe Coviello <[EMAIL PROTECTED]> wrote:
> 
> 
> > +   [EMAIL PROTECTED] {
> > +   compatible = "ohci-be";
> > +   reg = ;
> > +   interrupts = <8 4 9 4>;
> > +   interrupt-parent = < &UIC1 >;
> 
> Are you sure the trigger/level settings on those interrupts is
> correct?
> 
> > +   };  
> > +   };
> > +
> > +   PCI0: [EMAIL PROTECTED] {
> > +   device_type = "pci";
> > +   #interrupt-cells = <1>;
> > +   #size-cells = <2>;
> > +   #address-cells = <3>;
> > +   compatible = "ibm,plb440ep-pci", "ibm,plb-pci";
> > +   primary;
> > +   reg = <0 eec0 8 /* Config space access */
> > +  0 eed0 4 /* IACK */
> > +  0 eed0 4 /* Special cycle */
> > +  0 ef40 40>;  /* Internal registers */
> > +
> > +   /* Outbound ranges, one memory and one IO,
> > +* later cannot be changed. Chip supports a second
> > +* IO range but we don't use it for now
> > +*/
> > +   ranges = <0200 0 a000 0 a000 0 2000
> > + 0100 0  0 e800 0 0001>;
> > +
> > +   /* Inbound 2GB range starting at 0 */
> > +   dma-ranges = <4200 0 0 0 0 0 8000>;
> 
> You have no interrupt mapping for the PCI node.  How do you have
> working PCI here?

Also, if these questions result in changes to the DTS, could you please
convert it to a dts-v1 format?  Otherwise I'll have to do it myself and
it's cleaner if it comes in that way.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board

[Kumar Gala]

diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/ 
powerpc/platforms/86xx/mpc8610_hpcd.c

index dea1320..290d717 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -71,9 +71,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
/* Alloc mpic structure and per isu has 16 INT entries. */
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
-   0, 256, " MPIC ");
+   64, 256, " MPIC ");
BUG_ON(mpic1 == NULL);

+   mpic_assign_isu(mpic1, 0, res.start + 0x1);
+   mpic_assign_isu(mpic1, 1, res.start + 0x10800);
+   mpic_assign_isu(mpic1, 2, res.start + 0x11600);
+


I don't understand why you are breaking the interrupts up like this.

If you leave as it was, the MSIs would start at hw irq 176

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/1] ehea: Fix use after free on reboot

[Jan-Bernd Themann]

On Wednesday 14 May 2008 16:48, Brian King wrote:
> 
> Fixes the following use after free oops:
> 
> ehea: Reboot: freeing all eHEA resources
> Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6c5b
> Faulting instruction address: 0xd0354488
> cpu 0x0: Vector: 300 (Data Access) at [c0002ec6f310]
> pc: d0354488: .ehea_shutdown_single_port+0x50/0x78 [ehea]
> lr: d035447c: .ehea_shutdown_single_port+0x44/0x78 [ehea]
> sp: c0002ec6f590
>msr: 80009032
>dar: 6b6b6b6b6b6b6c5b
>  dsisr: 4000
>   current = 0xc000281412e0
>   paca= 0xc06df300
> pid   = 10930, comm = reboot
> enter ? for help
> [c0002ec6f590] d035d64c .ehea_remove+0x44/0x124 [ehea] 
> (unreliable)
> [c0002ec6f630] c0319f88 .of_platform_device_remove+0x40/0x58
> [c0002ec6f6a0] c0291018 .__device_release_driver+0xb0/0xf0
> [c0002ec6f730] c0291120 .driver_detach+0xc8/0xfc
> [c0002ec6f7c0] c028fe24 .bus_remove_driver+0xb4/0x114
> [c0002ec6f850] c0291768 .driver_unregister+0x54/0x74
> [c0002ec6f8e0] c031a0c8 .of_unregister_driver+0x14/0x28
> [c0002ec6f950] c0023ba0 .ibmebus_unregister_driver+0x10/0x24
> [c0002ec6f9c0] d0354180 .ehea_reboot_notifier+0x30/0x4c [ehea]
> [c0002ec6fa40] c03c95a8 .notifier_call_chain+0x5c/0xcc
> [c0002ec6fae0] c0082cd4 .__blocking_notifier_call_chain+0x70/0xb0
> [c0002ec6fb90] c0075cf8 .kernel_restart_prepare+0x24/0x58
> [c0002ec6fc10] c0075f0c .kernel_restart+0x20/0x6c
> [c0002ec6fc90] c0078674 .sys_reboot+0x1d4/0x290
> [c0002ec6fe30] c00086ac syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 0ff63a40
> SP (ffceea50) is in userspace
> 
> Signed-off-by: Brian King <[EMAIL PROTECTED]>
> ---
> 
>  linux-2.6-bjking1/drivers/net/ehea/ehea_main.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff -puN drivers/net/ehea/ehea_main.c~ehea_useafter_free_fix 
> drivers/net/ehea/ehea_main.c
> --- linux-2.6/drivers/net/ehea/ehea_main.c~ehea_useafter_free_fix 
> 2008-05-14 09:38:10.0 -0500
> +++ linux-2.6-bjking1/drivers/net/ehea/ehea_main.c2008-05-14 
> 09:38:10.0 -0500
> @@ -3177,11 +3177,12 @@ out_err:
> 
>  static void ehea_shutdown_single_port(struct ehea_port *port)
>  {
> + struct ehea_adapter *adapter = port->adapter;
>   unregister_netdev(port->netdev);
>   ehea_unregister_port(port);
>   kfree(port->mc_list);
>   free_netdev(port->netdev);
> - port->adapter->active_ports--;
> + adapter->active_ports--;
>  }
> 
>  static int ehea_setup_ports(struct ehea_adapter *adapter)
> _
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

The patch looks good. 

Acked-by: Jan-Bernd Themann <[EMAIL PROTECTED]>

Thanks,
Jan-Bernd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Kumar Gala]

On May 20, 2008, at 7:41 AM, Anton Vorontsov wrote:


On Tue, May 20, 2008 at 01:04:55AM -0500, Kumar Gala wrote:


On May 19, 2008, at 12:46 PM, Anton Vorontsov wrote:


GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts. These timers are used by the drivers that
need time precise interrupts (like for USB transactions scheduling  
for
the Freescale USB Host controller as found in some QE and CPM  
chips),
or these timers could be used as wakeup events from the CPU deep- 
sleep

mode.

Things unimplemented:
1. Cascaded (32 bit) timers (1-2, 3-4).
 This is straightforward to implement when needed, two timers should
 be marked as "requested" and configured as appropriate.
2. Super-cascaded (64 bit) timers (1-2-3-4).
 This is also straightforward to implement when needed, all timers
 should be marked as "requested" and configured as appropriate.

Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt |   37 +++-
arch/powerpc/Kconfig |5 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_gtm.c|  424 +++ 
++

+
include/asm-powerpc/fsl_gtm.h|   47 +++
5 files changed, 513 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_gtm.c
create mode 100644 include/asm-powerpc/fsl_gtm.h




diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3934e26..e5d3366 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -538,6 +538,11 @@ config FSL_LBC
help
  Freescale Localbus support

+config FSL_GTM
+   bool


I'd prefer something like:

depends on PPC_83xx || QUICC_ENGINE || CPM2


Btw, this is silent config, selected by the board's Kconfig
(same as QE block, for example). So "depends on" here is just
no-op, since select disregards dependencies. Still want this?


I do, its at least documentation if its not used.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Kumar Gala]

+void __init fsl_gtm_init(void)
+{
+   struct device_node *np;
+
+   for_each_compatible_node(np, NULL, "fsl,gtm") {
+   int i;
+   struct gtm *gtm;
+   const u32 *clock;
+   int size;
+
+   gtm = kzalloc(sizeof(*gtm), GFP_KERNEL);
+   if (!gtm) {
+   pr_err("%s: unable to allocate memory\n",
+   np->full_name);
+   continue;
+   }


why bother with making this a dynamic alloc?


Because different platforms have different number of GTMs
blocks. For QE machines this could be up to three GTMs, and QE-less
usually implement two GTMs. Not sure about CPM2.


ok, that makes sense.


+
+   spin_lock_init(>m->lock);
+
+   clock = of_get_property(np, "clock-frequency", &size);
+   if (!clock || size != sizeof(*clock)) {
+   pr_err("%s: no clock-frequency\n", np->full_name);
+   goto err;
+   }
+   gtm->clock = *clock;
+
+   for (i = 0; i < ARRAY_SIZE(gtm->timers); i++) {
+   int ret;
+   struct resource irq;
+
+   ret = of_irq_to_resource(np, i, &irq);
+   if (ret == NO_IRQ) {
+   pr_err("%s: not enough interrupts specified\n",
+  np->full_name);
+   goto err;
+   }
+   gtm->timers[i].irq = irq.start;
+   gtm->timers[i].gtm = gtm;
+   }
+
+   gtm->regs = of_iomap(np, 0);
+   if (!gtm->regs) {
+   pr_err("%s: unable to iomap registers\n",
+  np->full_name);
+   goto err;
+   }
+
+   gtm_set_shortcuts(np, gtm->timers, gtm->regs);
+   list_add(>m->list_node, >ms);
+
+   /* We don't want to lose the node and its ->data */
+   np->data = gtm;
+   of_node_get(np);
+
+   continue;
+err:
+   kfree(gtm);
+   }
+}


Shouldn't we have an arch_initcall(fsl_gtm_init);


There (and in the QE GPIO) was an arch_initcall, but based on
Grant Likely's review it was removed in favour of platform-specific
machine_initcalls.

See http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg16469.html
There I was trying to argue, but quickly gave up. ;-) I don't have any
strong preference for this anyway. I can do either way, just tell  
which

you prefer.


I'd prefer the arch_initcall().  If its the board that is going to do  
the Kconfig select on this that seems sufficient to say do "init" for  
me w/o an explicit call to it.



diff --git a/include/asm-powerpc/fsl_gtm.h b/include/asm-powerpc/
fsl_gtm.h
new file mode 100644
index 000..49f1240
--- /dev/null
+++ b/include/asm-powerpc/fsl_gtm.h
@@ -0,0 +1,47 @@
+/*
+ * Freescale General-purpose Timers Module
+ *
+ * Copyright (c) Freescale Semicondutor, Inc. 2006.
+ *   Shlomi Gridish <[EMAIL PROTECTED]>
+ *   Jerry Huang <[EMAIL PROTECTED]>
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *   Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute  it and/or
modify it
+ * under  the terms of  the GNU General  Public License as  
published

by the
+ * Free Software Foundation;  either version 2 of the  License, or
(at your
+ * option) any later version.
+ */
+
+#ifndef __ASM_FSL_GTM_H
+#define __ASM_FSL_GTM_H
+
+#include 
+
+struct gtm;
+
+struct gtm_timer {
+   unsigned int irq;
+
+   struct gtm *gtm;
+   bool requested;
+   u8 __iomem *gtcfr;
+   __be16 __iomem *gtmdr;
+   __be16 __iomem *gtpsr;
+   __be16 __iomem *gtcnr;
+   __be16 __iomem *gtrfr;
+   __be16 __iomem *gtevr;
+};
+
+extern void __init fsl_gtm_init(void);
+extern struct gtm_timer *gtm_get_timer(int width);
+extern struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm,  
int

timer,
+   int width);
+extern void gtm_put_timer(struct gtm_timer *tmr);
+extern int gtm_reset_timer16(struct gtm_timer *tmr, unsigned long
usec,
+bool reload);
+extern int gtm_reset_utimer16(struct gtm_timer *tmr, u16 usec, bool
reload);


can you explain the difference between these two.  I'm not sure I
understand the difference.


This is explained in the .c file with a kernel doc. Basically the
difference is that timer16 could silently crop the precision, while
utimer16 could not thus explicitly accepts u16 argument (max. timer
interval with usec precision fits in u16).


Maybe I'm confused what the utility is of cropping the precision in  
this way is.  I'd also say that _timer16 is poorly named to convey the  
behavior.  I'm not sure what to call it because I sti

Re: [PATCH] Add kernstart_addr to list of allowed symbols in prom_init

[Kumar Gala]

On May 20, 2008, at 7:48 AM, Michael Ellerman wrote:


Since commit "85xx: Add support for relocatable kernel (and
booting at non-zero)" (37dd2badcfcec35f5e21a0926968d77a404f03c3),
PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE
and FLATMEM is enabled.

PHYSICAL_START is used in prom_init.c and so kernstart_addr
needs to be added to the list of allowed symbols that
prom_init.c can access.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>


Acked-by: Kumar Gala <[EMAIL PROTECTED]>

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[Laurent Pinchart]

On Tuesday 20 May 2008 02:31, David Brownell wrote:
> On Tuesday 15 April 2008, Laurent Pinchart wrote:
> > Or maybe some kind of gpio_set_option() with flags specific to the 
> > controller ? This could be used to enable open-drain outputs or internal 
> > pull-ups for instance.
> 
> That presumes that the pin config is associated with the GPIO
> controller, rather than being an independent modules...
> 
> In the cases that a platform has such an association, there
> should be no problem just using a platform-specific code to
> do the relevant magic.

To call GPIO chip specific functions, the driver needs a way to get the GPIO 
chip associated with the GPIO.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75


pgp9VNmMUEwT7.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Sam440ep support

[Josh Boyer]

On Mon, 19 May 2008 17:20:47 +0200
Giuseppe Coviello <[EMAIL PROTECTED]> wrote:


> + [EMAIL PROTECTED] {
> + compatible = "ohci-be";
> + reg = ;
> + interrupts = <8 4 9 4>;
> + interrupt-parent = < &UIC1 >;

Are you sure the trigger/level settings on those interrupts is
correct?

> + };  
> + };
> +
> + PCI0: [EMAIL PROTECTED] {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb440ep-pci", "ibm,plb-pci";
> + primary;
> + reg = <0 eec0 8 /* Config space access */
> +0 eed0 4 /* IACK */
> +0 eed0 4 /* Special cycle */
> +0 ef40 40>;  /* Internal registers */
> +
> + /* Outbound ranges, one memory and one IO,
> +  * later cannot be changed. Chip supports a second
> +  * IO range but we don't use it for now
> +  */
> + ranges = <0200 0 a000 0 a000 0 2000
> +   0100 0  0 e800 0 0001>;
> +
> + /* Inbound 2GB range starting at 0 */
> + dma-ranges = <4200 0 0 0 0 0 8000>;

You have no interrupt mapping for the PCI node.  How do you have
working PCI here?

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[Laurent Pinchart]

Hi David,

On Tuesday 20 May 2008 02:25, David Brownell wrote:
> On Tuesday 15 April 2008, Laurent Pinchart wrote:
> > I'm implementing flow control and modem control lines support in the
> > cpm_uart driver.
> >
> > The implementation is based on the GPIO lib. Modem control lines are
> > described in the device tree as GPIO resources and accessed through the OF
> > GPIO bindings. The I/O ports have to be initialized as GPIOs in the
> > platform-specific code.
> 
> I don't follow the "have to be" ... why couldn't the platform
> setup code know that if a given UART is being used with hardware
> handshaking, that means a particular pin mux config should be used?

Flow control and modem control lines are two different beasts (although flow 
control uses a subset of the modem control lines).

The UART driver needs to get and set the modem control lines state. This is 
easily handled by the GPIO library without requiring any change to GPIO lib. 
The only requirement, as stated above, is that platform-specific code 
initializes the corresponding pins as GPIOs. I'm not sure to understand what 
you don't get, as my point is that the platform setup code must configure the 
pins appropriately, exactly as you mention in your comment.

> Are there maybe some on-chip routing options, so that for example
> RTS2 could come out on any of three different balls?  (In which
> case that setup code could just be told *which* config to use...)

That's possible yes, but that's not really an issue. Platform setup code is by 
definition platform-specific and has knowledge of the hardware, so it can 
setup pins correctly.

> In this case I'm asking specifically about the normal all-works-ok
> situation ... no errata or similar complications I mention below.
> 
> >  An option would be to export gpio_to_chip from drivers/gpio/gpiolib.c
> >  and use cpm1/2_set_pin in the cpm_uart driver.
> 
> Help me to understand this a bit.  UARTs are a fair example of places
> where I've seen such pin reconfiguration be useful, but it's never
> seemed to be generalizable except possibly as callbacks to SOC-specific
> code (which don't imply updating generic programming interfaces).

Callbacks worked fine on ppc but are now more difficult to implement in 
powerpc. This is why I'm looking for a generic solution based on the device 
tree.

> I've seen examples where the hardware flow control normally works, so
> that board setup sets up those pins in "hardware flow control" mode
> when it's told the board has them wired up that way ... but then, some
> chip revisions have errata forcing the driver to use a particular
> port's handshake pins as GPIOs in some cases.  (Obviously troublesome
> except at low data rates, so one hopes the board designers just avoid
> using those UARTs in that mode.)

The issue is that flow control must be configurable. Userspace software can 
turn it on or off. To handle that on CPM2-based platforms, the pins connected 
to CTS and RTS must be switched between GPIO mode (no flow control) and 
dedicated function mode (hard flow control) at runtime in the UART driver.

> I've also seen examples where the UART clock needs to be disabled in
> deeper sleep states, but the system still wants the UART to be a wake
> event source ... by having either the START bit, or maybe BREAK (it
> gives a longer latch period), kick in a gpio-based pin change IRQ on
> the UARTn.RX line.
> 
> Now in *both* of those examples I've seen before, the solution could
> not be generic.  When the pin was used as GPIO, a particular pinmux
> configuration was needed.  (Bitfield X of register Y has value Z ...
> or maybe a couple registers needed to change.)  And when used as a
> UART signal, a different one was used.  (Same setup.  Maybe value Z
> became value W.  Or again, maybe a few registers needed changing.)
> 
> And for different chips in the family, sometimes even different
> revisions of one chip, the W/X/Y/Z/etc values differed even for UART1.
> For other UARTs, the same was true.
> 
> So given that ... how would knowing the GPIO chip help, when I'd
> still need to find out the W/X/Y/Z/etc values?  And if I've got a
> way to convey W/X/Y/Z/etc -- canonical example being a callback to
> the relevant SOC-specific code --  why shouldn't that obviate the
> need for any scheme to look up the gpio chip?

On Freescale PowerPC hardware (specifically CPM2-based, but CPM1 and QE are 
quite similar), pins can either have a dedicated functionality or be used as 
a GPIO. This is handled through a group of registers, which are

- the data register, used in GPIO mode only
- the direction register, used in both GPIO and dedicated modes
- the pin assignment register, used to switch between GPIO and dedicated mode
- the open-drain register, used to switch between push-pull and open drain 
configurations

Let's take the UART CTS signal as an example, connected to port C, pin 15. The 
pin is always a push-pull output, so that configuration can be set in 
platform setup

Re: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)

[Takashi Iwai]

At Mon, 19 May 2008 19:23:10 +0200,
Giuseppe Coviello wrote:
> 
> On mer, 14/05/2008 14.26 +0200, Takashi Iwai wrote:
> [cut]
> > OK, here is another patch for testing.  Since I lost my old patch
> > somewhere (and it's not worth to dig the archive), I wrote it up
> > quickly from scratch.  This version should cover both SG and non-SG
> > buffers.  It's against the latest git tree.
> > 
> > The patch adds a hackish verison of dma_mmap_coherent() for some
> > architectures in sound/core/pcm_native.c.  I'm not sure whether this
> > works.  I just tested it on X86.  It'd be appreciated if someone can
> > test this.
> > 
> > Also, this disables HDSPM driver for non-X86/IA64 since the driver has
> > own copy and silence methods that are incompatible with the new
> > SG-buffer data.
> > 
> > 
> > And, yes, I know we need to clean up huge messes in ALSA memory
> > handling routines.  But, let's fix obvious bugs before starting a big
> > rewrite...
> > 
> 
> I've just tested this patch on the sam440ep and it works great (and
> sounds great, of course). I had also to make the following changes:

Hmm, weird.  cs4281 has no SG buffer at all, so basically it cannot
work like that...

FYI, the latest patches can be found on
git://git.kernel.org/pub/scm/linux/kernel/tiwai/sound-unstable-2.6.git


thanks,

Takashi


> 
> Signed-off-by: Giuseppe Coviello <[EMAIL PROTECTED]>
> 
> diff --git a/sound/pci/cs4281.c b/sound/pci/cs4281.c
> index 7556fd9..f5f208e 100644
> --- a/sound/pci/cs4281.c
> +++ b/sound/pci/cs4281.c
> @@ -952,6 +952,9 @@ static struct snd_pcm_ops snd_cs4281_playback_ops = {
>   .prepare =  snd_cs4281_playback_prepare,
>   .trigger =  snd_cs4281_trigger,
>   .pointer =  snd_cs4281_pointer,
> + .copy = snd_pcm_sgbuf_ops_copy,
> + .silence =  snd_pcm_sgbuf_ops_silence,
> +   .page = snd_pcm_sgbuf_ops_page,
>  };
>  
>  static struct snd_pcm_ops snd_cs4281_capture_ops = {
> @@ -963,6 +966,8 @@ static struct snd_pcm_ops snd_cs4281_capture_ops = {
>   .prepare =  snd_cs4281_capture_prepare,
>   .trigger =  snd_cs4281_trigger,
>   .pointer =  snd_cs4281_pointer,
> + .copy = snd_pcm_sgbuf_ops_copy,
> +   .page = snd_pcm_sgbuf_ops_page,
>  };
>  
>  static int __devinit snd_cs4281_pcm(struct cs4281 * chip, int device,
> 
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] Add kernstart_addr to list of allowed symbols in prom_init

[Michael Ellerman]

Since commit "85xx: Add support for relocatable kernel (and
booting at non-zero)" (37dd2badcfcec35f5e21a0926968d77a404f03c3),
PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE
and FLATMEM is enabled.

PHYSICAL_START is used in prom_init.c and so kernstart_addr
needs to be added to the list of allowed symbols that
prom_init.c can access.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---

Not sure if anyone is building this config in practice, but it
is broken in 26 without this patch.

 arch/powerpc/kernel/prom_init_check.sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/prom_init_check.sh 
b/arch/powerpc/kernel/prom_init_check.sh
index 8e24fc1..31729a9 100644
--- a/arch/powerpc/kernel/prom_init_check.sh
+++ b/arch/powerpc/kernel/prom_init_check.sh
@@ -20,7 +20,7 @@ WHITELIST="add_reloc_offset __bss_start __bss_stop 
copy_and_flush
 _end enter_prom memcpy memset reloc_offset __secondary_hold
 __secondary_hold_acknowledge __secondary_hold_spinloop __start
 strcmp strcpy strlcpy strlen strncmp strstr logo_linux_clut224
-reloc_got2"
+reloc_got2 kernstart_addr"
 
 NM="$1"
 OBJ="$2"
-- 
1.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUILD_FAILURE] linux-next: Tree for May 20 - build failure on powerpc

[Michael Ellerman]

On Tue, 2008-05-20 at 16:25 +0530, Kamalesh Babulal wrote:
> Hi Stephen,
> 
> The next-20080520 kernel build fails on powerpc, when build the randconfig 
> with
> build error message

>   CC  arch/powerpc/kernel/prom_init.o
>   CALLarch/powerpc/kernel/prom_init_check.sh
> Error: External symbol 'kernstart_addr' referenced from prom_init.c
> make[1]: *** [prom_init_check] Error 1
> make: *** [arch/powerpc/kernel] Error 2

It's broken in upstream actually, for RELOCATABLE && FLATMEM.

Patch on the way.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Anton Vorontsov]

On Tue, May 20, 2008 at 01:04:55AM -0500, Kumar Gala wrote:
>
> On May 19, 2008, at 12:46 PM, Anton Vorontsov wrote:
>
>> GTM stands for General-purpose Timers Module and able to generate
>> timer{1,2,3,4} interrupts. These timers are used by the drivers that
>> need time precise interrupts (like for USB transactions scheduling for
>> the Freescale USB Host controller as found in some QE and CPM chips),
>> or these timers could be used as wakeup events from the CPU deep-sleep
>> mode.
>>
>> Things unimplemented:
>> 1. Cascaded (32 bit) timers (1-2, 3-4).
>>   This is straightforward to implement when needed, two timers should
>>   be marked as "requested" and configured as appropriate.
>> 2. Super-cascaded (64 bit) timers (1-2-3-4).
>>   This is also straightforward to implement when needed, all timers
>>   should be marked as "requested" and configured as appropriate.
>>
>> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
>> ---
>> Documentation/powerpc/booting-without-of.txt |   37 +++-
>> arch/powerpc/Kconfig |5 +
>> arch/powerpc/sysdev/Makefile |1 +
>> arch/powerpc/sysdev/fsl_gtm.c|  424 + 
>> +
>> include/asm-powerpc/fsl_gtm.h|   47 +++
>> 5 files changed, 513 insertions(+), 1 deletions(-)
>> create mode 100644 arch/powerpc/sysdev/fsl_gtm.c
>> create mode 100644 include/asm-powerpc/fsl_gtm.h
>
>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 3934e26..e5d3366 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -538,6 +538,11 @@ config FSL_LBC
>>  help
>>Freescale Localbus support
>>
>> +config FSL_GTM
>> +bool
>
> I'd prefer something like:
>
> depends on PPC_83xx || QUICC_ENGINE || CPM2

Btw, this is silent config, selected by the board's Kconfig
(same as QE block, for example). So "depends on" here is just
no-op, since select disregards dependencies. Still want this?

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] [POWERPC] sysdev: implement FSL GTM support

[Anton Vorontsov]

On Tue, May 20, 2008 at 01:04:55AM -0500, Kumar Gala wrote:
[...]
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 3934e26..e5d3366 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -538,6 +538,11 @@ config FSL_LBC
>>  help
>>Freescale Localbus support
>>
>> +config FSL_GTM
>> +bool
>
> I'd prefer something like:
>
> depends on PPC_83xx || QUICC_ENGINE || CPM2

Ok.

>> +/**
>> + * gtm_get_specific_timer - request specific GTM timer
>> + * @gtm:specific GTM, pass here GTM's device_node->data
>> + * @timer:  specific timer number, Timer1 is 0.
>> + * @width:  timer width (only 16 bits wide timers implemented so far)
>> + *
>> + * This function reserves GTM timer for later use. It returns  
>> gtm_timer
>> + * structure to use with the rest of GTM API, you should use timer- 
>> >irq
>> + * to manage timer interrupt.
>> + */
>> +struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm, int timer, 
>> int width)
>> +{
>> +struct gtm_timer *ret = ERR_PTR(-EBUSY);
>> +
>> +if (width != 16)
>> +return ERR_PTR(-ENOSYS);
>
> should we not range check timer (since it can only be 0..3)?

I thought that caller should be smart enough to not ask for bogus
timers. Ok, will range check.

>> +
>> +spin_lock_irq(>m->lock);
>> +
>> +if (gtm->timers[timer].requested)
>> +goto out;
>> +
>> +ret = >m->timers[timer];
>> +ret->requested = true;
>> +
>> +out:
>> +spin_unlock_irq(>m->lock);
>> +return ret;
>> +}
>> +EXPORT_SYMBOL(gtm_get_specific_timer);
>> +
>> +/**
>> + * gtm_put_timer - release GTM timer
>> + * @width:  timer width (only 16 bits wide timers implemented so far)
>> + *
>> + * This function releases GTM timer so others may request it.
>> + */
>> +void gtm_put_timer(struct gtm_timer *tmr)
>> +{
>> +spin_lock_irq(&tmr->gtm->lock);
>> +
>> +tmr->requested = false;
>
> should we not stop the timer as well?

Sounds reasonable. I recalling that I intended to implement that,
but obviously forgot. ;-)

>>
>> +
>> +spin_unlock_irq(&tmr->gtm->lock);
>> +}
>> +EXPORT_SYMBOL(gtm_put_timer);
>> +
>> +/*
>> + * This is back-end for the exported functions, it's used to reset  
>> single
>> + * timer in reference mode.
>> + */
>> +static int gtm_reset_ref_timer16(struct gtm_timer *tmr, int  
>> frequency,
>> + int reference_value, bool free_run)
>> +{
>> +struct gtm *gtm = tmr->gtm;
>> +int num = tmr - >m->timers[0];
>> +unsigned int prescaler;
>> +u8 iclk = GTMDR_ICLK_ICLK;
>> +u8 psr;
>> +u8 sps;
>> +unsigned long flags;
>> +int max_prescaler = 256 * 256 * 16;
>> +
>> +/* CPM2 doesn't have primary prescaler */
>> +if (!tmr->gtpsr)
>> +max_prescaler /= 256;
>> +
>> +prescaler = gtm->clock / frequency;
>> +/*
>> + * We have two 8 bit prescalers -- primary and secondary (psr, sps),
>> + * plus "slow go" mode (clk / 16). So, total prescale value is
>> + * 16 * (psr + 1) * (sps + 1). Though, for CPM2 GTMs we losing psr.
>> + */
>> +if (prescaler > max_prescaler)
>> +return -EINVAL;
>> +
>> +if (prescaler > max_prescaler / 16) {
>> +iclk = GTMDR_ICLK_SLGO;
>> +prescaler /= 16;
>> +}
>> +
>> +if (prescaler <= 256) {
>> +psr = 0;
>> +sps = prescaler - 1;
>> +} else {
>> +psr = 256 - 1;
>> +sps = prescaler / 256 - 1;
>> +}
>> +
>> +spin_lock_irqsave(>m->lock, flags);
>> +
>> +/*
>> + * Properly reset timers: stop, reset, set up prescalers, reference
>> + * value and clear event register.
>> + */
>> +clrsetbits_8(tmr->gtcfr, ~(GTCFR_STP(num) | GTCFR_RST(num)),
>> + GTCFR_STP(num) | GTCFR_RST(num));
>> +
>> +setbits8(tmr->gtcfr, GTCFR_STP(num));
>> +
>> +if (tmr->gtpsr)
>> +out_be16(tmr->gtpsr, psr);
>> +clrsetbits_be16(tmr->gtmdr, 0x, iclk | GTMDR_SPS(sps) |
>> +GTMDR_ORI | (free_run ? GTMDR_FRR : 0));
>> +out_be16(tmr->gtcnr, 0);
>> +out_be16(tmr->gtrfr, reference_value);
>> +out_be16(tmr->gtevr, 0x);
>> +
>> +/* Let it be. */
>> +clrbits8(tmr->gtcfr, GTCFR_STP(num));
>> +
>> +spin_unlock_irqrestore(>m->lock, flags);
>> +
>> +return 0;
>> +}
>> +/**
>> + * gtm_reset_timer16 - reset 16 bit timer with arbitrary precision
>> + * @tmr:pointer to the gtm_timer structure obtained from  
>> gtm_get_timer
>> + * @usec:   timer interval in microseconds
>> + * @reload: if set, the timer will reset upon expiry rather than
>> + *  continue running free.
>> + *
>> + * This function (re)sets the GTM timer so that it counts up to the  
>> requested
>> + * interval value, and fires the interrupt when the value is reached. 
>> This
>> + * function will reduce the precision of the timer as needed in order 
>> for the
>> + * requested timeout to fit in a 16-bit register.
>
> is t

Re: [PATCH 3/4] spi: Add OF binding support for SPI busses

[Gary Jennejohn]

On Mon, 19 May 2008 21:19:50 +0400
Anton Vorontsov <[EMAIL PROTECTED]> wrote:

> On Mon, May 19, 2008 at 07:09:00PM +0200, Gary Jennejohn wrote:
[snip extraneous content]
> > My problem was, and is, that there's no generic GPIO support for powerpc.
> > At least, not that I'm aware of.  Please tell me if I'm wrong.
> 
> Documentation/powerpc/booting-without-of.txt
> VIII - Specifying GPIO information for devices.
> 
> And include/linux/of_gpio.h + drivers/of/gpio.c.
> 

Thanks! I'll look into using this.

---
Gary Jennejohn
*
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/7] [POWERPC] QE: add support for QE USB clocks routing

[Anton Vorontsov]

On Tue, May 20, 2008 at 02:04:13PM +1000, Stephen Rothwell wrote:
> Hi Anton,
> 
> On Mon, 19 May 2008 21:46:55 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/arch/powerpc/sysdev/qe_lib/usb.c
> 
> > +#include 
> 
> Nothing in this file requires anything in linux/of.h or asm/of.h ...

Yeah, this is left-over... Thanks for catching this.

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ppc -> powerpc : where is 11 min rtc update gone ?

[Paul Mackerras]

Philippe De Muyter writes:

> I have a ARCH=powerpc linux-2.6.25-rc6 linux running with an i2c rtc chip,
> and synchronized to a ntp server.
> 
> I noticed that my rtc chip does not get updated by the kernel, just like
> it would be on all other architectures (included ppc).

That is now supposed to be done by the code inside #ifdef
CONFIG_GENERIC_CMOS_UPDATE in kernel/time/ntp.c.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[git pull] Please pull powerpc.git merge branch

[Paul Mackerras]

Linus,

Please pull from the 'merge' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge

to get a collection of small fixes and a defconfig update for
powerpc, plus an update to MAINTAINERS for the Cell port.

Thanks,
Paul.

 MAINTAINERS|   23 ++-
 arch/powerpc/boot/.gitignore   |8 -
 arch/powerpc/boot/Makefile |6 +
 arch/powerpc/boot/dts/mpc8377_mds.dts  |   18 ++
 arch/powerpc/configs/chrp32_defconfig  |  164 +-
 arch/powerpc/configs/g5_defconfig  |  226 +++
 arch/powerpc/configs/iseries_defconfig |  146 +---
 arch/powerpc/configs/pmac32_defconfig  |  174 +++-
 arch/powerpc/configs/ppc64_defconfig   |  236 +++-
 arch/powerpc/configs/pseries_defconfig |  224 +++---
 arch/powerpc/mm/hash_low_32.S  |2 
 lib/lmb.c  |3 
 12 files changed, 675 insertions(+), 555 deletions(-)

Adrian Bunk (1):
  [POWERPC] powerpc/mm/hash_low_32.S: Remove CVS keyword

Arnd Bergmann (1):
  [POWERPC] Update Cell MAINTAINERS entry, add spufs entry

Kumar Gala (4):
  lmb: Fix compile warning
  [POWERPC] Remove generated files on make clean
  [POWERPC] Update arch/powerpc/boot/.gitignore
  [POWERPC] Fix mpc8377_mds.dts DMA nodes to match spec

Paul Mackerras (1):
  [POWERPC] Update defconfigs for desktop/server systems

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

ppc -> powerpc : where is 11 min rtc update gone ?

[Philippe De Muyter]

Hi everybody,

I have a ARCH=powerpc linux-2.6.25-rc6 linux running with an i2c rtc chip,
and synchronized to a ntp server.

I noticed that my rtc chip does not get updated by the kernel, just like
it would be on all other architectures (included ppc).

Looking at the differences between ./arch/powerpc/kernel/time.c and
./arch/ppc/kernel/time.c, I see that 

/*
 * update the rtc when needed ...

code segement has disappeared

Is it expected to be done somewhere else (where ?) or is there another
good reason for this removal ?

Kind regards

Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[BUILD_FAILURE] linux-next: Tree for May 20 - build failure on powerpc

[Kamalesh Babulal]

Hi Stephen,

The next-20080520 kernel build fails on powerpc, when build the randconfig with
build error message


  CC  arch/powerpc/kernel/prom_init.o
  CALLarch/powerpc/kernel/prom_init_check.sh
Error: External symbol 'kernstart_addr' referenced from prom_init.c
make[1]: *** [prom_init_check] Error 1
make: *** [arch/powerpc/kernel] Error 2



-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.26-rc3-next-20080520
# Tue May 20 15:04:04 2008
#
# CONFIG_PPC64 is not set

#
# Processor support
#
# CONFIG_6xx is not set
CONFIG_PPC_85xx=y
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_E500=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
CONFIG_FSL_EMB_PERFMON=y
# CONFIG_PHYS_64BIT is not set
CONFIG_SPE=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFAULT_UIMAGE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
CONFIG_GROUP_SCHED=y
# CONFIG_FAIR_GROUP_SCHED is not set
CONFIG_RT_GROUP_SCHED=y
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
# CONFIG_MARKERS is not set
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
# CONFIG_HAVE_DMA_ATTRS is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
CONFIG_BLK_DEV_BSG=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_CLASSIC_RCU=y

#
# Platform support
#
# CONFIG_PPC_MPC512x is not set
# CONFIG_PPC_MPC5121 is not set
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PQ2ADS is not set
CONFIG_MPC85xx=y
CONFIG_MPC8540_ADS=y
# CONFIG_MPC8560_ADS is not set
# CONFIG_MPC85xx_CDS is not set
# CONFIG_MPC85xx_MDS is not set
CONFIG_MPC85xx_DS=y
# CONFIG_KSI8560 is not set
# CONFIG_STX_GP3 is not set
# CONFIG_TQM8540 is not set
CONFIG_TQM8541=y
# CONFIG_TQM8555 is not set
CONFIG_TQM8560=y
# CONFIG_SBC8548 is not set
# CONFIG_SBC8560 is not set
CONFIG_TQM85xx=y
# CONFIG_IPIC is not set
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
CONFIG_PPC_I8259=y
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_DEBUG is not set
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is no

[PATCH 3/4 V4] Enable MSI support for MPC8610HPCD board

[Jason Jin]

This patch enable the MSI on 8610hpcd board.
Through the msi-available-ranges property, All the 256
msi interrupts can be tested on this board.

Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
In the V4 version,
Change the compatible name in dts.

 arch/powerpc/boot/dts/mpc8610_hpcd.dts |   16 
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c |6 +-
 2 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts 
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 08a780d..0a70b30 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -182,6 +182,22 @@
big-endian;
};
 
+   [EMAIL PROTECTED] {
+   compatible = "fsl,mpc8610-msi", "fsl,mpic-msi";
+   reg = <0x41600 0x80>;
+   msi-available-ranges = <0 0x100>;
+   interrupts = <
+   0xb0 0
+   0xb1 0
+   0xb2 0
+   0xb3 0
+   0xb4 0
+   0xb5 0
+   0xb6 0
+   0xb7 0>;
+   interrupt-parent = <&mpic>;
+   };
+
[EMAIL PROTECTED] {
compatible = "fsl,mpc8610-guts";
reg = <0xe 0x1000>;
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c 
b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index dea1320..290d717 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -71,9 +71,13 @@ static void __init mpc86xx_hpcd_init_irq(void)
/* Alloc mpic structure and per isu has 16 INT entries. */
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
-   0, 256, " MPIC ");
+   64, 256, " MPIC ");
BUG_ON(mpic1 == NULL);
 
+   mpic_assign_isu(mpic1, 0, res.start + 0x1);
+   mpic_assign_isu(mpic1, 1, res.start + 0x10800);
+   mpic_assign_isu(mpic1, 2, res.start + 0x11600);
+
mpic_init(mpic1);
 }
 
-- 
1.5.4

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 2/4 V6] MSI support on 83xx/85xx/86xx board

[Jason Jin]

This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were setup for this chip.

Before using the MSI interrupt, PCI/PCIE device need to
ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
bitmap show which MSI interrupt was used, reserve bit in
the bitmap can be used to force the device use some designate
MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
for testing the all the MSI interrupts. The msi-available-ranges
property in the dts file was used for this purpose.

Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
In this V6 version,
change the compatible according to the change in dts

 arch/powerpc/sysdev/Makefile  |3 +-
 arch/powerpc/sysdev/fsl_msi.c |  436 +
 arch/powerpc/sysdev/fsl_msi.h |   42 
 arch/powerpc/sysdev/fsl_pci.c |   14 ++
 4 files changed, 494 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/sysdev/fsl_msi.c
 create mode 100644 arch/powerpc/sysdev/fsl_msi.h

diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 2cc5052..dd6dff3 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,7 @@ endif
 
 mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
 obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+fsl-msi-obj-$(CONFIG_PCI_MSI)  += fsl_msi.o
 
 obj-$(CONFIG_PPC_MPC106)   += grackle.o
 obj-$(CONFIG_PPC_DCR_NATIVE)   += dcr-low.o
@@ -11,7 +12,7 @@ obj-$(CONFIG_PPC_PMI) += pmi.o
 obj-$(CONFIG_U3_DART)  += dart_iommu.o
 obj-$(CONFIG_MMIO_NVRAM)   += mmio_nvram.o
 obj-$(CONFIG_FSL_SOC)  += fsl_soc.o
-obj-$(CONFIG_FSL_PCI)  += fsl_pci.o
+obj-$(CONFIG_FSL_PCI)  += fsl_pci.o $(fsl-msi-obj-y)
 obj-$(CONFIG_FSL_LBC)  += fsl_lbc.o
 obj-$(CONFIG_RAPIDIO)  += fsl_rio.o
 obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
new file mode 100644
index 000..9d0685b
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -0,0 +1,436 @@
+/*
+ * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Tony Li <[EMAIL PROTECTED]>
+ *Jason Jin <[EMAIL PROTECTED]>
+ *
+ * The hwirq alloc and free code reuse from sysdev/mpic_msi.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "fsl_msi.h"
+
+struct fsl_msi_feature {
+   u32 fsl_pic_ip;
+   u32 msiir_offset;
+};
+
+static struct fsl_msi *fsl_msi;
+
+static inline u32 fsl_msi_read(u32 __iomem *base, unsigned int reg)
+{
+   return in_be32(base + (reg >> 2));
+}
+
+static inline void fsl_msi_write(u32 __iomem *base,
+   unsigned int reg, u32 value)
+{
+   out_be32(base + (reg >> 2), value);
+}
+
+/*
+ * We do not need this actually. The MSIR register has been read once
+ * in the cascade interrupt. So, this MSI interrupt has been acked
+*/
+static void fsl_msi_end_irq(unsigned int virq)
+{
+}
+
+static struct irq_chip fsl_msi_chip = {
+   .mask   = mask_msi_irq,
+   .unmask = unmask_msi_irq,
+   .ack= fsl_msi_end_irq,
+   .typename   = " FSL-MSI  ",
+};
+
+static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
+   irq_hw_number_t hw)
+{
+   struct irq_chip *chip = &fsl_msi_chip;
+
+   get_irq_desc(virq)->status |= IRQ_TYPE_EDGE_FALLING;
+
+   set_irq_chip_and_handler(virq, chip,  handle_edge_irq);
+
+   return 0;
+}
+
+static struct irq_host_ops fsl_msi_host_ops = {
+   .map = fsl_msi_host_map,
+};
+
+irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
+{
+   unsigned long flags;
+   int offset, order = get_count_order(num);
+
+   spin_lock_irqsave(&msi->bitmap_lock, flags);
+
+   offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
+   NR_MSI_IRQS, order);
+
+   spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+
+   pr_debug("%s: allocated 0x%x (2^%d) at offset 0x%x\n",
+   __func__, num, order, offset);
+
+   return offset;
+}
+
+void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
+{
+   unsigned long flags;
+   int order = get_count_order(num);
+
+   pr_debug("%s: freeing 0x%x (2^%d) at offset 0x%x\n",
+   __func__, num, order, offset);
+
+   spin_lock_irqsave(&msi->bitmap_lock, flags);
+   bitm

[PATCH 4/4 V4] Enable MSI support for 85xxds board

[Jason Jin]

This patch enabled MSI on 8544ds and 8572ds board.
So far only one MSI interrupt can generate on 8544 board.

Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
In the V4 version,
Change the compatible name in dts file.

 arch/powerpc/boot/dts/mpc8544ds.dts  |   16 
 arch/powerpc/boot/dts/mpc8572ds.dts  |   16 
 arch/powerpc/platforms/85xx/mpc85xx_ds.c |7 ++-
 3 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts 
b/arch/powerpc/boot/dts/mpc8544ds.dts
index 6a0d8db..08183fd 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -219,6 +219,22 @@
device_type = "open-pic";
big-endian;
};
+
+   [EMAIL PROTECTED] {
+   compatible = "fsl,mpc8544-msi", "fsl,mpic-msi";
+   reg = <0x41600 0x80>;
+   msi-available-ranges = <0 0x100>;
+   interrupts = <
+   0xb0 0
+   0xb1 0
+   0xb2 0
+   0xb3 0
+   0xb4 0
+   0xb5 0
+   0xb6 0
+   0xb7 0>;
+   interrupt-parent = <&mpic>;
+   };
};
 
pci0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts 
b/arch/powerpc/boot/dts/mpc8572ds.dts
index 66f27ab..5103882 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -221,6 +221,22 @@
fsl,has-rstcr;
};
 
+   [EMAIL PROTECTED] {
+   compatible = "fsl,mpc8572-msi", "fsl,mpic-msi";
+   reg = <0x41600 0x80>;
+   msi-available-ranges = <0 0x100>;
+   interrupts = <
+   0xb0 0
+   0xb1 0
+   0xb2 0
+   0xb3 0
+   0xb4 0
+   0xb5 0
+   0xb6 0
+   0xb7 0>;
+   interrupt-parent = <&mpic>;
+   };
+
mpic: [EMAIL PROTECTED] {
clock-frequency = <0>;
interrupt-controller;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index dfd8b4a..2696d2f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -79,9 +79,13 @@ void __init mpc85xx_ds_pic_init(void)
 
mpic = mpic_alloc(np, r.start,
  MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
-   0, 256, " OpenPIC  ");
+   64, 256, " OpenPIC  ");
BUG_ON(mpic == NULL);
 
+   mpic_assign_isu(mpic, 0, r.start + 0x1);
+   mpic_assign_isu(mpic, 1, r.start + 0x10800);
+   mpic_assign_isu(mpic, 2, r.start + 0x11600);
+
mpic_init(mpic);
 
 #ifdef CONFIG_PPC_I8259
@@ -195,6 +199,7 @@ static int __init mpc85xxds_publish_devices(void)
return of_platform_bus_probe(NULL, mpc85xxds_ids, NULL);
 }
 machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices);
+machine_device_initcall(mpc8572_ds, mpc85xxds_publish_devices);
 
 /*
  * Called very early, device-tree isn't unflattened
-- 
1.5.4

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/4 V4] booting-without-of for Freescale MSI

[Jason Jin]

Binding document adding for Freescale MSI support.

Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
---
In the V4 version, per Kumar's suggestion,
Change the compatile name like "fsl,CHIP-msi", "fsl,mpic-msi"/"fsl,ipic-msi".

 Documentation/powerpc/booting-without-of.txt |   43 +-
 1 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt 
b/Documentation/powerpc/booting-without-of.txt
index 1d2a772..149b59c 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,7 +57,10 @@ Table of Contents
   n) 4xx/Axon EMAC ethernet nodes
   o) Xilinx IP cores
   p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+  q) USB EHCI controllers
+  r) Freescale Display Interface Unit
+  s) Freescale on board FPGA
+  t) Freescael MSI interrupt controller
 
   VII - Marvell Discovery mv64[345]6x System Controller chips
 1) The /system-controller node
@@ -2870,6 +2873,44 @@ platforms are moved over to use the 
flattened-device-tree model.
reg = <0xe800 32>;
};
 
+t) Freescale MSI interrupt controller
+
+Reguired properities:
+- compatible : compatible list, contains 2 entries,
+  first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,
+  etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
+  the parent type.
+- reg : should contain the address and the length of the shared message
+  interrupt register set.
+- msi-available-ranges: use  style section to define which
+  msi interrupt can be used in the 256 msi interrupts. This property is
+  optional, without this, all the 256 MSI interrupts can be used.
+- interrupts : each one of the interrupts here is one entry per 32 MSIs,
+  and routed to the host interrupt controller. the interrupts should
+  be set as edge sensitive.
+- interrupt-parent: the phandle for the interrupt controller
+  that services interrupts for this device. for 83xx cpu, the interrupts
+  are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed
+  to MPIC.
+
+Example
+   [EMAIL PROTECTED] {
+   compatible = "fsl,mpc8610-msi", "fsl,mpic-msi";
+   reg = <0x41600 0x80>;
+   msi-available-ranges = <0 0x100>;
+   interrupts = <
+   0xb0 0
+   0xb1 0
+   0xb2 0
+   0xb3 0
+   0xb4 0
+   0xb5 0
+   0xb6 0
+   0xb7 0>;
+   interrupt-parent = <&mpic>;
+   };
+
+
 VII - Marvell Discovery mv64[345]6x System Controller chips
 ===
 
-- 
1.5.4

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

libfdt: Seval cleanups to parameter checking (v3)

[David Gibson]

This patch makes a couple of small cleanups to parameter checking of
libfdt functions.

- In several functions which take a node offset, we use an
idiom involving fdt_next_tag() first to check that we have indeed been
given a node offset.  This patch adds a helper function
_fdt_check_node_offset() to encapsulate this usage of fdt_next_tag().

- In fdt_rw.c in several places we have the expanded version
of the RW_CHECK_HEADER() macro for no particular reason.  This patch
replaces those instances with an invocation of the macro; that's what
it's for.

- In fdt_sw.c we rename the check_header_sw() function to
sw_check_header() to match the analgous function in fdt_rw.c, and we
provide an SW_CHECK_HEADER() wrapper macro as RW_CHECK_HEADER()
functions in fdt_rw.c

Signed-off-by: David Gibson <[EMAIL PROTECTED]>

---
 libfdt/fdt.c |   17 -
 libfdt/fdt_ro.c  |   26 --
 libfdt/fdt_rw.c  |   24 
 libfdt/fdt_sw.c  |   31 +++
 libfdt/libfdt_internal.h |1 +
 5 files changed, 44 insertions(+), 55 deletions(-)


Gah!  Dammit, missed a warning in the last version.  Third time lucky?

Index: dtc/libfdt/fdt.c
===
--- dtc.orig/libfdt/fdt.c   2008-05-20 16:32:11.0 +1000
+++ dtc/libfdt/fdt.c2008-05-20 17:07:58.0 +1000
@@ -129,16 +129,23 @@ uint32_t fdt_next_tag(const void *fdt, i
return tag;
 }
 
+int _fdt_check_node_offset(const void *fdt, int offset)
+{
+   if ((offset < 0) || (offset % FDT_TAGSIZE)
+   || (fdt_next_tag(fdt, offset, &offset) != FDT_BEGIN_NODE))
+   return -FDT_ERR_BADOFFSET;
+
+   return offset;
+}
+
 int fdt_next_node(const void *fdt, int offset, int *depth)
 {
int nextoffset = 0;
uint32_t tag;
 
-   if (offset >= 0) {
-   tag = fdt_next_tag(fdt, offset, &nextoffset);
-   if (tag != FDT_BEGIN_NODE)
-   return -FDT_ERR_BADOFFSET;
-   }
+   if (offset >= 0)
+   if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
+   return nextoffset;
 
do {
offset = nextoffset;
Index: dtc/libfdt/libfdt_internal.h
===
--- dtc.orig/libfdt/libfdt_internal.h   2008-05-20 16:32:11.0 +1000
+++ dtc/libfdt/libfdt_internal.h2008-05-20 16:32:24.0 +1000
@@ -66,6 +66,7 @@
}
 
 uint32_t _fdt_next_tag(const void *fdt, int startoffset, int *nextoffset);
+int _fdt_check_node_offset(const void *fdt, int offset);
 const char *_fdt_find_string(const char *strtab, int tabsize, const char *s);
 int _fdt_node_end_offset(void *fdt, int nodeoffset);
 
Index: dtc/libfdt/fdt_ro.c
===
--- dtc.orig/libfdt/fdt_ro.c2008-05-20 16:32:11.0 +1000
+++ dtc/libfdt/fdt_ro.c 2008-05-20 17:07:58.0 +1000
@@ -157,16 +157,12 @@ int fdt_path_offset(const void *fdt, con
 
 const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
 {
-   const struct fdt_node_header *nh;
+   const struct fdt_node_header *nh = _fdt_offset_ptr(fdt, nodeoffset);
int err;
 
-   if ((err = fdt_check_header(fdt)) != 0)
-   goto fail;
-
-   err = -FDT_ERR_BADOFFSET;
-   nh = fdt_offset_ptr(fdt, nodeoffset, sizeof(*nh));
-   if (!nh || (fdt32_to_cpu(nh->tag) != FDT_BEGIN_NODE))
-   goto fail;
+   if (((err = fdt_check_header(fdt)) != 0)
+   || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
+   goto fail;
 
if (len)
*len = strlen(nh->name);
@@ -189,17 +185,11 @@ const struct fdt_property *fdt_get_prope
int offset, nextoffset;
int err;
 
-   if ((err = fdt_check_header(fdt)) != 0)
-   goto fail;
-
-   err = -FDT_ERR_BADOFFSET;
-   if (nodeoffset % FDT_TAGSIZE)
-   goto fail;
-
-   tag = fdt_next_tag(fdt, nodeoffset, &nextoffset);
-   if (tag != FDT_BEGIN_NODE)
-   goto fail;
+   if (((err = fdt_check_header(fdt)) != 0)
+   || ((err = _fdt_check_node_offset(fdt, nodeoffset)) < 0))
+   goto fail;
 
+   nextoffset = err;
do {
offset = nextoffset;
 
Index: dtc/libfdt/fdt_rw.c
===
--- dtc.orig/libfdt/fdt_rw.c2008-05-20 16:32:11.0 +1000
+++ dtc/libfdt/fdt_rw.c 2008-05-20 17:17:35.0 +1000
@@ -172,8 +172,7 @@ int fdt_add_mem_rsv(void *fdt, uint64_t 
struct fdt_reserve_entry *re;
int err;
 
-   if ((err = rw_check_header(fdt)))
-   return err;
+   RW_CHECK_HEADER(fdt);
 
re = _fdt_mem_rsv_w(fdt, fdt_num_mem_rsv(fdt));
err = _blob