Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for

2008-09-13 Thread Benjamin Herrenschmidt

 [snip]
  diff --git a/arch/powerpc/kernel/head_booke.h 
  b/arch/powerpc/kernel/head_booke.h
  index fce2df9..4f802df 100644
  --- a/arch/powerpc/kernel/head_booke.h
  +++ b/arch/powerpc/kernel/head_booke.h
  @@ -20,7 +20,9 @@
  beq 1f;  \
  mfspr   r1,SPRN_SPRG3;  /* if from user, start at top of   */\
  lwz r1,THREAD_INFO-THREAD(r1); /* this thread's kernel stack   */\
  -   addir1,r1,THREAD_SIZE;   \
  +   lis r11,[EMAIL PROTECTED];   \
  +   ori r11,r11,[EMAIL PROTECTED];  
   \
  +   add r1,r1,r11;
  \
 
 It would be nice if we could avoid the extra instruction here when the
 page sizes isn't big enough to require it.

As a matter of fact, I don't see why THREAD_SIZE should ever need that,
there is no reason to change the kernel stack size.

   1: subir1,r1,INT_FRAME_SIZE;   /* Allocate an exception frame */\
  mr  r11,r1;  \
  stw r10,_CCR(r11);  /* save various registers  */\
  @@ -112,7 +114,8 @@
  andi.   r10,r10,MSR_PR;  \
  mfspr   r11,SPRN_SPRG3; /* if from user, start at top of   */\
  lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
  -   addir11,r11,EXC_LVL_FRAME_OVERHEAD; /* allocate stack frame*/\
  +   addis   r11,r11,[EMAIL PROTECTED]; /* allocate stack frame */\
  +   addir11,r11,[EMAIL PROTECTED];  /* allocate stack frame */\
 
 And here.

Same comment. That size doesn't need to change and can remain safely
below 32k

Ben.

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


Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for

2008-09-13 Thread Benjamin Herrenschmidt
On Thu, 2008-09-11 at 09:57 -0700, prodyut hazarika wrote:

 You should mention an example of dedicated cases (eg. RAID).
 I think this help should mention that for page size 256KB, you will
 need to have a special version of binutils, since the ELF standard
 mentions page sizes only upto 64KB.

He should also put a BIG FAT warning with 256K pages. Those will -not-
work with most existing userspace. The maximum page size supported by
the current userspace ABI is 64K as this is the alignment requirement of
our toolchain for the various program sections.

(Note that uClibc last I looked was also still broken with 4K pages but
that shouldn't be a big deal to fix).

Ben.


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


Re: [PATCH v4 1/4] powerpc: Introduce local (non-broadcast) forms of tlb invalidates

2008-09-13 Thread Benjamin Herrenschmidt

  static inline void flush_tlb_range(struct vm_area_struct *vma,
  unsigned long start, unsigned long end)
  {
 - _tlbia();
 + _tlbil_all();
  }

Why not the _pid() variant here ?

 +/*
 + * Flush MMU TLB for a particular process id, but only on the local processor
 + * (no broadcast)
 + */
 +_GLOBAL(_tlbil_pid)
 + li  r3,(MMUCSR0_TLBFI)@l
 + mtspr   SPRN_MMUCSR0, r3
 +1:
 + mfspr   r3,SPRN_MMUCSR0
 + andi.   r3,r3,[EMAIL PROTECTED]
 + bne 1b
 + blr

This will do a full inval of the TLB right ? Might be worth mentioning
this implementation limitation in a comment..

Cheers,
Ben.


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


demuxing irqs

2008-09-13 Thread Jon Smirl
Can someone point me at a simple example of how to demux irqs using
the powerpc irq functions? I have eight devices on a single irq and I
want to turn them into virtual irqs.

-- 
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/2] ehea: fix phyp debugging typo

2008-09-13 Thread Jeff Garzik

Sebastien Dugue wrote:

  Fix typo in ehea_h_query_ehea() which prevents building when DEBUG is on.

Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
---
 drivers/net/ehea/ehea_phyp.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c
index 156eb63..2a33a61 100644
--- a/drivers/net/ehea/ehea_phyp.c
+++ b/drivers/net/ehea/ehea_phyp.c
@@ -535,7 +535,7 @@ u64 ehea_h_query_ehea(const u64 adapter_handle, void 
*cb_addr)
   cb_logaddr,  /* R5 */
   0, 0, 0, 0, 0);  /* R6-R10 */
 #ifdef DEBUG
-   ehea_dmp(cb_addr, sizeof(struct hcp_query_ehea), hcp_query_ehea);
+   ehea_dump(cb_addr, sizeof(struct hcp_query_ehea), hcp_query_ehea);
 #endif
return hret;


applied


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


Re: [PATCH 2/2] ehea: fix mutex and spinlock use

2008-09-13 Thread Jeff Garzik

Sebastien Dugue wrote:

  Looks like to me that the ehea_fw_handles.lock mutex and the
ehea_bcmc_regs.lock spinlock are taken much longer than necessary and could
as well be pushed inside the functions that need them
(ehea_update_firmware_handles() and ehea_update_bcmc_registrations())
rather than at each callsite.

Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
---
 drivers/net/ehea/ehea_main.c |   26 --
 1 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index b70c531..c765ec6 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -219,9 +219,11 @@ static void ehea_update_firmware_handles(void)
}
 
 out_update:

+   mutex_lock(ehea_fw_handles.lock);
kfree(ehea_fw_handles.arr);
ehea_fw_handles.arr = arr;
ehea_fw_handles.num_entries = i;
+   mutex_unlock(ehea_fw_handles.lock);
 }
 
 static void ehea_update_bcmc_registrations(void)

@@ -293,9 +295,11 @@ static void ehea_update_bcmc_registrations(void)
}
 
 out_update:

+   spin_lock(ehea_bcmc_regs.lock);
kfree(ehea_bcmc_regs.arr);
ehea_bcmc_regs.arr = arr;
ehea_bcmc_regs.num_entries = i;
+   spin_unlock(ehea_bcmc_regs.lock);
 }
 
 static struct net_device_stats *ehea_get_stats(struct net_device *dev)

@@ -1770,8 +1774,6 @@ static int ehea_set_mac_addr(struct net_device *dev, void 
*sa)
 
 	memcpy(dev-dev_addr, mac_addr-sa_data, dev-addr_len);
 
-	spin_lock(ehea_bcmc_regs.lock);

-
/* Deregister old MAC in pHYP */
if (port-state == EHEA_PORT_UP) {
ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
@@ -1792,7 +1794,6 @@ static int ehea_set_mac_addr(struct net_device *dev, void 
*sa)
 
 out_upregs:

ehea_update_bcmc_registrations();
-   spin_unlock(ehea_bcmc_regs.lock);
 out_free:
kfree(cb0);
 out:
@@ -1954,8 +1955,6 @@ static void ehea_set_multicast_list(struct net_device 
*dev)
}
ehea_promiscuous(dev, 0);
 
-	spin_lock(ehea_bcmc_regs.lock);

-
if (dev-flags  IFF_ALLMULTI) {
ehea_allmulti(dev, 1);
goto out;
@@ -1985,7 +1984,6 @@ static void ehea_set_multicast_list(struct net_device 
*dev)
}
 out:
ehea_update_bcmc_registrations();
-   spin_unlock(ehea_bcmc_regs.lock);
return;
 }
 
@@ -2466,8 +2464,6 @@ static int ehea_up(struct net_device *dev)

if (port-state == EHEA_PORT_UP)
return 0;
 
-	mutex_lock(ehea_fw_handles.lock);

-
ret = ehea_port_res_setup(port, port-num_def_qps,
  port-num_add_tx_qps);
if (ret) {
@@ -2504,8 +2500,6 @@ static int ehea_up(struct net_device *dev)
}
}
 
-	spin_lock(ehea_bcmc_regs.lock);

-
ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
if (ret) {
ret = -EIO;
@@ -2527,10 +2521,8 @@ out:
ehea_info(Failed starting %s. ret=%i, dev-name, ret);
 
 	ehea_update_bcmc_registrations();

-   spin_unlock(ehea_bcmc_regs.lock);
 
 	ehea_update_firmware_handles();

-   mutex_unlock(ehea_fw_handles.lock);
 
 	return ret;

 }
@@ -2580,9 +2572,6 @@ static int ehea_down(struct net_device *dev)
if (port-state == EHEA_PORT_DOWN)
return 0;
 
-	mutex_lock(ehea_fw_handles.lock);

-
-   spin_lock(ehea_bcmc_regs.lock);
ehea_drop_multicast_list(dev);
ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
 
@@ -2591,7 +2580,6 @@ static int ehea_down(struct net_device *dev)

port-state = EHEA_PORT_DOWN;
 
 	ehea_update_bcmc_registrations();

-   spin_unlock(ehea_bcmc_regs.lock);
 
 	ret = ehea_clean_all_portres(port);

if (ret)
@@ -2599,7 +2587,6 @@ static int ehea_down(struct net_device *dev)
  dev-name, ret);
 
 	ehea_update_firmware_handles();

-   mutex_unlock(ehea_fw_handles.lock);
 
 	return ret;

 }
@@ -3378,7 +3365,6 @@ static int __devinit ehea_probe_adapter(struct of_device 
*dev,
ehea_error(Invalid ibmebus device probed);
return -EINVAL;
}
-   mutex_lock(ehea_fw_handles.lock);
 
 	adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);

if (!adapter) {
@@ -3462,7 +3448,6 @@ out_free_ad:
 
 out:

ehea_update_firmware_handles();
-   mutex_unlock(ehea_fw_handles.lock);
return ret;
 }
 
@@ -3481,8 +3466,6 @@ static int __devexit ehea_remove(struct of_device *dev)
 
 	flush_scheduled_work();
 
-	mutex_lock(ehea_fw_handles.lock);

-
ibmebus_free_irq(adapter-neq-attr.ist1, adapter);
tasklet_kill(adapter-neq_tasklet);


applied


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


Re: [PATCH 1/3] ibm_newemac: Allow the no flow control EMAC feature to work

2008-09-13 Thread Jeff Garzik

Josh Boyer wrote:

Some PowerPC 40x chips have errata that force us not to use the integrated
flow control.  We have the feature defined, but it currently can't be used
because it is never added to EMAC_FTRS_POSSIBLE.

This adds a Kconfig option for affected platforms to select and puts the
feature in the EMAC_FTRS_POSSIBLE list.  This is set for PowerPC 405EZ
platforms as well.

Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
 drivers/net/ibm_newemac/Kconfig |4 
 drivers/net/ibm_newemac/core.c  |2 ++
 drivers/net/ibm_newemac/core.h  |3 +++
 3 files changed, 9 insertions(+), 0 deletions(-)


ACK patches 1-3


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


Re: [PATCH] ibm_newemac: Add support for GPCS, SGMII and M88E1112 PHY

2008-09-13 Thread Jeff Garzik

Victor Gallardo wrote:

This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.

Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
 drivers/net/ibm_newemac/core.c |   40 +++
 drivers/net/ibm_newemac/core.h |3 +
 drivers/net/ibm_newemac/phy.c  |   84 
 drivers/net/ibm_newemac/phy.h  |2 +
 4 files changed, 120 insertions(+), 9 deletions(-)


ACK, please coordinate with the driver maintainer to get this merged


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


Re: [PATCH 1/2] ehea: Fix DLPAR memory handling

2008-09-13 Thread Jeff Garzik

Hannes Hering wrote:

The ehea busmap must be allocated only once in the first of many calls of the
ehea_create_busmap_callback.

Signed-off-by: Hannes Hering [EMAIL PROTECTED]
---

diff -Nurp -X dontdiff linux-2.6.27-rc5/drivers/net/ehea/ehea_qmr.c 
patched_kernel/drivers/net/ehea/ehea_qmr.c
--- linux-2.6.27-rc5/drivers/net/ehea/ehea_qmr.c2008-08-29 
00:52:02.0 +0200
+++ patched_kernel/drivers/net/ehea/ehea_qmr.c  2008-09-05 15:31:30.0 
+0200
@@ -595,7 +595,8 @@ static int ehea_create_busmap_callback(u
end_section = start_section + ((nr_pages * PAGE_SIZE) / EHEA_SECTSIZE);
mr_len = *(unsigned long *)arg;
 
-	ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);

+   if (!ehea_bmap)
+   ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);
if (!ehea_bmap)
return -ENOMEM;


applied


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


Re: demuxing irqs

2008-09-13 Thread Roland Dreier
  Can someone point me at a simple example of how to demux irqs using
  the powerpc irq functions? I have eight devices on a single irq and I
  want to turn them into virtual irqs.

Sorry about the previous reply.

Anyway, what are you going to demux based on?  Do you have some other
signal you can read in the interrupt dispatch code that tells you which
device raised the interrupt?  What happens if two devices raise an
interrupt at the same time?

If you just have 8 interrupt lines wire-ORed together then you probably
just need to register your interrupt handlers with IRQF_SHARED and run 8
interrupt handlers on an interrupt.

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


Re: demuxing irqs

2008-09-13 Thread Jon Smirl
On Sat, Sep 13, 2008 at 6:41 PM, Roland Dreier [EMAIL PROTECTED] wrote:
   Can someone point me at a simple example of how to demux irqs using
   the powerpc irq functions? I have eight devices on a single irq and I
   want to turn them into virtual irqs.

 Sorry about the previous reply.

 Anyway, what are you going to demux based on?  Do you have some other
 signal you can read in the interrupt dispatch code that tells you which
 device raised the interrupt?  What happens if two devices raise an
 interrupt at the same time?

 If you just have 8 interrupt lines wire-ORed together then you probably
 just need to register your interrupt handlers with IRQF_SHARED and run 8
 interrupt handlers on an interrupt.

The muxed interrupts are inside a SOC CPU.  For example eight GPIOs
can each individually be enabled to trigger hardware interrupt 7. When
I get hw interrupt 7 i want to demux it into 8 virtual interrupts.
There are eight bit registers for individually acking, enabling, etc
each of the eight multiplexed interrupts. With eight virutal
interrupts each user can register a different handler and isn't aware
the muxing is going on.

-- 
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: demuxing irqs

2008-09-13 Thread Roland Dreier
  The muxed interrupts are inside a SOC CPU.  For example eight GPIOs
  can each individually be enabled to trigger hardware interrupt 7. When
  I get hw interrupt 7 i want to demux it into 8 virtual interrupts.
  There are eight bit registers for individually acking, enabling, etc
  each of the eight multiplexed interrupts. With eight virutal
  interrupts each user can register a different handler and isn't aware
  the muxing is going on.

I see... well, assuming all the issues around handling multiple
simultaneous (or overlapping) interrupts are OK, you could look at how
arch/powerpc/sysdev/uic.c handles the cascaded interrupt controllers for
4xx SoCs.  The idea of that code is that you get an interrupt, and look
look at interrupt cause register 0, and see interrupt X, and to handle
interrupt X you read interrupt cause register 1 to see which the real
interrupt is.  And you might see interrupt Y, which means to go onto
interrupt cause register 2.

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


Re: [PATCH 2/2] ehea: Enable DLPAR memory remove

2008-09-13 Thread Jeff Garzik

Hannes Hering wrote:

This patch adds the capability flag to the capability list for dynamic LPAR
memory remove to enable this feature.

Signed-off-by: Hannes Hering [EMAIL PROTECTED]
---

diff -Nurp -X dontdiff linux-2.6.27-rc5/drivers/net/ehea/ehea.h 
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.27-rc5/drivers/net/ehea/ehea.h2008-08-29 00:52:02.0 
+0200
+++ patched_kernel/drivers/net/ehea/ehea.h  2008-09-05 15:33:12.0 
+0200
@@ -40,13 +40,13 @@
 #include asm/io.h
 
 #define DRV_NAME	ehea

-#define DRV_VERSIONEHEA_0092
+#define DRV_VERSIONEHEA_0093
 
 /* eHEA capability flags */

 #define DLPAR_PORT_ADD_REM 1
 #define DLPAR_MEM_ADD  2
 #define DLPAR_MEM_REM  4
-#define EHEA_CAPABILITIES  (DLPAR_PORT_ADD_REM | DLPAR_MEM_ADD)
+#define EHEA_CAPABILITIES  (DLPAR_PORT_ADD_REM | DLPAR_MEM_ADD | DLPAR_MEM_REM)


applied


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


Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for

2008-09-13 Thread Josh Boyer
On Sat, 13 Sep 2008 10:49:13 -0700
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 On Thu, 2008-09-11 at 09:57 -0700, prodyut hazarika wrote:
 
  You should mention an example of dedicated cases (eg. RAID).
  I think this help should mention that for page size 256KB, you will
  need to have a special version of binutils, since the ELF standard
  mentions page sizes only upto 64KB.
 
 He should also put a BIG FAT warning with 256K pages. Those will -not-
 work with most existing userspace. The maximum page size supported by
 the current userspace ABI is 64K as this is the alignment requirement of
 our toolchain for the various program sections.

I think that's been noted like 5 times now :)

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