Re: [PATCH] pata_of_platform: fix no irq handling

[Tejun Heo]

Anton Vorontsov wrote:
 When no irq specified the pata_of_platform fills the irq_res with -1,
 which is wrong to do for two reasons:
 
 1. By definition, 'no irq' should be IRQ 0, not some negative integer;
 2. pata_platform checks for irq_res.start  0, but since irq_res.start
is unsigned type, the check will be true for `-1'.
 
 Reported-by: Steven A. Falco [EMAIL PROTECTED]
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]

applied to #tj-upstream (will soon be sent upstream)

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

Re: [PATCH RFC] pata_platform: add 8 bit data io support

[Tejun Heo]

Hello,

Wang Jian wrote:
 +static void pata_platform_postreset(struct ata_link *link, unsigned int 
 *classes)
 +{
 + struct ata_port *ap = link-ap;
 + struct ata_device *dev;
 + u8 select = ATA_DEVICE_OBS;
 +
 + /* Call default callback first */
 + ata_sff_postreset(link, classes);
 +
 + if (!(ap-flags  ATA_FLAG_8BIT_DATA))
 + return;
 +
 + /* Set 8-bit mode. We know we can do that */
 + ata_link_for_each_dev(dev, link) {
 + if (dev-devno)
 + select |= ATA_DEV1;
 +
 + iowrite8(SETFEATURES_8BIT_ON, ap-ioaddr.feature_addr);
 + iowrite8(select, ap-ioaddr.device_addr);
 + iowrite8(ATA_CMD_SET_FEATURES, ap-ioaddr.command_addr);

Aieee... Please don't do this.  I think it best belongs to
ata_dev_configure() or -dev_config() if you wanna put it in low level
driver.

 @@ -106,7 +159,8 @@ int __devinit __pata_platform_probe(struct device *dev,
   struct resource *ctl_res,
   struct resource *irq_res,
   unsigned int ioport_shift,
 - int __pio_mask)
 + int __pio_mask,
 + unsigned int data_width)
  {
   struct ata_host *host;
   struct ata_port *ap;
 @@ -140,6 +194,9 @@ int __devinit __pata_platform_probe(struct device *dev,
   ap-pio_mask = __pio_mask;
   ap-flags |= ATA_FLAG_SLAVE_POSS;
  
 + if (data_width == ATA_DATA_WIDTH_8BIT)
 + ap-flags |= ATA_FLAG_8BIT_DATA;

It's strange to define ATA_DATA_WIDTH_* constants in ata.h and only
use it in ata_platform.

Overall, I think the bulk of the 8bit PIO implementation should go
into the libata core layer and transfer width should be property of
struct ata_device - probably right above or below pio/dma_mode and
xfer_mode/shift fields.

Thanks.

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

Re: [RFC 0/6] Proposal for a Generic PWM Device API

[Geert Uytterhoeven]

On Fri, 10 Oct 2008, Bill Gatliff wrote:
 Paul Mundt wrote:
  Your first version should have been to linux-embedded and linux-kernel.
  If you want to alert the linux-arm-kernel people to the fact that a
  discussion is going on in this area, then feel free to post a
  notification to the list with references to the relevant lists. There is
  no reason why public lists should have to dig in to private archives to
  try and play catch up.
 
 I'm not asking anyone to do that.  Just review the patches posted to the list 
 of
 your choice.  Or, don't review them.  Up to you.
 
 My next update will be the one where I formally request a review with intent 
 to
 merge into mainline.  That one will go to linux-embedded only, with
 notifications sent elsewhere as indicated per community request.  I don't 
 have a
 problem with that.  I can't change history, but I'm doing what you are asking 
 of
 me otherwise.

For a formally request for review, you do want to CC lkml.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:+32 (0)2 700 8453
Fax:  +32 (0)2 700 8622
E-mail:   [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC 1/3] hvc_console: rework setup to replace irq functions with callbacks

[Christian Borntraeger]

Am Montag, 13. Oktober 2008 schrieb Benjamin Herrenschmidt:
   ... key      at: [c0939018] proc_subdir_lock+0x18/0x38
  ... acquired at:
    [c00832e8] .__lock_acquire+0x814/0x8ec
    [c0083464] .lock_acquire+0xa4/0xec
    [c04e713c] ._spin_lock+0x44/0xa0
    [c0139144] .xlate_proc_name+0x50/0xf8
    [c01392f4] .remove_proc_entry+0x44/0x298
    [c00a1e74] .unregister_handler_proc+0x40/0x58
    [c009fc58] .free_irq+0x124/0x18c
    [c02e6634] .notifier_del_irq+0x28/0x48
    [c02e5ddc] .hvc_close+0xa0/0x110
    [c02cc328] .release_dev+0x244/0x580
    [c02cc688] .tty_release+0x24/0x44
    [c00e5384] .__fput+0xf8/0x1dc
    [c00e1bec] .filp_close+0xb4/0xdc
    [c00e33a4] .sys_close+0xac/0x100
    [c00084d4] syscall_exit+0x0/0x40


Hmmm. 
Can you try if this patch fixes the lockdep trace?

This would be analog to
commit b1b135c8d619cb2c7045d6ee4e48375882518bb5
Author: Christian Borntraeger [EMAIL PROTECTED]
Date:   Thu Aug 7 09:18:34 2008 +0200

fix spinlock recursion in hvc_console

commit 611e097d7707741a336a0677d9d69bec40f29f3d
Author: Christian Borntraeger [EMAIL PROTECTED]
hvc_console: rework setup to replace irq functions with callbacks
introduced a spinlock recursion problem.


Signed-off-by: Christian Borntraeger[EMAIL PROTECTED]
---
 drivers/char/hvc_console.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

Index: linux-2.6/drivers/char/hvc_console.c
===
--- linux-2.6.orig/drivers/char/hvc_console.c
+++ linux-2.6/drivers/char/hvc_console.c
@@ -367,13 +367,13 @@ static void hvc_close(struct tty_struct 
spin_lock_irqsave(hp-lock, flags);
 
if (--hp-count == 0) {
-   if (hp-ops-notifier_del)
-   hp-ops-notifier_del(hp, hp-data);
-
/* We are done with the tty pointer now. */
hp-tty = NULL;
spin_unlock_irqrestore(hp-lock, flags);
 
+   if (hp-ops-notifier_del)
+   hp-ops-notifier_del(hp, hp-data);
+
/*
 * Chain calls chars_in_buffer() and returns immediately if
 * there is no buffered data otherwise sleeps on a wait queue
@@ -416,11 +416,11 @@ static void hvc_hangup(struct tty_struct
hp-n_outbuf = 0;
hp-tty = NULL;
 
+   spin_unlock_irqrestore(hp-lock, flags);
+
if (hp-ops-notifier_del)
hp-ops-notifier_del(hp, hp-data);
 
-   spin_unlock_irqrestore(hp-lock, flags);
-
while(temp_open_count) {
--temp_open_count;
kref_put(hp-kref, destroy_hvc_struct);

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

Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64

[Geert Uytterhoeven]

On Sun, 12 Oct 2008, Aaron Tokhy wrote:
 I recently built 2.6.27 with these patches on my PS3.
 
 http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-patches/ps3-wip/ps3vram-driver.patch
 http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-patches/ps3-wip/ps3vram-proc-fs.patch
 
 These patches enable the 'ps3vram' module, which creates a MTD node

 Now I am not sure if the patch is the issue.  None of the functions in

No, we've seen similar things happen without ps3vram, too.

 BUG: soft lockup - CPU#0 stuck for 61s! [top:22788]
 Modules linked in: evdev hci_usb usbhid bluetooth usb_storage snd_ps3
 ehci_hcd snd_pcm ohci_hcd snd_page_alloc snd_timer usbcore snd sg
 ps3_lpm soundcore
 irq event stamp: 5018780
 hardirqs last  enabled at (5018779): [c0007c1c] restore+0x1c/0xe4
 hardirqs last disabled at (5018780): [c0003600] 
 decrementer_common+0x100/0x180
 softirqs last  enabled at (5018778): [c0020928] 
 .call_do_softirq+0x14/0x24
 softirqs last disabled at (5018773): [c0020928] 
 .call_do_softirq+0x14/0x24
 NIP: c0084110 LR: c0084468 CTR: c03181d0
 REGS: c6f37280 TRAP: 0901   Not tainted  (2.6.27)
 MSR: 80008032 EE,IR,DR  CR: 42004424  XER: 
 TASK = c798[22788] 'top' THREAD: c6f34000 CPU: 0
 GPR00: 0001 c6f37500 c05543d0 c6f37570
 GPR04:  c008427c 0001 
 GPR08: 0830 0001  c0b96874
 GPR12: 80008032 c0586300
 NIP [c0084110] .csd_flag_wait+0x14/0x1c
 LR [c0084468] .smp_call_function_single+0x13c/0x164
 Call Trace:
 [c6f37500] [c0084468] .smp_call_function_single+0x13c/0x164 
 (unreliable)

smp_call_function_single() causes an IPI to be sent to the other CPU thread.
However, the IPI never seems to arrive at the other CPU thread, causing the
soft lockup message to be printed on the console.

If this happens when the BKL is held before sending the IPI, the system will
deadlock when the other CPU thread tries to acquire the BKL. In that
unfortunate case, you won't see any message on the console of a retail PS3,
though.

So far we do not know what's the exact cause of the IPI not arriving, hence
suggestions are welcome.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:+32 (0)2 700 8453
Fax:  +32 (0)2 700 8622
E-mail:   [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH RFC] pata_platform: add 8 bit data io support

[Wang Jian]

Tejun Heo wrote:

Hello,

Wang Jian wrote:

+static void pata_platform_postreset(struct ata_link *link, unsigned int 
*classes)
+{
+   struct ata_port *ap = link-ap;
+   struct ata_device *dev;
+   u8 select = ATA_DEVICE_OBS;
+
+   /* Call default callback first */
+   ata_sff_postreset(link, classes);
+
+   if (!(ap-flags  ATA_FLAG_8BIT_DATA))
+   return;
+
+   /* Set 8-bit mode. We know we can do that */
+   ata_link_for_each_dev(dev, link) {
+   if (dev-devno)
+   select |= ATA_DEV1;
+
+   iowrite8(SETFEATURES_8BIT_ON, ap-ioaddr.feature_addr);
+   iowrite8(select, ap-ioaddr.device_addr);
+   iowrite8(ATA_CMD_SET_FEATURES, ap-ioaddr.command_addr);


Aieee... Please don't do this.  I think it best belongs to
ata_dev_configure() or -dev_config() if you wanna put it in low level
driver.



Good.

I remember the spec states that this setfeature command should be issued
every time reset is issued. This is just a quick and safe hack.

I will look into libata deeper and figure out how to do it better per your
suggestion.


@@ -106,7 +159,8 @@ int __devinit __pata_platform_probe(struct device *dev,
struct resource *ctl_res,
struct resource *irq_res,
unsigned int ioport_shift,
-   int __pio_mask)
+   int __pio_mask,
+   unsigned int data_width)
 {
struct ata_host *host;
struct ata_port *ap;
@@ -140,6 +194,9 @@ int __devinit __pata_platform_probe(struct device *dev,
ap-pio_mask = __pio_mask;
ap-flags |= ATA_FLAG_SLAVE_POSS;
 
+	if (data_width == ATA_DATA_WIDTH_8BIT)

+   ap-flags |= ATA_FLAG_8BIT_DATA;


It's strange to define ATA_DATA_WIDTH_* constants in ata.h and only
use it in ata_platform.


I have expressed in another reply that the best place the code belongs to
should be decided first. The usage of flags looks ugly too :)



Overall, I think the bulk of the 8bit PIO implementation should go
into the libata core layer and transfer width should be property of
struct ata_device - probably right above or below pio/dma_mode and
xfer_mode/shift fields.



Yes, I agree it'd better go into libata core layer. But for transfer
width, I think it is not belongs to ata_device. It's about how ata
controller wired for data line. (In my case, it is how CF card wired).
Am I wrong?


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

Re: [PATCH RFC] pata_platform: add 8 bit data io support

[Tejun Heo]

Wang Jian wrote:
 Tejun Heo wrote:
 Hello,

 Wang Jian wrote:
 +static void pata_platform_postreset(struct ata_link *link, unsigned
 int *classes)
 +{
 +struct ata_port *ap = link-ap;
 +struct ata_device *dev;
 +u8 select = ATA_DEVICE_OBS;
 +
 +/* Call default callback first */
 +ata_sff_postreset(link, classes);
 +
 +if (!(ap-flags  ATA_FLAG_8BIT_DATA))
 +return;
 +
 +/* Set 8-bit mode. We know we can do that */
 +ata_link_for_each_dev(dev, link) {
 +if (dev-devno)
 +select |= ATA_DEV1;
 +
 +iowrite8(SETFEATURES_8BIT_ON, ap-ioaddr.feature_addr);
 +iowrite8(select, ap-ioaddr.device_addr);
 +iowrite8(ATA_CMD_SET_FEATURES, ap-ioaddr.command_addr);

 Aieee... Please don't do this.  I think it best belongs to
 ata_dev_configure() or -dev_config() if you wanna put it in low level
 driver.

 
 Good.
 
 I remember the spec states that this setfeature command should be issued
 every time reset is issued. This is just a quick and safe hack.
 
 I will look into libata deeper and figure out how to do it better per your
 suggestion.

Yeap, ata_dev_configure() exactly is the place you're looking for.
It's reponsible for reprogramming the device after it has been reset.

 +if (data_width == ATA_DATA_WIDTH_8BIT)
 +ap-flags |= ATA_FLAG_8BIT_DATA;

 It's strange to define ATA_DATA_WIDTH_* constants in ata.h and only
 use it in ata_platform.
 
 I have expressed in another reply that the best place the code belongs to
 should be decided first. The usage of flags looks ugly too :)

:-)

 Overall, I think the bulk of the 8bit PIO implementation should go
 into the libata core layer and transfer width should be property of
 struct ata_device - probably right above or below pio/dma_mode and
 xfer_mode/shift fields.

 
 Yes, I agree it'd better go into libata core layer. But for transfer
 width, I think it is not belongs to ata_device. It's about how ata
 controller wired for data line. (In my case, it is how CF card wired).
 Am I wrong?

Well, yes, it primarily depends on the controller but ISTR cases where
PIO issues resolved by turning off 32bit PIO (dunno why that is, some
timing issue?) and for things like that to work, the setting should be
per-device.  I'm not too sure about this.  Cc'ing Alan.  He should
know much better than I do.

Alan, where does 8/16/32-bit PIO transfer belong?  Host, port or
device?

Thanks.

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

Re: [RFC 1/3] hvc_console: rework setup to replace irq functions with callbacks

[Benjamin Herrenschmidt]

   if (--hp-count == 0) {
 - if (hp-ops-notifier_del)
 - hp-ops-notifier_del(hp, hp-data);
 -
   /* We are done with the tty pointer now. */
   hp-tty = NULL;
   spin_unlock_irqrestore(hp-lock, flags);
  
 + if (hp-ops-notifier_del)
 + hp-ops-notifier_del(hp, hp-data);
 +

I will try. Of course the risk here is that the interrupt happens
after we set hp-tty to NULL, so we probably need to check within the
interrupt handler for a NULL tty. I haven't checked if that's the case
(I'm not in front of the code right now).

Ben.


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

RE: [PATCH] remove bogus ppc_select syscall

[Sadashiiv, Halesh]

-Original Message-
From: Paul Mackerras [mailto:[EMAIL PROTECTED]
Sent: Friday, October 10, 2008 1:14 PM
To: [EMAIL PROTECTED]
Cc: Arnd Bergmann; [EMAIL PROTECTED]; Sadashiiv, Halesh;
linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] remove bogus ppc_select syscall

Benjamin Herrenschmidt writes:

 On Wed, 2008-09-24 at 08:39 +0200, Arnd Bergmann wrote:
  The ppc_select function was introduced in linux-2.3.48 in order to
support
  code confusing the legacy select() calling convention with the
standard
one.
  Even 11 years ago, all correctly built code should not have done
this
and
  could have easily been phased out. Nothing that was compiled later
should
  actually try to use the old_select interface, and it would have
been
broken
  already on all ppc64 kernels with the syscall emulation layer.
 
  This patch brings the 32 bit compat ABI and the native 32 bit ABI
for
  powerpc into a consistent state, by removing support for both the
  old_select system call number and the handler for it.

  .../...

 It's me or the patch is whitespaces damaged ?

Please don't apply Arnd's patch.  As I said, all we need is this
one-line change in arch/powerpc/include/asm/systbl.h:

-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)


I have tested the testcase that I have provided at the time of reporting
this issue. But it didn't work as expected with the above patch you
provided.
(Failed to return EINVAL on negative value of n to select())

Please let me know about this. I have tested on PPC32 2.6.23.

-Halesh


Paul.



---
This email is confidential and intended only for the use of the individual or 
entity named above and may contain information that is privileged. If you are 
not the intended recipient, you are notified that any dissemination, 
distribution or copying of this email is strictly prohibited. If you have 
received this email in error, please notify us immediately by return email or 
telephone and destroy the original message. - This mail is sent via Sony Asia 
Pacific Mail Gateway.
---

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

[PATCH v2] powerpc: FPGA support for GE Fanuc SBC610

[Martyn Welch]

Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).

This patch adds support for the registers held in the devices main FPGA,
exposing extra information about the revision of the board through cpuinfo.

Signed-off-by: Martyn Welch [EMAIL PROTECTED]
---

Kumar: Sorry for the delay, I was on holiday.

This patch has been reworked to apply on top of Becky's show_cpuinfo patch
(0161dca52d950676d727336cef1441ea2bcfba98)

 arch/powerpc/boot/dts/gef_sbc610.dts |4 +++
 arch/powerpc/platforms/86xx/gef_sbc610.c |   39 ++
 2 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts 
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 771a776..6ed6083 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -84,6 +84,10 @@
  6 0 0xfd00 0x0080 // IO FPGA (8-bit)
  7 0 0xfd80 0x0080;   // IO FPGA (32-bit)
 
+   [EMAIL PROTECTED],0 {
+   compatible = gef,fpga-regs;
+   reg = 0x4 0x0 0x40;
+   };
gef_pic: [EMAIL PROTECTED],4000 {
#interrupt-cells = 1;
interrupt-controller;
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c 
b/arch/powerpc/platforms/86xx/gef_sbc610.c
index 3873c20..64162b6 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc610.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -73,6 +73,7 @@ static void __init gef_sbc610_init_irq(void)
 
 static void __init gef_sbc610_setup_arch(void)
 {
+   struct device_node *regs;
 #ifdef CONFIG_PCI
struct device_node *np;
 
@@ -86,8 +87,42 @@ static void __init gef_sbc610_setup_arch(void)
 #ifdef CONFIG_SMP
mpc86xx_smp_init();
 #endif
+
+   /* Remap basic board registers */
+   regs = of_find_compatible_node(NULL, NULL, gef,fpga-regs);
+   if (regs) {
+   sbc610_regs = of_iomap(regs, 0);
+   if (sbc610_regs == NULL)
+   printk(KERN_WARNING Unable to map board registers\n);
+   }
+}
+
+/* Return the PCB revision */
+static unsigned int gef_sbc610_get_pcb_rev(void)
+{
+   unsigned int reg;
+
+   reg = ioread32(sbc610_regs);
+   return (reg  8)  0xff;
+}
+
+/* Return the board (software) revision */
+static unsigned int gef_sbc610_get_board_rev(void)
+{
+   unsigned int reg;
+
+   reg = ioread32(sbc610_regs);
+   return (reg  16)  0xff;
 }
 
+/* Return the FPGA revision */
+static unsigned int gef_sbc610_get_fpga_rev(void)
+{
+   unsigned int reg;
+
+   reg = ioread32(sbc610_regs);
+   return (reg  24)  0xf;
+}
 
 static void gef_sbc610_show_cpuinfo(struct seq_file *m)
 {
@@ -96,6 +131,10 @@ static void gef_sbc610_show_cpuinfo(struct seq_file *m)
 
seq_printf(m, Vendor\t\t: GE Fanuc Intelligent Platforms\n);
 
+   seq_printf(m, Revision\t: %u%c\n, gef_sbc610_get_pcb_rev(),
+   ('A' + gef_sbc610_get_board_rev() - 1));
+   seq_printf(m, FPGA Revision\t: %u\n, gef_sbc610_get_fpga_rev());
+
seq_printf(m, SVR\t\t: 0x%x\n, svid);
seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
 }

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

RE: [PATCH] remove bogus ppc_select syscall

[Sadashiiv, Halesh]

Please don't apply Arnd's patch.  As I said, all we need is this
one-line change in arch/powerpc/include/asm/systbl.h:

-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)


I have tested the testcase that I have provided at the time of
reporting
this issue. But it didn't work as expected with the above patch you
provided.
(Failed to return EINVAL on negative value of n to select())

Please let me know about this. I have tested on PPC32 2.6.23.

Hi all,

Apologies, Test failed because of small typo in test case, The above
patch provided has been tested on PPC32. Works fine and as expected.

Reported-by: Halesh Sadashiv [EMAIL PROTECTED]
Tested-by: Halesh Sadashiv [EMAIL PROTECTED]

Thanks,
Halesh



-Halesh


Paul.



---
This email is confidential and intended only for the use of the individual or 
entity named above and may contain information that is privileged. If you are 
not the intended recipient, you are notified that any dissemination, 
distribution or copying of this email is strictly prohibited. If you have 
received this email in error, please notify us immediately by return email or 
telephone and destroy the original message. - This mail is sent via Sony Asia 
Pacific Mail Gateway.
---

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

Re: [RFC 1/3] hvc_console: rework setup to replace irq functions with callbacks

[Benjamin Herrenschmidt]

On Mon, 2008-10-13 at 10:47 +0200, Christian Borntraeger wrote:
  I will try. Of course the risk here is that the interrupt happens
  after we set hp-tty to NULL, so we probably need to check within the
  interrupt handler for a NULL tty. I haven't checked if that's the case
  (I'm not in front of the code right now).
 
 Even the old code (without my patch) was setting hp-tty to NULL before doing 
 the irq_free, so that should be ok.

Yup, just checked, it should be allright as long as it's cleared with
the spinlock held, which seems to be the case with your patch. I'll test
your fixup patch tomorrow to see if it clears the lockdep error.

Thanks !

Ben.


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

Re: Floating inputs on unused GPIO pins

[Geert Uytterhoeven]

On Mon, 13 Oct 2008, Laurent Pinchart wrote:
 our hardware engineer asked me to make sure all unused GPIO pins are 
 configured as outputs to avoid floating inputs. He got theory on his side 
 (floating inputs can lead to higher current consumption, metastability or 
 even permanent damage), but I'd like to ask the list for practical feedback.
 
 I haven't been able to find any mention of floating input protection in the 
 MPC8248 documents. Has anyone here experienced issues with floating inputs in 
 real-life designs ? Do you setup your board with all unused GPIO pins 
 configured as outputs ?

I always thought configurable GPIO pins default to _inputs_ after power-on, so
it's safe to tie them to VCC through a pull-up resistor?
For CMOS, you can tie them to VDD or GND without a resistor.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:+32 (0)2 700 8453
Fax:  +32 (0)2 700 8622
E-mail:   [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC 1/3] hvc_console: rework setup to replace irq functions with callbacks

[Christian Borntraeger]

Am Montag, 13. Oktober 2008 schrieb Benjamin Herrenschmidt:
 
  if (--hp-count == 0) {
  -   if (hp-ops-notifier_del)
  -   hp-ops-notifier_del(hp, hp-data);
  -
  /* We are done with the tty pointer now. */
  hp-tty = NULL;
  spin_unlock_irqrestore(hp-lock, flags);
   
  +   if (hp-ops-notifier_del)
  +   hp-ops-notifier_del(hp, hp-data);
  +
 
 I will try. Of course the risk here is that the interrupt happens
 after we set hp-tty to NULL, so we probably need to check within the
 interrupt handler for a NULL tty. I haven't checked if that's the case
 (I'm not in front of the code right now).

Even the old code (without my patch) was setting hp-tty to NULL before doing 
the irq_free, so that should be ok.

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

Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selects CONFIG_INTEL_IOATDMA=y

[Brice Goglin]

Adrian Bunk wrote:
 On Mon, Oct 13, 2008 at 03:45:59PM +0530, Kamalesh Babulal wrote:
   
 Hi,

2.6.27-git2 kernel build fails, while building the kernel with
 allyesconfig option. The allyesconfig selects CONFIG_INTEL_IOATDMA=y

 CC   drivers/dma/ioat_dca.o
 drivers/dma/ioat_dca.c: In function ‘dca_enabled_in_bios’:
 drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
 ‘cpuid_eax’
 drivers/dma/ioat_dca.c: In function ‘system_has_dca_enabled’:
 drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
 ‘boot_cpu_has’
 drivers/dma/ioat_dca.c:91: error: ‘X86_FEATURE_DCA’ undeclared (first 
 use in this function)
 drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
 only once
 drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
 drivers/dma/ioat_dca.c: In function ‘ioat_dca_get_tag’:
 drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
 ‘cpu_physical_id’
 make[2]: *** [drivers/dma/ioat_dca.o] Error 1
 make[1]: *** [drivers/dma] Error 2
 make: *** [drivers] Error 2
 ...
 

 Thanks for the report, the MYRI10GE and IXGBE commits that introduced 
 the select's are really broken.

 For fixing it I need to know the intended semantics.

 Brian, Jesse, is it OK to limit the drivers to m with 
 CONFIG_INTEL_IOATDMA=m ?
   

I think I would rather drop DCA from myri10ge if IOATDMA=m while
myri10ge=y. What's the simplest way to do so?

When Jesse told me to commit this in myri10ge, I thought it would be
nice to have DCA work the same than NETDMA/DMAengine does: you can have
NETDMA enabled without IOATDMA (either not built at all, or just not
loaded). You just don't get any DMA channel when you ask for one. Why
not do the same for DCA? There could be some generic DCA layer that can
be built all the time and returns DCA resources only if IOATDMA is
loaded/built ?

Brice

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

Re: Floating inputs on unused GPIO pins

[Bill Gatliff]

Laurent Pinchart wrote:

 
 There are no internal pull-up or pull-down resistors on the MPC8248 GPIO 
 pins. I know our hardware engineer has a valid point theoretically. Does the 
 point stand practically, or does the MPC8248 
 state-of-the-art(tm)(c)(whatever) technology make floating inputs safe ?

Well, Freescale's own layout recommendations recommend pullups or pulldowns for
all input pins, but it's isn't clear what motivates that suggestion.

The block diagram, Figure 37-21, is less than helpful.  :)  I recall a doc
somewhere that showed the input protection circuitry ends up providing a modest
pullup/down, so the line never truly floats.  But it's a very high-impedance
path, and I can't seem to find the doc anyway so it could be for a completely
different chip altogether.

The part isn't going to blow up if you leave inputs unconnected, at least if you
avoid high-EMI/RFI environments.  But I can imagine the possibility of increased
power consumption if I try hard enough.  I would think that the magnitude would
be completely swamped by the consumption of the rest of the chip, however...

The technical answer might not be the best political one, at least not without
Freescale-branded docs to back you up.  I say, write the code and make everyone
else happy.  :)

At least until someone plugs in that expansion module!


b.g.
-- 
Bill Gatliff
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Floating inputs on unused GPIO pins

[Laurent Pinchart]

Hi everybody,

our hardware engineer asked me to make sure all unused GPIO pins are configured 
as outputs to avoid floating inputs. He got theory on his side (floating inputs 
can lead to higher current consumption, metastability or even permanent 
damage), but I'd like to ask the list for practical feedback.

I haven't been able to find any mention of floating input protection in the 
MPC8248 documents. Has anyone here experienced issues with floating inputs in 
real-life designs ? Do you setup your board with all unused GPIO pins 
configured as outputs ?

Best regards,

-- 
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


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: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selects CONFIG_INTEL_IOATDMA=y

[Adrian Bunk]

On Mon, Oct 13, 2008 at 03:45:59PM +0530, Kamalesh Babulal wrote:
 Hi,
 
2.6.27-git2 kernel build fails, while building the kernel with
 allyesconfig option. The allyesconfig selects CONFIG_INTEL_IOATDMA=y
 
 CC   drivers/dma/ioat_dca.o
 drivers/dma/ioat_dca.c: In function ‘dca_enabled_in_bios’:
 drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
 ‘cpuid_eax’
 drivers/dma/ioat_dca.c: In function ‘system_has_dca_enabled’:
 drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
 ‘boot_cpu_has’
 drivers/dma/ioat_dca.c:91: error: ‘X86_FEATURE_DCA’ undeclared (first use 
 in this function)
 drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
 only once
 drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
 drivers/dma/ioat_dca.c: In function ‘ioat_dca_get_tag’:
 drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
 ‘cpu_physical_id’
 make[2]: *** [drivers/dma/ioat_dca.o] Error 1
 make[1]: *** [drivers/dma] Error 2
 make: *** [drivers] Error 2
...

Thanks for the report, the MYRI10GE and IXGBE commits that introduced 
the select's are really broken.

For fixing it I need to know the intended semantics.

Brian, Jesse, is it OK to limit the drivers to m with 
CONFIG_INTEL_IOATDMA=m ?

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: Floating inputs on unused GPIO pins

[Laurent Pinchart]

Hi Leon,

On Monday 13 October 2008, Leon Woestenberg wrote:
 Hello Laurent,
 
 On Mon, Oct 13, 2008 at 11:56 AM, Laurent Pinchart
 [EMAIL PROTECTED] wrote:
  our hardware engineer asked me to make sure all unused GPIO pins are
  configured as outputs to avoid floating inputs. He got theory on his side
  (floating inputs can lead to higher current consumption, metastability or
  even permanent damage), but I'd like to ask the list for practical
  feedback.
 
 Ideally, configure them as inputs or tri-state (both mean high
 impedance), and do use pull-down or -up resistors.

As I explained in my mail to Geert, that's not really an option. The GPIO pins 
are connected to an optional expansion module. When the module is plugged in 
the pins have dedicated functions. When the module is not present they are by 
default floating inputs. That's the case our hardware engineer is concerned 
about.

 Now, the answer might be different when your pins are not connected.
 Check on the processor if internal pull resistors are present. If so,
 use as input. If not, then your h/w engineer *may* have a point, not
 sure on that though.

There are no internal pull-up or pull-down resistors on the MPC8248 GPIO pins. 
I know our hardware engineer has a valid point theoretically. Does the point 
stand practically, or does the MPC8248 state-of-the-art(tm)(c)(whatever) 
technology make floating inputs safe ?

-- 
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


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] powerpc: Add legacy PCI access via sysfs

[Josh Boyer]

On Fri, Oct 10, 2008 at 10:39:18AM -0700, Jesse Barnes wrote:
On Thursday, October 9, 2008 7:50 pm Benjamin Herrenschmidt wrote:
 This patch adds support for legacy_io and legacy_mem files in
 bus class directories in sysfs for powerpc

 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
 ---

Applied to linux-next, thanks.

Is that targeted towards .28 or .29?  Ben has a 4xx specific patch
that depends on this one, and I just need to know which version to
bring that in for.

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

Re: Floating inputs on unused GPIO pins

[Leon Woestenberg]

Hello Laurent,

On Mon, Oct 13, 2008 at 11:56 AM, Laurent Pinchart
[EMAIL PROTECTED] wrote:
 our hardware engineer asked me to make sure all unused GPIO pins are 
 configured as outputs to avoid floating inputs. He got theory on his side 
 (floating inputs can lead to higher current consumption, metastability or 
 even permanent damage), but I'd like to ask the list for practical feedback.

Ideally, configure them as inputs or tri-state (both mean high
impedance), and do use pull-down or -up resistors.

Now, the answer might be different when your pins are not connected.
Check on the processor if internal pull resistors are present. If so,
use as input. If not, then your h/w engineer *may* have a point, not
sure on that though.

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

Re: Floating inputs on unused GPIO pins

[Laurent Pinchart]

Hi Geert,

On Monday 13 October 2008, Geert Uytterhoeven wrote:
 On Mon, 13 Oct 2008, Laurent Pinchart wrote:
  our hardware engineer asked me to make sure all unused GPIO pins are
  configured as outputs to avoid floating inputs. He got theory on his side
  (floating inputs can lead to higher current consumption, metastability or
  even permanent damage), but I'd like to ask the list for practical
  feedback.
  
  I haven't been able to find any mention of floating input protection in
  the MPC8248 documents. Has anyone here experienced issues with floating
  inputs in real-life designs ? Do you setup your board with all unused GPIO
  pins configured as outputs ?   
 
 I always thought configurable GPIO pins default to _inputs_ after power-on,
 so it's safe to tie them to VCC through a pull-up resistor?
 For CMOS, you can tie them to VDD or GND without a resistor.

That's not really an option. The GPIO pins are connected to an optional 
expansion module. When the module is plugged in the pins have dedicated 
functions. When the module is not present they are by default floating inputs. 
That's the case our hardware engineer is concerned about.

Best regards,

-- 
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


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 V2 4/4] POWERPC: Merge 32 and 64-bit dma code

[Josh Boyer]

On Fri, Sep 12, 2008 at 03:34:46PM -0500, Becky Bruce wrote:
We essentially adopt the 64-bit dma code, with some changes to support
32-bit systems, including HIGHMEM.  dma functions on 32-bit are now
invoked via accessor functions which call the correct op for a device based
on archdata dma_ops.  If there is no archdata dma_ops, this defaults
to dma_direct_ops.

In addition, the dma_map/unmap_page functions are added to dma_ops
because we can't just fall back on map/unmap_single when HIGHMEM is
enabled. In the case of dma_direct_*, we stop using map/unmap_single
and just use the page version - this saves a lot of ugly
ifdeffing.  We leave map/unmap_single in the dma_ops definition,
though, because they are needed by the iommu code, which does not
implement map/unmap_page.  Ideally, going forward, we will completely
eliminate map/unmap_single and just have map/unmap_page, if it's
workable for 64-bit.

Signed-off-by: Becky Bruce [EMAIL PROTECTED]

While doing a buildall this morning, I notice chrp32_defconfig fails
to build with:

drivers/built-in.o: In function `hard_dma_setup':
floppy.c:(.text+0x6e40e): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e412): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e53e): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e546): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e54a): undefined reference to `isa_bridge_pcidev'
make[1]: *** [.tmp_vmlinux1] Error 1

(the hard_dma_setup thing is in arch/powerpc/include/asm/floppy.h).

I did a git bisect and it pointed at this commit as causing the build
to fail.  Why, I have no idea.

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

Re: [Cbe-oss-dev] powerpc/cell/oprofile: fix mutex locking for spu-oprofile

[Arnd Bergmann]

On Monday 25 August 2008, Arnd Bergmann wrote:
 On Monday 25 August 2008, Paul Mackerras wrote:
  
   Since rc4 is out now, I understand if you feel more comfortable with
   putting the patch into -next instead of -merge.
  
  Linus has been getting stricter about only putting in fixes for
  regressions and serious bugs (see his recent email to Dave Airlie on
  LKML for instance).  I assume that the corruption is just in the data
  that is supplied to userspace and doesn't extend to any kernel data
  structures.
 
 That's right, please queue it for -next then.

I just realized that this patch never made it into powerpc-next after
all, neither benh nor paulus version. Whoever is handling it today,
could you please pull

 master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git merge

to get this commit below. I have rebased it on top of the current
benh/powerpc/next branch.

Thanks,

Arnd 

---

commit aa5810fa545515c9f383e3e649bd120bef9c7f29
Author: Carl Love [EMAIL PROTECTED]
Date:   Fri Aug 8 15:38:36 2008 -0700

powerpc/cell/oprofile: fix mutex locking for spu-oprofile

The issue is the SPU code is not holding the kernel mutex lock while
adding samples to the kernel buffer.

This patch creates per SPU buffers to hold the data.  Data
is added to the buffers from in interrupt context.  The data
is periodically pushed to the kernel buffer via a new Oprofile
function oprofile_put_buff(). The oprofile_put_buff() function
is called via a work queue enabling the funtion to acquire the
mutex lock.

The existing user controls for adjusting the per CPU buffer
size is used to control the size of the per SPU buffers.
Similarly, overflows of the SPU buffers are reported by
incrementing the per CPU buffer stats.  This eliminates the
need to have architecture specific controls for the per SPU
buffers which is not acceptable to the OProfile user tool
maintainer.

The export of the oprofile add_event_entry() is removed as it
is no longer needed given this patch.

Note, this patch has not addressed the issue of indexing arrays
by the spu number.  This still needs to be fixed as the spu
numbering is not guarenteed to be 0 to max_num_spus-1.

Signed-off-by: Carl Love [EMAIL PROTECTED]
Signed-off-by: Maynard Johnson [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Acked-by: Acked-by: Robert Richter [EMAIL PROTECTED]

 arch/powerpc/oprofile/cell/pr_util.h   |   13 +
 arch/powerpc/oprofile/cell/spu_profiler.c  |4
 arch/powerpc/oprofile/cell/spu_task_sync.c |  236 ---
 drivers/oprofile/buffer_sync.c |   24 ++
 drivers/oprofile/cpu_buffer.c  |   15 +
 drivers/oprofile/event_buffer.c|2
 drivers/oprofile/event_buffer.h|7
 include/linux/oprofile.h   |   16 +
 drivers/oprofile/cpu_buffer.c  |4
 9 files changed, 284 insertions(+), 37 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: performance: memcpy vs. __copy_tofrom_user

[Scott Wood]

On Sun, Oct 12, 2008 at 09:32:07AM +1100, Benjamin Herrenschmidt wrote:
 On Wed, 2008-10-08 at 12:40 -0500, Scott Wood wrote:
  
  The performance difference most likely comes from the fact that copy 
  to/from user can assume that the memory is cacheable, while memcpy is 
  occasionally used on cache-inhibited memory -- so dcbz isn't used.  We 
  may be better off handling the alignment fault on those occasions, and 
  we should use dcba on chips that support it.
 
 Note that the kernel memcpy isn't supposed to be used for non-cacheable
 memory. That's what memcpy_to/fromio are for.

I agree that it *shouldn't*, but the presence of cacheble_memcpy (used
only by the EMAC driver, AFAICT) suggests that it was a concern.

 But Paul has a point that for small copies especially, the cost of
 the cache instructions outweigh their benefit.

Possibly, but what is the overall effect on the system of using them,
even if it hurts small copies slightly?  How many small copies are of
constant size, which could be diverted to another implementation at
compile-time?  Even run-time diversion may help, as the cost of a small
memcpy is only important if you do it many times, in which case the
branch will probably be correctly predicted.

Given the networking results Dominik posted, I think it's worth a look.

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

gigE 2.6.27 USB

[Kevin Diggs]

Hi,

I managed to wrestle my gigE to the ground and get it to boot
2.6.27. I have, however, noticed that some messages are showing up in
dmesg. There are alot of them. They are continuous. They appear to come
from drivers/usb/core/hub.c:2916. It looks like they come in pairs (this
beast has two ports (root hubs)). I plugged in a USB CF reader. It
appears to work. The keyboard and mouse (a Logitech wireless receiver)
seems to work. 2.6.24 did not do this.

kevin
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.27
# Sat Oct 11 21:51:09 2008
#
# CONFIG_PPC64 is not set

#
# Processor support
#
CONFIG_6xx=y
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=2
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_HAVE_LATENCYTOP_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=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=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_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=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=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_PCSPKR_PLATFORM=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 is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
# CONFIG_HAVE_DMA_ATTRS is not set
CONFIG_USE_GENERIC_SMP_HELPERS=y
# CONFIG_HAVE_CLK is not set
CONFIG_PROC_PAGE_MONITOR=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
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_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

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

#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
CONFIG_CLASSIC32=y
CONFIG_PPC_CHRP=y
# CONFIG_MPC5121_ADS is not set
# CONFIG_MPC5121_GENERIC is not set
# CONFIG_PPC_MPC52xx is not set
CONFIG_PPC_PMAC=y
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PPC_82xx is not set
# CONFIG_PQ2ADS is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_86xx is not set
CONFIG_PPC_NATIVE=y
# CONFIG_UDBG_RTAS_CONSOLE is not set
# CONFIG_IPIC is not set
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
CONFIG_PPC_I8259=y
CONFIG_PPC_RTAS=y
# CONFIG_RTAS_ERROR_LOGGING is not set
CONFIG_RTAS_PROC=y
# CONFIG_MMIO_NVRAM is not set
CONFIG_PPC_MPC106=y
# 

Re: [Cbe-oss-dev] powerpc/cell/oprofile: fix mutex locking for spu-oprofile

[Robert Richter]

On 13.10.08 16:53:28, Arnd Bergmann wrote:
 On Monday 25 August 2008, Arnd Bergmann wrote:
  On Monday 25 August 2008, Paul Mackerras wrote:
   
Since rc4 is out now, I understand if you feel more comfortable with
putting the patch into -next instead of -merge.
   
   Linus has been getting stricter about only putting in fixes for
   regressions and serious bugs (see his recent email to Dave Airlie on
   LKML for instance).  I assume that the corruption is just in the data
   that is supplied to userspace and doesn't extend to any kernel data
   structures.
  
  That's right, please queue it for -next then.
 
 I just realized that this patch never made it into powerpc-next after
 all, neither benh nor paulus version. Whoever is handling it today,
 could you please pull
 
  master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git merge
 
 to get this commit below. I have rebased it on top of the current
 benh/powerpc/next branch.

All powerpc oprofile patches are in this branch:

git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git powerpc-for-paul

Pending patches are:

Carl Love (1):
  powerpc/cell/oprofile: fix mutex locking for spu-oprofile

Roel Kluin (1):
  powerpc/cell/oprofile: vma_map: fix test on overlay_tbl_offset

Please pull from there.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: [EMAIL PROTECTED]

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

[PATCH v3] powerpc: FPGA support for GE Fanuc SBC610

[Martyn Welch]

Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).

This patch adds support for the registers held in the devices main FPGA,
exposing extra information about the revision of the board through cpuinfo.

Signed-off-by: Martyn Welch [EMAIL PROTECTED]
---

Stephen: Thanks for spotting that error.

New to rev 3:
 * Added of_node_put()

 arch/powerpc/boot/dts/gef_sbc610.dts |4 +++
 arch/powerpc/platforms/86xx/gef_sbc610.c |   40 ++
 2 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts 
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 771a776..6ed6083 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -84,6 +84,10 @@
  6 0 0xfd00 0x0080 // IO FPGA (8-bit)
  7 0 0xfd80 0x0080;   // IO FPGA (32-bit)
 
+   [EMAIL PROTECTED],0 {
+   compatible = gef,fpga-regs;
+   reg = 0x4 0x0 0x40;
+   };
gef_pic: [EMAIL PROTECTED],4000 {
#interrupt-cells = 1;
interrupt-controller;
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c 
b/arch/powerpc/platforms/86xx/gef_sbc610.c
index 3873c20..821c45f 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc610.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -73,6 +73,7 @@ static void __init gef_sbc610_init_irq(void)
 
 static void __init gef_sbc610_setup_arch(void)
 {
+   struct device_node *regs;
 #ifdef CONFIG_PCI
struct device_node *np;
 
@@ -86,8 +87,43 @@ static void __init gef_sbc610_setup_arch(void)
 #ifdef CONFIG_SMP
mpc86xx_smp_init();
 #endif
+
+   /* Remap basic board registers */
+   regs = of_find_compatible_node(NULL, NULL, gef,fpga-regs);
+   if (regs) {
+   sbc610_regs = of_iomap(regs, 0);
+   if (sbc610_regs == NULL)
+   printk(KERN_WARNING Unable to map board registers\n);
+   of_node_put(regs);
+   }
+}
+
+/* Return the PCB revision */
+static unsigned int gef_sbc610_get_pcb_rev(void)
+{
+   unsigned int reg;
+
+   reg = ioread32(sbc610_regs);
+   return (reg  8)  0xff;
+}
+
+/* Return the board (software) revision */
+static unsigned int gef_sbc610_get_board_rev(void)
+{
+   unsigned int reg;
+
+   reg = ioread32(sbc610_regs);
+   return (reg  16)  0xff;
 }
 
+/* Return the FPGA revision */
+static unsigned int gef_sbc610_get_fpga_rev(void)
+{
+   unsigned int reg;
+
+   reg = ioread32(sbc610_regs);
+   return (reg  24)  0xf;
+}
 
 static void gef_sbc610_show_cpuinfo(struct seq_file *m)
 {
@@ -96,6 +132,10 @@ static void gef_sbc610_show_cpuinfo(struct seq_file *m)
 
seq_printf(m, Vendor\t\t: GE Fanuc Intelligent Platforms\n);
 
+   seq_printf(m, Revision\t: %u%c\n, gef_sbc610_get_pcb_rev(),
+   ('A' + gef_sbc610_get_board_rev() - 1));
+   seq_printf(m, FPGA Revision\t: %u\n, gef_sbc610_get_fpga_rev());
+
seq_printf(m, SVR\t\t: 0x%x\n, svid);
seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
 }

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

Re: [PATCH] powerpc/cell/oprofile: vma_map: fix test on overlay_tbl_offset

[Robert Richter]

On 07.10.08 10:38:33, Arnd Bergmann wrote:
 From: Roel Kluin [EMAIL PROTECTED]
 
 Offset is unsigned and when an address isn't found in the vma map
 vma_map_lookup() returns the vma physical address + 0x1000.
 
 vma_map_lookup used to return 0x on a failed lookup, but
 a change was made to return the vma physical address + 0x1000
 There are two callers of vam_map_lookup: one of them correctly 
 deals with this new return value, but the other (below) did not.  
 
 Signed-off-by: Roel Kluin [EMAIL PROTECTED]
 Acked-by: Maynard Johnson [EMAIL PROTECTED]
 Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Cc: Carl Love [EMAIL PROTECTED]

The patch has been applied to the powerpc-for-paul branch of
git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git

Thanks Roel and Arnd,

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: [EMAIL PROTECTED]

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

Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code

[Josh Boyer]

On Mon, Oct 13, 2008 at 10:49:04AM -0400, Josh Boyer wrote:
On Fri, Sep 12, 2008 at 03:34:46PM -0500, Becky Bruce wrote:
We essentially adopt the 64-bit dma code, with some changes to support
32-bit systems, including HIGHMEM.  dma functions on 32-bit are now
invoked via accessor functions which call the correct op for a device based
on archdata dma_ops.  If there is no archdata dma_ops, this defaults
to dma_direct_ops.

In addition, the dma_map/unmap_page functions are added to dma_ops
because we can't just fall back on map/unmap_single when HIGHMEM is
enabled. In the case of dma_direct_*, we stop using map/unmap_single
and just use the page version - this saves a lot of ugly
ifdeffing.  We leave map/unmap_single in the dma_ops definition,
though, because they are needed by the iommu code, which does not
implement map/unmap_page.  Ideally, going forward, we will completely
eliminate map/unmap_single and just have map/unmap_page, if it's
workable for 64-bit.

Signed-off-by: Becky Bruce [EMAIL PROTECTED]

While doing a buildall this morning, I notice chrp32_defconfig fails
to build with:

drivers/built-in.o: In function `hard_dma_setup':
floppy.c:(.text+0x6e40e): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e412): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e53e): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e546): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e54a): undefined reference to `isa_bridge_pcidev'
make[1]: *** [.tmp_vmlinux1] Error 1

(the hard_dma_setup thing is in arch/powerpc/include/asm/floppy.h).

I did a git bisect and it pointed at this commit as causing the build
to fail.  Why, I have no idea.

Ok, I was annoyed enough to look at why.

Basically, before this patch pci_map_single on 32-bit PPC seemed to
be compiled down to __dma_sync(ptr, size, direction); and the dev
parameter to the function was never actually used.  The compiler
seems to have optimized this out entirely, so we don't get the odd
link reference to isa_bridge_pcidev at all.  (Neither pci_map_single
or isa_bridge_pcidev are present in the vmlinux at all).

With the patch, the compiler doesn't do this code elimination
because pci_map_single boils down to dma_map_page, which calls
get_dma_direct_offset with the dev parameter.  So since it is
still used, the compiler can't eliminate it and hence FAIL.

I have no patch for this at the moment.  Someone should look at
it more closely, because this is causing the 5 chrp32_defconfig
users to weep.

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

Re: [PATCH 1/1] IB/ehca: Disallow creating UC QP with SRQ

[Hoang-Nam Nguyen]

Hi Roland,
That looks good to me.
Thanks for all help.

Nam

On Friday 10 October 2008 23:41, Roland Dreier wrote:
 thanks, applied -- it didn't apply to the latest tree, because of the
 flush CQE changes, so I merged it manually as below -- let me know if
 this is wrong:
 
 commit 0540bbbe455e123a1692d26205ad1a29983883b0
 Author: Hoang-Nam Nguyen [EMAIL PROTECTED]
 Date:   Fri Oct 10 14:40:39 2008 -0700
 
 IB/ehca: Don't allow creating UC QP with SRQ
 
 This patch prevents a UC QP to be created attached to an SRQ, since
 current firmware does not support this feature.
 
 Signed-off-by: Michael Faath [EMAIL PROTECTED]
 Signed-off-by: Roland Dreier [EMAIL PROTECTED]
 
 diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c 
 b/drivers/infiniband/hw/ehca/ehca_qp.c
 index 4dbe287..40b578d 100644
 --- a/drivers/infiniband/hw/ehca/ehca_qp.c
 +++ b/drivers/infiniband/hw/ehca/ehca_qp.c
 @@ -502,6 +502,12 @@ static struct ehca_qp *internal_create_qp(
   if (init_attr-srq) {
   my_srq = container_of(init_attr-srq, struct ehca_qp, ib_srq);
 
 + if (qp_type == IB_QPT_UC) {
 + ehca_err(pd-device, UC with SRQ not supported);
 + atomic_dec(shca-num_qps);
 + return ERR_PTR(-EINVAL);
 + }
 +
   has_srq = 1;
   parms.ext_type = EQPT_SRQBASE;
   parms.srq_qpn = my_srq-real_qp_num;
 


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

Re: [PATCH v2] powerpc: FPGA support for GE Fanuc SBC610

[Stephen Rothwell]

Hi Martyn,

On Mon, 13 Oct 2008 09:53:49 +0100 Martyn Welch [EMAIL PROTECTED] wrote:

 --- a/arch/powerpc/platforms/86xx/gef_sbc610.c
 +++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
 @@ -73,6 +73,7 @@ static void __init gef_sbc610_init_irq(void)
  
  static void __init gef_sbc610_setup_arch(void)
  {
 + struct device_node *regs;
  #ifdef CONFIG_PCI
   struct device_node *np;
  
 @@ -86,8 +87,42 @@ static void __init gef_sbc610_setup_arch(void)
  #ifdef CONFIG_SMP
   mpc86xx_smp_init();
  #endif
 +
 + /* Remap basic board registers */
 + regs = of_find_compatible_node(NULL, NULL, gef,fpga-regs);
 + if (regs) {
 + sbc610_regs = of_iomap(regs, 0);
 + if (sbc610_regs == NULL)
 + printk(KERN_WARNING Unable to map board registers\n);

You need an of_node_put(regs) here.

 + }
 +}
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


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

Re: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27

[Joakim Tjernlund]

On Mon, 2008-10-13 at 14:01 +0200, Joakim Tjernlund wrote:
 So I upgraded my tree for our custom mpc8321 boards.
 I2c and ethernet stopped working.
 
 Ethernet: I am using the ucc_geth driver and now
 it seems like it won't TX any pkgs.
 ethtool -S eth0  shows that the RX countes are increasing but
 the TX ones stays a zero. 

The ethernet problem turned out to be .bd_mem_part = MEM_PART_MURAM
not working anymore.
The default .bd_mem_part = MEM_PART_SYSTEM works. No idea as
to what caused this though.

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

[PATCH]IB/ehca:reject dynamic memory add/remove

[Stefan Roscher]

Since the ehca device driver does not support dynamic memory add and remove
operations, the driver must explicitly reject such requests in order to prevent
unpredictable behaviors related to memory regions already occupied and being
used by InfiniBand applications.
The solution is to add a memory notifier to the ehca device driver and if a 
request
for dynamic memory add or remove comes in, ehca will always reject it.

Signed-off-by: Stefan Roscher [EMAIL PROTECTED]
---

diff -Nurp linux-2.6.27-rc6-7/drivers/infiniband/hw/ehca/ehca_main.c 
linux-2.6.27-rc6-7.new/drivers/infiniband/hw/ehca/ehca_main.c
--- linux-2.6.27-rc6-7/drivers/infiniband/hw/ehca/ehca_main.c   2008-09-16 
18:19:27.0 +0200
+++ linux-2.6.27-rc6-7.new/drivers/infiniband/hw/ehca/ehca_main.c   
2008-10-03 13:52:50.0 +0200
@@ -44,6 +44,8 @@
 #include linux/slab.h
 #endif
 
+#include linux/notifier.h
+#include linux/memory.h
 #include ehca_classes.h
 #include ehca_iverbs.h
 #include ehca_mrmw.h
@@ -964,6 +966,41 @@ void ehca_poll_eqs(unsigned long data)
spin_unlock(shca_list_lock);
 }
 
+static int ehca_mem_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+   static unsigned long ehca_dmem_warn_time;
+
+   switch (action) {
+   case MEM_CANCEL_OFFLINE:
+   case MEM_CANCEL_ONLINE:
+   case MEM_ONLINE:
+   case MEM_OFFLINE:
+   return NOTIFY_OK;
+   case MEM_GOING_ONLINE:
+   case MEM_GOING_OFFLINE:
+   /* only ok if no hca is attached to the lpar */
+   spin_lock(shca_list_lock);
+   if (list_empty(shca_list)) {
+   spin_unlock(shca_list_lock);
+   return NOTIFY_OK;
+   } else {
+   spin_unlock(shca_list_lock);
+   if (printk_timed_ratelimit(ehca_dmem_warn_time,
+  30 * 1000))
+   ehca_gen_err(DMEM operations are not allowed
+as long as an ehca adapter is
+attached to the LPAR);
+   return NOTIFY_BAD;
+   }
+   }
+   return NOTIFY_OK;
+}
+
+static struct notifier_block ehca_mem_nb = {
+   .notifier_call = ehca_mem_notifier,
+};
+
 static int __init ehca_module_init(void)
 {
int ret;
@@ -991,6 +1028,12 @@ static int __init ehca_module_init(void)
goto module_init2;
}
 
+   ret = register_memory_notifier(ehca_mem_nb);
+   if (ret) {
+   ehca_gen_err(Failed registering memory add/remove notifier);
+   goto module_init3;
+   }
+
if (ehca_poll_all_eqs != 1) {
ehca_gen_err(WARNING!!!);
ehca_gen_err(It is possible to lose interrupts.);
@@ -1003,6 +1046,9 @@ static int __init ehca_module_init(void)
 
return 0;
 
+module_init3:
+   ibmebus_unregister_driver(ehca_driver);
+
 module_init2:
ehca_destroy_slab_caches();
 
@@ -1018,6 +1064,8 @@ static void __exit ehca_module_exit(void
 
ibmebus_unregister_driver(ehca_driver);
 
+   unregister_memory_notifier(ehca_mem_nb);
+
ehca_destroy_slab_caches();
 
ehca_destroy_comp_pool();
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Floating inputs on unused GPIO pins

[Leon Woestenberg]

Hello Laurent,

On Mon, Oct 13, 2008 at 3:12 PM, Bill Gatliff [EMAIL PROTECTED] wrote:
 At least until someone plugs in that expansion module!

Bill's remark made a neuron connection in my head:

Can you detect if the module is inserted or not? (By reading a known
state of some pin)?

You could then configure the pins dynamically in your driver.

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

[PATCH v7] ppc4xx gpio driver

[Steven A. Falco]

This patch adds support for the GPIO functions of PPC40x and PPC44x
SOCs.

Signed-off-by: Steve Falco [EMAIL PROTECTED]
Acked-by: Stefan Roese [EMAIL PROTECTED]
Acked-by: Sean MacLennan [EMAIL PROTECTED]
---
I believe I've satisfied all the comments that have been made for this
driver.

Josh - is there anything else you'd like to see before pulling this into
your tree?


Changes from the previous version:

1) Removed !! from the input routine.  A separate patch for sysfs gpio
export to sanitize its input has been posted.

2) Used the clr/set macros to improve readability.

3) Changed the device from amcc to ibm.

diff --git a/arch/powerpc/platforms/40x/Kconfig 
b/arch/powerpc/platforms/40x/Kconfig
index a9260e2..aaada72 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -139,6 +139,14 @@ config STB03xxx
select IBM405_ERR77
select IBM405_ERR51
 
+config PPC4xx_GPIO
+   bool PPC4xx GPIO support
+   depends on 40x
+   select ARCH_REQUIRE_GPIOLIB
+   select GENERIC_GPIO
+   help
+ Enable gpiolib support for ppc40x based boards
+
 # 40x errata/workaround config symbols, selected by the CPU models above
 
 # All 405-based cores up until the 405GPR and 405EP have this errata.
diff --git a/arch/powerpc/platforms/44x/Kconfig 
b/arch/powerpc/platforms/44x/Kconfig
index 249ba01..eec5cb4 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -127,6 +143,14 @@ config XILINX_VIRTEX440_GENERIC_BOARD
  Most Virtex 5 designs should use this unless it needs to do some
  special configuration at board probe time.
 
+config PPC4xx_GPIO
+   bool PPC4xx GPIO support
+   depends on 44x
+   select ARCH_REQUIRE_GPIOLIB
+   select GENERIC_GPIO
+   help
+ Enable gpiolib support for ppc440 based boards
+
 # 44x specific CPU modules, selected based on the board above.
 config 440EP
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a90054b..35d5765 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_OF_RTC)  += of_rtc.o
 ifeq ($(CONFIG_PCI),y)
 obj-$(CONFIG_4xx)  += ppc4xx_pci.o
 endif
+obj-$(CONFIG_PPC4xx_GPIO)  += ppc4xx_gpio.o
 
 # Temporary hack until we have migrated to asm-powerpc
 ifeq ($(ARCH),powerpc)
diff --git a/arch/powerpc/sysdev/ppc4xx_gpio.c 
b/arch/powerpc/sysdev/ppc4xx_gpio.c
new file mode 100644
index 000..110efe2
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_gpio.c
@@ -0,0 +1,217 @@
+/*
+ * PPC4xx gpio driver
+ *
+ * Copyright (c) 2008 Harris Corporation
+ * Copyright (c) 2008 Sascha Hauer [EMAIL PROTECTED], Pengutronix
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Steve Falco [EMAIL PROTECTED]
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/spinlock.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+#include linux/types.h
+
+#define GPIO_MASK(gpio)(0x8000  (gpio))
+#define GPIO_MASK2(gpio)   (0xc000  ((gpio) * 2))
+
+/* Physical GPIO register layout */
+struct ppc4xx_gpio {
+   __be32 or;
+   __be32 tcr;
+   __be32 osrl;
+   __be32 osrh;
+   __be32 tsrl;
+   __be32 tsrh;
+   __be32 odr;
+   __be32 ir;
+   __be32 rr1;
+   __be32 rr2;
+   __be32 rr3;
+   __be32 reserved1;
+   __be32 isr1l;
+   __be32 isr1h;
+   __be32 isr2l;
+   __be32 isr2h;
+   __be32 isr3l;
+   __be32 isr3h;
+};
+
+struct ppc4xx_gpio_chip {
+   struct of_mm_gpio_chip mm_gc;
+   spinlock_t lock;
+};
+
+/*
+ * GPIO LIB API implementation for GPIOs
+ *
+ * There are a maximum of 32 gpios in each gpio controller.
+ */
+
+static inline struct ppc4xx_gpio_chip *
+to_ppc4xx_gpiochip(struct of_mm_gpio_chip *mm_gc)
+{
+   return container_of(mm_gc, struct ppc4xx_gpio_chip, mm_gc);
+}
+
+static int ppc4xx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+   struct ppc4xx_gpio __iomem *regs = mm_gc-regs;
+
+   return in_be32(regs-ir)  GPIO_MASK(gpio);
+}
+
+static inline void
+__ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+

Re: [RFC 1/6] [PWM] Generic PWM API implementation

[Scott Wood]

On Fri, Oct 10, 2008 at 09:07:30AM -0500, Bill Gatliff wrote:
 Benjamin Herrenschmidt wrote:
  And you haven't provided -any- changeset comment. That isn't good :-)
 
 What's the easiest way to do that with git?

Enter the changeset comment in git commit.

 I'm using git-format-patch and git-send-email to produce the changeset
 emails themselves, after extensive use of git-add --interactive and
 git-rebase --interactive to get rid of the mundane commit stuff that
 I do because of my highly interrupt-driven workflow.

If your final commit is generated from something other than git commit,
you can use git commit --amend to edit the comment.

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

Re: [patch] powerpc: implement optimised mutex fastpaths

[Scott Wood]

On Sun, Oct 12, 2008 at 07:47:32AM +0200, Nick Piggin wrote:
 +static inline int __mutex_cmpxchg_lock(atomic_t *v, int old, int new)
 +{
 + int t;
 +
 + __asm__ __volatile__ (
 +1:  lwarx   %0,0,%1 # mutex trylock\n\
 + cmpw0,%0,%2\n\
 + bne-2f\n
 + PPC405_ERR77(0,%1)
 +stwcx.  %3,0,%1\n\
 + bne-1b
 + ISYNC_ON_SMP
 + \n\
 +2:
 + : =r (t)
 + : r (v-counter), r (old), r (new)
 + : cc, memory);

This will break if the compiler picks r0 for v-counter.  Use b as the
constraint, or better yet do lwarx %0, %y1, with a Z (v-counter)
constraint.

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

Re: [patch] powerpc: implement optimised mutex fastpaths

[Scott Wood]

On Mon, Oct 13, 2008 at 11:15:47AM -0500, Scott Wood wrote:
 On Sun, Oct 12, 2008 at 07:47:32AM +0200, Nick Piggin wrote:
  +static inline int __mutex_cmpxchg_lock(atomic_t *v, int old, int new)
  +{
  +   int t;
  +
  +   __asm__ __volatile__ (
  +1:lwarx   %0,0,%1 # mutex trylock\n\
  +   cmpw0,%0,%2\n\
  +   bne-2f\n
  +   PPC405_ERR77(0,%1)
  +  stwcx.  %3,0,%1\n\
  +   bne-1b
  +   ISYNC_ON_SMP
  +   \n\
  +2:
  +   : =r (t)
  +   : r (v-counter), r (old), r (new)
  +   : cc, memory);
 
 This will break if the compiler picks r0 for v-counter.  Use b as the
 constraint, or better yet do lwarx %0, %y1, with a Z (v-counter)
 constraint.

Sorry, had a morning brain-fart there -- you're not using the base
register.

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

Re: [PATCH] powerpc/83xx: add NAND support for the MPC8360E-RDK boards

[Kumar Gala]

On Oct 10, 2008, at 1:05 PM, Anton Vorontsov wrote:


The StMicro NAND chip (512Mbit, 64MB) is connected to the local bus,
the first local bus' user-programmable machine is configured by the
firmware to work with NAND chips.

QE GPIO pin is used to poll the NAND's Ready-Not-Busy signal.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc836x_rdk.dts |   12 
1 files changed, 12 insertions(+), 0 deletions(-)



applied.

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

Re: 2.6.27 g5 config?

[Benjamin Herrenschmidt]

On Sat, 2008-10-11 at 18:25 -0700, Kevin Diggs wrote:
 Hi,
 
   I always have trouble getting an initial build to boot. Usually
 it is with keyboards and video console. Currently, I can't seem to find
 the root disk.

Why don't you just use a g5_defconfig ?

Ben.


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

Re: [PATCH v3] powerpc: FPGA support for GE Fanuc SBC610

[Kumar Gala]

On Oct 13, 2008, at 10:16 AM, Martyn Welch wrote:

Support for the SBC610 VPX Single Board Computer from GE Fanuc  
(PowerPC

MPC8641D).

This patch adds support for the registers held in the devices main  
FPGA,
exposing extra information about the revision of the board through  
cpuinfo.


Signed-off-by: Martyn Welch [EMAIL PROTECTED]
---

Stephen: Thanks for spotting that error.

New to rev 3:
* Added of_node_put()

arch/powerpc/boot/dts/gef_sbc610.dts |4 +++
arch/powerpc/platforms/86xx/gef_sbc610.c |   40 + 
+

2 files changed, 44 insertions(+), 0 deletions(-)


applied.

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

Re: [PATCH 2/3] kvmppc: add hypercall infrastructure - guest part v3

[Kumar Gala]

On Sep 16, 2008, at 1:27 AM, [EMAIL PROTECTED] wrote:


From: Christian Ehrhardt [EMAIL PROTECTED]

This adds the guest portion of the hypercall infrastructure.

Version 3 now follows the beat ABI, but proposes a new  
implementation style as
static inline asm functions instead of pure assembler code. That  
should allow

the compiler to be more flexible and therefore a better optimization.

If people agree on that new implementation style we might merge this  
code.

The current implementation of beat style hypercalls can be found in
arch/powerpc/platforms/cell/beat_hvCall.S

Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
epapr_hcalls.h |   59 +++ 
++

1 file changed, 59 insertions(+)

[diff]

diff --git a/include/asm-powerpc/epapr_hcalls.h b/include/asm- 
powerpc/epapr_hcalls.h

new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/epapr_hcalls.h
@@ -0,0 +1,59 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA   
02110-1301, USA.

+ *
+ * Copyright IBM Corp. 2008
+ *
+ * Authors:
+ * Christian Ehrhardt [EMAIL PROTECTED]
+ */
+
+#ifndef __POWERPC_EPAPR_HCALLS_H__
+#define __POWERPC_EPAPR_HCALLS_H__
+
+#ifdef __KERNEL__
+
+/* Hypercalls use the beat ABI */
+#define KVM_HYPERCALL_BIN 0x4422


Any reason this isn't 'sc' ?

Also, can we make this sc 1 so its works when we have HW hypervisor  
support?


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

[PATCH] powerpc/boot: compare _start against ei.loadsize instead ei.memsize

[Sebastian Andrzej Siewior]

If the vmlinux binary in memory is larger than 4 MiB than it collides
with the initial boot code which is linked at 4 MiB in case of cuBoot.
If the the uncompressed image size (on disk size) is less than 4 MiB
then it would fit. The difference between those two sizes is the bss
section. In cuBoot we have the dtb embedded right after the data
section so it is very likely that the reset of the bss section (in
kernel's start up code) will overwrite the dtb blob. Therefore we
reallocate the dtb. Something similar is allready done to the initrd.

Signed-off-by: Sebastian Andrzej Siewior [EMAIL PROTECTED]
---
 arch/powerpc/boot/libfdt-wrapper.c |   16 
 arch/powerpc/boot/main.c   |   14 --
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/boot/libfdt-wrapper.c 
b/arch/powerpc/boot/libfdt-wrapper.c
index c541fd8..1daa73f 100644
--- a/arch/powerpc/boot/libfdt-wrapper.c
+++ b/arch/powerpc/boot/libfdt-wrapper.c
@@ -165,6 +165,7 @@ static unsigned long fdt_wrapper_finalize(void)
 void fdt_init(void *blob)
 {
int err;
+   int bufsize;
 
dt_ops.finddevice = fdt_wrapper_finddevice;
dt_ops.getprop = fdt_wrapper_getprop;
@@ -178,16 +179,15 @@ void fdt_init(void *blob)
 
/* Make sure the dt blob is the right version and so forth */
fdt = blob;
-   err = fdt_open_into(fdt, fdt, fdt_totalsize(blob));
-   if (err == -FDT_ERR_NOSPACE) {
-   int bufsize = fdt_totalsize(fdt) + 4;
-   buf = malloc(bufsize);
-   err = fdt_open_into(fdt, buf, bufsize);
-   }
+   bufsize = fdt_totalsize(fdt) + 4;
+   buf = malloc(bufsize);
+   if(!buf)
+   fatal(malloc failed. can't relocate the device tree\n\r);
+
+   err = fdt_open_into(fdt, buf, bufsize);
 
if (err != 0)
fatal(fdt_init(): %s\n\r, fdt_strerror(err));
 
-   if (buf)
-   fdt = buf;
+   fdt = buf;
 }
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index 9e7f3dd..ae32801 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -56,9 +56,19 @@ static struct addr_range prep_kernel(void)
if (platform_ops.vmlinux_alloc) {
addr = platform_ops.vmlinux_alloc(ei.memsize);
} else {
-   if ((unsigned long)_start  ei.memsize)
+   /*
+* Check if the kernel image (without bss) would overwrite the
+* bootwrapper. The device tree has been moved in fdt_init()
+* to an area allocated with malloc() (somewhere past _end).
+*/
+   if ((unsigned long)_start  ei.loadsize)
fatal(Insufficient memory for kernel at address 0!
-   (_start=%p)\n\r, _start);
+   (_start=%p, uncomressed size=%08x)\n\r,
+  _start, ei.loadsize);
+
+   if ((unsigned long)_end  ei.memsize)
+   fatal(The final kernel image would overwrite the 
+   device tree\n\r);
}
 
/* Finally, gunzip the kernel */
-- 
1.5.6.5

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

Re: [PATCH] powerpc: fix fsl_upm nand driver modular build

[Kumar Gala]

On Oct 8, 2008, at 7:32 PM, Anton Vorontsov wrote:


The fsl_upm nand driver fails to build because fsl_lbc_lock isn't
exported, the lock is needed by the inlined fsl_upm_run_pattern()
function:

ERROR: fsl_lbc_lock [drivers/mtd/nand/fsl_upm.ko] undefined!

Dave Jones purposed to export the lock, but it is better to just  
uninline

the fsl_upm_run_pattern().

When uninlined we also no longer need the exported fsl_lbc_regs, and
both fsl_lbc_lock and fsl_lbc_regs could be marked static.

While at it, also add some missing includes that we should have  
included

explicitly.

Reported-by: Dave Jones [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---



applied.

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

Re: performance: memcpy vs. __copy_tofrom_user

[Scott Wood]

On Sat, Oct 11, 2008 at 09:05:49PM -0500, Matt Sealey wrote:
 Benjamin Herrenschmidt wrote:
 The reason where we require a -real-good- reason to do it is
 simply because of the drawbacks. The cost of enabling altivec
 in the kernel can be high (especially if the user is using it)
 and it's not context switched for kernel code (just like the
 FPU) for obvious performance reasons. Thus any use of altivec in the
 kernel must be done within non-preemptible sections, which can
 cause higher latencies in preemptible kernels.

It doesn't need to be done in non-preemptible sections, if you have a
separate per-thread save area for kernel fp/altivec use (and appropriate
flags so an FP unavailable handler knows which regs to restore), and you
can avoid using it in a preempting context.

In a realtime-configured kernel, preempting contexts should be fairly
minimal, so the loss of altivec use is not of critical performance impact
(other than one branch to determine if it can be used).

In a throughput-configured kernel, do it as you described (disable
preemption), and be able to use altivec memcpy in interrupt handlers, and
reduce the thread size.

 Would the examples (page copy, page clear) be an okay place to do it?
 These sections can't be preempted anyway (right?),

Why can't they be preempted?

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

Please pull from 'powerpc-next' branch

[Kumar Gala]

Please pull from 'powerpc-next' branch of

master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git 
powerpc-next

to receive the following updates:

 Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt |   40 ++
 Documentation/powerpc/dts-bindings/fsl/dma.txt   |   13
 Documentation/powerpc/dts-bindings/fsl/ssi.txt   |   20 -
 arch/powerpc/boot/dts/gef_sbc610.dts |   41 ++
 arch/powerpc/boot/dts/mpc5121ads.dts |3
 arch/powerpc/boot/dts/mpc8313erdb.dts|3
 arch/powerpc/boot/dts/mpc8315erdb.dts|3
 arch/powerpc/boot/dts/mpc832x_mds.dts|3
 arch/powerpc/boot/dts/mpc832x_rdb.dts|3
 arch/powerpc/boot/dts/mpc8349emitx.dts   |6
 arch/powerpc/boot/dts/mpc8349emitxgp.dts |3
 arch/powerpc/boot/dts/mpc834x_mds.dts|6
 arch/powerpc/boot/dts/mpc836x_mds.dts|3
 arch/powerpc/boot/dts/mpc836x_rdk.dts|   15
 arch/powerpc/boot/dts/mpc8377_mds.dts|   10
 arch/powerpc/boot/dts/mpc8377_rdb.dts|3
 arch/powerpc/boot/dts/mpc8378_mds.dts|   10
 arch/powerpc/boot/dts/mpc8378_rdb.dts|3
 arch/powerpc/boot/dts/mpc8379_mds.dts|   10
 arch/powerpc/boot/dts/mpc8379_rdb.dts|3
 arch/powerpc/boot/dts/mpc8536ds.dts  |2
 arch/powerpc/boot/dts/mpc8610_hpcd.dts   |4
 arch/powerpc/boot/dts/sbc8349.dts|3
 arch/powerpc/configs/83xx/asp8347_defconfig  |2
 arch/powerpc/configs/83xx/mpc8313_rdb_defconfig  |2
 arch/powerpc/configs/83xx/mpc8315_rdb_defconfig  |2
 arch/powerpc/configs/83xx/mpc832x_mds_defconfig  |2
 arch/powerpc/configs/83xx/mpc832x_rdb_defconfig  |2
 arch/powerpc/configs/83xx/mpc834x_itx_defconfig  |2
 arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig|2
 arch/powerpc/configs/83xx/mpc834x_mds_defconfig  |2
 arch/powerpc/configs/83xx/mpc836x_mds_defconfig  |2
 arch/powerpc/configs/83xx/mpc836x_rdk_defconfig  |2
 arch/powerpc/configs/83xx/mpc837x_mds_defconfig  |2
 arch/powerpc/configs/83xx/mpc837x_rdb_defconfig  |2
 arch/powerpc/configs/83xx/sbc834x_defconfig  |2
 arch/powerpc/configs/86xx/gef_sbc610_defconfig   |5
 arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |2
 arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig |2
 arch/powerpc/configs/86xx/sbc8641d_defconfig |2
 arch/powerpc/configs/ep8248e_defconfig   |2
 arch/powerpc/configs/mpc8272_ads_defconfig   |2
 arch/powerpc/configs/mpc83xx_defconfig   |2
 arch/powerpc/configs/pq2fads_defconfig   |2
 arch/powerpc/include/asm/fsl_lbc.h   |   48 --
 arch/powerpc/kernel/head_fsl_booke.S |4
 arch/powerpc/kernel/pci_32.c |5
 arch/powerpc/platforms/512x/Kconfig  |2
 arch/powerpc/platforms/512x/mpc5121_ads.c|   10
 arch/powerpc/platforms/83xx/Kconfig  |5
 arch/powerpc/platforms/83xx/mpc837x_mds.c|8
 arch/powerpc/platforms/85xx/Kconfig  |1
 arch/powerpc/platforms/86xx/Makefile |2
 arch/powerpc/platforms/86xx/gef_pic.c|  258 +++
 arch/powerpc/platforms/86xx/gef_pic.h|   11
 arch/powerpc/platforms/86xx/gef_sbc610.c |   65 +++
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c   |1
 arch/powerpc/platforms/Kconfig   |   12
 arch/powerpc/sysdev/fsl_lbc.c|   53 ++-
 arch/powerpc/sysdev/fsl_pci.c|   58 ++-
 arch/powerpc/sysdev/fsl_soc.c|   38 --
 arch/powerpc/sysdev/fsl_soc.h|8
 arch/powerpc/sysdev/qe_lib/Kconfig   |9
 drivers/i2c/chips/Kconfig|   11
 drivers/i2c/chips/Makefile   |1
 drivers/i2c/chips/mcu_mpc8349emitx.c |  209 
 drivers/of/base.c|2
 67 files changed, 901 insertions(+), 175 deletions(-)

Anton Vorontsov (7):
  powerpc/QE: move QE_GPIO Kconfig symbol into the platforms/Kconfig
  powerpc/83xx: don't probe broken PCI on mpc837x_mds boards
  powerpc/83xx: add DS1374 RTC support for the MPC837xE-MDS boards
  OF: add fsl,mcu-mpc8349emitx to the exception list
  i2c: MPC8349E-mITX Power Management and GPIO expander driver
  

Re: Floating inputs on unused GPIO pins

[Leon Woestenberg]

Hi Laurent,

On Mon, Oct 13, 2008 at 1:04 PM, Laurent Pinchart
[EMAIL PROTECTED] wrote:
 There are no internal pull-up or pull-down resistors on the MPC8248 GPIO 
 pins. I know our hardware engineer has a valid point theoretically. Does the 
 point stand practically, or does the MPC8248 
 state-of-the-art(tm)(c)(whatever) technology make floating inputs safe ?

Ask Freescale?

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

MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27

[Joakim Tjernlund]

So I upgraded my tree for our custom mpc8321 boards.
I2c and ethernet stopped working.

Ethernet: I am using the ucc_geth driver and now
it seems like it won't TX any pkgs.
ethtool -S eth0  shows that the RX countes are increasing but
the TX ones stays a zero. 

Secondly i2c, I have this in my platform driver:
static struct i2c_board_info __initdata tmcu_i2c_devices[] = {
{ I2C_BOARD_INFO(rtc-ds1307, 0x68),
  .type = ds1337,
},
};

int __init tmcu_i2c_board_devs(void)
{
int ret;
ret = i2c_register_board_info(0, tmcu_i2c_devices,
  ARRAY_SIZE(tmcu_i2c_devices));
return ret;
}
arch_initcall(tmcu_i2c_board_devs);

This no longer works, but if I add
[EMAIL PROTECTED] {
compatible = dallas,ds1337;
reg = 68;
};
to my device tree so the whole I2c node looks like this:
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
device_type = i2c;
compatible = fsl-i2c;
reg = 3000 100;
interrupts = e 8;
interrupt-parent = ipic;
dfsrr;

[EMAIL PROTECTED] {
compatible = dallas,ds1337;
reg = 68;
};
};
it works again. Is my static init of the rtc device faulty or is this
a bug in the kernel?

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

Re: [PATCH]IB/ehca:reject dynamic memory add/remove

[Dave Hansen]

On Mon, 2008-10-13 at 13:10 +0200, Stefan Roscher wrote:
 Since the ehca device driver does not support dynamic memory add and remove
 operations, the driver must explicitly reject such requests in order to 
 prevent
 unpredictable behaviors related to memory regions already occupied and being
 used by InfiniBand applications.
 The solution is to add a memory notifier to the ehca device driver and if a 
 request
 for dynamic memory add or remove comes in, ehca will always reject it.

Why doesn't the driver support it?

This seems like an awfully extreme action to take.  Do you have plans to
support this in the driver soon?

-- Dave

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

Re: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27

[Joakim Tjernlund]

On Mon, 2008-10-13 at 11:31 -0500, Scott Wood wrote:
 On Mon, Oct 13, 2008 at 02:01:55PM +0200, Joakim Tjernlund wrote:
  Secondly i2c, I have this in my platform driver:
  static struct i2c_board_info __initdata tmcu_i2c_devices[] = {
  { I2C_BOARD_INFO(rtc-ds1307, 0x68),
.type = ds1337,
  },
  };
  
  int __init tmcu_i2c_board_devs(void)
  {
  int ret;
  ret = i2c_register_board_info(0, tmcu_i2c_devices,
ARRAY_SIZE(tmcu_i2c_devices));
  return ret;
  }
  arch_initcall(tmcu_i2c_board_devs);
 
 i2c-mpc.c now registers as a dynamically-numbered bus; you need to either
 use the device tree, or call i2c_new_device().
 
 -Scott

Thanks, but is this really so? Reading include/linux/i2c.h makes me
wonder if not the i2c_register_board_info() should still work.
Calling i2c_new_device() from an initcall() procedure does not
seem easy/possible, you need the adapter to do that. Maybe I just
missing something obvious?

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

[2.6 patch] export genphy_restart_aneg

[Adrian Bunk]

This patch fixes the following build error caused by
commit ed94493fb38a665cebcf750dfabe8a6dd13e136f
(mv643xx_eth: convert to phylib):

--  snip  --

...
  Building modules, stage 2.
  MODPOST 1280 modules
ERROR: genphy_restart_aneg [drivers/net/mv643xx_eth.ko] undefined!
...
make[2]: *** [__modpost] Error 1

--  snip  --


Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1716274..f11e900 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -557,6 +557,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
 
return ctl;
 }
+EXPORT_SYMBOL(genphy_restart_aneg);
 
 
 /**

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

Re: [PATCH 2/3] kvmppc: add hypercall infrastructure - guest part v3

[Hollis Blanchard]

On Mon, 2008-10-13 at 11:42 -0500, Kumar Gala wrote:
  +
  +/* Hypercalls use the beat ABI */
  +#define KVM_HYPERCALL_BIN 0x4422
 
 Any reason this isn't 'sc' ?
 
 Also, can we make this sc 1 so its works when we have HW hypervisor  
 support?

Actually, it is sc 1.

Many versions of as (including 2.16.1) don't recognize that instruction.
This is the standard workaround for situations like that.

-- 
Hollis Blanchard
IBM Linux Technology Center

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

Re: [PATCH] powerpc: Add legacy PCI access via sysfs

[Jesse Barnes]

On Monday, October 13, 2008 7:07 am Josh Boyer wrote:
 On Fri, Oct 10, 2008 at 10:39:18AM -0700, Jesse Barnes wrote:
 On Thursday, October 9, 2008 7:50 pm Benjamin Herrenschmidt wrote:
  This patch adds support for legacy_io and legacy_mem files in
  bus class directories in sysfs for powerpc
 
  Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
  ---
 
 Applied to linux-next, thanks.

 Is that targeted towards .28 or .29?  Ben has a 4xx specific patch
 that depends on this one, and I just need to know which version to
 bring that in for.

I was planning on sending it for .28.

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

Re: [PATCH 2/3] kvmppc: add hypercall infrastructure - guest part v3

[Kumar Gala]

On Oct 13, 2008, at 12:29 PM, Hollis Blanchard wrote:


On Mon, 2008-10-13 at 11:42 -0500, Kumar Gala wrote:

+
+/* Hypercalls use the beat ABI */
+#define KVM_HYPERCALL_BIN 0x4422


Any reason this isn't 'sc' ?

Also, can we make this sc 1 so its works when we have HW hypervisor
support?


Actually, it is sc 1.

Many versions of as (including 2.16.1) don't recognize that  
instruction.

This is the standard workaround for situations like that.


Ahh, we'll than can we add that to the comment, and rename  
'KVM_HYPERCALL_BIN' to something like 'EPAPR_HYPERCALL_INSTR'


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

Re: [PATCH] powerpc: compile kernel for linkstations optimized for size

[Guennadi Liakhovetski]

On Mon, 13 Oct 2008, Rogério Brito wrote:

 From: Rogério Brito [EMAIL PROTECTED]
 
 Since Linkstations and Kuroboxes often have *very* little memory (as
 they are embedded systems), it is desirable to get their kernels
 compiled optimized for size.
 
 Signed-off-by: Rogério Brito [EMAIL PROTECTED]
 
 ---
 
 I have been using kernels optimized for size on my Kurobox (standard)
 for many different releases and I have experienced no problem with this
 option enabled. Thus, this patch.

The comment for this option says: watch out for broken compilers, if 
this doesn't hold any more, it should be remove, if it still holds, I 
wouldn't turn this on by default, as I don't think we can test all 
possible (cross- or native-) compilers users might want to use. In any 
case this is one of options that users can select themselves, if it suits 
them. Also I don't think your CC list is correct, you wanted to send this 
to the powerpc list and one of powerpc / subarch maintainer.

Thanks
Guennadi

 
 --- linux/arch/powerpc/configs/linkstation_defconfig.old  2008-10-13 
 00:33:00.0 -0300
 +++ linux/arch/powerpc/configs/linkstation_defconfig  2008-10-13 
 00:38:58.0 -0300
 @@ -90,7 +90,7 @@ CONFIG_NAMESPACES=y
  # CONFIG_PID_NS is not set
  CONFIG_BLK_DEV_INITRD=y
  CONFIG_INITRAMFS_SOURCE=
 -# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
 +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
  CONFIG_SYSCTL=y
  # CONFIG_EMBEDDED is not set
  CONFIG_SYSCTL_SYSCALL=y
 
 
 -- 
 Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8
 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
 Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev
 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: enable heap randomization for linkstations

[Guennadi Liakhovetski]

On Mon, 13 Oct 2008, Rogério Brito wrote:

 The current defconfig for Linkstation/Kuroboxes has the Disable Heap
 Randomization option enabled.
 
 Since some of these machines are facing the internet, it helps to have
 heap randomization enabled. This patch enables it.

Same as the previous patch - this is one of options, that users select 
according to their needs. If any specific distribution enables this option 
by default in their kernels, they can do this too, don't think this is 
critical enough to patch the defconfig.

Thanks
Guennadi

 
 
 Signed-off-by: Rogério Brito [EMAIL PROTECTED]
 
 ---
 
 --- linux/arch/powerpc/configs/linkstation_defconfig.old  2008-10-13 
 00:33:00.0 -0300
 +++ linux/arch/powerpc/configs/linkstation_defconfig  2008-10-13 
 01:11:28.0 -0300
 @@ -1,7 +1,7 @@
  #
  # Automatically generated make config: don't edit
 -# Linux kernel version: 2.6.27-rc4
 -# Thu Aug 21 00:52:05 2008
 +# Linux kernel version: 2.6.27
 +# Mon Oct 13 01:11:21 2008
  #
  # CONFIG_PPC64 is not set
  
 @@ -101,7 +101,7 @@ CONFIG_HOTPLUG=y
  CONFIG_PRINTK=y
  CONFIG_BUG=y
  CONFIG_ELF_CORE=y
 -CONFIG_COMPAT_BRK=y
 +# CONFIG_COMPAT_BRK is not set
  CONFIG_BASE_FULL=y
  CONFIG_FUTEX=y
  CONFIG_ANON_INODES=y
 @@ -1211,7 +1211,6 @@ CONFIG_USB_STORAGE=m
  # CONFIG_USB_STORAGE_ALAUDA is not set
  # CONFIG_USB_STORAGE_ONETOUCH is not set
  # CONFIG_USB_STORAGE_KARMA is not set
 -# CONFIG_USB_STORAGE_SIERRA is not set
  # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
  # CONFIG_USB_LIBUSUAL is not set
  
 
 -- 
 Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8
 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
 Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev
 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code

[Kumar Gala]

On Oct 13, 2008, at 10:41 AM, Josh Boyer wrote:


On Mon, Oct 13, 2008 at 10:49:04AM -0400, Josh Boyer wrote:

On Fri, Sep 12, 2008 at 03:34:46PM -0500, Becky Bruce wrote:
We essentially adopt the 64-bit dma code, with some changes to  
support

32-bit systems, including HIGHMEM.  dma functions on 32-bit are now
invoked via accessor functions which call the correct op for a  
device based

on archdata dma_ops.  If there is no archdata dma_ops, this defaults
to dma_direct_ops.

In addition, the dma_map/unmap_page functions are added to dma_ops
because we can't just fall back on map/unmap_single when HIGHMEM is
enabled. In the case of dma_direct_*, we stop using map/unmap_single
and just use the page version - this saves a lot of ugly
ifdeffing.  We leave map/unmap_single in the dma_ops definition,
though, because they are needed by the iommu code, which does not
implement map/unmap_page.  Ideally, going forward, we will  
completely

eliminate map/unmap_single and just have map/unmap_page, if it's
workable for 64-bit.

Signed-off-by: Becky Bruce [EMAIL PROTECTED]


While doing a buildall this morning, I notice chrp32_defconfig fails
to build with:

drivers/built-in.o: In function `hard_dma_setup':
floppy.c:(.text+0x6e40e): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e412): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e53e): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e546): undefined reference to `isa_bridge_pcidev'
floppy.c:(.text+0x6e54a): undefined reference to `isa_bridge_pcidev'
make[1]: *** [.tmp_vmlinux1] Error 1

(the hard_dma_setup thing is in arch/powerpc/include/asm/floppy.h).

I did a git bisect and it pointed at this commit as causing the build
to fail.  Why, I have no idea.


Ok, I was annoyed enough to look at why.

Basically, before this patch pci_map_single on 32-bit PPC seemed to
be compiled down to __dma_sync(ptr, size, direction); and the dev
parameter to the function was never actually used.  The compiler
seems to have optimized this out entirely, so we don't get the odd
link reference to isa_bridge_pcidev at all.  (Neither pci_map_single
or isa_bridge_pcidev are present in the vmlinux at all).

With the patch, the compiler doesn't do this code elimination
because pci_map_single boils down to dma_map_page, which calls
get_dma_direct_offset with the dev parameter.  So since it is
still used, the compiler can't eliminate it and hence FAIL.

I have no patch for this at the moment.  Someone should look at
it more closely, because this is causing the 5 chrp32_defconfig
users to weep.


Isn't this the type of regression we should fix post -rc1 :)

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

[PATCH 0/5] Acadia support

[Josh Boyer]

Updated patch set for the AMCC Acadia board.  As Arnd suggested, I implemented
the ppc40x_simple platform and simply add Acadia as the first supported board.

The patches are slightly reordered and the defconfig is updated as well.

josh

Josh Boyer (5):
  powerpc/40x: AMCC PowerPC 405EZ Acadia DTS
  powerpc/40x: Add AMCC PowerPC 405EZ to cputable
  powerpc/40x: Add PowerPC 40x simple platform support
  powerpc/40x: Add cuboot wrapper for Acadia board
  powerpc/40x: Add PowerPC 405EZ Acadia defconfig

 arch/powerpc/boot/Makefile |4 +-
 arch/powerpc/boot/cuboot-acadia.c  |  174 ++
 arch/powerpc/boot/dts/acadia.dts   |  224 +++
 arch/powerpc/configs/40x/acadia_defconfig  |  921 
 arch/powerpc/kernel/cputable.c |   13 +
 arch/powerpc/platforms/40x/Kconfig |   22 +
 arch/powerpc/platforms/40x/Makefile|1 +
 arch/powerpc/platforms/40x/ppc40x_simple.c |   80 +++
 8 files changed, 1438 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/cuboot-acadia.c
 create mode 100644 arch/powerpc/boot/dts/acadia.dts
 create mode 100644 arch/powerpc/configs/40x/acadia_defconfig
 create mode 100644 arch/powerpc/platforms/40x/ppc40x_simple.c

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

[PATCH 1/5] powerpc/40x: AMCC PowerPC 405EZ Acadia DTS

[Josh Boyer]

Add the base DTS for the AMCC PowerPC 405EZ Acadia evalution board.
In addition to some of the normal PPC 40x peripherals, the Acadia
board has:
- 64 MiB PSRAM
- NOR and NAND flash
- Two USB 1.1 host ports
- Two CAN 2.0 ports
- ADC and DAC connectors
- LCD display

This adds the basic platform support to build from.

Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
 arch/powerpc/boot/dts/acadia.dts |  224 ++
 1 files changed, 224 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/acadia.dts

diff --git a/arch/powerpc/boot/dts/acadia.dts b/arch/powerpc/boot/dts/acadia.dts
new file mode 100644
index 000..57291f6
--- /dev/null
+++ b/arch/powerpc/boot/dts/acadia.dts
@@ -0,0 +1,224 @@
+/*
+ * Device Tree Source for AMCC Acadia (405EZ)
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = 1;
+   #size-cells = 1;
+   model = amcc,acadia;
+   compatible = amcc,acadia;
+   dcr-parent = {/cpus/[EMAIL PROTECTED];
+
+   aliases {
+   ethernet0 = EMAC0;
+   serial0 = UART0;
+   serial1 = UART1;
+   };
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   [EMAIL PROTECTED] {
+   device_type = cpu;
+   model = PowerPC,405EZ;
+   reg = 0x0;
+   clock-frequency = 0; /* Filled in by wrapper */
+   timebase-frequency = 0; /* Filled in by wrapper */
+   i-cache-line-size = 32;
+   d-cache-line-size = 32;
+   i-cache-size = 16384;
+   d-cache-size = 16384;
+   dcr-controller;
+   dcr-access-method = native;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x0 0x0; /* Filled in by wrapper */
+   };
+
+   UIC0: interrupt-controller {
+   compatible = ibm,uic-405ez, ibm,uic;
+   interrupt-controller;
+   dcr-reg = 0x0c0 0x009;
+   cell-index = 0;
+   #address-cells = 0;
+   #size-cells = 0;
+   #interrupt-cells = 2;
+   };
+
+   plb {
+   compatible = ibm,plb-405ez, ibm,plb3;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   clock-frequency = 0; /* Filled in by wrapper */
+
+   MAL0: mcmal {
+   compatible = ibm,mcmal-405ez, ibm,mcmal;
+   dcr-reg = 0x380 0x62;
+   num-tx-chans = 1;
+   num-rx-chans = 1;
+   interrupt-parent = UIC0;
+   /* 405EZ has only 3 interrupts to the UIC, as
+* SERR, TXDE, and RXDE are or'd together into
+* one UIC bit
+*/
+   interrupts = 
+   0x13 0x4 /* TXEOB */
+   0x15 0x4 /* RXEOB */
+   0x12 0x4 /* SERR, TXDE, RXDE */;
+   };
+
+   POB0: opb {
+   compatible = ibm,opb-405ez, ibm,opb;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   dcr-reg = 0x0a 0x05;
+   clock-frequency = 0; /* Filled in by wrapper */
+
+   UART0: [EMAIL PROTECTED] {
+   device_type = serial;
+   compatible = ns16550;
+   reg = 0xef600300 0x8;
+   virtual-reg = 0xef600300;
+   clock-frequency = 0; /* Filled in by wrapper 
*/
+   current-speed = 115200;
+   interrupt-parent = UIC0;
+   interrupts = 0x5 0x4;
+   };
+
+   UART1: [EMAIL PROTECTED] {
+   device_type = serial;
+   compatible = ns16550;
+   reg = 0xef600400 0x8;
+   clock-frequency = 0; /* Filled in by wrapper 
*/
+   current-speed = 115200;
+   interrupt-parent = UIC0;
+   interrupts = 0x6 0x4;
+   };
+
+   IIC: [EMAIL PROTECTED] {
+   compatible = ibm,iic-405ez, ibm,iic;
+   reg = 0xef600500 0x11;
+

[PATCH 2/5] powerpc/40x: Add AMCC PowerPC 405EZ to cputable

[Josh Boyer]

This adds the AMCC PowerPC 405EZ chip to the cputable

Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
 arch/powerpc/kernel/cputable.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e70d048..b1eb834 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1277,6 +1277,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check  = machine_check_4xx,
.platform   = ppc405,
},
+   {
+   /* 405EZ */
+   .pvr_mask   = 0x,
+   .pvr_value  = 0x4151,
+   .cpu_name   = 405EZ,
+   .cpu_features   = CPU_FTRS_40X,
+   .cpu_user_features  = PPC_FEATURE_32 |
+   PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+   .icache_bsize   = 32,
+   .dcache_bsize   = 32,
+   .machine_check  = machine_check_4xx,
+   .platform   = ppc405,
+   },
{   /* default match */
.pvr_mask   = 0x,
.pvr_value  = 0x,
-- 
1.5.5.1


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

[PATCH 3/5] powerpc/40x: Add PowerPC 40x simple platform support

[Josh Boyer]

This adds a common board file for almost all of the simple PowerPC 40x
boards that exist today.  This is intended to be a single place to add
support for boards that do not differ in platform support from most of the
evaluation boards that are used as reference platforms.  Boards that have
specific requirements or custom hardware setup should still have their own
board.c file.

The first board ported to this is the AMCC PowerPC 405EZ Acadia board.

Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
 arch/powerpc/platforms/40x/Kconfig |   22 
 arch/powerpc/platforms/40x/Makefile|1 +
 arch/powerpc/platforms/40x/ppc40x_simple.c |   80 
 3 files changed, 103 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/platforms/40x/ppc40x_simple.c

diff --git a/arch/powerpc/platforms/40x/Kconfig 
b/arch/powerpc/platforms/40x/Kconfig
index a9260e2..72ba3a7 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -14,6 +14,15 @@
 #  help
 #This option enables support for the CPCI405 board.
 
+config ACADIA
+   bool Acadia
+   depends on 40x
+   default n
+   select PPC40x_SIMPLE
+   select 405EZ
+   help
+ This option enables support for the AMCC 405EZ Acadia evaluation 
board.
+
 config EP405
bool EP405/EP405PC
depends on 40x
@@ -93,6 +102,13 @@ config XILINX_VIRTEX_GENERIC_BOARD
  Most Virtex designs should use this unless it needs to do some
  special configuration at board probe time.
 
+config PPC40x_SIMPLE
+   bool Simple PowerPC 40x board support
+   depends on 40x
+   default n
+   help
+ This option enables the simple PowerPC 40x platform support.
+
 # 40x specific CPU modules, selected based on the board above.
 config NP405H
bool
@@ -118,6 +134,12 @@ config 405EX
select IBM_NEW_EMAC_EMAC4
select IBM_NEW_EMAC_RGMII
 
+config 405EZ
+   bool
+   select IBM_NEW_EMAC_NO_FLOW_CTRL
+   select IBM_NEW_EMAC_MAL_CLR_ICINTSTAT
+   select IBM_NEW_EMAC_MAL_COMMON_ERR
+
 config 405GPR
bool
 
diff --git a/arch/powerpc/platforms/40x/Makefile 
b/arch/powerpc/platforms/40x/Makefile
index 5533a5c..1d93273 100644
--- a/arch/powerpc/platforms/40x/Makefile
+++ b/arch/powerpc/platforms/40x/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_MAKALU)+= makalu.o
 obj-$(CONFIG_WALNUT)   += walnut.o
 obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD)  += virtex.o
 obj-$(CONFIG_EP405)+= ep405.o
+obj-$(CONFIG_PPC40x_SIMPLE)+= ppc40x_simple.o
diff --git a/arch/powerpc/platforms/40x/ppc40x_simple.c 
b/arch/powerpc/platforms/40x/ppc40x_simple.c
new file mode 100644
index 000..4498a86
--- /dev/null
+++ b/arch/powerpc/platforms/40x/ppc40x_simple.c
@@ -0,0 +1,80 @@
+/*
+ * Generic PowerPC 40x platform support
+ *
+ * Copyright 2008 IBM Corporation
+ *
+ * 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.
+ *
+ * This implements simple platform support for PowerPC 44x chips.  This is
+ * mostly used for eval boards or other simple and generic 44x boards.  If
+ * your board has custom functions or hardware, then you will likely want to
+ * implement your own board.c file to accommodate it.
+ */
+
+#include asm/machdep.h
+#include asm/pci-bridge.h
+#include asm/ppc4xx.h
+#include asm/prom.h
+#include asm/time.h
+#include asm/udbg.h
+#include asm/uic.h
+
+#include linux/init.h
+#include linux/of_platform.h
+
+static __initdata struct of_device_id ppc40x_of_bus[] = {
+   { .compatible = ibm,plb3, },
+   { .compatible = ibm,plb4, },
+   { .compatible = ibm,opb, },
+   { .compatible = ibm,ebc, },
+   { .compatible = simple-bus, },
+   {},
+};
+
+static int __init ppc40x_device_probe(void)
+{
+   of_platform_bus_probe(NULL, ppc40x_of_bus, NULL);
+
+   return 0;
+}
+machine_device_initcall(ppc40x_simple, ppc40x_device_probe);
+
+/* This is the list of boards that can be supported by this simple
+ * platform code.  This does _not_ mean the boards are compatible,
+ * as they most certainly are not from a device tree perspective.
+ * However, their differences are handled by the device tree and the
+ * drivers and therefore they don't need custom board support files.
+ *
+ * Again, if your board needs to do things differently then create a
+ * board.c file for it rather than adding it to this list.
+ */
+static char *board[] __initdata = {
+   amcc,acadia
+};
+
+static int __init ppc40x_probe(void)
+{
+   unsigned long root = of_get_flat_dt_root();
+   int i = 0;
+
+   for (i = 0; i  ARRAY_SIZE(board); i++) {
+   if (of_flat_dt_is_compatible(root, board[i])) {
+   ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+

[PATCH 4/5] powerpc/40x: Add cuboot wrapper for Acadia board

[Josh Boyer]

This adds a cuboot wrapper for the AMCC PowerPC 405EZ Acadia board.  The
clocking code is derived from U-Boot, originally written by Stefan Roese.

Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
 arch/powerpc/boot/Makefile|4 +-
 arch/powerpc/boot/cuboot-acadia.c |  174 +
 2 files changed, 177 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/cuboot-acadia.c

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 6403275..5f4a59c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -68,7 +68,8 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c 
cuboot-85xx.c holly.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 virtex.c redboot-83xx.c cuboot-sam440ep.c
+   virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
+   cuboot-acadia.c
 src-boot := $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -211,6 +212,7 @@ image-$(CONFIG_DEFAULT_UIMAGE)  += uImage
 # Board ports in arch/powerpc/platform/40x/Kconfig
 image-$(CONFIG_EP405)  += dtbImage.ep405
 image-$(CONFIG_WALNUT) += treeImage.walnut
+image-$(CONFIG_ACADIA) += cuImage.acadia
 
 # Board ports in arch/powerpc/platform/44x/Kconfig
 image-$(CONFIG_EBONY)  += treeImage.ebony cuImage.ebony
diff --git a/arch/powerpc/boot/cuboot-acadia.c 
b/arch/powerpc/boot/cuboot-acadia.c
new file mode 100644
index 000..0634aba
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-acadia.c
@@ -0,0 +1,174 @@
+/*
+ * Old U-boot compatibility for Acadia
+ *
+ * Author: Josh Boyer [EMAIL PROTECTED]
+ *
+ * Copyright 2008 IBM Corporation
+ *
+ * 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 ops.h
+#include io.h
+#include dcr.h
+#include stdio.h
+#include 4xx.h
+#include 44x.h
+#include cuboot.h
+
+#define TARGET_4xx
+#include ppcboot.h
+
+static bd_t bd;
+
+#define CPR_PERD0_SPIDV_MASK   0x000F /* SPI Clock Divider */
+
+#define PLLC_SRC_MASK 0x2000 /* PLL feedback source */
+
+#define PLLD_FBDV_MASK0x1F00 /* PLL feedback divider value */
+#define PLLD_FWDVA_MASK0x000F /* PLL forward divider A value */
+#define PLLD_FWDVB_MASK0x0700 /* PLL forward divider B value */
+
+#define PRIMAD_CPUDV_MASK  0x0F00 /* CPU Clock Divisor Mask */
+#define PRIMAD_PLBDV_MASK  0x000F /* PLB Clock Divisor Mask */
+#define PRIMAD_OPBDV_MASK  0x0F00 /* OPB Clock Divisor Mask */
+#define PRIMAD_EBCDV_MASK  0x000F /* EBC Clock Divisor Mask */
+
+#define PERD0_PWMDV_MASK   0xFF00 /* PWM Divider Mask */
+#define PERD0_SPIDV_MASK   0x000F /* SPI Divider Mask */
+#define PERD0_U0DV_MASK0xFF00 /* UART 0 Divider Mask */
+#define PERD0_U1DV_MASK0x00FF /* UART 1 Divider Mask */
+
+static void get_clocks(void)
+{
+   unsigned long sysclk, cpr_plld, cpr_pllc, cpr_primad, plloutb, i;
+   unsigned long pllFwdDiv, pllFwdDivB, pllFbkDiv, pllPlbDiv, pllExtBusDiv;
+   unsigned long pllOpbDiv, freqEBC, freqUART, freqOPB;
+   unsigned long div;  /* total divisor udiv * bdiv */
+   unsigned long umin; /* minimum udiv */
+   unsigned short diff;/* smallest diff */
+   unsigned long udiv; /* best udiv */
+   unsigned short idiff;   /* current diff */
+   unsigned short ibdiv;   /* current bdiv */
+   unsigned long est;  /* current estimate */
+   unsigned long baud;
+   void *np;
+
+   /* read the sysclk value from the CPLD */
+   sysclk = (in_8((unsigned char *)0x8000) == 0xc) ?  : 
3000;
+
+   /*
+* Read PLL Mode registers
+*/
+   cpr_plld = CPR0_READ(DCRN_CPR0_PLLD);
+   cpr_pllc = CPR0_READ(DCRN_CPR0_PLLC);
+
+   /*
+* Determine forward divider A
+*/
+   pllFwdDiv = ((cpr_plld  PLLD_FWDVA_MASK)  16);
+
+   /*
+* Determine forward divider B
+*/
+   pllFwdDivB = ((cpr_plld  PLLD_FWDVB_MASK)  8);
+   if (pllFwdDivB == 0)
+   pllFwdDivB = 8;
+
+   /*
+* Determine FBK_DIV.
+*/
+   pllFbkDiv = ((cpr_plld  PLLD_FBDV_MASK)  24);
+   if (pllFbkDiv == 0)
+   pllFbkDiv = 256;
+
+   /*
+* Read CPR_PRIMAD register
+*/
+   cpr_primad = CPR0_READ(DCRN_CPR0_PRIMAD);
+
+   /*
+* Determine PLB_DIV.
+*/
+   pllPlbDiv = ((cpr_primad  

[PATCH 5/5] powerpc/40x: Add PowerPC 405EZ Acadia defconfig

[Josh Boyer]

Add simple defconfig for the AMCC PowerPC 405EZ Acadia evaluation board

Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
 arch/powerpc/configs/40x/acadia_defconfig |  921 +
 1 files changed, 921 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/configs/40x/acadia_defconfig

diff --git a/arch/powerpc/configs/40x/acadia_defconfig 
b/arch/powerpc/configs/40x/acadia_defconfig
new file mode 100644
index 000..39bd9eb
--- /dev/null
+++ b/arch/powerpc/configs/40x/acadia_defconfig
@@ -0,0 +1,921 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.27-rc5
+# Mon Oct 13 13:47:16 2008
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+# CONFIG_6xx is not set
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+CONFIG_40x=y
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_4xx=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_NOT_COHERENT_CACHE=y
+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_HAVE_LATENCYTOP_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 is not set
+CONFIG_PPC_DCR_NATIVE=y
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_PPC_DCR=y
+CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=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=14
+# CONFIG_CGROUPS is not set
+CONFIG_GROUP_SCHED=y
+# CONFIG_FAIR_GROUP_SCHED is not set
+# CONFIG_RT_GROUP_SCHED is not set
+CONFIG_USER_SCHED=y
+# CONFIG_CGROUP_SCHED is not set
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+# CONFIG_RELAY is not set
+# CONFIG_NAMESPACES is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SYSCTL=y
+CONFIG_EMBEDDED=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_KALLSYMS_EXTRA_PASS=y
+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 is not set
+# CONFIG_MARKERS is not set
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_HAVE_IOREMAP_PROT=y
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_ARCH_TRACEHOOK=y
+# CONFIG_HAVE_DMA_ATTRS is not set
+# CONFIG_USE_GENERIC_SMP_HELPERS is not set
+# CONFIG_HAVE_CLK is not set
+CONFIG_PROC_PAGE_MONITOR=y
+# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+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=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BLK_DEV_INTEGRITY is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED=anticipatory
+CONFIG_CLASSIC_RCU=y
+# CONFIG_PPC4xx_PCI_EXPRESS is not set
+
+#
+# Platform support
+#
+# CONFIG_PPC_CELL is not set
+# CONFIG_PPC_CELL_NATIVE is not set
+# CONFIG_PQ2ADS is not set
+CONFIG_ACADIA=y
+# CONFIG_EP405 is not set
+# CONFIG_KILAUEA is not set
+# CONFIG_MAKALU is not set
+# CONFIG_WALNUT is not set
+# CONFIG_XILINX_VIRTEX_GENERIC_BOARD is not set
+CONFIG_PPC40x_SIMPLE=y
+CONFIG_405EZ=y
+# CONFIG_IPIC is not set
+# CONFIG_MPIC is not set
+# CONFIG_MPIC_WEIRD is not set
+# CONFIG_PPC_I8259 is not set
+# CONFIG_PPC_RTAS is not set
+# CONFIG_MMIO_NVRAM is not set
+# 

RE: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y

[Brandeburg, Jesse]

Adrian Bunk wrote:
 On Mon, Oct 13, 2008 at 03:45:59PM +0530, Kamalesh Babulal wrote:
 Hi,
 
2.6.27-git2 kernel build fails, while building the kernel with

from subject, on PPC.

 allyesconfig option. The allyesconfig selects CONFIG_INTEL_IOATDMA=y
 
 CC   drivers/dma/ioat_dca.o
 drivers/dma/ioat_dca.c: In function ‘dca_enabled_in_bios’:
 drivers/dma/ioat_dca.c:81: error: implicit declaration of function
 ‘cpuid_eax’ drivers/dma/ioat_dca.c: In function
 ‘system_has_dca_enabled’: 
 drivers/dma/ioat_dca.c:91: error: implicit declaration of function
 ‘boot_cpu_has’ drivers/dma/ioat_dca.c:91: error:
 ‘X86_FEATURE_DCA’ undeclared (first use in this function)
 drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is
 reported only once drivers/dma/ioat_dca.c:91: error: for each
 function it appears in.)  
 drivers/dma/ioat_dca.c: In function ‘ioat_dca_get_tag’:
 drivers/dma/ioat_dca.c:190: error: implicit declaration of function
 ‘cpu_physical_id’ make[2]: *** [drivers/dma/ioat_dca.o] Error 1
 make[1]: *** [drivers/dma] Error 2
 make: *** [drivers] Error 2
 ...
 
 Thanks for the report, the MYRI10GE and IXGBE commits that introduced
 the select's are really broken.

it fixed an obvious bug with CONFIG_IXGBE=y and CONFIG_INTEL_IOATDMA=m, 
unfortunate that it is so difficult to use Kconfig for the uninitiated.
 
 For fixing it I need to know the intended semantics.
 
 Brian, Jesse, is it OK to limit the drivers to m with
 CONFIG_INTEL_IOATDMA=m ?

why is the IOATDMA driver not depending on x86?  x86 hardware (32 and 64 bit) 
are the only machines that will have ioatdma support, since the ioatdma (and 
dca) device is only in Intel server chipsets since S5000 (aka S5000, S5400, 
S7400 and derivatives/followons)

What we want, is myri10ge and ixgbe drivers that can build whether or not 
CONFIG_INTEL_IOATDMA is enabled.  IF CONFIG_INTEL_IOATDMA *is* enabled (which 
it should not be on PPC) then there are several cases we want to work:
CONFIG_INTEL_IOATDMA=m  --- CONFIG_IXGBE=[m|n]
CONFIG_INTEL_IOATDMA=y  --- CONFIG_IXGBE=[m|y|n]
CONFIG_INTEL_IOATDMA=n  --- CONFIG_IXGBE=[m|y|n]
CONFIG_INTEL_IOATDMA depends on X86

same for myri10ge I think.  I hope that cleared something up, we can seriously 
use some help from the experts to get Kconfig correct for this.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code

[Josh Boyer]

On Mon, 13 Oct 2008 13:06:36 -0500
Kumar Gala [EMAIL PROTECTED] wrote:

 
 On Oct 13, 2008, at 10:41 AM, Josh Boyer wrote:
 
  On Mon, Oct 13, 2008 at 10:49:04AM -0400, Josh Boyer wrote:
  On Fri, Sep 12, 2008 at 03:34:46PM -0500, Becky Bruce wrote:
  We essentially adopt the 64-bit dma code, with some changes to  
  support
  32-bit systems, including HIGHMEM.  dma functions on 32-bit are now
  invoked via accessor functions which call the correct op for a  
  device based
  on archdata dma_ops.  If there is no archdata dma_ops, this defaults
  to dma_direct_ops.
 
  In addition, the dma_map/unmap_page functions are added to dma_ops
  because we can't just fall back on map/unmap_single when HIGHMEM is
  enabled. In the case of dma_direct_*, we stop using map/unmap_single
  and just use the page version - this saves a lot of ugly
  ifdeffing.  We leave map/unmap_single in the dma_ops definition,
  though, because they are needed by the iommu code, which does not
  implement map/unmap_page.  Ideally, going forward, we will  
  completely
  eliminate map/unmap_single and just have map/unmap_page, if it's
  workable for 64-bit.
 
  Signed-off-by: Becky Bruce [EMAIL PROTECTED]
 
  While doing a buildall this morning, I notice chrp32_defconfig fails
  to build with:
 
  drivers/built-in.o: In function `hard_dma_setup':
  floppy.c:(.text+0x6e40e): undefined reference to `isa_bridge_pcidev'
  floppy.c:(.text+0x6e412): undefined reference to `isa_bridge_pcidev'
  floppy.c:(.text+0x6e53e): undefined reference to `isa_bridge_pcidev'
  floppy.c:(.text+0x6e546): undefined reference to `isa_bridge_pcidev'
  floppy.c:(.text+0x6e54a): undefined reference to `isa_bridge_pcidev'
  make[1]: *** [.tmp_vmlinux1] Error 1
 
  (the hard_dma_setup thing is in arch/powerpc/include/asm/floppy.h).
 
  I did a git bisect and it pointed at this commit as causing the build
  to fail.  Why, I have no idea.
 
  Ok, I was annoyed enough to look at why.
 
  Basically, before this patch pci_map_single on 32-bit PPC seemed to
  be compiled down to __dma_sync(ptr, size, direction); and the dev
  parameter to the function was never actually used.  The compiler
  seems to have optimized this out entirely, so we don't get the odd
  link reference to isa_bridge_pcidev at all.  (Neither pci_map_single
  or isa_bridge_pcidev are present in the vmlinux at all).
 
  With the patch, the compiler doesn't do this code elimination
  because pci_map_single boils down to dma_map_page, which calls
  get_dma_direct_offset with the dev parameter.  So since it is
  still used, the compiler can't eliminate it and hence FAIL.
 
  I have no patch for this at the moment.  Someone should look at
  it more closely, because this is causing the 5 chrp32_defconfig
  users to weep.
 
 Isn't this the type of regression we should fix post -rc1 :)

I don't think it matters much when it gets fixed, pre or post -rc1.  But
it should probably get fixed.  My hack was to pull isa_bridge_pcidev
into pci-common.c and export it from there.  The 64-bit PCI code can
initialized it, and the 32-bit can leave it NULL.  But I have no idea
if that is sane.  If so, I can probably submit a patch for it.

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

Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code

[Kumar Gala]

While doing a buildall this morning, I notice chrp32_defconfig  
fails

to build with:

drivers/built-in.o: In function `hard_dma_setup':
floppy.c:(.text+0x6e40e): undefined reference to  
`isa_bridge_pcidev'
floppy.c:(.text+0x6e412): undefined reference to  
`isa_bridge_pcidev'
floppy.c:(.text+0x6e53e): undefined reference to  
`isa_bridge_pcidev'
floppy.c:(.text+0x6e546): undefined reference to  
`isa_bridge_pcidev'
floppy.c:(.text+0x6e54a): undefined reference to  
`isa_bridge_pcidev'

make[1]: *** [.tmp_vmlinux1] Error 1

(the hard_dma_setup thing is in arch/powerpc/include/asm/floppy.h).

I did a git bisect and it pointed at this commit as causing the  
build

to fail.  Why, I have no idea.


Ok, I was annoyed enough to look at why.

Basically, before this patch pci_map_single on 32-bit PPC seemed to
be compiled down to __dma_sync(ptr, size, direction); and the dev
parameter to the function was never actually used.  The compiler
seems to have optimized this out entirely, so we don't get the odd
link reference to isa_bridge_pcidev at all.  (Neither pci_map_single
or isa_bridge_pcidev are present in the vmlinux at all).

With the patch, the compiler doesn't do this code elimination
because pci_map_single boils down to dma_map_page, which calls
get_dma_direct_offset with the dev parameter.  So since it is
still used, the compiler can't eliminate it and hence FAIL.

I have no patch for this at the moment.  Someone should look at
it more closely, because this is causing the 5 chrp32_defconfig
users to weep.


Isn't this the type of regression we should fix post -rc1 :)


I don't think it matters much when it gets fixed, pre or post -rc1.   
But

it should probably get fixed.  My hack was to pull isa_bridge_pcidev
into pci-common.c and export it from there.  The 64-bit PCI code can
initialized it, and the 32-bit can leave it NULL.  But I have no idea
if that is sane.  If so, I can probably submit a patch for it.


I was just joking around about our new regression policy.. anyways I  
hope ben or maybe anton can comment about the ISA code.


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

Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y

[Brice Goglin]

Brandeburg, Jesse wrote:
 What we want, is myri10ge and ixgbe drivers that can build whether or not 
 CONFIG_INTEL_IOATDMA is enabled.  IF CONFIG_INTEL_IOATDMA *is* enabled (which 
 it should not be on PPC) then there are several cases we want to work:
 CONFIG_INTEL_IOATDMA=m  --- CONFIG_IXGBE=[m|n]
 CONFIG_INTEL_IOATDMA=y  --- CONFIG_IXGBE=[m|y|n]
 CONFIG_INTEL_IOATDMA=n  --- CONFIG_IXGBE=[m|y|n]
 CONFIG_INTEL_IOATDMA depends on X86
   

I am not sure I want to prevent myri10ge=y just because ioatdma=m.

I would vote for adding some Kconfig stuff to define CONFIG_MYRI10GE_DCA
as boolean set to yes if (IOATDMA=y and MYRI10GE=y/m) or (IOATDMA=m and
MYRI10GE=m). And then use #ifdef CONFIG_MYRI10GE_DCA in the driver source.

Brice

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

Re: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27

[Scott Wood]

Joakim Tjernlund wrote:

On Mon, 2008-10-13 at 11:31 -0500, Scott Wood wrote:

i2c-mpc.c now registers as a dynamically-numbered bus; you need to either
use the device tree, or call i2c_new_device().


Thanks, but is this really so? Reading include/linux/i2c.h makes me
wonder if not the i2c_register_board_info() should still work.


Why?  Note that the add-on versus mainboard distinction in the 
comment is just an example; the actual distinction is 
dynamically-numbered versus statically-numbered.  Since the controller 
itself is probed from the device tree, there's no good way of statically 
assigning a bus number to it.



Calling i2c_new_device() from an initcall() procedure does not
seem easy/possible, you need the adapter to do that. Maybe I just
missing something obvious?


The obvious and easy way is to just use the device tree.

If that isn't possible (such as due to device trees embedded in existing 
firmware), you can find the adapter device as a child of the of_device.


Finding the of_device from the device_node may be difficult, though.
We could have i2c-mpc set node-data to the of_device (or maybe the 
adapter struct), or maybe should add an of_device member of device_node 
that gets filled in by of_platform?


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

Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y

[Adrian Bunk]

On Mon, Oct 13, 2008 at 08:21:45PM +0200, Brice Goglin wrote:
 Brandeburg, Jesse wrote:
  What we want, is myri10ge and ixgbe drivers that can build whether or not 
  CONFIG_INTEL_IOATDMA is enabled.  IF CONFIG_INTEL_IOATDMA *is* enabled 
  (which it should not be on PPC) then there are several cases we want to 
  work:
  CONFIG_INTEL_IOATDMA=m  --- CONFIG_IXGBE=[m|n]
  CONFIG_INTEL_IOATDMA=y  --- CONFIG_IXGBE=[m|y|n]
  CONFIG_INTEL_IOATDMA=n  --- CONFIG_IXGBE=[m|y|n]
  CONFIG_INTEL_IOATDMA depends on X86
 
 I am not sure I want to prevent myri10ge=y just because ioatdma=m.
...

Technically both solutions are possible, which to choose is just a 
policy decision you have to agree on.

In practice it will anyway only rarely matter.

But considering that igb is in a similar situation it would be nice if 
all 3 drivers would handle it the same way.

 Brice

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [PATCH] powerpc: enable heap randomization for linkstations

[Scott Wood]

On Mon, Oct 13, 2008 at 08:05:09PM +0200, Guennadi Liakhovetski wrote:
 On Mon, 13 Oct 2008, Rogério Brito wrote:
 
  The current defconfig for Linkstation/Kuroboxes has the Disable Heap
  Randomization option enabled.
  
  Since some of these machines are facing the internet, it helps to have
  heap randomization enabled. This patch enables it.
 
 Same as the previous patch - this is one of options, that users select 
 according to their needs. If any specific distribution enables this option 
 by default in their kernels, they can do this too, don't think this is 
 critical enough to patch the defconfig.

Just because users/distros can change it doesn't mean it's pointless to
discuss what default is sane, and make changes if the current default
isn't.

For security-related options it's usually best to default to the more
secure state, especially since the option description talks about it
being needed mainly for libc5 compatibility -- did libc5 ever even exist
for powerpc?  

The only reason it was turned on in the first place was likely the
default y, which in turn is there to avoid breaking old x86 distros.

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

Re: [2.6 patch] export genphy_restart_aneg

[David Miller]

From: Andy Fleming [EMAIL PROTECTED]
Date: Mon, 13 Oct 2008 13:04:30 -0500

 
 On Oct 13, 2008, at 12:19, Adrian Bunk wrote:
 
  This patch fixes the following build error caused by
  commit ed94493fb38a665cebcf750dfabe8a6dd13e136f
  (mv643xx_eth: convert to phylib):
 
  --  snip  --
 
  ...
   Building modules, stage 2.
   MODPOST 1280 modules
  ERROR: genphy_restart_aneg [drivers/net/mv643xx_eth.ko] undefined!
  ...
  make[2]: *** [__modpost] Error 1
 
  --  snip  --
 
 
  Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
 
 Could you get genphy_setup_forced, too?  It doesn't appear to be used, but 
 it's currently in include/linux/phy.h, and not static.

When there is a use we can add the export.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27

[Joakim Tjernlund]

 -Original Message-
 From: Scott Wood [mailto:[EMAIL PROTECTED]
 Sent: den 13 oktober 2008 20:31
 To: [EMAIL PROTECTED]
 Cc: 'linuxppc-dev Development'
 Subject: Re: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 
 2.6.27
 
 Joakim Tjernlund wrote:
  On Mon, 2008-10-13 at 11:31 -0500, Scott Wood wrote:
  i2c-mpc.c now registers as a dynamically-numbered bus; you need to either
  use the device tree, or call i2c_new_device().
 
  Thanks, but is this really so? Reading include/linux/i2c.h makes me
  wonder if not the i2c_register_board_info() should still work.
 
 Why?  Note that the add-on versus mainboard distinction in the
 comment is just an example; the actual distinction is
 dynamically-numbered versus statically-numbered.  Since the controller
 itself is probed from the device tree, there's no good way of statically
 assigning a bus number to it.

Because all the kernel comments I can see still implies that this should work
and because this was the only way in earlier releases to add an i2c device.

 
  Calling i2c_new_device() from an initcall() procedure does not
  seem easy/possible, you need the adapter to do that. Maybe I just
  missing something obvious?
 
 The obvious and easy way is to just use the device tree.
 
 If that isn't possible (such as due to device trees embedded in existing
 firmware), you can find the adapter device as a child of the of_device.

Possible yes, safe no. As is now I cannot use 2.6.27 on my current u-boot. 
and that may cause trouble in the field.

I always had the impression that OF was an optional add on, but now it seems
that it is mandatory for i2c?
 
 Finding the of_device from the device_node may be difficult, though.
 We could have i2c-mpc set node-data to the of_device (or maybe the
 adapter struct), or maybe should add an of_device member of device_node
 that gets filled in by of_platform?

hmm, no easy way out then? I need a way to do this from my board code without
adding new stuff to the driver. A hack that only works in 2.6.27 will do.

 Jocke


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

Re: [PATCH v7] ppc4xx gpio driver

[Josh Boyer]

On Mon, Oct 13, 2008 at 12:04:09PM -0400, Steven A. Falco wrote:
This patch adds support for the GPIO functions of PPC40x and PPC44x
SOCs.

Signed-off-by: Steve Falco [EMAIL PROTECTED]
Acked-by: Stefan Roese [EMAIL PROTECTED]
Acked-by: Sean MacLennan [EMAIL PROTECTED]
---
I believe I've satisfied all the comments that have been made for this
driver.

Josh - is there anything else you'd like to see before pulling this into
your tree?

Nope.  It should be added a bit later today.  Nice job.

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

Re: MPC8321, ethernet and i2c problems after upgrade from 2.6.25 to 2.6.27

[Scott Wood]

Joakim Tjernlund wrote:

Because all the kernel comments I can see still implies that this should work


Which kernel comments?


and because this was the only way in earlier releases to add an i2c device.


We've supported enumerating i2c-mpc devices using the device tree for 
almost as long as there's been new-style i2c devices.



The obvious and easy way is to just use the device tree.

If that isn't possible (such as due to device trees embedded in existing
firmware), you can find the adapter device as a child of the of_device.


Possible yes, safe no. As is now I cannot use 2.6.27 on my current u-boot. 


Why not?  U-boot allows you to pass in a device tree dynamically.


I always had the impression that OF was an optional add on, but now it seems
that it is mandatory for i2c?


It's mandatory for device drivers such as i2c-mpc that expect it.


Finding the of_device from the device_node may be difficult, though.
We could have i2c-mpc set node-data to the of_device (or maybe the
adapter struct), or maybe should add an of_device member of device_node
that gets filled in by of_platform?


hmm, no easy way out then? I need a way to do this from my board code without
adding new stuff to the driver. A hack that only works in 2.6.27 will do.


You could add the node to the device tree from platform code, if you run 
before the i2c adapter's probe() runs.  Or, if you really want to stick 
with your current way of doing things, and are willing to own both 
pieces if it breaks, you can comment out this test in 
i2c_register_adapter, and always call i2c_scan_static_board_info:


if (adap-nr  __i2c_first_dynamic_bus_num)
i2c_scan_static_board_info(adap);

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

Re: [PATCH] powerpc: enable heap randomization for linkstations

[Guennadi Liakhovetski]

On Mon, 13 Oct 2008, Scott Wood wrote:

 On Mon, Oct 13, 2008 at 08:05:09PM +0200, Guennadi Liakhovetski wrote:
  On Mon, 13 Oct 2008, Rogério Brito wrote:
  
   The current defconfig for Linkstation/Kuroboxes has the Disable Heap
   Randomization option enabled.
   
   Since some of these machines are facing the internet, it helps to have
   heap randomization enabled. This patch enables it.
  
  Same as the previous patch - this is one of options, that users select 
  according to their needs. If any specific distribution enables this option 
  by default in their kernels, they can do this too, don't think this is 
  critical enough to patch the defconfig.
 
 Just because users/distros can change it doesn't mean it's pointless to
 discuss what default is sane, and make changes if the current default
 isn't.
 
 For security-related options it's usually best to default to the more
 secure state, especially since the option description talks about it
 being needed mainly for libc5 compatibility -- did libc5 ever even exist
 for powerpc?  

In a 2.6.27-rc5-ish snapshot I counted 68 enabled and 11 disabled 
CONFIG_COMPAT_BRK under arch/powerpc/configs/. Ok, enabling it for all 
would be a bit rude, and one has to start somewhere...

 The only reason it was turned on in the first place was likely the
 default y, which in turn is there to avoid breaking old x86 distros.

Then maybe it would be better to make default y only for some platforms?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc: pseries_remove_lmb() should validate pfn

[Nathan Fontenot]

The pfn of the memory to be removed should be validated prior to
attempting to remove the memory.  In cases where the probe of a
memory section fails during hotplug add, the pfn for the lmb may
not be valid.

Signed-off-by: Badari Pulavarty [EMAIL PROTECTED]
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]

---

--- linux-2.6.orig/arch/powerpc/platforms/pseries/hotplug-memory.c  
2008-10-01 14:20:08.0 -0500
+++ linux-2.6/arch/powerpc/platforms/pseries/hotplug-memory.c   2008-10-13 
13:19:49.0 -0500
@@ -22,6 +22,12 @@
int ret;

start_pfn = base  PAGE_SHIFT;
+
+   if (!pfn_valid(start_pfn)) {
+   lmb_remove(base, lmb_size);
+   return 0;
+   }
+
zone = page_zone(pfn_to_page(start_pfn));

/*

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

Re: [PATCH 2/16] xics: update default_server during migrate_irqs_away

[Nathan Fontenot]

Milton Miller wrote:

Currently, every time we determine which irq server to use, we check if
default_server, which is the id of the bootcpu, is still online.  But
default_server is a hardware cpu, not the logical cpu id needed to index
cpu_online_map.  


Since the default server can only go offline during a cpu hotplug event,
explicitly check the default server and choose the new one when we move
irqs away from the cpu being offlined.

This has the added benefit of only needing the boot_cpuid to be updated
and not relying on the cpu being marked offline during migrate_irqs_away.

Also, since xics_update_irq_servers only reads device tree information, we
can call it before xics_init_host in xics_init_IRQ and then default_server
will always be valid when we can reach get_irq_server via the host ops.

Signed-off-by: Milton Miller [EMAIL PROTECTED]


Acked-by: Nathan Fontenot [EMAIL PROTECTED]


---
I realized the hard vs soft cpu id as I was writing the patch description.
get_irq_server is called from unmask and set affinity.  


The effects of this bug would be the increased pathlength to walk the
device tree in the unmask and set affinity methods, and possible failure
to migrate irqs during cpu hotplug removal (not likely to be seen on
until a sequence of remove and adds is performed).

This check dates to 2.6.25 via de0723dcca6e593a12a259798a54eb0e82628fb8.

Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04 
16:36:07.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c  2008-10-04 
16:36:09.0 -0500
@@ -208,9 +208,6 @@ static int get_irq_server(unsigned int v
cpumask_t cpumask = irq_desc[virq].affinity;
cpumask_t tmp = CPU_MASK_NONE;
 
-	if (! cpu_isset(default_server, cpu_online_map))

-   xics_update_irq_servers();
-
if (!distribute_irqs)
return default_server;
 
@@ -685,8 +682,8 @@ void __init xics_init_IRQ(void)

if (found == 0)
return;
 
-	xics_init_host();

xics_update_irq_servers();
+   xics_init_host();
 
 	if (firmware_has_feature(FW_FEATURE_LPAR))

ppc_md.get_irq = xics_get_irq_lpar;
@@ -779,6 +776,10 @@ void xics_migrate_irqs_away(void)
int cpu = smp_processor_id(), hw_cpu = hard_smp_processor_id();
unsigned int irq, virq;
 
+	/* If we used to be the default server, move to the new boot_cpuid */

+   if (hw_cpu == default_server)
+   xics_update_irq_servers();
+
/* Reject any interrupt that was queued to us... */
xics_set_cpu_priority(0);
 

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

Re: [PATCH] powerpc/cell/oprofile: vma_map: fix test on overlay_tbl_offset

[Benjamin Herrenschmidt]

On Mon, 2008-10-13 at 17:21 +0200, Robert Richter wrote:
 On 07.10.08 10:38:33, Arnd Bergmann wrote:
  From: Roel Kluin [EMAIL PROTECTED]
  
  Offset is unsigned and when an address isn't found in the vma map
  vma_map_lookup() returns the vma physical address + 0x1000.
  
  vma_map_lookup used to return 0x on a failed lookup, but
  a change was made to return the vma physical address + 0x1000
  There are two callers of vam_map_lookup: one of them correctly 
  deals with this new return value, but the other (below) did not.  
  
  Signed-off-by: Roel Kluin [EMAIL PROTECTED]
  Acked-by: Maynard Johnson [EMAIL PROTECTED]
  Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  Cc: Carl Love [EMAIL PROTECTED]
 
 The patch has been applied to the powerpc-for-paul branch of
 git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git

I think I already put it in the powerpc next branch.

Cheers,
Ben.


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

Re: performance: memcpy vs. __copy_tofrom_user

[Benjamin Herrenschmidt]

 It doesn't need to be done in non-preemptible sections, if you have a
 separate per-thread save area for kernel fp/altivec use (and appropriate
 flags so an FP unavailable handler knows which regs to restore), and you
 can avoid using it in a preempting context.

Yuck.

Ben.


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

Re: [PATCH] powerpc: enable heap randomization for linkstations

[Rogério Brito]

Hi, Scott, Guennadi.

On 13/10/2008, at 16:44, Scott Wood wrote:


On Mon, Oct 13, 2008 at 08:05:09PM +0200, Guennadi Liakhovetski wrote:

On Mon, 13 Oct 2008, Rogério Brito wrote:

The current defconfig for Linkstation/Kuroboxes has the Disable  
Heap

Randomization option enabled.

Since some of these machines are facing the internet, it helps to  
have

heap randomization enabled. This patch enables it.


Same as the previous patch - this is one of options, that users  
select
according to their needs. If any specific distribution enables  
this option
by default in their kernels, they can do this too, don't think  
this is

critical enough to patch the defconfig.


I think that the matter is not being critical or not, but of  
including a sane default as the kernel should be a place for best- 
current-practices.


Just because users/distros can change it doesn't mean it's  
pointless to

discuss what default is sane, and make changes if the current default
isn't.


Exactly my point.


For security-related options it's usually best to default to the more
secure state, especially since the option description talks about it
being needed mainly for libc5 compatibility -- did libc5 ever even  
exist

for powerpc?


I don't know, but even Debian's very ancient distributions all came  
with libc6 on powerpc.



The only reason it was turned on in the first place was likely the
default y, which in turn is there to avoid breaking old x86 distros.


Exactly. Agreed 100%.


Regards, Rogério Brito.

--
Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org



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

Re: [PATCH] powerpc: compile kernel for linkstations optimized for size

[Rogério Brito]

Hi, Guennadi.

On 13/10/2008, at 16:03, Guennadi Liakhovetski wrote:


On Mon, 13 Oct 2008, Rogério Brito wrote:


From: Rogério Brito [EMAIL PROTECTED]

Since Linkstations and Kuroboxes often have *very* little memory (as
they are embedded systems), it is desirable to get their kernels
compiled optimized for size.

Signed-off-by: Rogério Brito [EMAIL PROTECTED]

---

I have been using kernels optimized for size on my Kurobox (standard)
for many different releases and I have experienced no problem with  
this

option enabled. Thus, this patch.


The comment for this option says: watch out for broken compilers, if
this doesn't hold any more, it should be remove, if it still holds, I
wouldn't turn this on by default, as I don't think we can test all


Pragmatically speaking, -O2 can be broken too (and see the amount of  
ICEs that you can get with newer kernels even compiling with -O2).  
Unless you prove that the compiler is correct and keeps all its  
invariants, then you can rely on this. But, pragmatically speaking  
again, gcc has bugs.


But leaving the mathematical situation aside (Dijkstra would have  
spanked all of us here :)), as I mentioned below the signed off line,  
I have been using -Os and it is working fine. It's serving me quite  
well and with a decent uptime:


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - -

lutz:~# uptime
 19:22:53 up 17 days,  5:56,  1 user,  load average: 0.00, 0.00, 0.00
lutz:~# uname -a
Linux lutz 2.6.27-rc6.try02 #8 Fri Sep 26 11:29:55 BRT 2008 ppc GNU/ 
Linux

lutz:~#
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - -


And, despite the 0.00 load, I'm streaming music with it via mt-daapd  
and serving cifs mounts.



possible (cross- or native-) compilers users might want to use. In any
case this is one of options that users can select themselves, if it  
suits

them.


And that is, not to mention, with a very home-brew and quick'n'dirty  
cross-compiled kernel (with a vanilla gcc 4.2.0 taken straight from  
gcc.gnu.org; the same with the kernel: no patches applied).


--
Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org



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

RE: [PATCH] remove bogus ppc_select syscall

[Paul Mackerras]

Sadashiiv, Halesh writes:

 I have tested the testcase that I have provided at the time of reporting
 this issue. But it didn't work as expected with the above patch you
 provided.
 (Failed to return EINVAL on negative value of n to select())

How is your testcase invoking select?  Is it doing its own hand-coded
system call using __NR_select?  If so the testcase is broken - it
should be using __NR__newselect.

If the test is using the ordinary glibc select(), then please send the
source code of the test program.

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

Re: performance: memcpy vs. __copy_tofrom_user

[Scott Wood]

Benjamin Herrenschmidt wrote:

It doesn't need to be done in non-preemptible sections, if you have a
separate per-thread save area for kernel fp/altivec use (and appropriate
flags so an FP unavailable handler knows which regs to restore), and you
can avoid using it in a preempting context.


Yuck.


Hmm?  It's simple and achieves the desired result (avoiding 
non-preemptible regions without unduly restricting the ability to 
extract performance from the hardware).


Would it be nicer to avoid FP/Altivec in the kernel altogether?  Sure. 
If the benchmarking says that we're better off with it, though, then so 
be it.


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

Re: [PATCH v3] powerpc: FPGA support for GE Fanuc SBC610

[Stephen Rothwell]

On Mon, 13 Oct 2008 16:16:45 +0100 Martyn Welch [EMAIL PROTECTED] wrote:

 Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
 MPC8641D).
 
 This patch adds support for the registers held in the devices main FPGA,
 exposing extra information about the revision of the board through cpuinfo.
 
 Signed-off-by: Martyn Welch [EMAIL PROTECTED]
 ---
 
 Stephen: Thanks for spotting that error.
 
 New to rev 3:
  * Added of_node_put()

Acked-by: Stephen Rothwell [EMAIL PROTECTED] for of accessing

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


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

Re: [2.6 patch] export genphy_restart_aneg

[Andy Fleming]

On Oct 13, 2008, at 12:19, Adrian Bunk wrote:


This patch fixes the following build error caused by
commit ed94493fb38a665cebcf750dfabe8a6dd13e136f
(mv643xx_eth: convert to phylib):

--  snip  --

...
 Building modules, stage 2.
 MODPOST 1280 modules
ERROR: genphy_restart_aneg [drivers/net/mv643xx_eth.ko] undefined!
...
make[2]: *** [__modpost] Error 1

--  snip  --


Signed-off-by: Adrian Bunk [EMAIL PROTECTED]



Could you get genphy_setup_forced, too?  It doesn't appear to be used,  
but it's currently in include/linux/phy.h, and not static.


Alternatively, we could change genphy_setup_forced to be static.  :)

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

Re: [PATCH 1/2] powerpc: don't pass unused regs around in head_.*.S

[Benjamin Herrenschmidt]

On Sun, 2008-10-12 at 16:08 +0200, Sebastian Andrzej Siewior wrote:
 From: Sebastian Andrzej Siewior [EMAIL PROTECTED]
 
 This looks like a relict from arch/ppc. machine_init() is accepting
 only two parameters (dtb, phys) and is using only the first one.

This isn't 100% correct actually...

First, the base head_32.S (could be called head_6xx.S I suppose)
supports a few more calling conventions such as the real OF one, with
added support for initrd and cmdline in registers , and the BootX one.

Then, calling convention for the other cases is slightly better defined
than just having r3 contain a device-tree pointer. The physical address
is an important part of it, the fact that r5 is NULL to differenciate
from an OF entry too, and we're moving toward the full ePAPR definition.

Cheers,
Ben.


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

Re: [PATCH] pata_of_platform: fix no irq handling

[Benjamin Herrenschmidt]

On Mon, 2008-10-13 at 15:56 +0900, Tejun Heo wrote:
 Anton Vorontsov wrote:
  When no irq specified the pata_of_platform fills the irq_res with -1,
  which is wrong to do for two reasons:
  
  1. By definition, 'no irq' should be IRQ 0, not some negative integer;
  2. pata_platform checks for irq_res.start  0, but since irq_res.start
 is unsigned type, the check will be true for `-1'.
  
  Reported-by: Steven A. Falco [EMAIL PROTECTED]
  Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
 
 applied to #tj-upstream (will soon be sent upstream)

Hrm... I applied it to powerpc.git too :-) Hopefully the merge will sort
it out !

Cheers,
Ben.


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

Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code

[Benjamin Herrenschmidt]

On Mon, 2008-10-13 at 14:21 -0400, Josh Boyer wrote:
 I don't think it matters much when it gets fixed, pre or post -rc1.  But
 it should probably get fixed.  My hack was to pull isa_bridge_pcidev
 into pci-common.c and export it from there.  The 64-bit PCI code can
 initialized it, and the 32-bit can leave it NULL.  But I have no idea
 if that is sane.  If so, I can probably submit a patch for it.

I think the proper fix in the long run is to make the isa bridge
handling code in pci-64 common, but that's going to be after I rework
the IO space allocation/mapping mechanisms for pci-32 to also look like
pci-64 so it will take a little while.

In the meantime, I agree, just leave it to NULL, we can do a better
fixup on top of that. As it is, it's going to hurt Pegasos too (the
other 5 users :-)

Cheers,
Ben.


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

Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code

[Benjamin Herrenschmidt]

On Mon, 2008-10-13 at 13:22 -0500, Kumar Gala wrote:
  I don't think it matters much when it gets fixed, pre or post -rc1.   
  But
  it should probably get fixed.  My hack was to pull isa_bridge_pcidev
  into pci-common.c and export it from there.  The 64-bit PCI code can
  initialized it, and the 32-bit can leave it NULL.  But I have no idea
  if that is sane.  If so, I can probably submit a patch for it.
 
 I was just joking around about our new regression policy.. anyways I  
 hope ben or maybe anton can comment about the ISA code.

My policy for that sort of bug is fix ASAP. I'll give it a go when I do
my test builds. Funny I didn't catch it, I might be lacking a chrp32
defconfig in my build tests :-)

Cheers,
Ben.

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

Re: [PATCH] powerpc: Add legacy PCI access via sysfs

[Benjamin Herrenschmidt]

  Is that targeted towards .28 or .29?  Ben has a 4xx specific patch
  that depends on this one, and I just need to know which version to
  bring that in for.
 
 I was planning on sending it for .28.

There's a minor bogon in the powerpc side patch, ie, I left an unused
variable from an old version of the patch. No big deal, but if you
haven't merged yet, let me know and I'll do a new spin. If you have
already, I'll do a fixup later on via the powerpc.git tree.

BTW. When do you intend to send that to Linus ?

Cheers,
Ben.


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

Re: [PATCH] powerpc: Add legacy PCI access via sysfs

[Benjamin Herrenschmidt]

On Fri, 2008-10-10 at 13:50 +1100, Benjamin Herrenschmidt wrote:
 This patch adds support for legacy_io and legacy_mem files in
 bus class directories in sysfs for powerpc
 
 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
 ---
 
 This is version 2, slightly different approach for getting at VGA
 memory which works a lot better with bridges providing a separate
 ISA Memory hole (which is the case of most of them).

Drop it Jesse. It's missing-quilt-ref busticated. One of these days
I'll figure a scripted way to avoid that problem.

New one on the way.

Cheers,
Ben.


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

Re: [RFC 1/3] hvc_console: rework setup to replace irq functions with callbacks

[Benjamin Herrenschmidt]

 Hmmm. 
 Can you try if this patch fixes the lockdep trace?

Yup, the patch fixes it, I'll commit it via the powerpc.git tree if you
don't have any objection.

Cheers,
Ben.

 This would be analog to
 commit b1b135c8d619cb2c7045d6ee4e48375882518bb5
 Author: Christian Borntraeger [EMAIL PROTECTED]
 Date:   Thu Aug 7 09:18:34 2008 +0200
 
 fix spinlock recursion in hvc_console
 
 commit 611e097d7707741a336a0677d9d69bec40f29f3d
 Author: Christian Borntraeger [EMAIL PROTECTED]
 hvc_console: rework setup to replace irq functions with callbacks
 introduced a spinlock recursion problem.
 
 
 Signed-off-by: Christian Borntraeger[EMAIL PROTECTED]
 ---
  drivers/char/hvc_console.c |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)
 
 Index: linux-2.6/drivers/char/hvc_console.c
 ===
 --- linux-2.6.orig/drivers/char/hvc_console.c
 +++ linux-2.6/drivers/char/hvc_console.c
 @@ -367,13 +367,13 @@ static void hvc_close(struct tty_struct 
   spin_lock_irqsave(hp-lock, flags);
  
   if (--hp-count == 0) {
 - if (hp-ops-notifier_del)
 - hp-ops-notifier_del(hp, hp-data);
 -
   /* We are done with the tty pointer now. */
   hp-tty = NULL;
   spin_unlock_irqrestore(hp-lock, flags);
  
 + if (hp-ops-notifier_del)
 + hp-ops-notifier_del(hp, hp-data);
 +
   /*
* Chain calls chars_in_buffer() and returns immediately if
* there is no buffered data otherwise sleeps on a wait queue
 @@ -416,11 +416,11 @@ static void hvc_hangup(struct tty_struct
   hp-n_outbuf = 0;
   hp-tty = NULL;
  
 + spin_unlock_irqrestore(hp-lock, flags);
 +
   if (hp-ops-notifier_del)
   hp-ops-notifier_del(hp, hp-data);
  
 - spin_unlock_irqrestore(hp-lock, flags);
 -
   while(temp_open_count) {
   --temp_open_count;
   kref_put(hp-kref, destroy_hvc_struct);

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

[PATCH] powerpc: Add legacy PCI access via sysfs (v3)

[Benjamin Herrenschmidt]

This patch adds support for legacy_io and legacy_mem files in
bus class directories in sysfs for powerpc

Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---

This is version 3, this time after doing a quilt ref and thus
getting a patch that actually useful. Sorry about the mishap.

 arch/powerpc/include/asm/pci-bridge.h |7 +
 arch/powerpc/include/asm/pci.h|   11 ++
 arch/powerpc/kernel/pci-common.c  |  136 +-
 3 files changed, 153 insertions(+), 1 deletion(-)

--- linux-work.orig/arch/powerpc/include/asm/pci.h  2008-10-03 
19:47:08.0 +1000
+++ linux-work/arch/powerpc/include/asm/pci.h   2008-10-10 10:50:46.0 
+1100
@@ -123,6 +123,16 @@ int pci_mmap_page_range(struct pci_dev *
 /* Tell drivers/pci/proc.c that we have pci_mmap_page_range() */
 #define HAVE_PCI_MMAP  1
 
+extern int pci_legacy_read(struct pci_bus *bus, loff_t port, u32 *val,
+  size_t count);
+extern int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val,
+  size_t count);
+extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
+ struct vm_area_struct *vma,
+ enum pci_mmap_state mmap_state);
+
+#define HAVE_PCI_LEGACY1
+
 #if defined(CONFIG_PPC64) || defined(CONFIG_NOT_COHERENT_CACHE)
 /*
  * For 64-bit kernels, pci_unmap_{single,page} is not a nop.
@@ -226,5 +236,6 @@ extern void pci_resource_to_user(const s
 extern void pcibios_do_bus_setup(struct pci_bus *bus);
 extern void pcibios_fixup_of_probed_bus(struct pci_bus *bus);
 
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_PCI_H */
Index: linux-work/arch/powerpc/kernel/pci-common.c
===
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-03 
19:47:08.0 +1000
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-14 11:32:38.0 
+1100
@@ -452,7 +452,8 @@ pgprot_t pci_phys_mem_access_prot(struct
pci_dev_put(pdev);
}
 
-   DBG(non-PCI map for %lx, prot: %lx\n, offset, prot);
+   DBG(non-PCI map for %llx, prot: %lx\n,
+   (unsigned long long)offset, prot);
 
return __pgprot(prot);
 }
@@ -491,6 +492,131 @@ int pci_mmap_page_range(struct pci_dev *
return ret;
 }
 
+/* This provides legacy IO read access on a bus */
+int pci_legacy_read(struct pci_bus *bus, loff_t port, u32 *val, size_t size)
+{
+   unsigned long offset;
+   struct pci_controller *hose = pci_bus_to_host(bus);
+   struct resource *rp = hose-io_resource;
+   void __iomem *addr;
+
+   /* Check if port can be supported by that bus. We only check
+* the ranges of the PHB though, not the bus itself as the rules
+* for forwarding legacy cycles down bridges are not our problem
+* here. So if the host bridge supports it, we do it.
+*/
+   offset = (unsigned long)hose-io_base_virt - _IO_BASE;
+   offset += port;
+
+   if (!(rp-flags  IORESOURCE_IO))
+   return -ENXIO;
+   if (offset  rp-start || (offset + size)  rp-end)
+   return -ENXIO;
+   addr = hose-io_base_virt + port;
+
+   switch(size) {
+   case 1:
+   *((u8 *)val) = in_8(addr);
+   return 1;
+   case 2:
+   if (port  1)
+   return -EINVAL;
+   *((u16 *)val) = in_le16(addr);
+   return 2;
+   case 4:
+   if (port  3)
+   return -EINVAL;
+   *((u32 *)val) = in_le32(addr);
+   return 4;
+   }
+   return -EINVAL;
+}
+
+/* This provides legacy IO write access on a bus */
+int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val, size_t size)
+{
+   unsigned long offset;
+   struct pci_controller *hose = pci_bus_to_host(bus);
+   struct resource *rp = hose-io_resource;
+   void __iomem *addr;
+
+   /* Check if port can be supported by that bus. We only check
+* the ranges of the PHB though, not the bus itself as the rules
+* for forwarding legacy cycles down bridges are not our problem
+* here. So if the host bridge supports it, we do it.
+*/
+   offset = (unsigned long)hose-io_base_virt - _IO_BASE;
+   offset += port;
+
+   if (!(rp-flags  IORESOURCE_IO))
+   return -ENXIO;
+   if (offset  rp-start || (offset + size)  rp-end)
+   return -ENXIO;
+   addr = hose-io_base_virt + port;
+
+   /* WARNING: The generic code is idiotic. It gets passed a pointer
+* to what can be a 1, 2 or 4 byte quantity and always reads that
+* as a u32, which means that we have to correct the location of
+* the data read within those 32 bits for size 1 and 2
+*/
+   switch(size) {
+   case 1:
+   out_8(addr, val  24);
+   return 

Re: [2.6 patch] export genphy_restart_aneg

[David Miller]

From: Adrian Bunk [EMAIL PROTECTED]
Date: Mon, 13 Oct 2008 20:19:00 +0300

 This patch fixes the following build error caused by
 commit ed94493fb38a665cebcf750dfabe8a6dd13e136f
 (mv643xx_eth: convert to phylib):

Applied, th anks Adrian.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 4/4] POWERPC: Merge 32 and 64-bit dma code

[Kumar Gala]

On Oct 13, 2008, at 6:30 PM, Benjamin Herrenschmidt wrote:


On Mon, 2008-10-13 at 13:22 -0500, Kumar Gala wrote:

I don't think it matters much when it gets fixed, pre or post -rc1.
But
it should probably get fixed.  My hack was to pull isa_bridge_pcidev
into pci-common.c and export it from there.  The 64-bit PCI code can
initialized it, and the 32-bit can leave it NULL.  But I have no  
idea

if that is sane.  If so, I can probably submit a patch for it.


I was just joking around about our new regression policy..  
anyways I

hope ben or maybe anton can comment about the ISA code.


My policy for that sort of bug is fix ASAP. I'll give it a go when I  
do

my test builds. Funny I didn't catch it, I might be lacking a chrp32
defconfig in my build tests :-)


I pointed out to Stephen that kisskb.ellerman.id.au hasn't been  
updating.. there is a chrp32 defconfig in there that would normally  
catch something like this.


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

Re: [PATCH] powerpc/boot: compare _start against ei.loadsize instead ei.memsize

[David Gibson]

On Mon, Oct 13, 2008 at 11:15:26AM +0200, Sebastian Andrzej Siewior wrote:
 If the vmlinux binary in memory is larger than 4 MiB than it collides
 with the initial boot code which is linked at 4 MiB in case of cuBoot.
 If the the uncompressed image size (on disk size) is less than 4 MiB
 then it would fit. The difference between those two sizes is the bss
 section. In cuBoot we have the dtb embedded right after the data
 section so it is very likely that the reset of the bss section (in
 kernel's start up code) will overwrite the dtb blob. Therefore we
 reallocate the dtb. Something similar is allready done to the initrd.
 
 Signed-off-by: Sebastian Andrzej Siewior [EMAIL PROTECTED]

This patch looks sound to me.  It does strike me as only a stopgap
until we come up with some better way of managing the early memory,
preferably avoiding the magical fixed 4MiB (or whatever) offset.

Still, it looks safe - since it does check that the wrapper's malloc()
region can't collide with the kernel's BSS.  So, if this little slice
of extra BSS room is useful for the time being, I see no reason not to
apply the patch.

Acked-by: David Gibson [EMAIL PROTECTED]

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: performance: memcpy vs. __copy_tofrom_user

[Matt Sealey]

Scott Wood wrote:

Benjamin Herrenschmidt wrote:


Yuck.


Hmm?  It's simple and achieves the desired result (avoiding 
non-preemptible regions without unduly restricting the ability to 
extract performance from the hardware).


Would it be nicer to avoid FP/Altivec in the kernel altogether?  Sure. 
If the benchmarking says that we're better off with it, though, then so 
be it.


There should definitely be a nice API for an in-kernel AltiVec context
save/restore. When preemption happens doesn't it do some equivalent of
the userspace context switch? Why can't the preemption system take care
of it?

At worst case you make the worst case latency bigger, but at best case
you gain performance across the board.

One thing which is worrying me is that now that Ben has thrown down the
gauntlet (note, I'm not going to be coding a line, but I know a man who
can :) how on earth do we benchmark the differences here?

--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

linux-next: manual merge of the powerpc tree

[Stephen Rothwell]

Hi Paul, Ben,

Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/include/asm/dcr-regs.h between commit
6fbc779c03591ee536fef9efb7d7e20f281d0b5c (ibm_newemac: Fix EMAC soft
reset on 460EX/GT) from Linus' tree and commit
fbcc4bacee30cad4e4a13d05492a9ed0c9c3e8c7 (ibm_newemac: MAL support for
PowerPC 405EZ) from the powerpc tree.

Just overlapping additions.  I fixed it up by taking both additions.
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/



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

linux-next: manual merge of the powerpc tree

[Stephen Rothwell]

Hi Paul, Ben,

Today's linux-next merge of the powerpc tree got a conflict in
drivers/net/ibm_newemac/core.h between commit
6fbc779c03591ee536fef9efb7d7e20f281d0b5c (ibm_newemac: Fix EMAC soft
reset on 460EX/GT) from Linus' tree and commit
b68d185ab12b1fc8000432c5d5ab5404d4788b4c (ibm_newemac: Allow the no
flow control EMAC feature to work) from the powerpc tree.

Just overlapping additions.
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


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