dtc: Cleanup \nnn and \xNN string escape handling

[David Gibson]

Several small cleanups to the handling of octal and hex string
escapes:
- Use strncmp() instead dof what were essentially open-coded
  versions of the same, with short fixed lengths.
- The call path to get_oct_char() means an empty escape is not
  possible.  So replace the error message in this case with an
  assert.
- Use die() instead of a non-fatal error message if
  get_hex_char() is given an empty escape.  Change error
  message to close match gcc's in the same circumstance.

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

---
 data.c |   19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

Index: dtc/data.c
===
--- dtc.orig/data.c 2008-03-17 16:37:04.0 +1100
+++ dtc/data.c  2008-03-17 16:37:04.0 +1100
@@ -75,16 +75,11 @@ static char get_oct_char(const char *s, 
long val;
 
x[3] = '\0';
-   x[0] = s[(*i)];
-   if (x[0]) {
-   x[1] = s[(*i)+1];
-   if (x[1])
-   x[2] = s[(*i)+2];
-   }
+   strncpy(x, s + *i, 3);
 
val = strtol(x, endx, 8);
-   if ((endx - x) == 0)
-   fprintf(stderr, Empty \\nnn escape\n);
+
+   assert(endx  x);
 
(*i) += endx - x;
return val;
@@ -97,13 +92,11 @@ static char get_hex_char(const char *s, 
long val;
 
x[2] = '\0';
-   x[0] = s[(*i)];
-   if (x[0])
-   x[1] = s[(*i)+1];
+   strncpy(x, s + *i, 2);
 
val = strtol(x, endx, 16);
-   if ((endx - x) == 0)
-   fprintf(stderr, Empty \\x escape\n);
+   if (!(endx   x))
+   die(\\x used with no following hex digits\n);
 
(*i) += endx - x;
return val;

-- 
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: [PATCH] Fix PMU + soft interrupt disable bug

[Benjamin Herrenschmidt]

On Sun, 2008-03-16 at 23:27 -0500, Anton Blanchard wrote:
 Since the PMU is an NMI now, it can come at any time we are only soft
 disabled. We must hard disable around the two places we allow the kernel
 stack SLB and r1 to go out of sync. Otherwise the PMU exception can
 force a kernel stack SLB into another slot.
 
 Signed-off-by: Anton Blanchard [EMAIL PROTECTED]

Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---

 ---
 
 Index: kernel/arch/powerpc/mm/slb.c
 ===
 --- kernel.orig/arch/powerpc/mm/slb.c 2007-11-05 11:22:03.0 -0600
 +++ kernel/arch/powerpc/mm/slb.c  2007-11-05 18:09:45.0 -0600
 @@ -113,6 +113,12 @@ void slb_flush_and_rebolt(void)
   slb_shadow_update(get_paca()-kstack, lflags, 2);
   }
  
 + /*
 +  * We can't take a PMU exception in the following code, so hard
 +  * disable interrupts.
 +  */
 + hard_irq_disable();
 +
   /* We need to do this all in asm, so we're sure we don't touch
* the stack between the slbia and rebolting it. */
   asm volatile(isync\n
 Index: kernel/arch/powerpc/kernel/process.c
 ===
 --- kernel.orig/arch/powerpc/kernel/process.c 2007-11-05 18:10:44.0 
 -0600
 +++ kernel/arch/powerpc/kernel/process.c  2007-11-05 18:10:46.0 
 -0600
 @@ -331,6 +331,12 @@ struct task_struct *__switch_to(struct t
   account_process_vtime(current);
   calculate_steal_time();
  
 + /*
 +  * We can't take a PMU exception inside _switch() since there is a
 +  * window where the kernel stack SLB and the kernel stack are out
 +  * of sync. Hard disable here.
 +  */
 + hard_irq_disable();
   last = _switch(old_thread, new_thread);
  
   local_irq_restore(flags);
 
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[PATCH] arch/powerpc/platforms/iseries/pci.c: Use time_* macros

[S . Çağlar Onur]

The functions time_before, time_before_eq, time_after, and time_after_eq are 
more robust for comparing jiffies against other values.

So following patch implements usage of the time_after() macro, defined at 
linux/jiffies.h, which deals with wrapping correctly

Cc: linuxppc-dev@ozlabs.org
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: S.Çağlar Onur [EMAIL PROTECTED]
---
 arch/powerpc/platforms/iseries/pci.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/iseries/pci.c 
b/arch/powerpc/platforms/iseries/pci.c
index cc562e4..02a634f 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -23,6 +23,7 @@
 
 #undef DEBUG
 
+#include linux/jiffies.h
 #include linux/kernel.h
 #include linux/list.h
 #include linux/string.h
@@ -586,7 +587,7 @@ static inline struct device_node *xlate_iomm_address(
static unsigned long last_jiffies;
static int num_printed;
 
-   if ((jiffies - last_jiffies)  60 * HZ) {
+   if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
-- 
1.5.4.3

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

Re: simple MPC5200B system

[André Schwarz]

Grant Likely wrote:

On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
[EMAIL PROTECTED] wrote:
  

All,

 I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+
 ... maybe someone could give me some hints.
 Up to now the systems have been running on 2.6.19 without any problems.

 This is what I've done so far :

 - get a recent system with 2.6.19 running and keep the toolchain (gcc
 4.0) including RFS uImage.
 - latest bootloader (u-boot 1.3.2) is running fine with dtb support.
 - Kernel and RFS images are available via bootp/tftp
 - device tree blob seems ok, i.e. u-boot can display the blob and fill
 in all clocks correctly.
 - Kernel gets called with Kernel, RFS and dtb on suitable adresses
 (0x10, 0x60, 0x5F).
 - nothing more happens. It looks like the console isn't working properly
 - maybe worse ...



Can you either halt the processor or reset the board and access memory
after this point?  You should see if you can access __log_buf (Look in
System.map for the address and subtract 0xc000 to get the physical
address).   __log_buf should give you clues about how far booting
progresses.

  
As soon as my abatron debugger is back I'll give it a try - currently 
it's out for an update ...
Are there any restrictions for the memory locations of the kernel, 
initrd and dtb images ?


Thanks for the help. I'll post the __log_buf tomorrow ... propably.


 The kernel has been build using the MPC5200 simple setup. I've added
 our board identifier mv,mvbluecougar to the list of supported boards
 in the mpc52xx_simple.c file. This identifier is used in the dtb as
 well of course. This should be enough along with a valid device tree
 blob, isn't it ? Did I miss anything already ?



Yes, this should be enough (on a side note; it should probably be
matrix-vision,bluecougar unless of''mv' is your company's stock
ticker symbol).

  

 As far as I did understand by reading the docs it should be possible
 running a general MPC52xx kernel with a custom dtb ? Is this correct ?



That is correct.

  

 The dts file has already been reduced to a minimum, i.e. only the cpu,
 pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm,
 pci, ata or advanced features like mtd partitions. All I want to get
 working is the serial console on /dev/ttyPSC0.



Cheers,
g.

  

regards,
André


MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: 
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 11/11] hvcbeat: fix buffer manipulation

[Ishizaki Kou]

This patch fixes a potential bug at drivers/char/hvc_beat.c.
 - hvc_put_term_char routine will decrement rest variable twice,
   and forget to advance buf pointer by nlen bytes.
This bug was not hit because the output handler in
drivers/char/hvc_console.c splits given output into 16 bytes
at maximum.

This patch is one of a series that I posted on Mar.14, celleb:
patchset for 2.6.26 (take2). I send this again because it
would be lost.

Reported-by: Timur Tabi [EMAIL PROTECTED]
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
---
 drivers/char/hvc_beat.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/char/hvc_beat.c
===
--- a/drivers/char/hvc_beat.c   2008-03-10 14:11:57.0 +0900
+++ b/drivers/char/hvc_beat.c   2008-03-10 14:13:40.0 +0900
@@ -78,8 +78,8 @@
for (rest = cnt; rest  0; rest -= nlen) {
nlen = (rest  16) ? 16 : rest;
memcpy(kb, buf, nlen);
-   beat_put_term_char(vtermno, rest, kb[0], kb[1]);
-   rest -= nlen;
+   beat_put_term_char(vtermno, nlen, kb[0], kb[1]);
+   buf += nlen;
}
return cnt;
 }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Jeff Garzik]

Stefan Roese wrote:

From: Pravin M. Bathija [EMAIL PROTECTED]

Problem Description and Fix
---
When a pause packet(with destination as reserved Multicast address) is
received by the EMAC hardware to control the flow of frames being
transmitted by it, it is dropped by the hardware unless the reserved
Multicast address is hashed in to the GAHT[1-4] registers. This code fix
adds the default reserved multicast address to the GAHT[1-4] registers
in the EMAC(s) present on the chip. The flow control with Pause packets
will only work if the following register bits are programmed in EMAC:
EMACx_MR1[APP] = 1
EMACx_RMR[BAE] = 1
EMACx_RMR[MAE] = 1

Behavior that may be observed in a running system
-
A host transferring data from a PPC based system may send a Pause packet
to the PPC EMAC requesting it to slow down the flow of packets. If the
default reserved multicast MAC address is not programmed into the
GAHT[1-4] registers this Pause packet will be dropped by PPC EMAC and no
Flow Control will be done.

Signed-off-by: Pravin M. Bathija [EMAIL PROTECTED]
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
 drivers/net/ibm_newemac/core.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)


applied


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

Re: [PATCH] net: NEWEMAC: Add compatible ibm,tah to tah matching table

[Jeff Garzik]

Stefan Roese wrote:

Add ibm,tah to the compatible matching table of the ibm_newemac
tah driver. The type tah is still preserved for compatibility reasons.
New dts files should use the compatible property though.

Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
 drivers/net/ibm_newemac/tah.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)


applied


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

Re: [PATCH 1/4] Emerson ATCA-C125 bootwrapper

[Alexandr Smirnov]

David,

+   /* Unfortunately, the specific model number is encoded in the
+* soc node name in existing dts files -- once that is fixed,
+* this can do a simple path lookup.
+*/



Since this is a new board, couldn't you name the soc node /soc and
dispense with this more complicated way of doing things?  Or would
that break other versions of u-boot that are in use?
  
As I understand you would like to rename /soc8548 node to /soc and make 
a simple path lookup like following:

- soc = find_node_by_devtype(NULL, soc);
+ soc = finddevice(/soc);
Is this correct?

But fsl_soc code still uses of_find_node_by_type so we can't remove 
device_type property from node /soc and therefor simplify device tree.



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

[PATCH v2] MTD support for the AMCC Taishan

[Imre Kaloz]

Signed-off-by: Imre Kaloz [EMAIL PROTECTED]
---
 arch/powerpc/boot/dts/taishan.dts  |   29 +++-
 arch/powerpc/configs/taishan_defconfig |   79 +++-
 2 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/taishan.dts 
b/arch/powerpc/boot/dts/taishan.dts
index 8278068..db102e9 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -174,7 +174,34 @@
interrupts = 5 4;
interrupt-parent = UIC1;
 
-   /* TODO: Add other EBC devices */
+   [EMAIL PROTECTED],0 {
+   compatible = cfi-flash;
+   bank-width = 4;
+   device-width = 2;
+   reg = 0 00 400;
+   #address-cells = 1;
+   #size-cells = 1;
+   [EMAIL PROTECTED] {
+   label = kernel;
+   reg = 0 18;
+   };
+   [EMAIL PROTECTED] {
+   label = root;
+   reg = 18 20;
+   };
+   [EMAIL PROTECTED] {
+   label = user;
+   reg = 38 3bc;
+   };
+   [EMAIL PROTECTED] {
+   label = env;
+   reg = 3f4 8;
+   };
+   [EMAIL PROTECTED] {
+   label = u-boot;
+   reg = 3fc 4;
+   };
+   };
};
 
 
diff --git a/arch/powerpc/configs/taishan_defconfig 
b/arch/powerpc/configs/taishan_defconfig
index 087aedc..e53c926 100644
--- a/arch/powerpc/configs/taishan_defconfig
+++ b/arch/powerpc/configs/taishan_defconfig
@@ -348,7 +348,83 @@ CONFIG_FW_LOADER=y
 # CONFIG_SYS_HYPERVISOR is not set
 CONFIG_CONNECTOR=y
 CONFIG_PROC_EVENTS=y
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+# CONFIG_MTD_BLKDEVS is not set
+# CONFIG_MTD_BLOCK is not set
+# CONFIG_MTD_BLOCK_RO is not set
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
 CONFIG_OF_DEVICE=y
 # CONFIG_PARPORT is not set
 CONFIG_BLK_DEV=y
@@ -660,6 +736,7 @@ CONFIG_TMPFS=y
 # CONFIG_BEFS_FS is not set
 # CONFIG_BFS_FS is not set
 # CONFIG_EFS_FS is not set
+# CONFIG_JFFS2_FS is not set
 CONFIG_CRAMFS=y
 # CONFIG_VXFS_FS is not set
 # CONFIG_MINIX_FS is not set
-- 
1.5.2.5

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

Re: [PATCH v2] MTD support for the AMCC Taishan

[Imre Kaloz]

On Mon, 17 Mar 2008 14:48:23 +0100, Imre Kaloz [EMAIL PROTECTED] wrote:

snip

Sorry, forgot to note that this version removes the kozio and extends  
the user partition accordingly, as Stefan asked.



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

Re: Trouble with SCC UART ports when moving from ppc to powerpc

[Scott Wood]

On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
 On Friday 07 March 2008 17:21, Scott Wood wrote:
  cpm2_reset() doesn't currently actually reset the CPM, for some reason
  (unlike cpm1).  This should probably be fixed, though then we'd have to
  deal with assigning SMC parameter RAM addresses ourselves.
 
 I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there any 
 reason not to rset the CPM in cpm2_reset() ?

The only issue I'm aware of other than the SMC parameter RAM relocation is
that the reset can't happen if the early udbg printk is being used.

 How should SMC parameter RAM assignment be handled ? I'm not very familiar 
 with the CPM1, 

CPM1 has hardcoded SMC parameter RAM addresses, so it's not relevant here.

 but for CPM2 the cpm_uart driver could easily cpm_dpalloc() parameter RAM.

It can, yes.  Patches welcome. :-)

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

Re: Interrupt handling documentation

[Laurent Pinchart]

On Thursday 13 March 2008 14:56, Laurent Pinchart wrote:
 Hi Michael,

 On Wednesday 12 March 2008 01:51, Michael Ellerman wrote:
  On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
   Hi everybody,
  
   is there any documentation describing interrupt handling for the
   powerpc architecture ? I'm writing a driver for a cascaded interrupt
   controller and the only source of information I found was the code.
 
  I don't think there's much documentation.

 I feared so :-)

  You might want to look at arch/powerpc/platforms/cell/axon_msi.c, it's a
  reasonably simple example of how to setup an irq_host and so on - well I
  think so :D

 Thanks for the pointer.

   I'm particularly interested in information about irq hosts (allocation
   and initialisation, especially the map and unmap callbacks) and irq
   chaining. Different drivers seem to implement cascaded irqs differently
   (for instance arch/powerpc/sysdev/uic.c uses setup_irq to register the
   cascaded irq handler, while
   arch/powerpc/platforms/82xx/pq2ads-pci-pic.c uses
   set_irq_chained_handler) so I'm a bit lost here.
 
  uic.c uses set_irq_chained_handler() now, so that probably answers that
  question. I don't think it makes all that much difference if you set it
  up by hand, but set_irq_chained_handler() is the neat way to do it.

 That pretty much answers my question. It's always a bit disturbing when
 different drivers use different APIs to accomplish the same task,
 especially when the lack of documentation doesn't clearly state which API
 should be used and which API is internal/deprecated.

I've been struggling with spurious interrupts related to my irq host for a 
day. Now that I've been able to solve the problem I thought I'd share the 
results here.

The PIC I am working with is linked to a falling-edge external irq on the 
CPM2. When the first PIC interrupt was generated the kernel called the PIC 
chained irq handler endlessly.

After some investigation it turned out the external interrupt bit in the CPM2 
interrupt pending register never got cleared. set_irq_chained_handler() 
registers the chained irq handler at the lowest level in the irq stack, 
bypassing all the interrupt acknowledgement/masking logic.

The fix was easy, all I had to do was to call desc-chip-ack(irq) at the 
beginning on the chained irq handler and desc-chip-eoi(irq) at the end. 
However, I'm wondering if this really belongs in the PIC code, or if PICs 
shouldn't be registered at a higher level (setup_irq or even request_irq) so 
that they would reuse the handle_*_irq handlers. Any opinion on this ?

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

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


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

[PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[John Linn]

The UART 16550 initialization was not setting up the registers
correctly. Code was added to pull the frequency and speed from
the device tree and initialize the registers using those values.

The boot code was not and is still not using the cmd line
to setup up the uart. The frequency of the clock driving the
UART must be specified in the device tree so that the baud
rate generator can be setup.

---

Please pull this patch for 2.6.26.
---
 arch/powerpc/boot/ns16550.c |   69 +-
 1 files changed, 54 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..d8edd48 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -15,23 +15,47 @@
 #include io.h
 #include ops.h
 
-#define UART_DLL   0   /* Out: Divisor Latch Low */
-#define UART_DLM   1   /* Out: Divisor Latch High */
-#define UART_FCR   2   /* Out: FIFO Control Register */
-#define UART_LCR   3   /* Out: Line Control Register */
-#define UART_MCR   4   /* Out: Modem Control Register */
-#define UART_LSR   5   /* In:  Line Status Register */
-#define UART_LSR_THRE  0x20/* Transmit-hold-register empty */
-#define UART_LSR_DR0x01/* Receiver data ready */
-#define UART_MSR   6   /* In:  Modem Status Register */
-#define UART_SCR   7   /* I/O: Scratch Register */
-
-static unsigned char *reg_base;
-static u32 reg_shift;
+#define UART_DLL   0   /* Out: Divisor Latch Low */
+#define UART_DLM   1   /* Out: Divisor Latch High */
+#define UART_FCR   2   /* Out: FIFO Control Register */
+#define UART_FCR_CLEAR_RCVR0x02/* Clear the RCVR FIFO */
+#define UART_FCR_CLEAR_XMIT0x04/* Clear the XMIT FIFO */
+#define UART_LCR   3   /* Out: Line Control Register */
+#define UART_MCR   4   /* Out: Modem Control Register */
+#define UART_MCR_RTS   0x02/* RTS complement */
+#define UART_MCR_DTR   0x01/* DTR complement */
+#define UART_LSR   5   /* In:  Line Status Register */
+#define UART_LSR_THRE  0x20/* Transmit-hold-register empty */
+#define UART_LSR_DR0x01/* Receiver data ready */
+#define UART_LCR_DLAB  0x80/* Divisor latch access bit */
+#define UART_LCR_WLEN8 0x03/* Wordlength: 8 bits */
+#define UART_MSR   6   /* In:  Modem Status Register */
+#define UART_SCR   7   /* I/O: Scratch Register */
+
+volatile static unsigned char *reg_base;
+volatile static u32 reg_shift;
+volatile static u16 divisor;
 
 static int ns16550_open(void)
 {
-   out_8(reg_base + (UART_FCR  reg_shift), 0x06);
+
+   /* Access baud rate */
+   out_8(reg_base + (UART_LCR  reg_shift), UART_LCR_DLAB);
+
+   /* Baud rate based on input clock */
+   out_8(reg_base + (UART_DLL  reg_shift), divisor  0xFF);
+   out_8(reg_base + (UART_DLM  reg_shift), divisor  8);
+
+   /* 8 data, 1 stop, no parity */
+   out_8(reg_base + (UART_LCR  reg_shift), UART_LCR_WLEN8);
+
+   /* RTS/DTR */
+   out_8(reg_base + (UART_MCR  reg_shift), UART_MCR_RTS | UART_MCR_DTR);
+
+   /* Clear transmitter and receiver */
+   out_8(reg_base + (UART_FCR  reg_shift), 
+   UART_FCR_CLEAR_XMIT | UART_FCR_CLEAR_RCVR);
+
return 0;
 }
 
@@ -56,6 +80,7 @@ int ns16550_console_init(void *devp, struct 
serial_console_data *scdp)
 {
int n;
unsigned long reg_phys;
+   u32 clk, spd;
 
n = getprop(devp, virtual-reg, reg_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -65,9 +90,23 @@ int ns16550_console_init(void *devp, struct 
serial_console_data *scdp)
reg_base = (void *)reg_phys;
}
 
-   n = getprop(devp, reg-shift, reg_shift, sizeof(reg_shift));
+   n = getprop(devp, reg-shift, (void *)reg_shift, sizeof(reg_shift));
if (n != sizeof(reg_shift))
reg_shift = 0;
+   
+   /* the base address has to change for devices with odd reg spacing */
+   reg_base = reg_base + ((1  reg_shift) - 1); 
+
+   n = getprop(devp, current-speed, (void *)spd, sizeof(spd));
+   if (n != sizeof(spd))
+   spd = 9600;
+
+   /* should there be a default clock rate?*/
+   n = getprop(devp, clock-frequency, (void *)clk, sizeof(clk));
+   if (n != sizeof(clk))
+   return -1;
+
+   divisor = clk / (16 * spd);
 
scdp-open = ns16550_open;
scdp-putc = ns16550_putc;
-- 
1.5.2.1



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

[PATCH 2/3] Xilinx: hwicap: Verify sync before reading idcode.

[Stephen Neuendorffer]

It appears that in some cases, the sync word might not be recognized
by the hardware correctly.  If this happens, then attempting to read
from the port results in an unrecoverable error because of the design
of the FPGA core.  This patch updates the code to check the status of
the device before reading the IDCODE, in order to avoid entering this
unrecoverable state.  This patch also adds additional NOOP commands
into the sychronization sequence, which appears to be necessary to
avoid the condition on some hardware.

Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c 
b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 304727d..5b8d646 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -250,8 +250,26 @@ static int hwicap_get_configuration_register(struct 
hwicap_drvdata *drvdata,
 * Create the data to be written to the ICAP.
 */
buffer[index++] = XHI_DUMMY_PACKET;
+   buffer[index++] = XHI_NOOP_PACKET;
buffer[index++] = XHI_SYNC_PACKET;
buffer[index++] = XHI_NOOP_PACKET;
+   buffer[index++] = XHI_NOOP_PACKET;
+
+   /*
+* Write the data to the FIFO and initiate the transfer of data present
+* in the FIFO to the ICAP device.
+*/
+   status = drvdata-config-set_configuration(drvdata,
+   buffer[0], index);
+   if (status)
+   return status;
+
+   /* If the syncword was not found, then we need to start over. */
+   status = drvdata-config-get_status(drvdata);
+   if ((status  XHI_SR_DALIGN_MASK) != XHI_SR_DALIGN_MASK)
+   return -EIO;
+
+   index = 0;
buffer[index++] = hwicap_type_1_read(reg) | 1;
buffer[index++] = XHI_NOOP_PACKET;
buffer[index++] = XHI_NOOP_PACKET;
-- 
1.5.3.4-dirty



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

[PATCH 0/3] Xilinx hwicap updates

[Stephen Neuendorffer]

The following sequence of patches makes the icap driver more robust,
by making better use of the status information from the cores.  In
addition, Lanana has assigned Major 259 for FPGA configuration
interfaces, so we now use it, rather than dynamically finding a major
number.

Grant: please pick these up for 2.6.26.  Do you think it's worth
patching virtex_devices.c at this point, or just punt on ARCH=ppc?

Steve


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

[PATCH 3/3] Xilinx: hwicap: Use fixed device major.

[Stephen Neuendorffer]

Major 259 has been assigned by lanana.  Use it.  Also, publish
/dev/icap[0-k] as the device entries, and register platform devices
named 'icap' to be consistent.

Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |   43 +---
 1 files changed, 14 insertions(+), 29 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c 
b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 5b8d646..016f905 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -36,7 +36,7 @@
  */
 
 /*
- * This is the code behind /dev/xilinx_icap -- it allows a user-space
+ * This is the code behind /dev/icap* -- it allows a user-space
  * application to use the Xilinx ICAP subsystem.
  *
  * The following operations are possible:
@@ -67,7 +67,7 @@
  * user-space application code that uses this device.  The simplest
  * way to use this interface is simply:
  *
- * cp foo.bit /dev/xilinx_icap
+ * cp foo.bit /dev/icap0
  *
  * Note that unless foo.bit is an appropriately constructed partial
  * bitstream, this has a high likelyhood of overwriting the design
@@ -105,18 +105,14 @@
 #include buffer_icap.h
 #include fifo_icap.h
 
-#define DRIVER_NAME xilinx_icap
+#define DRIVER_NAME icap
 
 #define HWICAP_REGS   (0x1)
 
-/* dynamically allocate device number */
-static int xhwicap_major;
-static int xhwicap_minor;
+#define XHWICAP_MAJOR 259
+#define XHWICAP_MINOR 0
 #define HWICAP_DEVICES 1
 
-module_param(xhwicap_major, int, S_IRUGO);
-module_param(xhwicap_minor, int, S_IRUGO);
-
 /* An array, which is set to true when the device is registered. */
 static bool probed_devices[HWICAP_DEVICES];
 static struct mutex icap_sem;
@@ -605,7 +601,7 @@ static int __devinit hwicap_setup(struct device *dev, int 
id,
probed_devices[id] = 1;
mutex_unlock(icap_sem);
 
-   devt = MKDEV(xhwicap_major, xhwicap_minor + id);
+   devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR + id);
 
drvdata = kzalloc(sizeof(struct hwicap_drvdata), GFP_KERNEL);
if (!drvdata) {
@@ -710,7 +706,7 @@ static int __devexit hwicap_remove(struct device *dev)
dev_set_drvdata(dev, NULL);
 
mutex_lock(icap_sem);
-   probed_devices[MINOR(dev-devt)-xhwicap_minor] = 0;
+   probed_devices[MINOR(dev-devt)-XHWICAP_MINOR] = 0;
mutex_unlock(icap_sem);
return 0;   /* success */
 }
@@ -850,23 +846,12 @@ static int __init hwicap_module_init(void)
icap_class = class_create(THIS_MODULE, xilinx_config);
mutex_init(icap_sem);
 
-   if (xhwicap_major) {
-   devt = MKDEV(xhwicap_major, xhwicap_minor);
-   retval = register_chrdev_region(
-   devt,
-   HWICAP_DEVICES,
-   DRIVER_NAME);
-   if (retval  0)
-   return retval;
-   } else {
-   retval = alloc_chrdev_region(devt,
-   xhwicap_minor,
-   HWICAP_DEVICES,
-   DRIVER_NAME);
-   if (retval  0)
-   return retval;
-   xhwicap_major = MAJOR(devt);
-   }
+   devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
+   retval = register_chrdev_region(devt,
+   HWICAP_DEVICES,
+   DRIVER_NAME);
+   if (retval  0)
+   return retval;
 
retval = platform_driver_register(hwicap_platform_driver);
 
@@ -891,7 +876,7 @@ static int __init hwicap_module_init(void)
 
 static void __exit hwicap_module_cleanup(void)
 {
-   dev_t devt = MKDEV(xhwicap_major, xhwicap_minor);
+   dev_t devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
 
class_destroy(icap_class);
 
-- 
1.5.3.4-dirty



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

[PATCH 1/3] Xilinx: hwicap: Refactor status handling code.

[Stephen Neuendorffer]

Both the buffer-based and fifo-based icap cores have a status
register.  Previously, this was only used internally to check whether
transactions have completed.  However, the status can be useful to the
main driver as well.  This patch exposes these status functions to the
main driver along with some masks for the differnet bits.

Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
 drivers/char/xilinx_hwicap/buffer_icap.c   |   22 ---
 drivers/char/xilinx_hwicap/buffer_icap.h   |5 ++-
 drivers/char/xilinx_hwicap/fifo_icap.c |   31 ---
 drivers/char/xilinx_hwicap/fifo_icap.h |1 +
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |2 +
 drivers/char/xilinx_hwicap/xilinx_hwicap.h |   24 +
 6 files changed, 58 insertions(+), 27 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c 
b/drivers/char/xilinx_hwicap/buffer_icap.c
index f577dae..aa7f796 100644
--- a/drivers/char/xilinx_hwicap/buffer_icap.c
+++ b/drivers/char/xilinx_hwicap/buffer_icap.c
@@ -74,7 +74,7 @@
 
 /**
  * buffer_icap_get_status - Get the contents of the status register.
- * @base_address: is the base address of the device
+ * @drvdata: a pointer to the drvdata.
  *
  * The status register contains the ICAP status and the done bit.
  *
@@ -88,9 +88,9 @@
  * D1 - Always 1
  * D0 - Done bit
  **/
-static inline u32 buffer_icap_get_status(void __iomem *base_address)
+u32 buffer_icap_get_status(struct hwicap_drvdata *drvdata)
 {
-   return in_be32(base_address + XHI_STATUS_REG_OFFSET);
+   return in_be32(drvdata-base_address + XHI_STATUS_REG_OFFSET);
 }
 
 /**
@@ -117,20 +117,8 @@ static inline u32 buffer_icap_get_bram(void __iomem 
*base_address,
  **/
 static inline bool buffer_icap_busy(void __iomem *base_address)
 {
-   return (buffer_icap_get_status(base_address)  1) == XHI_NOT_FINISHED;
-}
-
-/**
- * buffer_icap_busy - Return true if the icap device is not busy
- * @base_address: is the base address of the device
- *
- * The queries the low order bit of the status register, which
- * indicates whether the current configuration or readback operation
- * has completed.
- **/
-static inline bool buffer_icap_done(void __iomem *base_address)
-{
-   return (buffer_icap_get_status(base_address)  1) == XHI_FINISHED;
+   u32 status = in_be32(base_address + XHI_STATUS_REG_OFFSET);
+   return (status  1) == XHI_NOT_FINISHED;
 }
 
 /**
diff --git a/drivers/char/xilinx_hwicap/buffer_icap.h 
b/drivers/char/xilinx_hwicap/buffer_icap.h
index 0318495..c5b1840 100644
--- a/drivers/char/xilinx_hwicap/buffer_icap.h
+++ b/drivers/char/xilinx_hwicap/buffer_icap.h
@@ -44,8 +44,6 @@
 #include asm/io.h
 #include xilinx_hwicap.h
 
-void buffer_icap_reset(struct hwicap_drvdata *drvdata);
-
 /* Loads a partial bitstream from system memory. */
 int buffer_icap_set_configuration(struct hwicap_drvdata *drvdata, u32 *data,
 u32 Size);
@@ -54,4 +52,7 @@ int buffer_icap_set_configuration(struct hwicap_drvdata 
*drvdata, u32 *data,
 int buffer_icap_get_configuration(struct hwicap_drvdata *drvdata, u32 *data,
 u32 Size);
 
+u32 buffer_icap_get_status(struct hwicap_drvdata *drvdata);
+void buffer_icap_reset(struct hwicap_drvdata *drvdata);
+
 #endif
diff --git a/drivers/char/xilinx_hwicap/fifo_icap.c 
b/drivers/char/xilinx_hwicap/fifo_icap.c
index 6f45dbd..776b505 100644
--- a/drivers/char/xilinx_hwicap/fifo_icap.c
+++ b/drivers/char/xilinx_hwicap/fifo_icap.c
@@ -78,13 +78,6 @@
 #define XHI_CR_READ_MASK 0x0002 /* Read from ICAP to FIFO */
 #define XHI_CR_WRITE_MASK 0x0001 /* Write from FIFO to ICAP */
 
-/* Status Register (SR) */
-#define XHI_SR_CFGERR_N_MASK 0x0100 /* Config Error Mask */
-#define XHI_SR_DALIGN_MASK 0x0080 /* Data Alignment Mask */
-#define XHI_SR_RIP_MASK 0x0040 /* Read back Mask */
-#define XHI_SR_IN_ABORT_N_MASK 0x0020 /* Select Map Abort Mask */
-#define XHI_SR_DONE_MASK 0x0001 /* Done bit Mask  */
-
 
 #define XHI_WFO_MAX_VACANCY 1024 /* Max Write FIFO Vacancy, in words */
 #define XHI_RFO_MAX_OCCUPANCY 256 /* Max Read FIFO Occupancy, in words */
@@ -152,13 +145,35 @@ static inline void fifo_icap_start_readback(struct 
hwicap_drvdata *drvdata)
 }
 
 /**
+ * fifo_icap_get_status - Get the contents of the status register.
+ * @drvdata: a pointer to the drvdata.
+ *
+ * The status register contains the ICAP status and the done bit.
+ *
+ * D8 - cfgerr
+ * D7 - dalign
+ * D6 - rip
+ * D5 - in_abort_l
+ * D4 - Always 1
+ * D3 - Always 1
+ * D2 - Always 1
+ * D1 - Always 1
+ * D0 - Done bit
+ **/
+u32 fifo_icap_get_status(struct hwicap_drvdata *drvdata)
+{
+   u32 status = in_be32(drvdata-base_address + XHI_SR_OFFSET);
+   dev_dbg(drvdata-dev, Getting status = %x\n, status);
+   return status;
+}
+
+/**
  * fifo_icap_busy - Return true if the ICAP is still processing a transaction.
  * @drvdata: a pointer to the drvdata.
  **/
 static inline u32 

[PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus

[Anton Vorontsov]

MDIO-less PHYs should use CONFIG_FIXED_PHY driver and appropriate
fixed-link property in the device tree.

If not, ethernet will not work:
  e0024520:03 not found
  eth1: Could not attach to PHY
  IP-Config: Failed to open eth1

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 arch/powerpc/boot/dts/mpc8377_rdb.dts  |8 +---
 arch/powerpc/boot/dts/mpc8378_rdb.dts  |8 +---
 arch/powerpc/boot/dts/mpc8379_rdb.dts  |8 +---
 arch/powerpc/configs/mpc837x_rdb_defconfig |2 +-
 4 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts 
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index d2332fb..476f65a 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -164,12 +164,6 @@
reg = 0x2;
device_type = ethernet-phy;
};
-   phy3: [EMAIL PROTECTED] {
-   interrupt-parent = ipic;
-   interrupts = 18 0x8;
-   reg = 0x3;
-   device_type = ethernet-phy;
-   };
};
 
enet0: [EMAIL PROTECTED] {
@@ -195,7 +189,7 @@
interrupts = 35 0x8 36 0x8 37 0x8;
phy-connection-type = mii;
interrupt-parent = ipic;
-   phy-handle = phy3;
+   fixed-link = 1 1 1000 0 0;
};
 
serial0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts 
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 711f9a3..0e872a6 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -164,12 +164,6 @@
reg = 0x2;
device_type = ethernet-phy;
};
-   phy3: [EMAIL PROTECTED] {
-   interrupt-parent = ipic;
-   interrupts = 18 0x8;
-   reg = 0x3;
-   device_type = ethernet-phy;
-   };
};
 
enet0: [EMAIL PROTECTED] {
@@ -195,7 +189,7 @@
interrupts = 35 0x8 36 0x8 37 0x8;
phy-connection-type = mii;
interrupt-parent = ipic;
-   phy-handle = phy3;
+   fixed-link = 1 1 1000 0 0;
};
 
serial0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts 
b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index c11ceb7..1eb8def 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -164,12 +164,6 @@
reg = 0x2;
device_type = ethernet-phy;
};
-   phy3: [EMAIL PROTECTED] {
-   interrupt-parent = ipic;
-   interrupts = 18 0x8;
-   reg = 0x3;
-   device_type = ethernet-phy;
-   };
};
 
enet0: [EMAIL PROTECTED] {
@@ -195,7 +189,7 @@
interrupts = 35 0x8 36 0x8 37 0x8;
phy-connection-type = mii;
interrupt-parent = ipic;
-   phy-handle = phy3;
+   fixed-link = 1 1 1000 0 0;
};
 
serial0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/configs/mpc837x_rdb_defconfig 
b/arch/powerpc/configs/mpc837x_rdb_defconfig
index 91d291e..c429a33 100644
--- a/arch/powerpc/configs/mpc837x_rdb_defconfig
+++ b/arch/powerpc/configs/mpc837x_rdb_defconfig
@@ -425,7 +425,7 @@ CONFIG_MARVELL_PHY=y
 # CONFIG_SMSC_PHY is not set
 # CONFIG_BROADCOM_PHY is not set
 # CONFIG_ICPLUS_PHY is not set
-# CONFIG_FIXED_PHY is not set
+CONFIG_FIXED_PHY=y
 # CONFIG_MDIO_BITBANG is not set
 CONFIG_NET_ETHERNET=y
 CONFIG_MII=y
-- 
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine

[Dan Williams]

On Sun, Mar 16, 2008 at 2:30 PM, Olof Johansson [EMAIL PROTECTED] wrote:
 pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine

  DMA copy offload driver for PA Semi PWRficient. It uses the

 platform-specific functions to allocate channels, etc.

  Signed-off-by: Olof Johansson [EMAIL PROTECTED]

  ---

  Changes since last post:

  * Add DMA_INTERRUPT support and handling of the interrupt flag
  * Fix interrupt handler for above and add tasklet
  * Switch to spin_lock_bh() where possible
  * Remove empty dependency_added() function since it's no longer
   used in the framework.
  * Fix bug in ring full estimation.


Hi Olof,

Looks good, makes me want to go back and cleanup iop-adma a bit.  A
few fyi's below, but no other review comments.

  Note that this still needs to go on top of the powerpc.git tree due to the
  pasemi_dma.h updates that this driver depends on. I suggest merging this
  through pasemi.git-powerpc.git-linus with an Acked-by from the DMA guys.

Ok, it still may not compile in mainline until after 2.6.26-rc1 due to
additional dmaengine cleanups like the ack-to-flags change I posted
earlier.  Any better way to handle this?  Go through -mm?


  -Olof


Acked-by: Dan Williams [EMAIL PROTECTED]

 --- /dev/null
  +++ b/drivers/dma/pasemi_dma.c
[..]
  +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
  +{
  +   int old, new, i;

 +   struct pasemi_dma_desc *desc;
  +   dma_async_tx_callback callback;
  +
  +restart:
  +   spin_lock_bh(chan-desc_lock);

 +
  +   old = chan-next_to_clean;
  +
  +   new = *chan-chan.status  PAS_STATUS_PCNT_M;
  +   new = 2;
  +   new = (RING_SZ-1);
  +
  +   if (old  new)
  +   new += RING_SZ;
  +
  +   for (i = old; i  new; i += 4) {
  +   if (unlikely(chan-chan.ring_virt[i  (RING_SZ-1)]  
 XCT_COPY_O))
  +   break;
  +   desc = chan-ring_info[i  (RING_SZ-1)];
  +
  +   callback = desc-async_tx.callback;
  +   if (callback) {
  +   /* Can't re-lock and just loop, since another cpu
  +* might have came in here while we released the 
 lock.
  +* Instead, start all over again to re-read status 
 words.
  +*/

 +   chan-next_to_clean = i  (RING_SZ-1);
  +   spin_unlock_bh(chan-desc_lock);
  +   callback(desc-async_tx.callback_param);
  +   goto restart;
  +   }

Clients do not submit new operations in their callback routines so it
is ok to hold this lock over the callback.

Also, if your platform will need to support channel switching at some
point you can go ahead and add a call to async_tx_run_dependencies()
here.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] [POWERPC] Xilinx: Serial: Adding 8250 console support to OF serial

[John Linn]

This change adds code to serial_of.c to support the 8250 console.
Initialization was added to get the UART data from the device tree
and setup the UART and console for the 8250.

The cmd line was not being used for the baud rate and is still not
being used as the speed for the uart is being pulled from the UART
properties in the device tree. The input clock frequency for the
UART must be specified in the device tree so the baud rate generator
can be setup.

Signed-off-by: John Linn [EMAIL PROTECTED]

---

Please pull this patch for 2.6.26.
---
 drivers/serial/8250.c  |   20 ++--
 drivers/serial/of_serial.c |  128 
 2 files changed, 144 insertions(+), 4 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..7b32af1 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2366,7 +2366,7 @@ serial8250_type(struct uart_port *port)
return uart_config[type].name;
 }
 
-static struct uart_ops serial8250_pops = {
+struct uart_ops serial8250_pops = {
.tx_empty   = serial8250_tx_empty,
.set_mctrl  = serial8250_set_mctrl,
.get_mctrl  = serial8250_get_mctrl,
@@ -2519,10 +2519,13 @@ serial8250_console_write(struct console *co, const char 
*s, unsigned int count)
 static int __init serial8250_console_setup(struct console *co, char *options)
 {
struct uart_port *port;
+
+#ifndef CONFIG_SERIAL_OF_PLATFORM
int baud = 9600;
int bits = 8;
int parity = 'n';
int flow = 'n';
+#endif
 
/*
 * Check whether an invalid uart number has been specified, and
@@ -2535,10 +2538,13 @@ static int __init serial8250_console_setup(struct 
console *co, char *options)
if (!port-iobase  !port-membase)
return -ENODEV;
 
+#ifndef CONFIG_SERIAL_OF_PLATFORM
if (options)
uart_parse_options(options, baud, parity, bits, flow);
-
return uart_set_options(port, co, baud, parity, bits, flow);
+#else
+   return 0;
+#endif
 }
 
 static int serial8250_console_early_setup(void)
@@ -2547,7 +2553,7 @@ static int serial8250_console_early_setup(void)
 }
 
 static struct uart_driver serial8250_reg;
-static struct console serial8250_console = {
+struct console serial8250_console = {
.name   = ttyS,
.write  = serial8250_console_write,
.device = uart_console_device,
@@ -2558,13 +2564,19 @@ static struct console serial8250_console = {
.data   = serial8250_reg,
 };
 
-static int __init serial8250_console_init(void)
+int __init serial8250_console_init(void)
 {
serial8250_isa_init_ports();
register_console(serial8250_console);
return 0;
 }
+
+/* when OF is being used with the 8250 console, the OF hooks in the 
+   8250 console
+*/
+#if defined(CONFIG_SERIAL_8250_CONSOLE)  !defined(CONFIG_SERIAL_OF_PLATFORM)
 console_initcall(serial8250_console_init);
+#endif
 
 int serial8250_find_port(struct uart_port *p)
 {
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..eed245a 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -13,9 +13,11 @@
 #include linux/module.h
 #include linux/serial_core.h
 #include linux/serial_8250.h
+#include linux/console.h
 
 #include asm/of_platform.h
 #include asm/prom.h
+#include asm/io.h
 
 struct of_serial_info {
int type;
@@ -158,6 +160,132 @@ static void __exit of_platform_serial_exit(void)
 };
 module_exit(of_platform_serial_exit);
 
+#if defined(CONFIG_SERIAL_8250_CONSOLE)
+
+/* when an 8250 console is being used and OF, the OF needs to
+   setup the uart before the 8250 console initializes
+*/
+extern struct console serial8250_console;
+extern int serial8250_console_init(void);
+extern int early_serial_console_setup(struct uart_port *);
+extern struct uart_ops serial8250_pops;
+
+static struct uart_port of_uart_port;
+
+static struct of_device_id __devinit uart_of_match[] = {
+   { .type = serial, .compatible = ns16550, },
+   {},
+};
+
+static unsigned int *spd;
+
+/*
+ * Setup the uart based on OF properties
+ */
+static int __init uart_of_setup(struct device_node *np,
+   struct uart_port *port)
+{
+   struct resource resource;
+   const unsigned int *clk, *regshift;
+   int ret;
+
+   memset(port, 0, sizeof *port);
+   spd = of_get_property(np, current-speed, NULL);
+   regshift = of_get_property(np, reg-shift, NULL);
+   clk = of_get_property(np, clock-frequency, NULL);
+   if (!clk) {
+   return -ENODEV;
+   }
+
+   ret = of_address_to_resource(np, 0, resource);
+   if (ret) {
+   return ret;
+   }
+
+   spin_lock_init(port-lock);
+   port-irq = irq_of_parse_and_map(np, 0);
+   port-iotype = UPIO_MEM;
+   port-type = PORT_16550;
+   port-uartclk = *clk;
+   port-flags = UPF_SHARE_IRQ | 

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka [EMAIL PROTECTED] wrote:
 Grant Likely wrote:
   Paul, here is a bug fix that needs to go in for 2.6.25.

  Hi Grant,

  What is the status of the various MPC5200-related patches (support for
  TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
  time ago by Marian Balakowicz? There's been some comments to the patches
  on the list, which were addressed and no further discussion occurred, so
  we were hoping that the changes would go upstream (in 2.6.25). I can see
  that the .dts files for those boards are in the mainline already, but I
  see no trace of for example _defconfig files -- could you shed some
  light on this?

Yes, the separate dts files have been dropped in preference for a
single mpc5200_defconfig for all 5200 boards.

Cheers,
g.


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

powerpc: cuImage.* creation error

[Adrian Bunk]

When building all powerpc defconfigs in 2.6.25-rc6 exactly three of 
them fail to build, and all with similar problems:


mpc85xx_defconfig:

--  snip  --

...
  WRAParch/powerpc/boot/cuImage.tqm8540
DTC: dts-dtb  on file 
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8540.dts
powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such 
file or directory
make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1

--  snip  --


sbc8548_defconfig:

--  snip  --

...
Entry Point:  0x
make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', needed 
by `arch/powerpc/boot/zImage'.  Stop.

--  snip  --


tqm8540_defconfig:

--  snip  --

...
  WRAParch/powerpc/boot/cuImage.tqm8540
DTC: dts-dtb  on file 
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/tqm8540.dts
powerpc64-linux-ld: arch/powerpc/boot/cuboot-tqm8540.o: No such file: No such 
file or directory
make[2]: *** [arch/powerpc/boot/cuImage.tqm8540] Error 1

--  snip  --


Is this a problem on my side or is there a bug that should be fixed?


TIA
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] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus

[Joakim Tjernlund]

On Mon, 2008-03-17 at 20:52 +0300, Anton Vorontsov wrote:
 MDIO-less PHYs should use CONFIG_FIXED_PHY driver and appropriate
 fixed-link property in the device tree.
 
 If not, ethernet will not work:
   e0024520:03 not found
   eth1: Could not attach to PHY
   IP-Config: Failed to open eth1
 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]

Trying to add fixed-link support for ucc_geth as this is broken too. I
noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
my board once I got the ucc_geth driver to recognize fixed-link.
Does it work for you?

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

Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[Grant Likely]

On Mon, Mar 17, 2008 at 10:41 AM, John Linn [EMAIL PROTECTED] wrote:
 The UART 16550 initialization was not setting up the registers
  correctly. Code was added to pull the frequency and speed from
  the device tree and initialize the registers using those values.

  The boot code was not and is still not using the cmd line
  to setup up the uart. The frequency of the clock driving the
  UART must be specified in the device tree so that the baud
  rate generator can be setup.

The bootwrapper makes the assumption that the firmware has already
initialized the serial device and it should not be fiddled with so
that there is less chance of messing up a working output
configuration.

For platforms such as the virtex which don't have firmware the serial
port should be setup earlier in the boot process (in the appropriate
platform_init() function).

Cheers,
g.


  ---

  Please pull this patch for 2.6.26.
  ---
   arch/powerpc/boot/ns16550.c |   69 
 +-
   1 files changed, 54 insertions(+), 15 deletions(-)

  diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
  index f8f1b2f..d8edd48 100644
  --- a/arch/powerpc/boot/ns16550.c
  +++ b/arch/powerpc/boot/ns16550.c
  @@ -15,23 +15,47 @@
   #include io.h
   #include ops.h

  -#define UART_DLL   0   /* Out: Divisor Latch Low */
  -#define UART_DLM   1   /* Out: Divisor Latch High */
  -#define UART_FCR   2   /* Out: FIFO Control Register */
  -#define UART_LCR   3   /* Out: Line Control Register */
  -#define UART_MCR   4   /* Out: Modem Control Register */
  -#define UART_LSR   5   /* In:  Line Status Register */
  -#define UART_LSR_THRE  0x20/* Transmit-hold-register empty */
  -#define UART_LSR_DR0x01/* Receiver data ready */
  -#define UART_MSR   6   /* In:  Modem Status Register */
  -#define UART_SCR   7   /* I/O: Scratch Register */
  -
  -static unsigned char *reg_base;
  -static u32 reg_shift;
  +#define UART_DLL   0   /* Out: Divisor Latch Low */
  +#define UART_DLM   1   /* Out: Divisor Latch High */
  +#define UART_FCR   2   /* Out: FIFO Control Register */
  +#define UART_FCR_CLEAR_RCVR0x02/* Clear the RCVR FIFO */
  +#define UART_FCR_CLEAR_XMIT0x04/* Clear the XMIT FIFO */
  +#define UART_LCR   3   /* Out: Line Control Register */
  +#define UART_MCR   4   /* Out: Modem Control Register */
  +#define UART_MCR_RTS   0x02/* RTS complement */
  +#define UART_MCR_DTR   0x01/* DTR complement */
  +#define UART_LSR   5   /* In:  Line Status Register */
  +#define UART_LSR_THRE  0x20/* Transmit-hold-register empty */
  +#define UART_LSR_DR0x01/* Receiver data ready */
  +#define UART_LCR_DLAB  0x80/* Divisor latch access bit */
  +#define UART_LCR_WLEN8 0x03/* Wordlength: 8 bits */
  +#define UART_MSR   6   /* In:  Modem Status Register */
  +#define UART_SCR   7   /* I/O: Scratch Register */
  +
  +volatile static unsigned char *reg_base;
  +volatile static u32 reg_shift;
  +volatile static u16 divisor;

   static int ns16550_open(void)
   {
  -   out_8(reg_base + (UART_FCR  reg_shift), 0x06);
  +
  +   /* Access baud rate */
  +   out_8(reg_base + (UART_LCR  reg_shift), UART_LCR_DLAB);
  +
  +   /* Baud rate based on input clock */
  +   out_8(reg_base + (UART_DLL  reg_shift), divisor  0xFF);
  +   out_8(reg_base + (UART_DLM  reg_shift), divisor  8);
  +
  +   /* 8 data, 1 stop, no parity */
  +   out_8(reg_base + (UART_LCR  reg_shift), UART_LCR_WLEN8);
  +
  +   /* RTS/DTR */
  +   out_8(reg_base + (UART_MCR  reg_shift), UART_MCR_RTS | 
 UART_MCR_DTR);
  +
  +   /* Clear transmitter and receiver */
  +   out_8(reg_base + (UART_FCR  reg_shift),
  +   UART_FCR_CLEAR_XMIT | UART_FCR_CLEAR_RCVR);
  +
 return 0;
   }

  @@ -56,6 +80,7 @@ int ns16550_console_init(void *devp, struct 
 serial_console_data *scdp)
   {
 int n;
 unsigned long reg_phys;
  +   u32 clk, spd;

 n = getprop(devp, virtual-reg, reg_base, sizeof(reg_base));
 if (n != sizeof(reg_base)) {
  @@ -65,9 +90,23 @@ int ns16550_console_init(void *devp, struct 
 serial_console_data *scdp)
 reg_base = (void *)reg_phys;
 }

  -   n = getprop(devp, reg-shift, reg_shift, sizeof(reg_shift));
  +   n = getprop(devp, reg-shift, (void *)reg_shift, 
 sizeof(reg_shift));
 if (n != sizeof(reg_shift))
 reg_shift = 0;
  +
  +   /* the base address has to change for devices with odd reg spacing */
  +   reg_base = reg_base + ((1  reg_shift) - 1);
  +
  +   n = getprop(devp, current-speed, (void *)spd, sizeof(spd));
  +   if (n != sizeof(spd))
  +   spd = 9600;
  +
  

crash in init_ipic_sysfs on efika

[Olaf Hering]

I cant reproduce this bug on my board, but:

The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
ipic_init() fails. init_ipic_sysfs() will crash in that case.

Something like this may fix it:

Index: linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
===
--- linux-2.6.25-rc6.orig/arch/powerpc/sysdev/ipic.c
+++ linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
@@ -906,7 +906,7 @@ static int __init init_ipic_sysfs(void)
 {
int rc;
 
-   if (!primary_ipic-regs)
+   if (!primary_ipic || !primary_ipic-regs)
return -ENODEV;
printk(KERN_DEBUG Registering ipic with sysfs...\n);
 


ok boot eth:192.168.2.52,inst32 inst32 console=ttyPSC0,115200

SuSE Linux zImage starting: loaded at 0004-00d24cbc (0/0/01003ed8;
sp: 017ffe80)
uncompressing ELF header done. (0100 bytes)
Allocated 008584d4 bytes for kernel @ 0200
Allocated 00a963a2 bytes for initrd @ 02859000
uncompressing kernel done. (004faeb8 bytes)
entering kernel at 0201(2859000/a963a2/01003ed8)
OF stdout device is: /failsafe
command line: console=ttyPSC0,115200
memory layout at init:
  alloc_bottom : 032f
  alloc_top: 3000
  alloc_top_hi : f000c000
  rmo_top  : 3000
  ram_top  : f000c000
Looking for displays
instantiating rtas at 0x07ffb000 ... done
Applying EFIKA device tree fixups
Fixing bestcomm interrupts property
Adding Ethernet MDIO node
Adding Ethernet PHY node
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x032f1000 - 0x032f17e0
Device tree struct  0x032f2000 - 0x03315000
Calling quiesce ...
returning from prom_init
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 113264k/131072k available (4808k kernel code, 17648k reserved,
164k data, 461k bss, 228k init)
Security Framework initialized
AppArmor: AppArmor initialized
AppArmor: Unable to log event (1505) to audit subsys
AppArmor: Registered secondary security module name=capability
AppArmor: Unable to log event (1505) to audit subsys
Capability LSM initialized as secondary
Failure registering Root Plug module with the kernel
AppArmor: Unable to register %s as a secondary security module
name=root_plug
AppArmor: Unable to log event (1505) to audit subsys
Failure registering Root Plug  module with primary security module.
Mount-cache hash table entries: 512
net_namespace: 544 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
DMA: MPC52xx BestComm driver
DMA: MPC52xx BestComm engine @f0001200 ok !
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0486aac
Oops: Kernel access of bad area, sig: 11 [#1]
Efika
Modules linked in:
NIP: c0486aac LR: c0479200 CTR: c0486a90
REGS: c782bea0 TRAP: 0300   Not tainted  (2.6.25-rc5-git2-5-default)
MSR: 9032 EE,ME,IR,DR  CR: 44002082  XER: 2000
DAR: , DSISR: 2000
TASK = c78237c0[1] 'swapper' THREAD: c782a000
GPR00: c0479200 c782bf50 c78237c0 ffed 0003  

GPR08: fffc  c7800780 000f06a0 22002022 dff7 c0405540
c0405558
GPR16: c0405568 c040558c c0405594 c04055a4 c04055d0 c040 024184a4

GPR24:  c04a6468 c0405550 c782a000 c04e  
c04af198
NIP [c0486aac] init_ipic_sysfs+0x1c/0x90
LR [c0479200] kernel_init+0xf8/0x2a0
Call Trace:
[c782bf50] [c04869fc] mpc52xx_bcom_init+0x24/0x34 (unreliable)
[c782bf60] [c0479200] kernel_init+0xf8/0x2a0
[c782bff0] [c001330c] kernel_thread+0x44/0x60
Instruction dump:
80010024 bb61000c 38210020 7c0803a6 4e800020 9421fff0 7c0802a6 3d20c04f
3860ffed 90010014 93e1000c 81299730 8009 2f80 41be0058 3c60c041
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..

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

RE: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[John Linn]

That makes sense.  Since I'm not using a boot loader I didn't realize
that.

I'm not sure how hard it will be to get the data from the device tree at
that time.

I'll look into the details more.

What about checking to see if it's setup assuming that's possible by
looking at registers, and then not messing with it if it's already
setup, otherwise do what my patch does.

Thanks,
John

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
Sent: Monday, March 17, 2008 1:48 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART
initialization

On Mon, Mar 17, 2008 at 10:41 AM, John Linn [EMAIL PROTECTED]
wrote:
 The UART 16550 initialization was not setting up the registers
  correctly. Code was added to pull the frequency and speed from
  the device tree and initialize the registers using those values.

  The boot code was not and is still not using the cmd line
  to setup up the uart. The frequency of the clock driving the
  UART must be specified in the device tree so that the baud
  rate generator can be setup.

The bootwrapper makes the assumption that the firmware has already
initialized the serial device and it should not be fiddled with so
that there is less chance of messing up a working output
configuration.

For platforms such as the virtex which don't have firmware the serial
port should be setup earlier in the boot process (in the appropriate
platform_init() function).

Cheers,
g.


  ---

  Please pull this patch for 2.6.26.
  ---
   arch/powerpc/boot/ns16550.c |   69
+-
   1 files changed, 54 insertions(+), 15 deletions(-)

  diff --git a/arch/powerpc/boot/ns16550.c
b/arch/powerpc/boot/ns16550.c
  index f8f1b2f..d8edd48 100644
  --- a/arch/powerpc/boot/ns16550.c
  +++ b/arch/powerpc/boot/ns16550.c
  @@ -15,23 +15,47 @@
   #include io.h
   #include ops.h

  -#define UART_DLL   0   /* Out: Divisor Latch Low */
  -#define UART_DLM   1   /* Out: Divisor Latch High */
  -#define UART_FCR   2   /* Out: FIFO Control Register */
  -#define UART_LCR   3   /* Out: Line Control Register */
  -#define UART_MCR   4   /* Out: Modem Control Register */
  -#define UART_LSR   5   /* In:  Line Status Register */
  -#define UART_LSR_THRE  0x20/* Transmit-hold-register empty */
  -#define UART_LSR_DR0x01/* Receiver data ready */
  -#define UART_MSR   6   /* In:  Modem Status Register */
  -#define UART_SCR   7   /* I/O: Scratch Register */
  -
  -static unsigned char *reg_base;
  -static u32 reg_shift;
  +#define UART_DLL   0   /* Out: Divisor Latch Low */
  +#define UART_DLM   1   /* Out: Divisor Latch High */
  +#define UART_FCR   2   /* Out: FIFO Control Register
*/
  +#define UART_FCR_CLEAR_RCVR0x02/* Clear the RCVR FIFO */
  +#define UART_FCR_CLEAR_XMIT0x04/* Clear the XMIT FIFO */
  +#define UART_LCR   3   /* Out: Line Control Register
*/
  +#define UART_MCR   4   /* Out: Modem Control
Register */
  +#define UART_MCR_RTS   0x02/* RTS complement */
  +#define UART_MCR_DTR   0x01/* DTR complement */
  +#define UART_LSR   5   /* In:  Line Status Register
*/
  +#define UART_LSR_THRE  0x20/* Transmit-hold-register
empty */
  +#define UART_LSR_DR0x01/* Receiver data ready */
  +#define UART_LCR_DLAB  0x80/* Divisor latch access bit
*/
  +#define UART_LCR_WLEN8 0x03/* Wordlength: 8 bits */
  +#define UART_MSR   6   /* In:  Modem Status Register
*/
  +#define UART_SCR   7   /* I/O: Scratch Register */
  +
  +volatile static unsigned char *reg_base;
  +volatile static u32 reg_shift;
  +volatile static u16 divisor;

   static int ns16550_open(void)
   {
  -   out_8(reg_base + (UART_FCR  reg_shift), 0x06);
  +
  +   /* Access baud rate */
  +   out_8(reg_base + (UART_LCR  reg_shift), UART_LCR_DLAB);
  +
  +   /* Baud rate based on input clock */
  +   out_8(reg_base + (UART_DLL  reg_shift), divisor  0xFF);
  +   out_8(reg_base + (UART_DLM  reg_shift), divisor  8);
  +
  +   /* 8 data, 1 stop, no parity */
  +   out_8(reg_base + (UART_LCR  reg_shift), UART_LCR_WLEN8);
  +
  +   /* RTS/DTR */
  +   out_8(reg_base + (UART_MCR  reg_shift), UART_MCR_RTS |
UART_MCR_DTR);
  +
  +   /* Clear transmitter and receiver */
  +   out_8(reg_base + (UART_FCR  reg_shift),
  +   UART_FCR_CLEAR_XMIT |
UART_FCR_CLEAR_RCVR);
  +
 return 0;
   }

  @@ -56,6 +80,7 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
   {
 int n;
 unsigned long reg_phys;
  +   u32 clk, spd;

 n = getprop(devp, virtual-reg, reg_base, sizeof(reg_base));
 if (n != 

Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[Grant Likely]

On Mon, Mar 17, 2008 at 1:57 PM, John Linn [EMAIL PROTECTED] wrote:
 That makes sense.  Since I'm not using a boot loader I didn't realize
  that.

  I'm not sure how hard it will be to get the data from the device tree at
  that time.

You should be good.  It is now possible to read data from the device
tree at platform_init() time.

Cheers,
g.

  What about checking to see if it's setup assuming that's possible by
  looking at registers, and then not messing with it if it's already
  setup, otherwise do what my patch does.

Ugh.  The old arch/ppc code used to do this and it was kind of ugly
and fragile.  I'd rather avoid doing it again.

Cheers,
g.

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

RE: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[John Linn]

Great, I'll do that.

Does this also apply to my other patch, Adding 8250 console support to
OF serial, as it's not clear to me when to assume the UART is already
setup or not?

Thanks,
John

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
Sent: Monday, March 17, 2008 2:08 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART
initialization

On Mon, Mar 17, 2008 at 1:57 PM, John Linn [EMAIL PROTECTED] wrote:
 That makes sense.  Since I'm not using a boot loader I didn't realize
  that.

  I'm not sure how hard it will be to get the data from the device tree
at
  that time.

You should be good.  It is now possible to read data from the device
tree at platform_init() time.

Cheers,
g.

  What about checking to see if it's setup assuming that's possible by
  looking at registers, and then not messing with it if it's already
  setup, otherwise do what my patch does.

Ugh.  The old arch/ppc code used to do this and it was kind of ugly
and fragile.  I'd rather avoid doing it again.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.


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

Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[Grant Likely]

On Mon, Mar 17, 2008 at 2:10 PM, John Linn [EMAIL PROTECTED] wrote:
 Great, I'll do that.

  Does this also apply to my other patch, Adding 8250 console support to
  OF serial, as it's not clear to me when to assume the UART is already
  setup or not?

I haven't reviewed that one yet.  I'll get to it this afternoon.

g.

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

RE: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[Stephen Neuendorffer]

Grant,

If you have working platform code using libfdt, can you publish it?

Steve

 -Original Message-
 From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
 [EMAIL PROTECTED] On Behalf Of Grant
Likely
 Sent: Monday, March 17, 2008 1:08 PM
 To: John Linn
 Cc: linuxppc-dev@ozlabs.org
 Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART
initialization
 
 On Mon, Mar 17, 2008 at 1:57 PM, John Linn [EMAIL PROTECTED]
wrote:
  That makes sense.  Since I'm not using a boot loader I didn't
realize
   that.
 
   I'm not sure how hard it will be to get the data from the device
tree at
   that time.
 
 You should be good.  It is now possible to read data from the device
 tree at platform_init() time.
 
 Cheers,
 g.
 
   What about checking to see if it's setup assuming that's possible
by
   looking at registers, and then not messing with it if it's already
   setup, otherwise do what my patch does.
 
 Ugh.  The old arch/ppc code used to do this and it was kind of ugly
 and fragile.  I'd rather avoid doing it again.
 
 Cheers,
 g.
 
 --
 Grant Likely, B.Sc., P.Eng.
 Secret Lab Technologies Ltd.
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev


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

Re: [PATCH 2/3] Xilinx: hwicap: Verify sync before reading idcode.

[Grant Likely]

On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
[EMAIL PROTECTED] wrote:
 It appears that in some cases, the sync word might not be recognized
  by the hardware correctly.  If this happens, then attempting to read
  from the port results in an unrecoverable error because of the design
  of the FPGA core.  This patch updates the code to check the status of
  the device before reading the IDCODE, in order to avoid entering this
  unrecoverable state.  This patch also adds additional NOOP commands
  into the sychronization sequence, which appears to be necessary to
  avoid the condition on some hardware.

  Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]

  ---
   drivers/char/xilinx_hwicap/xilinx_hwicap.c |   18 ++
   1 files changed, 18 insertions(+), 0 deletions(-)

  diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c 
 b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
  index 304727d..5b8d646 100644
  --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
  +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
  @@ -250,8 +250,26 @@ static int hwicap_get_configuration_register(struct 
 hwicap_drvdata *drvdata,
  * Create the data to be written to the ICAP.
  */
 buffer[index++] = XHI_DUMMY_PACKET;
  +   buffer[index++] = XHI_NOOP_PACKET;
 buffer[index++] = XHI_SYNC_PACKET;
 buffer[index++] = XHI_NOOP_PACKET;
  +   buffer[index++] = XHI_NOOP_PACKET;
  +
  +   /*
  +* Write the data to the FIFO and initiate the transfer of data 
 present
  +* in the FIFO to the ICAP device.
  +*/
  +   status = drvdata-config-set_configuration(drvdata,
  +   buffer[0], index);
  +   if (status)
  +   return status;
  +
  +   /* If the syncword was not found, then we need to start over. */
  +   status = drvdata-config-get_status(drvdata);
  +   if ((status  XHI_SR_DALIGN_MASK) != XHI_SR_DALIGN_MASK)
  +   return -EIO;
  +
  +   index = 0;
 buffer[index++] = hwicap_type_1_read(reg) | 1;
 buffer[index++] = XHI_NOOP_PACKET;
 buffer[index++] = XHI_NOOP_PACKET;
  --
  1.5.3.4-dirty



  --
  To unsubscribe from this list: send the line unsubscribe linux-kernel in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/




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

Re: powerpc: cuImage.* creation error

[Paul Gortmaker]

In message: powerpc: cuImage.* creation error
on 17/03/2008 Adrian Bunk wrote:

 When building all powerpc defconfigs in 2.6.25-rc6 exactly three of 
 them fail to build, and all with similar problems:
 
 --  snip  --
 
 
 sbc8548_defconfig:
 
 --  snip  --
 
 ...
 Entry Point:  0x
 make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', 
 needed by `arch/powerpc/boot/zImage'.  Stop.
 

Untested, but I'll guess that this is at least part of the problem for
the sbc one...

Thanks,
Paul.

---

Author: Paul Gortmaker [EMAIL PROTECTED]
Date:   Mon Mar 17 15:47:03 2008 -0400

cuimage: fix board names in Makefile

Fix the copy and paste error from 25431333813686654907ab987fb5de10c10a16db
for the sbc8548 and sbc8560

Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4974d9e..1aded8f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += 
cuImage.tqm8540
 image-$(CONFIG_TQM8541)+= cuImage.tqm8541
 image-$(CONFIG_TQM8555)+= cuImage.tqm8555
 image-$(CONFIG_TQM8560)+= cuImage.tqm8560
-image-$(CONFIG_SBC8548)+= cuImage.tqm8548
-image-$(CONFIG_SBC8560)+= cuImage.tqm8560
+image-$(CONFIG_SBC8548)+= cuImage.sbc8548
+image-$(CONFIG_SBC8560)+= cuImage.sbc8560
 
 # Board ports in arch/powerpc/platform/embedded6xx/Kconfig
 image-$(CONFIG_STORCENTER) += cuImage.storcenter
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/3] Xilinx: hwicap: Use fixed device major.

[Grant Likely]

On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
[EMAIL PROTECTED] wrote:
 Major 259 has been assigned by lanana.  Use it.  Also, publish
  /dev/icap[0-k] as the device entries, and register platform devices
  named 'icap' to be consistent.

  Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]

Looks good to me
Acked-by: Grant Likely [EMAIL PROTECTED]

  ---
   drivers/char/xilinx_hwicap/xilinx_hwicap.c |   43 
 +---
   1 files changed, 14 insertions(+), 29 deletions(-)

  diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c 
 b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
  index 5b8d646..016f905 100644
  --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
  +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
  @@ -36,7 +36,7 @@
   
 */

   /*
  - * This is the code behind /dev/xilinx_icap -- it allows a user-space
  + * This is the code behind /dev/icap* -- it allows a user-space
   * application to use the Xilinx ICAP subsystem.
   *
   * The following operations are possible:
  @@ -67,7 +67,7 @@
   * user-space application code that uses this device.  The simplest
   * way to use this interface is simply:
   *
  - * cp foo.bit /dev/xilinx_icap
  + * cp foo.bit /dev/icap0
   *
   * Note that unless foo.bit is an appropriately constructed partial
   * bitstream, this has a high likelyhood of overwriting the design
  @@ -105,18 +105,14 @@
   #include buffer_icap.h
   #include fifo_icap.h

  -#define DRIVER_NAME xilinx_icap
  +#define DRIVER_NAME icap

   #define HWICAP_REGS   (0x1)

  -/* dynamically allocate device number */
  -static int xhwicap_major;
  -static int xhwicap_minor;
  +#define XHWICAP_MAJOR 259
  +#define XHWICAP_MINOR 0
   #define HWICAP_DEVICES 1

  -module_param(xhwicap_major, int, S_IRUGO);
  -module_param(xhwicap_minor, int, S_IRUGO);
  -
   /* An array, which is set to true when the device is registered. */
   static bool probed_devices[HWICAP_DEVICES];
   static struct mutex icap_sem;
  @@ -605,7 +601,7 @@ static int __devinit hwicap_setup(struct device *dev, 
 int id,
 probed_devices[id] = 1;
 mutex_unlock(icap_sem);

  -   devt = MKDEV(xhwicap_major, xhwicap_minor + id);
  +   devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR + id);

 drvdata = kzalloc(sizeof(struct hwicap_drvdata), GFP_KERNEL);
 if (!drvdata) {
  @@ -710,7 +706,7 @@ static int __devexit hwicap_remove(struct device *dev)
 dev_set_drvdata(dev, NULL);

 mutex_lock(icap_sem);
  -   probed_devices[MINOR(dev-devt)-xhwicap_minor] = 0;
  +   probed_devices[MINOR(dev-devt)-XHWICAP_MINOR] = 0;
 mutex_unlock(icap_sem);
 return 0;   /* success */
   }
  @@ -850,23 +846,12 @@ static int __init hwicap_module_init(void)
 icap_class = class_create(THIS_MODULE, xilinx_config);
 mutex_init(icap_sem);

  -   if (xhwicap_major) {
  -   devt = MKDEV(xhwicap_major, xhwicap_minor);
  -   retval = register_chrdev_region(
  -   devt,
  -   HWICAP_DEVICES,
  -   DRIVER_NAME);
  -   if (retval  0)
  -   return retval;
  -   } else {
  -   retval = alloc_chrdev_region(devt,
  -   xhwicap_minor,
  -   HWICAP_DEVICES,
  -   DRIVER_NAME);
  -   if (retval  0)
  -   return retval;
  -   xhwicap_major = MAJOR(devt);
  -   }
  +   devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
  +   retval = register_chrdev_region(devt,
  +   HWICAP_DEVICES,
  +   DRIVER_NAME);
  +   if (retval  0)
  +   return retval;

 retval = platform_driver_register(hwicap_platform_driver);

  @@ -891,7 +876,7 @@ static int __init hwicap_module_init(void)

   static void __exit hwicap_module_cleanup(void)
   {
  -   dev_t devt = MKDEV(xhwicap_major, xhwicap_minor);
  +   dev_t devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);

 class_destroy(icap_class);

  --
  1.5.3.4-dirty







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

Re: [PATCH 1/3] Xilinx: hwicap: Refactor status handling code.

[Grant Likely]

On Mon, Mar 17, 2008 at 11:36 AM, Stephen Neuendorffer
[EMAIL PROTECTED] wrote:
 Both the buffer-based and fifo-based icap cores have a status
  register.  Previously, this was only used internally to check whether
  transactions have completed.  However, the status can be useful to the
  main driver as well.  This patch exposes these status functions to the
  main driver along with some masks for the differnet bits.

  Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]

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

Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[Grant Likely]

On Mon, Mar 17, 2008 at 2:17 PM, Stephen Neuendorffer
[EMAIL PROTECTED] wrote:
 Grant,

  If you have working platform code using libfdt, can you publish it?

Yes,

I've actually already published it once.  I'll post v2 this afternoon.

g.


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

RE: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization

[Stephen Neuendorffer]

Sorry, guess I missed it...
Steve

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
 Sent: Monday, March 17, 2008 1:25 PM
 To: Stephen Neuendorffer
 Cc: John Linn; linuxppc-dev@ozlabs.org
 Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART
initialization
 
 On Mon, Mar 17, 2008 at 2:17 PM, Stephen Neuendorffer
 [EMAIL PROTECTED] wrote:
  Grant,
 
   If you have working platform code using libfdt, can you publish it?
 
 Yes,
 
 I've actually already published it once.  I'll post v2 this afternoon.
 
 g.
 
 
 --
 Grant Likely, B.Sc., P.Eng.
 Secret Lab Technologies Ltd.


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

Re: Interrupt handling documentation

[Benjamin Herrenschmidt]

On Mon, 2008-03-17 at 17:13 +0100, Laurent Pinchart wrote:

 The PIC I am working with is linked to a falling-edge external irq on the 
 CPM2. When the first PIC interrupt was generated the kernel called the PIC 
 chained irq handler endlessly.
 
 After some investigation it turned out the external interrupt bit in the CPM2 
 interrupt pending register never got cleared. set_irq_chained_handler() 
 registers the chained irq handler at the lowest level in the irq stack, 
 bypassing all the interrupt acknowledgement/masking logic.

Yes, exactly. To answer a previous question in the thread, the reason
there are two approaches to cascades is just that:

 - The easy approach using setup_irq(). The normal interrupt handling
is done for the cascade, it's masked/acked/whatever-is-needed as any
other interrupt before the second interrupt is fetched. This results
is slightly more kernel stack usage and overhead in getting to the
second interrupt, among other things, but is easier.

 - The fast approach using a chained handler. This, as you noticed,
bypass pretty much the whole stack and calls the chain handler directly.
That means that your chain handler is responsible to perform all the
necessary things to ensure the cascade interrupt is properly ack'ed
etc...
 
 The fix was easy, all I had to do was to call desc-chip-ack(irq) at the 
 beginning on the chained irq handler and desc-chip-eoi(irq) at the end. 

For an edge cascade, that would do, I suppose. But beware that if you
are only calling ack() and not mask(), then a subsequent chain interrupt
from the same cascade can (and will) potentially happen while you are
calling the handler as the cascade itself has been ack'ed and not
masked. In the case of cpm2, that also probably means you don't need to
call end().

That might be fine though, but it increases the chances of having of
stack overflows caused by interrupts stacking up.

 However, I'm wondering if this really belongs in the PIC code, or if PICs 
 shouldn't be registered at a higher level (setup_irq or even request_irq) so 
 that they would reuse the handle_*_irq handlers. Any opinion on this ?

They can. The chain handling mechanism is an optimisation. It avoids a
spinlock and other bits  pieces which improve performance  latency of
handling cascaded interrupts, at the expense of that added complexity.

Ben.

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

RE: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine

[Nelson, Shannon]

From: Olof Johansson [mailto:[EMAIL PROTECTED] 
Sent: Sunday, March 16, 2008 2:30 PM

pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine

DMA copy offload driver for PA Semi PWRficient. It uses the
platform-specific functions to allocate channels, etc.

Signed-off-by: Olof Johansson [EMAIL PROTECTED]

---

Changes since last post:

* Add DMA_INTERRUPT support and handling of the interrupt flag
* Fix interrupt handler for above and add tasklet
* Switch to spin_lock_bh() where possible
* Remove empty dependency_added() function since it's no longer
  used in the framework.
* Fix bug in ring full estimation.

Note that this still needs to go on top of the powerpc.git 
tree due to the
pasemi_dma.h updates that this driver depends on. I suggest 
merging this
through pasemi.git-powerpc.git-linus with an Acked-by from 
the DMA guys.

Hi Olof,

In the future please copy Maciej as one of the DMA guys as he has
taken over ioatdma for me.  Beyond that, one little picky comment
below...




-Olof

 [...]
 
+
+static unsigned int channels = 4;
+module_param(channels, uint, S_IRUGO);
+MODULE_PARM_DESC(channels, Number of channels for copy 
(default: 2));

Is the number of channels defaulting to 2 or 4?

sln

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

Re: Please pull linux-2.6-mpc52xx.git

[Wolfgang Denk]

In message [EMAIL PROTECTED] you wrote:

   What is the status of the various MPC5200-related patches (support for
   TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
   time ago by Marian Balakowicz? There's been some comments to the patches
   on the list, which were addressed and no further discussion occurred, so
   we were hoping that the changes would go upstream (in 2.6.25). I can see
   that the .dts files for those boards are in the mainline already, but I
   see no trace of for example _defconfig files -- could you shed some
   light on this?
 
 Yes, the separate dts files have been dropped in preference for a
 single mpc5200_defconfig for all 5200 boards.

I know that my opinion doesn't matter but that's a  stupid  thing  to
do. Do you think that this single mpc5200_defconfig will (a) work and
(b)  be  useful  on all 5200 boards? Who hast tested it, and on which
platforms?

And what about the other patches? I see no code for these boards in
arch/powerpc/platforms/52xx/ ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Minds are like parachutes - they only function when open.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Benjamin Herrenschmidt]

On Tue, 2008-03-18 at 08:25 +1100, Benjamin Herrenschmidt wrote:
   
   Signed-off-by: Pravin M. Bathija [EMAIL PROTECTED]
   Signed-off-by: Stefan Roese [EMAIL PROTECTED]
   ---
drivers/net/ibm_newemac/core.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
  
  applied
 
 Thanks. There's also a couple of patches from Valentine that should go
 in. I'll ask him to resend to you.

Actually, they need some arch bits so they are better off going through
Josh tree on top of the said changes.

Valentine, can you make sure Jeff at least has a chance to see them and
ack them though ?

Cheers,
Ben.


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

Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Benjamin Herrenschmidt]

  
  Signed-off-by: Pravin M. Bathija [EMAIL PROTECTED]
  Signed-off-by: Stefan Roese [EMAIL PROTECTED]
  ---
   drivers/net/ibm_newemac/core.c |7 +++
   1 files changed, 7 insertions(+), 0 deletions(-)
 
 applied

Thanks. There's also a couple of patches from Valentine that should go
in. I'll ask him to resend to you.

Cheers,
Ben.


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

Re: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Mon, Mar 17, 2008 at 2:59 PM, Wolfgang Denk [EMAIL PROTECTED] wrote:
 In message [EMAIL PROTECTED] you wrote:
  
 What is the status of the various MPC5200-related patches (support for
 TQM5200, CM5200 and Motion-PRO boards, few drivers, etc) posted some
 time ago by Marian Balakowicz? There's been some comments to the patches
 on the list, which were addressed and no further discussion occurred, so
 we were hoping that the changes would go upstream (in 2.6.25). I can see
 that the .dts files for those boards are in the mainline already, but I
 see no trace of for example _defconfig files -- could you shed some
 light on this?
  
   Yes, the separate dts files have been dropped in preference for a
   single mpc5200_defconfig for all 5200 boards.

  I know that my opinion doesn't matter but that's a  stupid  thing  to
  ^
Bull.  You know better than that.

  do. Do you think that this single mpc5200_defconfig will (a) work and
  (b)  be  useful  on all 5200 boards? Who hast tested it, and on which
  platforms?

a) the same way we know that 5200 ethernet driver (for example) works
on all 5200 boards.  If it breaks for one board then we fix it.
b) defconfigs is more about testing and a known working configuration
than it is about a distribution configuration.  It's not intended to
be the deployed config.  For a distribution/deployable image it is
expected that the engineer responsible will tailor the config.

  And what about the other patches? I see no code for these boards in
  arch/powerpc/platforms/52xx/ ?

All these boards are supported with
arch/powerpc/platforms/mpc5200_simple.c.  A kernel built for that
platform will boot on any of those boards as long as it is passed the
correct device tree.

Cheers,
g.

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

Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus

[Timur Tabi]

Joakim Tjernlund wrote:

 Trying to add fixed-link support for ucc_geth as this is broken too. I
 noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
 my board once I got the ucc_geth driver to recognize fixed-link.
 Does it work for you?

A long time ago there was a bug where ifconfig eth1 down would cause a kernel
panic if eth0 was also up.  The root cause was a bug in rheap.c.  However, this
code was fixed a year ago.  Could it be a similar bug?

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

Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus

[Joakim Tjernlund]

On Mon, 2008-03-17 at 16:46 -0500, Timur Tabi wrote:
 Joakim Tjernlund wrote:
 
  Trying to add fixed-link support for ucc_geth as this is broken too. I
  noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
  my board once I got the ucc_geth driver to recognize fixed-link.
  Does it work for you?
 
 A long time ago there was a bug where ifconfig eth1 down would cause a 
 kernel
 panic if eth0 was also up.  The root cause was a bug in rheap.c.  However, 
 this
 code was fixed a year ago.  Could it be a similar bug?

eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f
that fixed that bug? 2.6.23 works fine for me.

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

Re: powerpc: cuImage.* creation error

[Adrian Bunk]

On Mon, Mar 17, 2008 at 04:07:55PM -0400, Paul Gortmaker wrote:
 In message: powerpc: cuImage.* creation error
 on 17/03/2008 Adrian Bunk wrote:
 
  When building all powerpc defconfigs in 2.6.25-rc6 exactly three of 
  them fail to build, and all with similar problems:
  
  --  snip  --
  
  
  sbc8548_defconfig:
  
  --  snip  --
  
  ...
  Entry Point:  0x
  make[2]: *** No rule to make target `arch/powerpc/boot/cuImage.tqm8548', 
  needed by `arch/powerpc/boot/zImage'.  Stop.
  
 
 Untested, but I'll guess that this is at least part of the problem for
 the sbc one...

It doesn't fix the build, and adds sbc8560_defconfig to the list of 
non-compiling defconfigs:

--  snip  --

...
  WRAParch/powerpc/boot/cuImage.sbc8560
DTC: dts-dtb  on file 
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/sbc8560.dts
powerpc64-linux-ld: arch/powerpc/boot/cuboot-sbc8560.o: No such file: No such 
file or directory
make[2]: *** [arch/powerpc/boot/cuImage.sbc8560] Error 1

--  snip  --

 Thanks,
 Paul.
 
 ---
 
 Author: Paul Gortmaker [EMAIL PROTECTED]
 Date:   Mon Mar 17 15:47:03 2008 -0400
 
 cuimage: fix board names in Makefile
 
 Fix the copy and paste error from 25431333813686654907ab987fb5de10c10a16db
 for the sbc8548 and sbc8560
 
 Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
 
 diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
 index 4974d9e..1aded8f 100644
 --- a/arch/powerpc/boot/Makefile
 +++ b/arch/powerpc/boot/Makefile
 @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540)   += 
 cuImage.tqm8540
  image-$(CONFIG_TQM8541)  += cuImage.tqm8541
  image-$(CONFIG_TQM8555)  += cuImage.tqm8555
  image-$(CONFIG_TQM8560)  += cuImage.tqm8560
 -image-$(CONFIG_SBC8548)  += cuImage.tqm8548
 -image-$(CONFIG_SBC8560)  += cuImage.tqm8560
 +image-$(CONFIG_SBC8548)  += cuImage.sbc8548
 +image-$(CONFIG_SBC8560)  += cuImage.sbc8560
  
  # Board ports in arch/powerpc/platform/embedded6xx/Kconfig
  image-$(CONFIG_STORCENTER)   += cuImage.storcenter

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: Please pull linux-2.6-mpc52xx.git

[Wolfgang Denk]

In message [EMAIL PROTECTED] you wrote:

 b) defconfigs is more about testing and a known working configuration
 than it is about a distribution configuration.  It's not intended to
 be the deployed config.  For a distribution/deployable image it is
 expected that the engineer responsible will tailor the config.

This may be true in general, but for the boards in question it is
definitely incorrect:

* The TQM5200 configuration as provided is intended for  shipping  as
  default  configuration  for  this board. The engineer responsible
  already *did* the tailoring and put that  state  in  the  defconfig
  file.

* The CM5200 and Motion-Pro boards are custom designs, where the
  defconfig file matches exactly the requirements of the respective
  customers.

I feel it is very important to be able to include this  configuration
information  somewhere  with  the  kernel source tree - and to me the
defconfig file for a board is the most  natural  place  to  put  such
information.

Please understand that we do  NOT  expect  the  end  user  having  to
tailor  the  config  -  instead,  we  want  to  provide  a  default
configuration that can be used as is,  at  least  for  default  usage
cases.


If you don't want to use a board specific default configuration, then
please tell me what the recommended way is to provide a knwon  to  be
working,  tested  *and*  *useful*  default  configuration  for custom
boards in the Linux kernel tree?


 All these boards are supported with
 arch/powerpc/platforms/mpc5200_simple.c.  A kernel built for that
 platform will boot on any of those boards as long as it is passed the
 correct device tree.

I don't doubt that the kernel will boot. But that does not mean  that
it   is  ready  for  use  for  the  intended  purpose.  For  example,
arch/powerpc/platforms/52xx/motionpro.c contains code to  setup  some
custom   LEDs   on   this   board.   I   can't   find  that  code  in
arch/powerpc/platforms/mpc5200_simple.c.

It may be argued that this code should be moved somewhere else, but I
don't remeber to have seen any such review comments.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
You don't have to stay up nights to succeed; you have to  stay  awake
days.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus

[Joakim Tjernlund]

On Mon, 2008-03-17 at 16:46 -0500, Timur Tabi wrote:
 Joakim Tjernlund wrote:
 
  Trying to add fixed-link support for ucc_geth as this is broken too. I
  noticed that ifconfig eth1 up follwed by ifconfig eth1 down hangs
  my board once I got the ucc_geth driver to recognize fixed-link.
  Does it work for you?
 
 A long time ago there was a bug where ifconfig eth1 down would cause a 
 kernel
 panic if eth0 was also up.  The root cause was a bug in rheap.c.  However, 
 this
 code was fixed a year ago.  Could it be a similar bug?

BTW, I get this on the console:
BUG: soft lockup - CPU#0 stuck for 61s! [ifconfig:263]
NIP: c013649c LR: c0136490 CTR: c0015a34
REGS: c78a9cf0 TRAP: 0901   Not tainted  (2.6.25-rc5)
MSR: 9032 EE,ME,IR,DR  CR: 24022448  XER: 
TASK = c7822430[263] 'ifconfig' THREAD: c78a8000
GPR00:  c78a9da0 c7822430   0006  0240 
GPR08: 9032 c9062210 c02a  000c 
NIP [c013649c] ugeth_disable+0x13c/0x18c
LR [c0136490] ugeth_disable+0x130/0x18c
Call Trace:
[c78a9dc0] [c0136c8c] ucc_geth_stop+0x24/0xa0
[c78a9de0] [c01393e8] ucc_geth_close+0x9c/0xd8
[c78a9e00] [c0166f54] dev_close+0xac/0xb0
[c78a9e10] [c0169a7c] dev_change_flags+0x98/0x1c4
[c78a9e30] [c01b4a78] devinet_ioctl+0x668/0x79c
[c78a9eb0] [c01b6a94] inet_ioctl+0xb4/0xc4
[c78a9ec0] [c015a7a4] sock_ioctl+0x174/0x240
[c78a9ee0] [c0072efc] vfs_ioctl+0x88/0x9c
[c78a9ef0] [c0072fc8] do_vfs_ioctl+0xb8/0x400
[c78a9f10] [c0073350] sys_ioctl+0x40/0x74
[c78a9f40] [c000f2b0] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff65760
LR = 0xffeae5c
Instruction dump:
9149 8163 806b 4bedf571 38ac 38c0 7c641b78 3865 
4bedd70d 813e0008 7c0004ac 8009 0c00 4c00012c 740b2000 4182ffe

Which appear to be the last IN_BE call in ugeth_disable:

 7d4:   48 00 00 01 bl  7d4 ugeth_disable+0x12c
 7d8:   81 3e 00 08 lwz r9,8(r30)
DEF_MMIO_OUT(name, u##size, __stringify(insn) %1,0,%2)

DEF_MMIO_IN_BE(in_8, 8, lbz);
DEF_MMIO_IN_BE(in_be16, 16, lhz);
DEF_MMIO_IN_BE(in_be32, 32, lwz);
 7dc:   7c 00 04 ac sync
 7e0:   80 09 00 00 lwz r0,0(r9)
--- 7e4:   0c 00 00 00 twi 0,r0,0
 7e8:   4c 00 01 2c isync
 7ec:   74 0b 20 00 andis.  r11,r0,8192
 7f0:   41 82 ff ec beq+7dc ugeth_disable+0x134
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Jeff Garzik]

Benjamin Herrenschmidt wrote:

There's also the section mismatch patch I sent you.  I don't care who's
tree they go through, but I'd need to know either way so keep me in the
loop please.


Jeff, do you mind if we get those patches through the powerpc tree ?
EMAC is very powerpc specific and these are mostly internal driver
cuisine.


Fine with me in concept, though I haven't seen the patches in question.

Jeff



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

Re: [Patch] 8xx: MGSUVD support

[Scott Wood]

On Sun, Mar 09, 2008 at 07:59:14PM +0300, Vitaly Bordug wrote:
 I would like all the comments to be consistent C style (because that's it
 for the most other dts'es).

$ fgrep -rI // arch/powerpc/boot/dts/ | wc -l
539

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

Re: powerpc: cuImage.* creation error

[Grant Likely]

On Mon, Mar 17, 2008 at 1:36 PM, Adrian Bunk [EMAIL PROTECTED] wrote:
 When building all powerpc defconfigs in 2.6.25-rc6 exactly three of
  them fail to build, and all with similar problems:


Looks like I added a bogus target (no dts file for the board yet) and
didn't match correctly the init code for the other two.  Please try
this:

--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -253,7 +253,6 @@ image-$(CONFIG_TQM8540) += cuImage.tqm85
 image-$(CONFIG_TQM8541)+= cuImage.tqm8541
 image-$(CONFIG_TQM8555)+= cuImage.tqm8555
 image-$(CONFIG_TQM8560)+= cuImage.tqm8560
-image-$(CONFIG_SBC8548)+= cuImage.tqm8548
 image-$(CONFIG_SBC8560)+= cuImage.tqm8560

 # Board ports in arch/powerpc/platform/embedded6xx/Kconfig
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d50e498..511e09e 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -174,7 +174,7 @@ cuboot*)
 *-mpc83*)
 platformo=$object/cuboot-83xx.o
 ;;
-*-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+*-tqm854?|*-mpc8560*|*-tqm8560|*-tqm8555*)
 platformo=$object/cuboot-85xx-cpm2.o
 ;;
 *-mpc85*)


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

Re: powerpc: cuImage.* creation error

[Grant Likely]

On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker
[EMAIL PROTECTED] wrote:
 In message: powerpc: cuImage.* creation error

  @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += 
 cuImage.tqm8540
   image-$(CONFIG_TQM8541)+= cuImage.tqm8541
   image-$(CONFIG_TQM8555)+= cuImage.tqm8555
   image-$(CONFIG_TQM8560)+= cuImage.tqm8560
  -image-$(CONFIG_SBC8548)+= cuImage.tqm8548
  -image-$(CONFIG_SBC8560)+= cuImage.tqm8560
  +image-$(CONFIG_SBC8548)+= cuImage.sbc8548
  +image-$(CONFIG_SBC8560)+= cuImage.sbc8560

No, the suffix in the cuImage targets has a 1:1 relationship with dts
files in arch/powerpc/boot/dts/.  If a file doesn't exist there, then
the target cannot be built.

Cheers,
g.

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

Re: powerpc: cuImage.* creation error

[Paul Gortmaker]

In message: Re: powerpc: cuImage.* creation error
on 17/03/2008 Grant Likely wrote:

 On Mon, Mar 17, 2008 at 2:07 PM, Paul Gortmaker
 [EMAIL PROTECTED] wrote:
  In message: powerpc: cuImage.* creation error
 
   @@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += 
  cuImage.tqm8540
image-$(CONFIG_TQM8541)+= cuImage.tqm8541
image-$(CONFIG_TQM8555)+= cuImage.tqm8555
image-$(CONFIG_TQM8560)+= cuImage.tqm8560
   -image-$(CONFIG_SBC8548)+= cuImage.tqm8548
   -image-$(CONFIG_SBC8560)+= cuImage.tqm8560
   +image-$(CONFIG_SBC8548)+= cuImage.sbc8548
   +image-$(CONFIG_SBC8560)+= cuImage.sbc8560
 
 No, the suffix in the cuImage targets has a 1:1 relationship with dts
 files in arch/powerpc/boot/dts/.  If a file doesn't exist there, then
 the target cannot be built.

You should have both the sbc8548.dts and the sbc8560.dts in your tree.
They have been in there for several weeks now.

I just tested with the above here, and I was just about to hit send on
this extra chunk to fix the second half of the problem.

Note that I didn't lump the tqm8540 in with the other tqm, because the
defconfig tends to indicate it doesn't need 85xx-cpm2;  just 85xx.

Thanks,
Paul.

--

Author: Paul Gortmaker [EMAIL PROTECTED]
Date:   Mon Mar 17 18:33:52 2008 -0400

wrapper: Add entries for tqm8540 and sbc85xx

The wrapper script didn't have entries for the TQM8540 board and the
SBC8548 or SBC8560 boards.  I've assumed that the TQM8540 console is
8250 based and not CPM based by looking at its defconfig.  There was
also a trailing * on the TQM8555 entry that I removed too.

Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d50e498..8ec8ea8 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -174,7 +174,10 @@ cuboot*)
 *-mpc83*)
 platformo=$object/cuboot-83xx.o
 ;;
-*-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+*-tqm8540|*-sbc85*)
+platformo=$object/cuboot-85xx.o
+;;
+*-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555)
 platformo=$object/cuboot-85xx-cpm2.o
 ;;
 *-mpc85*)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.

[Scott Wood]

On Fri, Mar 14, 2008 at 10:24:30AM +0100, Heiko Schocher wrote:
 + setbits16(mpc8xx_immr-im_ioport.iop_pcso, 0x300);
 + cpm1_clk_setup(CPM_CLK_SCC3, CPM_CLK5, CPM_CLK_RX);
 + cpm1_clk_setup(CPM_CLK_SCC3, CPM_CLK6, CPM_CLK_TX);
 + setbits32(mpc8xx_immr-im_cpm.cp_pbpar, 0x300);
 + setbits32(mpc8xx_immr-im_cpm.cp_pbdir, 0x300);

Any particular reason not to use cpm1_set_pin() rather than those setbits?

 +static void __init mgsuvd_setup_arch(void)
 +{
 + struct device_node *cpu;
 +
 + cpu = of_find_node_by_type(NULL, cpu);
 + if (cpu != 0) {
 + const unsigned int *fp;
 +
 + fp = of_get_property(cpu, clock-frequency, NULL);
 + if (fp != 0)
 + loops_per_jiffy = *fp / HZ;
 + else
 + loops_per_jiffy = 5000 / HZ;
 + of_node_put(cpu);
 + }
 +

This is obsolete and unnecessary.

 + ROOT_DEV = Root_NFS;

Likewise.

 +static int __init mgsuvd_probe(void)
 +{
 + char *model = of_get_flat_dt_prop(of_get_flat_dt_root(),
 +   model, NULL);
 + if (model == NULL)
 + return 0;
 + if (strcmp(model, MGSUVD))
 + return 0;
 +
 + return 1;
 +}

Check compatible (using of_flat_dt_is_compatible), not model.

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

Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus

[Timur Tabi]

Joakim Tjernlund wrote:

 eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f
 that fixed that bug?

Yep.  Unfortunately, I don't really know enough about the ucc_geth driver to
know what could be wrong.  I just noticed your message and remembered that old 
bug.

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

Re: [PATCH] arch/powerpc/platforms/iseries/pci.c: Use time_* macros

[Stephen Rothwell]

On Mon, 17 Mar 2008 11:36:26 +0200 S.Çağlar Onur [EMAIL PROTECTED] wrote:

 The functions time_before, time_before_eq, time_after, and time_after_eq are 
 more robust for comparing jiffies against other values.
 
 So following patch implements usage of the time_after() macro, defined at 
 linux/jiffies.h, which deals with wrapping correctly
 
 Cc: linuxppc-dev@ozlabs.org
 Cc: Paul Mackerras [EMAIL PROTECTED]
 Cc: Andrew Morton [EMAIL PROTECTED]
 Signed-off-by: S.Çağlar Onur [EMAIL PROTECTED]

Acked-by: Stephen Rothwell [EMAIL PROTECTED]

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


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

Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus

[Joakim Tjernlund]

On Mon, 2008-03-17 at 18:08 -0500, Timur Tabi wrote:
 Joakim Tjernlund wrote:
 
  eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f
  that fixed that bug?
 
 Yep.  Unfortunately, I don't really know enough about the ucc_geth driver to
 know what could be wrong.  I just noticed your message and remembered that 
 old bug.
 

I noticed that ugeth_graceful_stop_rx() is lacking in_8()/out_8() so I
am adding that, but I cant test until tmw.

Also notice that there is a lot of in_beX()/out_beX() in the driver and
those functions use the sync instruction. Won't that much suny usage
hurt performance and is sync really needed?

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

Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Benjamin Herrenschmidt]

On Mon, 2008-03-17 at 18:31 -0400, Jeff Garzik wrote:
  Jeff, do you mind if we get those patches through the powerpc tree ?
  EMAC is very powerpc specific and these are mostly internal driver
  cuisine.
 
 Fine with me in concept, though I haven't seen the patches in
 question.

Yup, I've asked people to copy you on them so you get a chance to ack
them :-)

Cheers,
Ben.


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

Re: [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine

[Olof Johansson]

On Mon, Mar 17, 2008 at 11:46:39AM -0700, Dan Williams wrote:
 Looks good, makes me want to go back and cleanup iop-adma a bit.  A
 few fyi's below, but no other review comments.
 
   Note that this still needs to go on top of the powerpc.git tree due to the
   pasemi_dma.h updates that this driver depends on. I suggest merging this
   through pasemi.git-powerpc.git-linus with an Acked-by from the DMA guys.
 
 Ok, it still may not compile in mainline until after 2.6.26-rc1 due to
 additional dmaengine cleanups like the ack-to-flags change I posted
 earlier.  Any better way to handle this?  Go through -mm?

Either go through -mm where Andrew can keep it applied in appropriate
order and send upstream, or just merge it late. It's a new driver, and
they're normally OK to go in a little later. That might be the easiest
solution in this case.

 Acked-by: Dan Williams [EMAIL PROTECTED]

Thanks!

-Olof

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

Re: Please pull linux-2.6-mpc52xx.git

[Wolfgang Denk]

Dear Grant,

in message [EMAIL PROTECTED] you wrote:
 
 However, I have declined (for now) to pick up the defconfigs for those
 boards and instead merged in the config features they require into the
 mpc5200 defconfig.  My primary reason for doing so is to increase the
 likelyhood that full featured kernels are built and tested so that
 situations where board ports conflict with each other are caught and
 fixed.

I know what you mean, and I agree with the idea.

Unfortunately I think it's impossible to implement, especially on such
embedded processors with their high level of pin multiplexing.

For example, if you want to  include  testing  of  the  FEC  ethernet
driver,  you  will probably fail to test the second USB port. I think
it's simply not possible to test all possible  options  in  a  single
kernel  configuration - first it doesn't work (for example because of
pin multiplexing issues), second you will likely not be able to  find
hardware that implements all features at once.

My dream is to have a distributed  test  environment  -  a  framework
which  can  be used for automatic testing which includes building and
running the code on a set of systems, and which will then report  the
test results to a central location.

We have the same problem  (probably  to  a  much  higher  degree)  in
U-Boot;  nobody  can test all board configurations because nobody has
all the cross-tools installed nor the 500+ boards available.

 ojn has also been complaining about the number of defconfigs he needs
 to build to test all the powerpc configurations without any
 indications about which ones are important and which ones are not.

again, some distributed test tool might help - we would get not  only
information  abouyt  test results, but also which configurations have
been tested how frequently.

 There has been some discussion about having a subdirectory for
 optimized board configs, but nobody has done anything about it yet.

Is this a hint?

 The one part that I have a really strong opinion on is that there
 should be a full featured mpc5200 defconfig for build testing.  Beyond
 that (and if ojn can also be appeased) I can probably be convinced.  :-)

Maybe my expectations for full featured' are just too high..

 The LED code just hasn't been picked up.  IIRC, it was reworked to
 make it a proper driver in drivers/leds.  I need to look at it again,
 but it is a lot of code for a very simple thing and I wasn't sure if I
 should be the one to pick it up because it is in drivers/leds which
 has a different maintainer.

I see. Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
If some day we are defeated, well, war has  its  fortunes,  good  and
bad.
-- Commander Kor, Errand of Mercy, stardate 3201.7
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] Force 4K pages for IO addresses.

[Olof Johansson]

On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
 Currently HEA requires 4K pages for IO resources.  Just set the pages size to
 IO to 4K.

Well, that's too bad. Why penalize all platforms for it?

I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
waste tlb and erat space.


-Olof

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

Re: [Patch] 8xx: MGSUVD support

[Vitaly Bordug]

On Mon, 17 Mar 2008 17:38:21 -0500
Scott Wood wrote:

 On Sun, Mar 09, 2008 at 07:59:14PM +0300, Vitaly Bordug wrote:
  I would like all the comments to be consistent C style (because
  that's it for the most other dts'es).
 
 $ fgrep -rI // arch/powerpc/boot/dts/ | wc -l
 539
 
So, we should go ahead and add a bit more hassle :) ?

By consistent C style I mean:

+   clock-frequency = 0; /* Filled in by u-boot */ */
+   interrupts = f 2; // decrementer interrupt

using either one or other way for same-type comments.

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

Re: [PATCH] Fix PMU + soft interrupt disable bug

[Olof Johansson]

On Sun, Mar 16, 2008 at 11:27:09PM -0500, Anton Blanchard wrote:
 
 Since the PMU is an NMI now, it can come at any time we are only soft
 disabled. We must hard disable around the two places we allow the kernel
 stack SLB and r1 to go out of sync. Otherwise the PMU exception can
 force a kernel stack SLB into another slot.
 
 Signed-off-by: Anton Blanchard [EMAIL PROTECTED]

Acked-by: Olof Johansson [EMAIL PROTECTED]

This fixes some problems we've seen with multi-slb hits when running
oprofile.

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

Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Josh Boyer]

On Mon, 17 Mar 2008 18:31:53 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:

 Benjamin Herrenschmidt wrote:
  There's also the section mismatch patch I sent you.  I don't care who's
  tree they go through, but I'd need to know either way so keep me in the
  loop please.
  
  Jeff, do you mind if we get those patches through the powerpc tree ?
  EMAC is very powerpc specific and these are mostly internal driver
  cuisine.
 
 Fine with me in concept, though I haven't seen the patches in question.

http://marc.info/?l=linux-netdevm=120449748701492w=2

I sent it to Ben with netdev on CC because you asked the various people
sending NEWEMAC patches to you to find a single person.

So from now on, what are we going to do?  It seems we're playing net
maintainer russian roulette for NEWEMAC and it's getting old.

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

Re: [PATCH 1/4] Emerson ATCA-C125 bootwrapper

[David Gibson]

On Mon, Mar 17, 2008 at 03:19:45PM +0300, Alexandr Smirnov wrote:
 David,
 +   /* Unfortunately, the specific model number is encoded in the
 +* soc node name in existing dts files -- once that is fixed,
 +* this can do a simple path lookup.
 +*/
 

 Since this is a new board, couldn't you name the soc node /soc and
 dispense with this more complicated way of doing things?  Or would
 that break other versions of u-boot that are in use?
   
 As I understand you would like to rename /soc8548 node to /soc and make a 
 simple path lookup like following:
 - soc = find_node_by_devtype(NULL, soc);
 + soc = finddevice(/soc);
 Is this correct?

That's right.

 But fsl_soc code still uses of_find_node_by_type so we can't remove 
 device_type property from node /soc and therefor simplify device
 tree.

It does?  Grrr...  I thought that had been fixed and the only reason
the device_type was still needed was because some u-boot versions
needed it.  But you're right, that's not the case.

-- 
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: Please pull linux-2.6-mpc52xx.git

[Grant Likely]

On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk [EMAIL PROTECTED] wrote:
 Dear Grant,


  in message [EMAIL PROTECTED] you wrote:
  
   However, I have declined (for now) to pick up the defconfigs for those
   boards and instead merged in the config features they require into the
   mpc5200 defconfig.  My primary reason for doing so is to increase the
   likelyhood that full featured kernels are built and tested so that
   situations where board ports conflict with each other are caught and
   fixed.

  I know what you mean, and I agree with the idea.

  Unfortunately I think it's impossible to implement, especially on such
  embedded processors with their high level of pin multiplexing.

  For example, if you want to  include  testing  of  the  FEC  ethernet
  driver,  you  will probably fail to test the second USB port. I think
  it's simply not possible to test all possible  options  in  a  single
  kernel  configuration - first it doesn't work (for example because of
  pin multiplexing issues), second you will likely not be able to  find
  hardware that implements all features at once.

I don't think this example really applies.  Yes, I agree that I cannot
test all the functions, but that does not preclude building in all the
drivers and making sure that they don't cause a conflict by just being
present.  For instance, I can build a single kernel image right now
that should boot and fully run on the Efika, lite5200, tqm and motion
pro boards (although the Efika has a different wrapper).  I can only
test it on the Efika and lite5200 boards and I have to rely on other
people for the boards I don't have.  If it breaks; I expect to receive
an irate email in my Inbox telling me to fix it!

pin multiplexing shouldn't be an issue at all.  Only the devices which
are instantiated in the device tree will actually get initialized so
if the pins aren't hooked up then it shouldn't be in the tree.
Ideally, the bootloader should take care of the pin multiplexing
setup, but even if it doesn't it can be setup by platform code and
CONFIG_MULTIPLATFORM supports building multiple platforms into a
single image (within a processor family of course; you can't build a
405+6xx multiplatform kernel.)  tqm, motionpro and cm boards can all
use simple platform because they all have good firmware ports that
setup the hardware correctly in the first place.  lite5200(b) does not
because there are quite a few lite5200 boards 'in the wild' with
firmware that doesn't setup the board the way it should be (or at
least the way Linux likes it).

   There has been some discussion about having a subdirectory for
   optimized board configs, but nobody has done anything about it yet.

  Is this a hint?

Oh, probably.  :-)

Cheers,
g.

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

Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Benjamin Herrenschmidt]

 http://marc.info/?l=linux-netdevm=120449748701492w=2
 
 I sent it to Ben with netdev on CC because you asked the various people
 sending NEWEMAC patches to you to find a single person.
 
 So from now on, what are we going to do?  It seems we're playing net
 maintainer russian roulette for NEWEMAC and it's getting old.

I'm happy to collect the patches. I said I would do it, I was just taken
aback a bit by Jeff suddenly merging two of Stefan patches directly :-)

I was actually planning this week to post a serie of all the pending
EMAC patches for final review.

Cheers,
Ben.


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

Re: [PATCH v2] Force 4K pages for IO addresses.

[Benjamin Herrenschmidt]

On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote:
 On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
  Currently HEA requires 4K pages for IO resources.  Just set the pages size 
  to
  IO to 4K.
 
 Well, that's too bad. Why penalize all platforms for it?
 
 I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
 waste tlb and erat space.

We would have to make that pSeries specific for now I suppose...

We don't have a way to know that there can be an EHEA right ? It may
not be in the device-tree at boot and dynamically added to the
partition... And we can't dynamically demote the ioremap area like we
do for userspace as we have no tracking of bolted entries hashed in
early during boot (I plan to fix that but that will take a while).

Cheers,
Ben.


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

dtc: Change exit code for usage message

[David Gibson]

If dtc's command line arguments are invalid, it prints a usage message
and returns exit code 2.  That's the same exit code as for a failed
check, which is potentially confusing if running dtc from an automated
harness.  Therefore this patch changes the usage exit code to 3.

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

Index: dtc/dtc.c
===
--- dtc.orig/dtc.c  2008-03-18 14:02:42.0 +1100
+++ dtc/dtc.c   2008-03-18 14:02:46.0 +1100
@@ -106,7 +106,7 @@ static void  __attribute__ ((noreturn)) 
fprintf(stderr, \t\tForce - try to produce output even if the input 
tree has errors\n);
fprintf(stderr, \t-v\n);
fprintf(stderr, \t\tPrint DTC version and exit\n);
-   exit(2);
+   exit(3);
 }
 
 int main(int argc, char *argv[])

-- 
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: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Josh Boyer]

On Tue, 18 Mar 2008 13:41:40 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 
  http://marc.info/?l=linux-netdevm=120449748701492w=2
  
  I sent it to Ben with netdev on CC because you asked the various people
  sending NEWEMAC patches to you to find a single person.
  
  So from now on, what are we going to do?  It seems we're playing net
  maintainer russian roulette for NEWEMAC and it's getting old.
 
 I'm happy to collect the patches. I said I would do it, I was just taken
 aback a bit by Jeff suddenly merging two of Stefan patches directly :-)
 
 I was actually planning this week to post a serie of all the pending
 EMAC patches for final review.

Ok.  Either way, if it helps someone I'd be happy to roll them into a
newemac branch in my git tree.

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

Re: powerpc: cuImage.* creation error

[Grant Likely]

On Mon, Mar 17, 2008 at 5:22 PM, Grant Likely [EMAIL PROTECTED] wrote:
 On Mon, Mar 17, 2008 at 4:46 PM, Paul Gortmaker
   The wrapper script didn't have entries for the TQM8540 board and the
   SBC8548 or SBC8560 boards.  I've assumed that the TQM8540 console is
   8250 based and not CPM based by looking at its defconfig.  There was
   also a trailing * on the TQM8555 entry that I removed too.
  
  
   Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
  Acked-by: Grant Likely [EMAIL PROTECTED]

Actually, I looked again and tweaked a few details in the patch (it
was duplicating an existing clause in the wrapper script).  I'm just
about to post the edited version which I've tested in my environment.

Cheers,
g.

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

[PATCH][POWERPC] bootwrapper: Add entries for tqm8540 and sbc85xx

[Grant Likely]

From: Paul Gortmaker [EMAIL PROTECTED]

The wrapper script didn't have entries for the TQM8540 board and the
SBC8548 or SBC8560 boards.  I've assumed that the TQM8540 console is
8250 based and not CPM based by looking at its defconfig.  There was
also a trailing * on the TQM8555 entry that I removed too.

Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

Paulus; this fixes the broken defconfig issues that Adrian raised.  Can you
please pick this up for merger into 2.6.25?

Thanks,
g.

 arch/powerpc/boot/Makefile |4 ++--
 arch/powerpc/boot/wrapper  |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4974d9e..1aded8f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -253,8 +253,8 @@ image-$(CONFIG_TQM8540) += 
cuImage.tqm8540
 image-$(CONFIG_TQM8541)+= cuImage.tqm8541
 image-$(CONFIG_TQM8555)+= cuImage.tqm8555
 image-$(CONFIG_TQM8560)+= cuImage.tqm8560
-image-$(CONFIG_SBC8548)+= cuImage.tqm8548
-image-$(CONFIG_SBC8560)+= cuImage.tqm8560
+image-$(CONFIG_SBC8548)+= cuImage.sbc8548
+image-$(CONFIG_SBC8560)+= cuImage.sbc8560
 
 # Board ports in arch/powerpc/platform/embedded6xx/Kconfig
 image-$(CONFIG_STORCENTER) += cuImage.storcenter
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d50e498..8f8b849 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -174,10 +174,10 @@ cuboot*)
 *-mpc83*)
 platformo=$object/cuboot-83xx.o
 ;;
-*-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+*-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555)
 platformo=$object/cuboot-85xx-cpm2.o
 ;;
-*-mpc85*)
+*-mpc85*|*-tqm8540|*-sbc85*)
 platformo=$object/cuboot-85xx.o
 ;;
 esac

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

[BUG]2.6.25-rc6:Unable to handle kernel paging request

[Sudhir Kumar]

Hi,
I found the following bug at kernel boot up on my power machine
with 2.6.25-rc6 kernel.

USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
Unable to handle kernel paging request for data at address
0xd82e
Faulting instruction address: 0xc074ded8
cpu 0x0: Vector: 300 (Data Access) at [c0003e073aa0]
pc: c074ded8: .f71805f_find+0x44/0x32c
lr: c074e1f8: .f71805f_init+0x38/0x194
sp: c0003e073d20
   msr: 80009032
   dar: d82e
 dsisr: 4200
  current = 0xc000220851c0
  paca= 0xc07c2700
pid   = 1, comm = swapper
enter ? for help
[c0003e073dc0] c074e1f8 .f71805f_init+0x38/0x194
[c0003e073ea0] c0724bdc .kernel_init+0x204/0x3c8
[c0003e073f90] c0025df4 .kernel_thread+0x4c/0x68

For further reference some of the debug info is:
0:mon r
R00 = d82e   R16 = 41c0
R01 = c0003e073d20   R17 = c066ecc8
R02 = c08f4458   R18 = 
R03 = 002e   R19 = 003a1000
R04 = c0003e073e30   R20 = 0235a3d0
R05 = c0003e073e34   R21 = c075a3d0
R06 = 2444   R22 = 0235a640
R07 = c0010bcc   R23 = c075a640
R08 = c0003e073570   R24 = c066fe90
R09 = d800   R25 = 
R10 = cf9c2d60   R26 = c0003e07
R11 = ff87   R27 = c0003e073e30
R12 =    R28 = c0003e073e34
R13 = c07c2700   R29 = 002e
R14 =    R30 = c0880278
R15 = c0670448   R31 = c078e050
pc  = c074ded8 .f71805f_find+0x44/0x32c
lr  = c074e1f8 .f71805f_init+0x38/0x194
msr = 80009032   cr  = 2442
ctr = c074e1c0   xer = 0005   trap =  300
dar = d82e   dsisr = 4200

0:mon e
cpu 0x0: Vector: 300 (Data Access) at [c0003e073aa0]
pc: c074ded8: .f71805f_find+0x44/0x32c
lr: c074e1f8: .f71805f_init+0x38/0x194
sp: c0003e073d20
   msr: 80009032
   dar: d82e
 dsisr: 4200
  current = 0xc000220851c0
  paca= 0xc07c2700
pid   = 1, comm = swapper

0:mon di %pc
c074ded8  7d6919ae  stbxr11,r9,r3
c074dedc  3901  li  r8,1
c074dee0  990d01dc  stb r8,476(r13)
c074dee4  e93f  ld  r9,0(r31)
c074dee8  7c034a14  add r0,r3,r9
c074deec  7c0004ac  sync
c074def0  7d6919ae  stbxr11,r9,r3
c074def4  990d01dc  stb r8,476(r13)
c074def8  38800023  li  r4,35
c074defc  4bcc95e1  bl  c04174dc#
.superio_inw+0x0/0x134
c074df00  3940ffed  li  r10,-19
c074df04  5463043e  clrlwi  r3,r3,16
c074df08  2f831934  cmpwi   cr7,r3,6452
c074df0c  409e0260  bne cr7,c074e16c#
.f71805f_find+0x2d8/0x32c
c074df10  e93e8038  ld  r9,-32712(r30)
c074df14  a069  lhz r3,0(r9)
0:mon 

Thanks
Sudhir Kumar
ISTL, IBM
Bangalore
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver

[Benjamin Herrenschmidt]

On Tue, 2008-03-18 at 00:06 -0400, Jeff Garzik wrote:
 Benjamin Herrenschmidt wrote:
  http://marc.info/?l=linux-netdevm=120449748701492w=2
 
  I sent it to Ben with netdev on CC because you asked the various people
  sending NEWEMAC patches to you to find a single person.
 
  So from now on, what are we going to do?  It seems we're playing net
  maintainer russian roulette for NEWEMAC and it's getting old.
  
  I'm happy to collect the patches. I said I would do it, I was just taken
  aback a bit by Jeff suddenly merging two of Stefan patches directly :-)
 
 Sorry...  they were CC'd to me and netdev, Stefan had previously 
 contributed acceptable patches, and the patches looked OK, so...  :)

Sure they were fine, it's just a matter of getting the right
procedure :-)

Now, I'll collect the remaining ones and will send them for
review again.

Cheers,
Ben.


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