* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Paul Gortmaker @ 2010-03-02 16:27 UTC (permalink / raw)
To: vb; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <f608b67d1003011503h57b88742md889ba8d6da652bc@mail.gmail.com>
On 10-03-01 06:03 PM, vb@vsbe.com wrote:
> sounds very much like this issue:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-02/msg09470.html
Thanks for the link.
>
> (interrupt storm on the second port which is hit with breaks).
>
> It's not the uart driver problem per se, the below fixes it:
Actually, it is a uart *hardware* problem -- see in this same
thread where Scott Wood described an errata, and when I
implemented his interpretation of what the fix should look
like, things just worked. You might want to try out that patch
and see if it helps you, since from the link above, I see you
are also on a powerpc board.
Paul.
>
> *** linux/drivers/serial/serial_core.c#1 Wed Feb 24 17:46:22 2010
> --- linux/drivers/serial/serial_core.c#2 Mon Mar 1 15:00:29 2010
> ***************
> *** 622,632 ****
> struct uart_port *port = state->port;
>
> if (I_IXOFF(tty)) {
> if (port->x_char)
> port->x_char = 0;
> ! else
> uart_send_xchar(tty, START_CHAR(tty));
> }
>
> if (tty->termios->c_cflag& CRTSCTS)
> uart_set_mctrl(port, TIOCM_RTS);
> --- 622,632 ----
> struct uart_port *port = state->port;
>
> if (I_IXOFF(tty)) {
> if (port->x_char)
> port->x_char = 0;
> ! else if (!(tty->flags& (1<< TTY_IO_ERROR)))
> uart_send_xchar(tty, START_CHAR(tty));
> }
>
> if (tty->termios->c_cflag& CRTSCTS)
> uart_set_mctrl(port, TIOCM_RTS);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I did not get to trying to submit it, but it sure gets rid o the storm.
>
> cheers,
> /vb
>
> On Fri, Feb 26, 2010 at 11:25 AM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
>> chips seems to cause a short lived IRQ storm (/proc/interrupts
>> typically shows somewhere between 300 and 1500 events). Unfortunately
>> this renders SysRQ over the serial console completely inoperable.
>> Testing with obvious things like ACKing the event doesn't seem to
>> change anything vs. a completely dumb approach of just ignoring
>> it and waiting for it to stop, so that is what is implemented here.
>>
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
>> ---
>>
>> This is a refresh of a patch I'd done earlier -- I've tried to make
>> the bug support as generic as possible to minimize having board
>> specific ifdef crap in 8250.c -- any suggestions on how to further
>> improve it are welcome.
>>
>> drivers/serial/8250.c | 6 ++++++
>> drivers/serial/8250.h | 20 ++++++++++++++++++++
>> drivers/serial/Kconfig | 14 ++++++++++++++
>> include/linux/serial_reg.h | 2 ++
>> 4 files changed, 42 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
>> index e9b15c3..850b0e9 100644
>> --- a/drivers/serial/8250.c
>> +++ b/drivers/serial/8250.c
>> @@ -1531,6 +1531,11 @@ static void serial8250_handle_port(struct uart_8250_port *up)
>>
>> status = serial_inp(up, UART_LSR);
>>
>> + if ((up->bugs& UART_BUG_PPC)&& (status == UART_LSR_RFE_ERROR_BITS)) {
>> + spin_unlock_irqrestore(&up->port.lock, flags);
>> + return;
>> + }
>> +
>> DEBUG_INTR("status = %x...", status);
>>
>> if (status& (UART_LSR_DR | UART_LSR_BI))
>> @@ -1948,6 +1953,7 @@ static int serial8250_startup(struct uart_port *port)
>>
>> up->capabilities = uart_config[up->port.type].flags;
>> up->mcr = 0;
>> + up->bugs |= UART_KNOWN_BUGS;
>>
>> if (up->port.iotype != up->cur_iotype)
>> set_io_from_upio(port);
>> diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h
>> index 6e19ea3..2074ce1 100644
>> --- a/drivers/serial/8250.h
>> +++ b/drivers/serial/8250.h
>> @@ -49,6 +49,7 @@ struct serial8250_config {
>> #define UART_BUG_TXEN (1<< 1) /* UART has buggy TX IIR status */
>> #define UART_BUG_NOMSR (1<< 2) /* UART has buggy MSR status bits (Au1x00) */
>> #define UART_BUG_THRE (1<< 3) /* UART has buggy THRE reassertion */
>> +#define UART_BUG_PPC (1<< 4) /* UART has buggy PPC break IRQ storm */
>>
>> #define PROBE_RSA (1<< 0)
>> #define PROBE_ANY (~0)
>> @@ -78,3 +79,22 @@ struct serial8250_config {
>> #else
>> #define ALPHA_KLUDGE_MCR 0
>> #endif
>> +
>> +/*
>> + * The following UART bugs are currently dynamically detected and not
>> + * required to be contingent on any particular compile time options.
>> + */
>> +#define HAS_BUG_QUOT 0 /* assign UART_BUG_QUOT to enable */
>> +#define HAS_BUG_TXEN 0 /* assign UART_BUG_TXEN to enable */
>> +#define HAS_BUG_NOMSR 0 /* assign UART_BUG_NOMSR to enable */
>> +#define HAS_BUG_THRE 0 /* assign UART_BUG_THRE to enable */
>> +
>> +#ifdef CONFIG_SERIAL_8250_PPC_BUG
>> +#define HAS_BUG_PPC UART_BUG_PPC
>> +#else
>> +#define HAS_BUG_PPC 0
>> +#endif
>> +
>> +#define UART_KNOWN_BUGS (HAS_BUG_QUOT | HAS_BUG_TXEN | HAS_BUG_NOMSR | \
>> + HAS_BUG_THRE | HAS_BUG_PPC)
>> +
>> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
>> index 9ff47db..e01a411 100644
>> --- a/drivers/serial/Kconfig
>> +++ b/drivers/serial/Kconfig
>> @@ -70,6 +70,20 @@ config SERIAL_8250_CONSOLE
>>
>> If unsure, say N.
>>
>> +config SERIAL_8250_PPC_BUG
>> + bool "Fix 8250/16550 to handle IRQ storm after receipt of a break"
>> + depends on SERIAL_8250&& PPC32
>> + ---help---
>> + If you say Y here, addional checks will be added in the handling of
>> + interrupts on the serial ports which will prevent ill effects of
>> + an interrupt storm triggered by a break on the serial line. Without
>> + this enabled, a Sysrq via the serial console can be unusable on
>> + some systems.
>> +
>> + This is commonly observed on PPC32 MPC83xx/85xx/86xx based boards.
>> +
>> + If unsure, say N.
>> +
>> config FIX_EARLYCON_MEM
>> bool
>> depends on X86
>> diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
>> index cf9327c..010174f 100644
>> --- a/include/linux/serial_reg.h
>> +++ b/include/linux/serial_reg.h
>> @@ -111,6 +111,7 @@
>> #define UART_MCR_DTR 0x01 /* DTR complement */
>>
>> #define UART_LSR 5 /* In: Line Status Register */
>> +#define UART_LSR_RFE 0x80 /* Rx FIFO Error (BE, FE, or PE) */
>> #define UART_LSR_TEMT 0x40 /* Transmitter empty */
>> #define UART_LSR_THRE 0x20 /* Transmit-hold-register empty */
>> #define UART_LSR_BI 0x10 /* Break interrupt indicator */
>> @@ -119,6 +120,7 @@
>> #define UART_LSR_OE 0x02 /* Overrun error indicator */
>> #define UART_LSR_DR 0x01 /* Receiver data ready */
>> #define UART_LSR_BRK_ERROR_BITS 0x1E /* BI, FE, PE, OE bits */
>> +#define UART_LSR_RFE_ERROR_BITS 0xF1 /* RFE, TEMT, THRE, BI, DR bits */
>>
>> #define UART_MSR 6 /* In: Modem Status Register */
>> #define UART_MSR_DCD 0x80 /* Data Carrier Detect */
>> --
>> 1.6.5.2
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
^ permalink raw reply
* Re: [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag
From: Alan Stern @ 2010-03-02 15:50 UTC (permalink / raw)
To: Albert Herranz; +Cc: linux-usb, linuxppc-dev, linux-arm-kernel
In-Reply-To: <4B8C45DF.50607@yahoo.es>
On Mon, 1 Mar 2010, Albert Herranz wrote:
> > If transfer_buffer_length is 0 then do nothing.
> > Otherwise if num_sgs > 0 then do nothing.
> > Otherwise if URB_NO_TRANSFER_DMA_MAP and transfer_dma
> > are both set (this avoids your HCD_NO_COHERENT_MEM
> > case) then do nothing.
> >
>
> I see. This case would include the PIO case too (for which dma_handle
> is set to all 1s).
The test above should be transfer_dma != ~0, not transfer_dma != 0,
since ~0 means the DMA address isn't set. In fact I forgot to
include the PIO case; it should be handled by changing the remaining
tests as follows:
Otherwise if hcd->self.uses_dma is set then
If this URB doesn't require PIO then call dma_map_single
Otherwise if HCD_LOCAL_MEM is set then call hcd_alloc_coherent
Otherwise do nothing (PIO case).
Currently "this URB doesn't require PIO" is always true, but in the
future it won't be.
> So this assumes that transfer_dma should be set initially to 0 when
> allocating USB buffers for HCD_NO_COHERENT_MEM.
No, it should be set to ~0, the same as when buffers are allocated for
a PIO-based controller.
Alan Stern
^ permalink raw reply
* [PATCH 4/4] 8xx: Use SPRG2 and DAR registers to stash r11 and cr.
From: Joakim Tjernlund @ 2010-03-02 15:37 UTC (permalink / raw)
To: linuxppc-dev, Scott Wood
In-Reply-To: <1267544232-14784-4-git-send-email-Joakim.Tjernlund@transmode.se>
This avoids storing these registers in memory.
CPU6 errata will still use the old way.
Remove some G2 leftover accesses from 2.4
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/kernel/head_8xx.S | 49 +++++++++++++++++++++++++++++----------
1 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 6478a96..1f1a04b 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -71,9 +71,6 @@ _ENTRY(_start);
* in the first level table, but that would require many changes to the
* Linux page directory/table functions that I don't want to do right now.
*
- * I used to use SPRG2 for a temporary register in the TLB handler, but it
- * has since been put to other uses. I now use a hack to save a register
- * and the CCR at memory location 0.....Someday I'll fix this.....
* -- Dan
*/
.globl __start
@@ -302,8 +299,13 @@ InstructionTLBMiss:
DO_8xx_CPU6(0x3f80, r3)
mtspr SPRN_M_TW, r10 /* Save a couple of working registers */
mfcr r10
+#ifdef CONFIG_8xx_CPU6
stw r10, 0(r0)
stw r11, 4(r0)
+#else
+ mtspr SPRN_DAR, r10
+ mtspr SPRN_SPRG2, r11
+#endif
mfspr r10, SPRN_SRR0 /* Get effective address of fault */
#ifdef CONFIG_8xx_CPU15
addi r11, r10, 0x1000
@@ -359,13 +361,19 @@ InstructionTLBMiss:
DO_8xx_CPU6(0x2d80, r3)
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
- mfspr r10, SPRN_M_TW /* Restore registers */
+ /* Restore registers */
+#ifndef CONFIG_8xx_CPU6
+ mfspr r10, SPRN_DAR
+ mtcr r10
+ mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG2
+#else
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
#endif
+ mfspr r10, SPRN_M_TW
rfi
2:
mfspr r11, SPRN_SRR1
@@ -375,13 +383,20 @@ InstructionTLBMiss:
rlwinm r11, r11, 0, 0xffff
mtspr SPRN_SRR1, r11
- mfspr r10, SPRN_M_TW /* Restore registers */
+ /* Restore registers */
+#ifndef CONFIG_8xx_CPU6
+ mfspr r10, SPRN_DAR
+ mtcr r10
+ li r11, 0x00f0
+ mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG2
+#else
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
#endif
+ mfspr r10, SPRN_M_TW
b InstructionAccess
. = 0x1200
@@ -392,8 +407,13 @@ DataStoreTLBMiss:
DO_8xx_CPU6(0x3f80, r3)
mtspr SPRN_M_TW, r10 /* Save a couple of working registers */
mfcr r10
+#ifdef CONFIG_8xx_CPU6
stw r10, 0(r0)
stw r11, 4(r0)
+#else
+ mtspr SPRN_DAR, r10
+ mtspr SPRN_SPRG2, r11
+#endif
mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
/* If we are faulting a kernel address, we have to use the
@@ -461,18 +481,24 @@ DataStoreTLBMiss:
* of the MMU.
*/
2: li r11, 0x00f0
- mtspr SPRN_DAR,r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
- mfspr r10, SPRN_M_TW /* Restore registers */
+ /* Restore registers */
+#ifndef CONFIG_8xx_CPU6
+ mfspr r10, SPRN_DAR
+ mtcr r10
+ mtspr SPRN_DAR, r11 /* Tag DAR */
+ mfspr r11, SPRN_SPRG2
+#else
+ mtspr SPRN_DAR, r11 /* Tag DAR */
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
#endif
+ mfspr r10, SPRN_M_TW
rfi
/* This is an instruction TLB error on the MPC8xx. This could be due
@@ -684,9 +710,6 @@ start_here:
tophys(r4,r2)
addi r4,r4,THREAD /* init task's THREAD */
mtspr SPRN_SPRG_THREAD,r4
- li r3,0
- /* XXX What is that for ? SPRG2 appears otherwise unused on 8xx */
- mtspr SPRN_SPRG2,r3 /* 0 => r1 has kernel sp */
/* stack */
lis r1,init_thread_union@ha
--
1.6.4.4
^ permalink raw reply related
* [PATCH 3/4] 8xx: Don't touch ACCESSED when no SWAP.
From: Joakim Tjernlund @ 2010-03-02 15:37 UTC (permalink / raw)
To: linuxppc-dev, Scott Wood
In-Reply-To: <1267544232-14784-3-git-send-email-Joakim.Tjernlund@transmode.se>
Only the swap function cares about the ACCESSED bit in
the pte. Do not waste cycles updateting ACCESSED when swap
is not compiled into the kernel.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/kernel/head_8xx.S | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 84ca1d9..6478a96 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -343,10 +343,11 @@ InstructionTLBMiss:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
+#ifdef CONFIG_SWAP
andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT
cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
bne- cr0, 2f
-
+#endif
/* The Linux PTE won't go exactly into the MMU TLB.
* Software indicator bits 21 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
@@ -439,10 +440,11 @@ DataStoreTLBMiss:
* r11 = ((r10 & PRESENT) & ((r10 & ACCESSED) >> 5));
* r10 = (r10 & ~PRESENT) | r11;
*/
+#ifdef CONFIG_SWAP
rlwinm r11, r10, 32-5, _PAGE_PRESENT
and r11, r11, r10
rlwimi r10, r11, 0, _PAGE_PRESENT
-
+#endif
/* Honour kernel RO, User NA */
/* 0x200 == Extended encoding, bit 22 */
rlwimi r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 1/4] 8xx: Optimze TLB Miss handlers
From: Joakim Tjernlund @ 2010-03-02 15:37 UTC (permalink / raw)
To: linuxppc-dev, Scott Wood
In-Reply-To: <1267544232-14784-1-git-send-email-Joakim.Tjernlund@transmode.se>
This removes a couple of insn's from the TLB Miss
handlers whithout changing functionality.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/kernel/head_8xx.S | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 3ef743f..ecc4a02 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -343,17 +343,14 @@ InstructionTLBMiss:
cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
bne- cr0, 2f
- /* Clear PP lsb, 0x400 */
- rlwinm r10, r10, 0, 22, 20
-
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 22 and 28 must be clear.
+ * Software indicator bits 21 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
li r11, 0x00f0
- rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
+ rlwimi r10, r11, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */
DO_8xx_CPU6(0x2d80, r3)
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
@@ -444,9 +441,7 @@ DataStoreTLBMiss:
/* Honour kernel RO, User NA */
/* 0x200 == Extended encoding, bit 22 */
- /* r11 = (r10 & _PAGE_USER) >> 2 */
- rlwinm r11, r10, 32-2, 0x200
- or r10, r11, r10
+ rlwimi r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */
/* r11 = (r10 & _PAGE_RW) >> 1 */
rlwinm r11, r10, 32-1, 0x200
or r10, r11, r10
--
1.6.4.4
^ permalink raw reply related
* [PATCH 2/4] 8xx: Avoid testing for kernel space in ITLB Miss.
From: Joakim Tjernlund @ 2010-03-02 15:37 UTC (permalink / raw)
To: linuxppc-dev, Scott Wood
In-Reply-To: <1267544232-14784-2-git-send-email-Joakim.Tjernlund@transmode.se>
Only modules will cause ITLB Misses as we always pin
the first 8MB of kernel memory.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/kernel/head_8xx.S | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index ecc4a02..84ca1d9 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -318,12 +318,16 @@ InstructionTLBMiss:
/* If we are faulting a kernel address, we have to use the
* kernel page tables.
*/
+#ifdef CONFIG_MODULES
+ /* Only modules will cause ITLB Misses as we always
+ * pin the first 8MB of kernel memory */
andi. r11, r10, 0x0800 /* Address >= 0x80000000 */
beq 3f
lis r11, swapper_pg_dir@h
ori r11, r11, swapper_pg_dir@l
rlwimi r10, r11, 0, 2, 19
3:
+#endif
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
beq 2f /* If zero, don't try to find a pte */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 0/4] 8xx: Optimize TLB Miss code.
From: Joakim Tjernlund @ 2010-03-02 15:37 UTC (permalink / raw)
To: linuxppc-dev, Scott Wood
This set of tries to optimize the TLB code on 8xx even
more. If they work, it should be a noticable performance
boost.
I would be very happy if you could test them for me.
- v2:
Since Scott has done some testing of these patches I resend
them with my SOB.
Scott, can you "bless" these patches too?
Joakim Tjernlund (4):
8xx: Optimze TLB Miss handlers
8xx: Avoid testing for kernel space in ITLB Miss.
8xx: Don't touch ACCESSED when no SWAP.
8xx: Use SPRG2 and DAR registers to stash r11 and cr.
arch/powerpc/kernel/head_8xx.S | 70 +++++++++++++++++++++++++++-------------
1 files changed, 47 insertions(+), 23 deletions(-)
^ permalink raw reply
* Re: [Patch] mpc5200b: improve baud rate calculation (reach high baud rates, better accuracy)
From: Wolfram Sang @ 2010-03-02 15:27 UTC (permalink / raw)
To: Albrecht Dre�; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <22132814.1267520208614.JavaMail.ngmail@webmail14.arcor-online.net>
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
> > > > This should be handled using a new compatible-entry
> > > > "fsl,mpc5200b-psc-uart".
> > >
> >
> > > I agree that this would be a lot cleaner, but it's also a lot more
> > intrusive.
> > > CC'ing the device tree discussion list here... comments, please!!
> >
> > Why intrusive? Maybe I miss something?
>
> Not for the source file, but for all the dts files, if they want to benefit
> from the detection of the '5200B. Basically, *all* files have to be checked
> and touched if necessary. Again, I agree that this would be the clean
> approach, but I wanted to avoid that effort. Grant???
Please check the current 5200b-dts files. They already have the property,
exactly for the case that a specific driver may be added in the future. And
even if not, the behaviour of the driver would not change by missing your
driver improvement, so there is also no regression.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC: PATCH 01/13] powerpc/booke: Add Stack Marking support to Booke Exception Prolog
From: Dave Kleikamp @ 2010-03-02 15:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <68EF9A77-EB45-49D5-8496-686918DDC75C@kernel.crashing.org>
On Tue, 2010-03-02 at 08:50 -0600, Kumar Gala wrote:
> On Mar 1, 2010, at 1:13 PM, Dave Kleikamp wrote:
>
> > powerpc/booke: Add Stack Marking support to Booke Exception Prolog
> >
> > From: Torez Smith <lnxtorez@linux.vnet.ibm.com>
> >
> > Signed-off-by: Torez Smith <lnxtorez@linux.vnet.ibm.com>
> > Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> > ---
> >
> > arch/powerpc/kernel/head_booke.h | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
>
> Can this be explained further as to what this gets us or does.
Yeah. Sorry about that. This is a debugging aid that identifies an
exception on the stack. xmon recognizes the marker and identifies the
exception frame in the stack trace. Other sub-architectures have it,
but bookE is currently missing it.
Ben, Torez,
Is there any reason this patch is re-defining STACK_FRAME_REGS_MARKER
rather than including asm/ptrace.h?
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC: PATCH 01/13] powerpc/booke: Add Stack Marking support to Booke Exception Prolog
From: Kumar Gala @ 2010-03-02 14:50 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <20100301191301.20987.70132.sendpatchset@norville.austin.ibm.com>
On Mar 1, 2010, at 1:13 PM, Dave Kleikamp wrote:
> powerpc/booke: Add Stack Marking support to Booke Exception Prolog
>
> From: Torez Smith <lnxtorez@linux.vnet.ibm.com>
>
> Signed-off-by: Torez Smith <lnxtorez@linux.vnet.ibm.com>
> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> ---
>
> arch/powerpc/kernel/head_booke.h | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
Can this be explained further as to what this gets us or does.
- k
^ permalink raw reply
* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Peter Zijlstra @ 2010-03-02 14:44 UTC (permalink / raw)
To: Michael Neuling; +Cc: Ingo Molnar, linuxppc-dev, linux-kernel, ego
In-Reply-To: <12599.1267266087@neuling.org>
On Sat, 2010-02-27 at 21:21 +1100, Michael Neuling wrote:
> In message <11927.1267010024@neuling.org> you wrote:
> > > > If there's less the group will normally be balanced and we fall out and
> > > > end up in check_asym_packing().
> > > >
> > > > So what I tried doing with that loop is detect if there's a hole in the
> > > > packing before busiest. Now that I think about it, what we need to check
> > > > is if this_cpu (the removed cpu argument) is idle and less than busiest.
> > > >
> > > > So something like:
> > > >
> > > > static int check_asym_pacing(struct sched_domain *sd,
> > > > struct sd_lb_stats *sds,
> > > > int this_cpu, unsigned long *imbalance)
> > > > {
> > > > int busiest_cpu;
> > > >
> > > > if (!(sd->flags & SD_ASYM_PACKING))
> > > > return 0;
> > > >
> > > > if (!sds->busiest)
> > > > return 0;
> > > >
> > > > busiest_cpu = group_first_cpu(sds->busiest);
> > > > if (cpu_rq(this_cpu)->nr_running || this_cpu > busiest_cpu)
> > > > return 0;
> > > >
> > > > *imbalance = (sds->max_load * sds->busiest->cpu_power) /
> > > > SCHED_LOAD_SCALE;
> > > > return 1;
> > > > }
> > > >
> > > > Does that make sense?
> > >
> > > I think so.
> > >
> > > I'm seeing check_asym_packing do the right thing with the simple SMT2
> > > with 1 process case. It marks cpu0 as imbalanced when cpu0 is idle and
> > > cpu1 is busy.
> > >
> > > Unfortunately the process doesn't seem to be get migrated down though.
> > > Do we need to give *imbalance a higher value?
> >
> > So with ego help, I traced this down a bit more.
> >
> > In my simple test case (SMT2, t0 idle, t1 active) if f_b_g() hits our
> > new case in check_asym_packing(), load_balance then runs f_b_q().
> > f_b_q() has this:
> >
> > if (capacity && rq->nr_running == 1 && wl > imbalance)
> > continue;
> >
> > when check_asym_packing() hits, wl = 1783 and imbalance = 1024, so we
> > continue and busiest remains NULL.
> >
> > load_balance then does "goto out_balanced" and it doesn't attempt to
> > move the task.
> >
> > Based on this and on egos suggestion I pulled in Suresh Siddha patch
> > from: http://lkml.org/lkml/2010/2/12/352. This fixes the problem. The
> > process is moved down to t0.
> >
> > I've only tested SMT2 so far.
>
> I'm finding this SMT2 result to be unreliable. Sometimes it doesn't work
> for the simple 1 process case. It seems to change boot to boot.
> Sometimes it works as expected with t0 busy and t1 idle, but other times
> it's the other way around.
>
> When it doesn't work, check_asym_packing() is still marking processes to
> be pulled down but only gets run about 1 in every 4 calls to
> load_balance().
>
> For 2 of the other calls to load_balance, idle is CPU_NEWLY_IDLE and
> hence check_asym_packing() doesn't get called. This results in
> sd->nr_balance_failed being reset. When load_balance is next called and
> check_asym_packing() hits, need_active_balance() returns 0 as
> sd->nr_balance_failed is too small. This means the migration thread on
> t1 is not woken and the process remains there.
>
> So why does thread0 change from NEWLY_IDLE to IDLE and visa versa, when
> there is nothing running on it? Is this expected?
Ah, yes, you should probably allow both those.
NEWLY_IDLE is when we are about to schedule the idle thread, IDLE is
when a tick hits the idle thread.
I'm thinking that NEWLY_IDLE should also solve the NO_HZ case, since
we'll have passed through that before we enter tickless state, just make
sure SD_BALANCE_NEWIDLE is set on the relevant levels (should already be
so).
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Anton Vorontsov @ 2010-03-02 14:02 UTC (permalink / raw)
To: Kumar Gopalpet-B05799
Cc: linuxppc-dev list, netdev, linux-kernel, Martyn Welch,
Paul Gortmaker, davem
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81BC93EC3@zin33exm22.fsl.freescale.net>
Hi!
On Sat, Feb 27, 2010 at 11:05:32AM +0530, Kumar Gopalpet-B05799 wrote:
[...]
> Understood, and thanks for the explanation. Am I correct in saying that
> this is
> due to the out-of-order execution capability on powerpc ?
Nope, that was just a logic issue in the driver.
Though, with the patch, the eieio() is needed so that compiler (or CPU)
won't reorder lstatus and skbuff writes.
> I have one more question, why don't we use use atomic_t for num_txbdfree
> and
> completely do away with spin_locks in gfar_clean_tx_ring() and
> gfar_start_xmit().
> In an non-SMP, scenario I would feel there is absolutely no requirement
> of spin_locks
> and in case of SMP atomic operation would be much more safer on powerpc
> rather than spin_locks.
>
> What is your suggestion ?
I think that's a good idea.
However, in start_xmit() we'll have to keep the spinlock anyway
since it also protects from gfar_error(), which can modify
regs->tstat.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Problem with PCI bus rescan on 460EX
From: Felix Radensky @ 2010-03-02 13:27 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
I'm running linux-2.6.33 on a custom board based on 460EX.
There's a PCI-PCI bridge on this board, PLX 6254, and a single
hot-pluggable device behind the bridge.
When this device is plugged in before system boots everything works
fine: bridge and device are properly recognized by kernel, resources are
allocated and device memory regions are accessible. Below is relevant
kernel messages and lspci output:
PCI: Probing PCI hardware
pci_bus 0000:00: scanning bus
pci 0000:00:02.0: found [3388:0020] class 000604 header type 01
pci 0000:00:02.0: calling pcibios_fixup_resources+0x0/0xf4
pci 0000:00:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154
pci 0000:00:02.0: calling quirk_resource_alignment+0x0/0x200
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.0: PME# disabled
pci_bus 0000:00: fixups for bus
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 0
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: found [1575:0002] class 00ff00 header type 00
pci 0000:01:00.0: reg 10: [mem 0x80000000-0x800fffff]
pci 0000:01:00.0: reg 14: [mem 0x84000000-0x87ffffff]
pci 0000:01:00.0: reg 18: [mem 0x88000000-0x8bffffff]
pci 0000:01:00.0: reg 1c: [mem 0x8c000000-0x8c003fff]
pci 0000:01:00.0: calling pcibios_fixup_resources+0x0/0xf4
pci 0000:01:00.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154
pci 0000:01:00.0: calling quirk_resource_alignment+0x0/0x200
pci_bus 0000:01: fixups for bus
pci 0000:00:02.0: PCI bridge to [bus 01-01]
pci 0000:00:02.0: bridge window [mem 0x80000000-0x8c0fffff]
pci_bus 0000:01: bus scan returning with max=01
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 1
pci_bus 0000:00: bus scan returning with max=01
pci 0000:00:02.0: BAR 8: assigned [mem 0xd80000000-0xd89ffffff]
pci 0000:01:00.0: BAR 1: assigned [mem 0xd80000000-0xd83ffffff]
pci 0000:01:00.0: BAR 1: set to [mem 0xd80000000-0xd83ffffff] (PCI
address [0x80000000-0x83ffffff]
pci 0000:01:00.0: BAR 2: assigned [mem 0xd84000000-0xd87ffffff]
pci 0000:01:00.0: BAR 2: set to [mem 0xd84000000-0xd87ffffff] (PCI
address [0x84000000-0x87ffffff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xd88000000-0xd880fffff]
pci 0000:01:00.0: BAR 0: set to [mem 0xd88000000-0xd880fffff] (PCI
address [0x88000000-0x880fffff]
pci 0000:01:00.0: BAR 3: assigned [mem 0xd88100000-0xd88103fff]
pci 0000:01:00.0: BAR 3: set to [mem 0xd88100000-0xd88103fff] (PCI
address [0x88100000-0x88103fff]
pci 0000:00:02.0: PCI bridge to [bus 01-01]
pci 0000:00:02.0: bridge window [io disabled]
pci 0000:00:02.0: bridge window [mem 0xd80000000-0xd89ffffff]
pci 0000:00:02.0: bridge window [mem pref disabled]
pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
pci_bus 0000:00: resource 1 [mem 0xd80000000-0xdffffffff]
pci_bus 0000:01: resource 1 [mem 0xd80000000-0xd89ffffff]
00:02.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (transparent
mode) (rev 04)
00: 88 33 20 00 87 00 b0 02 04 00 04 06 08 80 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f1 01 a0 02
20: 00 80 f0 89 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 00 00 00 00
The problem arises when device is plugged in after boot. After doing
echo 1 > /sys/bus/pci/rescan
the device is identified, but bridge memory window is not allocated,
and reads from device memory regions return 0xffffffff. Below is
relevant output:
PCI: Probing PCI hardware
pci_bus 0000:00: scanning bus
pci 0000:00:02.0: found [3388:0020] class 000604 header type 01
pci 0000:00:02.0: calling pcibios_fixup_resources+0x0/0xf4
pci 0000:00:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154
pci 0000:00:02.0: calling quirk_resource_alignment+0x0/0x200
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.0: PME# disabled
pci_bus 0000:00: fixups for bus
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 0
pci_bus 0000:01: scanning bus
pci_bus 0000:01: fixups for bus
pci 0000:00:02.0: PCI bridge to [bus 01-01]
pci_bus 0000:01: bus scan returning with max=01
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 1
pci_bus 0000:00: bus scan returning with max=01
pci 0000:00:02.0: PCI bridge to [bus 01-01]
pci 0000:00:02.0: bridge window [io disabled]
pci 0000:00:02.0: bridge window [mem disabled]
pci 0000:00:02.0: bridge window [mem pref disabled]
pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
pci_bus 0000:00: resource 1 [mem 0xd80000000-0xdffffffff]
pci 0000:00:02.0: calling quirk_cardbus_legacy+0x0/0x54
pci 0000:00:02.0: calling quirk_usb_early_handoff+0x0/0x6cc
PCI: CLS 32 bytes, default 32
pci_bus 0000:00: scanning bus
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 0
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: found [1575:0002] class 00ff00 header type 00
pci 0000:01:00.0: reg 10: [mem 0x00000000-0x000fffff]
pci 0000:01:00.0: reg 14: [mem 0x00000000-0x03ffffff]
pci 0000:01:00.0: reg 18: [mem 0x00000000-0x03ffffff]
pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x00003fff]
pci 0000:01:00.0: calling pcibios_fixup_resources+0x0/0xf4
pci 0000:01:00.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154
pci 0000:01:00.0: calling quirk_resource_alignment+0x0/0x200
pci_bus 0000:01: bus scan returning with max=01
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 1
pci_bus 0000:00: bus scan returning with max=01
pci 0000:00:02.0: BAR 8: assigned [mem 0xd80000000-0xd89ffffff]
pci 0000:01:00.0: BAR 1: assigned [mem 0xd80000000-0xd83ffffff]
pci 0000:01:00.0: BAR 1: set to [mem 0xd80000000-0xd83ffffff] (PCI
address [0x80000000-0x83ffffff]
pci 0000:01:00.0: BAR 2: assigned [mem 0xd84000000-0xd87ffffff]
pci 0000:01:00.0: BAR 2: set to [mem 0xd84000000-0xd87ffffff] (PCI
address [0x84000000-0x87ffffff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xd88000000-0xd880fffff]
pci 0000:01:00.0: BAR 0: set to [mem 0xd88000000-0xd880fffff] (PCI
address [0x88000000-0x880fffff]
pci 0000:01:00.0: BAR 3: assigned [mem 0xd88100000-0xd88103fff]
pci 0000:01:00.0: BAR 3: set to [mem 0xd88100000-0xd88103fff] (PCI
address [0x88100000-0x88103fff]
00:02.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (transparent
mode) (rev 04)
00: 88 33 20 00 87 00 b0 02 04 00 04 06 08 80 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f1 01 a0 02
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 00 00 00 00
As you can see, the PLX BAR at address 0x20 is not properly configured.
Writing the value 0x89f08000 using setpci fixes access to hot-plugged
device.
Any idea why PCI bus rescan fails to allocate bridge memory window ?
Thanks a lot.
Felix.
^ permalink raw reply
* Re: [Patch] mpc5200b: improve baud rate calculation (reach high baud rates, better accuracy)
From: Albrecht Dreß @ 2010-03-02 8:56 UTC (permalink / raw)
To: w.sang; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20100302082858.GA4087@pengutronix.de>
Hi Wolfram:
[snip]
> > Yes, but I do all /calculations/ with the /4 prescaler for higher
> accuracy.
> > If the divisor exceeds the available 16 bits of the counter reg, I roun=
d
> > (divisor / 8) to use the /32 prescaler. Think of a 19-bit counter valu=
e,
> > where I can choose to use either the lower or the higher 16 bits for th=
e
> > counter reg.
>=20
> Okay, now I got it. (Maybe this is an indication for another comment abov=
e
> the
> set divisor function?)
O.k., I will add that comment...
> > Remember also that using the higher 16 bits (/32 prescaler) is
> > probably the exceptional case - with an IPB frequency of 132 MHz this
> will
> > happen only for standard baud rates B300 and slower.
>=20
> Even the rare cases have to be correct ;)
I agree - will make the debug output and comments clearer...
[snip]
> > > This should be handled using a new compatible-entry
> > > "fsl,mpc5200b-psc-uart".
> >=20
>=20
> > I agree that this would be a lot cleaner, but it's also a lot more
> intrusive.
> > CC'ing the device tree discussion list here... comments, please!!
>=20
> Why intrusive? Maybe I miss something?
Not for the source file, but for all the dts files, if they want to benefit=
from the detection of the '5200B. Basically, *all* files have to be check=
ed and touched if necessary. Again, I agree that this would be the clean a=
pproach, but I wanted to avoid that effort. Grant???
[snip]
> Leave those two function pointers empty and fill them during probe (probe
> has
> access to the compatible-property it was matched against, see its
> arguments).
> So it should be a matter of:
>=20
> if (matched_property =3D=3D 5200b)
> =09ops->func =3D this_one;
> else
> =09ops->func =3D that_one;
Umm, yes, that's true of course. Will pick it up.
Thanks, Albrecht.
Tolle Dekollet=E9s oder scharfe Tatoos? Vote jetzt ... oder mach selbst mit=
und zeige Deine Schokoladenseite
bei Topp oder Hopp von Arcor: http://www.arcor.de/rd/footer.toh
^ permalink raw reply
* Re: [Patch] mpc5200b: improve baud rate calculation (reach high baud rates, better accuracy)
From: Wolfram Sang @ 2010-03-02 8:28 UTC (permalink / raw)
To: Albrecht Dre�; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <14429243.1267517383754.JavaMail.ngmail@webmail14.arcor-online.net>
[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]
> [snip]
> > > + if (is_mpc5200b == 1)
> > > + return mpc5xxx_get_bus_frequency(p) * 4;
> > > + else
> > > + return mpc5xxx_get_bus_frequency(p) / 2;
> >
> > Isn't this wrong? You can also have /32 on the 5200B (the fallback).
>
> Yes, but I do all /calculations/ with the /4 prescaler for higher accuracy.
> If the divisor exceeds the available 16 bits of the counter reg, I round
> (divisor / 8) to use the /32 prescaler. Think of a 19-bit counter value,
> where I can choose to use either the lower or the higher 16 bits for the
> counter reg.
Okay, now I got it. (Maybe this is an indication for another comment above the
set divisor function?)
> Remember also that using the higher 16 bits (/32 prescaler) is
> probably the exceptional case - with an IPB frequency of 132 MHz this will
> happen only for standard baud rates B300 and slower.
Even the rare cases have to be correct ;)
> [snip]
> > > + /* Check only once if we are running on a mpc5200b or not */
> > > + if (is_mpc5200b == -1) {
> > > + struct device_node *np;
> > > +
> > > + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5200b-immr");
> >
> > This should be handled using a new compatible-entry
> > "fsl,mpc5200b-psc-uart".
>
> I agree that this would be a lot cleaner, but it's also a lot more intrusive.
> CC'ing the device tree discussion list here... comments, please!!
Why intrusive? Maybe I miss something?
> > You could also have a set_divisor-function for 5200 and 5200B and set it
> > here in the function struct (one reason less for the static ;))
>
> Hmmm, but then I would need a 'static struct psc_ops mpc5200b_psc_ops', where
> only two functions differ from the generic 52xx struct as it is implemented
> now. Using the static int needs less space. However, in combination with
> the new compatible entry, it would of course make sense.
Leave those two function pointers empty and fill them during probe (probe has
access to the compatible-property it was matched against, see its arguments).
So it should be a matter of:
if (matched_property == 5200b)
ops->func = this_one;
else
ops->func = that_one;
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [Patch] mpc5200b: improve baud rate calculation (reach high baud rates, better accuracy)
From: Albrecht Dreß @ 2010-03-02 8:09 UTC (permalink / raw)
To: w.sang; +Cc: linuxppc-dev, devicetree-discuss
Hi Wolfram!
Thanks a lot for your comments!
[snip]
> > + * as the chip can be only either a 5200B or not. */
> > +static int is_mpc5200b =3D -1;
> > +
> > +
>=20
> One empty line too much. Maybe we can also get rid of the static later in
> the
> process, but first things first.
Ooops....
[snip]
> > +=09if (is_mpc5200b =3D=3D 1)
> > +=09=09return mpc5xxx_get_bus_frequency(p) * 4;
> > +=09else
> > +=09=09return mpc5xxx_get_bus_frequency(p) / 2;
>=20
> Isn't this wrong? You can also have /32 on the 5200B (the fallback).
Yes, but I do all /calculations/ with the /4 prescaler for higher accuracy.=
If the divisor exceeds the available 16 bits of the counter reg, I round =
(divisor / 8) to use the /32 prescaler. Think of a 19-bit counter value, w=
here I can choose to use either the lower or the higher 16 bits for the cou=
nter reg. Remember also that using the higher 16 bits (/32 prescaler) is p=
robably the exceptional case - with an IPB frequency of 132 MHz this will h=
appen only for standard baud rates B300 and slower.
[snip]
> > +=09/* Check only once if we are running on a mpc5200b or not */
> > +=09if (is_mpc5200b =3D=3D -1) {
> > +=09=09struct device_node *np;
> > +
> > +=09=09np =3D of_find_compatible_node(NULL, NULL, "fsl,mpc5200b-immr");
>=20
> This should be handled using a new compatible-entry
> "fsl,mpc5200b-psc-uart".
I agree that this would be a lot cleaner, but it's also a lot more intrusiv=
e. CC'ing the device tree discussion list here... comments, please!!
> > +=09=09if (np) {
> > +=09=09=09is_mpc5200b =3D 1;
> > +=09=09=09dev_dbg(&op->dev, "mpc5200b: using /4 prescaler\n");
>=20
> Does this message respect the fallback case?
See comment above...
> You could also have a set_divisor-function for 5200 and 5200B and set it
> here
> in the function struct (one reason less for the static ;))
Hmmm, but then I would need a 'static struct psc_ops mpc5200b_psc_ops', whe=
re only two functions differ from the generic 52xx struct as it is implemen=
ted now. Using the static int needs less space. However, in combination w=
ith the new compatible entry, it would of course make sense.
Again, any insight from the device tree gurus would be appreciated!
Thanks, Albrecht.
Tolle Dekollet=E9s oder scharfe Tatoos? Vote jetzt ... oder mach selbst mit=
und zeige Deine Schokoladenseite
bei Topp oder Hopp von Arcor: http://www.arcor.de/rd/footer.toh
^ permalink raw reply
* Re: [PATCH v3 06/11] dma: Add MPC512x DMA driver
From: Dan Williams @ 2010-03-02 6:00 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: wd@denx.de, dzu@denx.de, linuxppc-dev@ozlabs.org, Piotr Ziecik
In-Reply-To: <20100301144619.71a6ceab@wker>
Anatolij Gustschin wrote:
> Hi Dan,
>
> any chance this patch could be merged for 2.6.34 ?
Looks good to me, I'll include it in the dmaengine pull request.
--
Dan
^ permalink raw reply
* Re: something gets odd when I set the mtd.dev.parent
From: Peter Pan @ 2010-03-02 3:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <48abf2c21003011820k4e259734ma5b1d0fd79fc4af9@mail.gmail.com>
Problem solved. The NULL oops is due to the mtd->dev.class->p is NULL,
which makes the spin_lock in "get_device_parent" function uses a false
spin_lock_t struct.
the line is "spin_lock(&dev->class->p->class_dirs.list_lock);"
That is mainly because in function add_mtd_device function uses the
static struct mtd_class to fill into mtd->dev.class. The static struct
is not initialized because I drop the driver in our custom dirctory,
which is in /arch/powerpc/platforms/..., not in the /drivers/mtd/nand
directory, after I put the file there and modifies the Makefile,
everything works fine.
2010/3/2 Peter Pan <pppeterpppan@gmail.com>:
>
> We use Address A20 and A21 connect to ALE and CLE, the data bus is
> connected through a buffer.
> The RE is OE AND with CS. the WE is PBS0 AND with CS. CE pin is
> connect to ground. It works
> fine in VxWorks. And also in our previous Linux version 2.6.22.
>
> Now, I get a odd problem. My GPCM Nand flash driver is mostly copied
> from fsl_upm.c. In the fun_probe
> function, I have printed out the of_device pointer status as follows:
> ofdev= 0xcf851ca0
> ofdev->dev= 0xcf851cb0
> ofdev->dev.class= 0xcf851d50
>
> Then I set the &ofdev->dev to mtd.dev.parent using
> fun->mtd.dev.parent = &ofdev->dev;
>
> Then I print out the values:
> fun->mtd.dev.parent= 0xcf851cb0
> fun->mtd.dev.parent->class= 0x0
>
> The parent pointer is identical, but the class member is NULL, which
> makes the access of NULL pointer oops
> later.
>
> I'm wondering why this could happen. The pointer points at the same
> address, shouldn't all the members be the
> same?
>
^ permalink raw reply
* something gets odd when I set the mtd.dev.parent
From: Peter Pan @ 2010-03-02 2:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
2010/2/27 Peter Pan <pppeterpppan@gmail.com>:
> 2010/2/27 Scott Wood <scottwood@freescale.com>:
>> On Fri, Feb 26, 2010 at 10:08:09AM +0800, Peter Pan wrote:
>> There isn't one. =A0I was not under the impression that such a configura=
tion
>> was even possible (how do you control ALE/CLE, for example?). =A0There i=
s a
>> NAND driver that uses UPM, though -- perhaps you could use that?
>>
>> How specifically is NAND connected to the SoC on your board? =A0What abo=
ut it
>> suggests GPCM?
>>
>> -Scott
>>
We use Address A20 and A21 connect to ALE and CLE, the data bus is
connected through a buffer.
The RE is OE AND with CS. the WE is PBS0 AND with CS. CE pin is
connect to ground. It works
fine in VxWorks. And also in our previous Linux version 2.6.22.
Now, I get a odd problem. My GPCM Nand flash driver is mostly copied
from fsl_upm.c. In the fun_probe
function, I have printed out the of_device pointer status as follows:
ofdev=3D 0xcf851ca0
ofdev->dev=3D 0xcf851cb0
ofdev->dev.class=3D 0xcf851d50
Then I set the &ofdev->dev to mtd.dev.parent using
fun->mtd.dev.parent =3D &ofdev->dev;
Then I print out the values:
fun->mtd.dev.parent=3D 0xcf851cb0
fun->mtd.dev.parent->class=3D 0x0
The parent pointer is identical, but the class member is NULL, which
makes the access of NULL pointer oops
later.
I'm wondering why this could happen. The pointer points at the same
address, shouldn't all the members be the
same?
^ permalink raw reply
* Re: [RFC: PATCH 03/13] powerpc/47x: Base ppc476 support
From: Josh Boyer @ 2010-03-02 0:47 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <1267485089.26041.30.camel@norville.austin.ibm.com>
On Mon, Mar 01, 2010 at 05:11:29PM -0600, Dave Kleikamp wrote:
>On Mon, 2010-03-01 at 15:19 -0500, Josh Boyer wrote:
>> Overall I'm just going to trust you that things aren't broken on 47x :)
>>
>> A few minor comments below. Also, if Torez and Benh contributed to this code,
>> then their S-o-b lines should be included as well (same goes for any other
>> patch).
>
>Right, wanted to make sure they approved of the current state of the
>patches. They'll go through Ben anyway.
Oh. I guess it doesn't matter much but I would like to test my tree with them
applied first.
(That's not a distrust that you haven't. It's me attempting to be a decent
maintainer for 4xx.)
josh
^ permalink raw reply
* Re: [Patch] mpc5200b: improve baud rate calculation (reach high baud rates, better accuracy)
From: Wolfram Sang @ 2010-03-02 0:32 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1267467114.2218.0@antares>
[-- Attachment #1: Type: text/plain, Size: 7080 bytes --]
Hi Albrecht,
On Mon, Mar 01, 2010 at 07:11:54PM +0100, Albrecht Dreß wrote:
> On the MPC5200B, select the baud rate prescaler as /4 by default to make very
> high baud rates (e.g. 3 MBaud) accessible and to achieve a higher precision
> for high baud rates in general. For baud rates below ~500 Baud, the code will
> automatically fall back to the /32 prescaler. The original MPC5200 does only
> have a /32 prescaler which is detected only once and stored in a global. A
> new chip-dependent method is used to set the divisor.
>
> Tested on a custom 5200B based board, with up to 3 MBaud.
>
> Signed-off-by: Albrecht Dreß <albrecht.dress@arcor.de>
>
> ---
>
> --- linux-2.6.33/drivers/serial/mpc52xx_uart.c.orig 2010-02-24 19:52:17.000000000 +0100
> +++ linux-2.6.33/drivers/serial/mpc52xx_uart.c 2010-02-26 21:12:51.000000000 +0100
> @@ -144,9 +144,17 @@ struct psc_ops {
> unsigned char (*read_char)(struct uart_port *port);
> void (*cw_disable_ints)(struct uart_port *port);
> void (*cw_restore_ints)(struct uart_port *port);
> + void (*set_divisor)(struct uart_port *port,
> + unsigned int divisor);
> unsigned long (*getuartclk)(void *p);
> };
>
> +/* We need to distinguish between the MPC5200 which has only a /32 prescaler,
> + * and the MPC5200B which has a /32 and a /4 prescaler. The global is fine,
> + * as the chip can be only either a 5200B or not. */
> +static int is_mpc5200b = -1;
> +
> +
One empty line too much. Maybe we can also get rid of the static later in the
process, but first things first.
> #ifdef CONFIG_PPC_MPC52xx
> #define FIFO_52xx(port) ((struct mpc52xx_psc_fifo __iomem *)(PSC(port)+1))
> static void mpc52xx_psc_fifo_init(struct uart_port *port)
> @@ -154,9 +162,6 @@ static void mpc52xx_psc_fifo_init(struct
> struct mpc52xx_psc __iomem *psc = PSC(port);
> struct mpc52xx_psc_fifo __iomem *fifo = FIFO_52xx(port);
>
> - /* /32 prescaler */
> - out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00);
> -
> out_8(&fifo->rfcntl, 0x00);
> out_be16(&fifo->rfalarm, 0x1ff);
> out_8(&fifo->tfcntl, 0x07);
> @@ -245,15 +250,40 @@ static void mpc52xx_psc_cw_restore_ints(
> out_be16(&PSC(port)->mpc52xx_psc_imr, port->read_status_mask);
> }
>
> +static void mpc52xx_psc_set_divisor(struct uart_port *port,
> + unsigned int divisor)
> +{
> + struct mpc52xx_psc __iomem *psc = PSC(port);
> +
> + /* prescaler */
> + if (is_mpc5200b != 1)
> + out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00); /* /32 */
> + else if (divisor > 0xffff) {
> + out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00); /* /32 */
> + divisor = (divisor + 4) / 8;
> + } else
> + out_be16(&psc->mpc52xx_psc_clock_select, 0xff00); /* /4 */
> +
> + /* ctr */
> + divisor &= 0xffff;
> + out_8(&psc->ctur, divisor >> 8);
> + out_8(&psc->ctlr, divisor & 0xff);
> +}
> +
> /* Search for bus-frequency property in this node or a parent */
> static unsigned long mpc52xx_getuartclk(void *p)
> {
> /*
> - * 5200 UARTs have a / 32 prescaler
> - * but the generic serial code assumes 16
> - * so return ipb freq / 2
> + * The 5200 has only /32 prescalers.
> + * 5200B UARTs have a /4 or a /32 prescaler. For higher accuracy, we
> + * do all calculations using the /4 prescaler for this chip.
> + * The generic serial code assumes /16 so return ipb freq / 2 (5200)
> + * or ipb freq * 4 (5200B).
> */
> - return mpc5xxx_get_bus_frequency(p) / 2;
> + if (is_mpc5200b == 1)
> + return mpc5xxx_get_bus_frequency(p) * 4;
> + else
> + return mpc5xxx_get_bus_frequency(p) / 2;
Isn't this wrong? You can also have /32 on the 5200B (the fallback).
> }
>
> static struct psc_ops mpc52xx_psc_ops = {
> @@ -272,6 +302,7 @@ static struct psc_ops mpc52xx_psc_ops =
> .read_char = mpc52xx_psc_read_char,
> .cw_disable_ints = mpc52xx_psc_cw_disable_ints,
> .cw_restore_ints = mpc52xx_psc_cw_restore_ints,
> + .set_divisor = mpc52xx_psc_set_divisor,
> .getuartclk = mpc52xx_getuartclk,
> };
>
> @@ -388,6 +419,16 @@ static void mpc512x_psc_cw_restore_ints(
> out_be32(&FIFO_512x(port)->rximr, port->read_status_mask & 0x7f);
> }
>
> +static void mpc512x_psc_set_divisor(struct uart_port *port,
> + unsigned int divisor)
> +{
> + struct mpc52xx_psc __iomem *psc = PSC(port);
> +
> + divisor &= 0xffff;
> + out_8(&psc->ctur, divisor >> 8);
> + out_8(&psc->ctlr, divisor & 0xff);
> +}
> +
> static unsigned long mpc512x_getuartclk(void *p)
> {
> return mpc5xxx_get_bus_frequency(p);
> @@ -409,6 +450,7 @@ static struct psc_ops mpc512x_psc_ops =
> .read_char = mpc512x_psc_read_char,
> .cw_disable_ints = mpc512x_psc_cw_disable_ints,
> .cw_restore_ints = mpc512x_psc_cw_restore_ints,
> + .set_divisor = mpc512x_psc_set_divisor,
> .getuartclk = mpc512x_getuartclk,
> };
> #endif
> @@ -564,7 +606,6 @@ mpc52xx_uart_set_termios(struct uart_por
> struct mpc52xx_psc __iomem *psc = PSC(port);
> unsigned long flags;
> unsigned char mr1, mr2;
> - unsigned short ctr;
> unsigned int j, baud, quot;
>
> /* Prepare what we're gonna write */
> @@ -604,7 +645,6 @@ mpc52xx_uart_set_termios(struct uart_por
>
> baud = uart_get_baud_rate(port, new, old, 0, port->uartclk/16);
> quot = uart_get_divisor(port, baud);
> - ctr = quot & 0xffff;
>
> /* Get the lock */
> spin_lock_irqsave(&port->lock, flags);
> @@ -635,8 +675,7 @@ mpc52xx_uart_set_termios(struct uart_por
> out_8(&psc->command, MPC52xx_PSC_SEL_MODE_REG_1);
> out_8(&psc->mode, mr1);
> out_8(&psc->mode, mr2);
> - out_8(&psc->ctur, ctr >> 8);
> - out_8(&psc->ctlr, ctr & 0xff);
> + psc_ops->set_divisor(port, quot);
>
> if (UART_ENABLE_MS(port, new->c_cflag))
> mpc52xx_uart_enable_ms(port);
> @@ -1113,6 +1152,19 @@ mpc52xx_uart_of_probe(struct of_device *
>
> dev_dbg(&op->dev, "mpc52xx_uart_probe(op=%p, match=%p)\n", op, match);
>
> + /* Check only once if we are running on a mpc5200b or not */
> + if (is_mpc5200b == -1) {
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5200b-immr");
This should be handled using a new compatible-entry "fsl,mpc5200b-psc-uart".
> + if (np) {
> + is_mpc5200b = 1;
> + dev_dbg(&op->dev, "mpc5200b: using /4 prescaler\n");
Does this message respect the fallback case?
You could also have a set_divisor-function for 5200 and 5200B and set it here
in the function struct (one reason less for the static ;))
> + of_node_put(np);
> + } else
> + is_mpc5200b = 0;
> + }
> +
> /* Check validity & presence */
> for (idx = 0; idx < MPC52xx_PSC_MAXNUM; idx++)
> if (mpc52xx_uart_nodes[idx] == op->node)
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC: PATCH 08/13] powerpc/476: define specific cpu table entry for DD1 and DD1.1 cores
From: Dave Kleikamp @ 2010-03-01 23:43 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <20100301202409.GB8963@zod.rchland.ibm.com>
On Mon, 2010-03-01 at 15:24 -0500, Josh Boyer wrote:
> On Mon, Mar 01, 2010 at 02:13:52PM -0500, Dave Kleikamp wrote:
> >powerpc/476: define specific cpu table entry for DD1 and DD1.1 cores
> >
> >From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> >There are still some unstable bits on the DD1 and DD1.1 cores. Don't use
> >the FPU or the tlbivax operation. Define CPU_FTR_476_DD1 and
> >CPU_FTR_476_DD1_1 for additional workarounds in later patches.
> >
> >The DD1 core requires workarounds triggered by both CPU_FTR_476_DD1
> >and CPU_FTR_476_DD1_1. the DD1.1 core only needs CPU_FTR_476_DD1_1
> >defined.
>
> DD1, DD1.1, and all others have the same PVR value? How do you tell which
> core version you have?
I seemed to have lost the change to the DD1.1 PVR value. I originally
coded it this way while I was waiting to find out what it was. DD1.1 is
0x11A52040. I don't know a value for the future versions, so that will
have to be filled in later. Actually, I should probably use 0x11A52000,
since that's what's defined in reg.h.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC: PATCH 06/13] powerpc/4xx: Simple platform for the ISS 4xx simulator
From: Dave Kleikamp @ 2010-03-01 23:33 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <20100301202910.GC8963@zod.rchland.ibm.com>
On Mon, 2010-03-01 at 15:29 -0500, Josh Boyer wrote:
> On Mon, Mar 01, 2010 at 12:16:00PM -0700, Dave Kleikamp wrote:
> >diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
> >index 1dfc1c1..915c295 100644
> >--- a/arch/powerpc/platforms/44x/Kconfig
> >+++ b/arch/powerpc/platforms/44x/Kconfig
> >@@ -162,6 +162,17 @@ config YOSEMITE
> > help
> > This option enables support for the AMCC PPC440EP evaluation board.
> >
> >+config ISS4xx
> >+ bool "ISS 4xx Simulator"
> >+ depends on (44x || 40x)
> >+ default n
> >+ select 405GP if 40x
> >+ select 440GP if 44x
>
> Won't that now build a 44x_46x kernel due to the 'select 440GP' there? If so,
> doesn't that cause issues for 476? Confused...
I hadn't really noticed this because it's been working. When both 44GP
and PPC_47x are defined, it doesn't cause any problems for the 476.
It's not right though.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC: PATCH 04/13] powerpc/476: add machine check handler for 47x core
From: Dave Kleikamp @ 2010-03-01 23:22 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <20100301210811.GA6699@lixom.net>
On Mon, 2010-03-01 at 15:08 -0600, Olof Johansson wrote:
> On Mon, Mar 01, 2010 at 05:13:23AM -0700, Dave Kleikamp wrote:
> > powerpc/476: add machine check handler for 47x core
> >
> > From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> >
> > The 47x core's MCSR varies from 44x, so it needs it's own machine check
> > handler.
>
>
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -376,6 +376,44 @@ int machine_check_440A(struct pt_regs *regs)
> > }
> > return 0;
> > }
> > +
> > +int machine_check_47x(struct pt_regs *regs)
> > +{
> > + unsigned long reason = get_mc_reason(regs);
> > +
> > + printk("Machine check in kernel mode.\n");
>
> It's quite possible that the other machine check handlers don't have
> printk KERN_-levels on them but it would be a good idea to use them here.
Right. As it's new code, it should be as correct as possible.
> > + if (reason & ESR_IMCP){
> > + printk("Instruction Synchronous Machine Check exception\n");
> > + mtspr(SPRN_ESR, reason & ~ESR_IMCP);
> > + }
> > + else {
>
> } else {
>
> Or, rather, add an early return above and you can just remove one level of indentation below.
agreed.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC: PATCH 03/13] powerpc/47x: Base ppc476 support
From: Dave Kleikamp @ 2010-03-01 23:11 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <20100301201900.GA8963@zod.rchland.ibm.com>
On Mon, 2010-03-01 at 15:19 -0500, Josh Boyer wrote:
> Overall I'm just going to trust you that things aren't broken on 47x :)
>
> A few minor comments below. Also, if Torez and Benh contributed to this code,
> then their S-o-b lines should be included as well (same goes for any other
> patch).
Right, wanted to make sure they approved of the current state of the
patches. They'll go through Ben anyway.
> On Mon, Mar 01, 2010 at 12:13:15PM -0700, Dave Kleikamp wrote:
> >diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> >index bc8dd53..4af1c28 100644
> >--- a/arch/powerpc/include/asm/reg.h
> >+++ b/arch/powerpc/include/asm/reg.h
> >@@ -813,6 +813,7 @@
> > #define PVR_403GC 0x00200200
> > #define PVR_403GCX 0x00201400
> > #define PVR_405GP 0x40110000
> >+#define PVR_476 0x11a52000
>
> Is that really needed? None of the 44x CPUs have a PVR value here.
init_cpu_state() checks the PVR against the high-order word of PVR_476
to determine whether the cpu is 44x or 47x, as we eventually want the
same kernel to run on either platform. It's either defined here, or
hardcoded there.
> > #define PVR_STB03XXX 0x40310000
> > #define PVR_NP405H 0x41410000
> > #define PVR_NP405L 0x41610000
>
> <snip>
>
> >diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> >index 2fc82ba..338ac47 100644
> >--- a/arch/powerpc/kernel/cputable.c
> >+++ b/arch/powerpc/kernel/cputable.c
> >@@ -1701,6 +1701,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
> > .machine_check = machine_check_440A,
> > .platform = "ppc440",
> > },
> >+ { /* 476 core */
> >+ .pvr_mask = 0xffff0000,
> >+ .pvr_value = 0x11a50000,
>
> Could we use PVR_476 here (if it's going to stay).
I guess it could, but it would be inconsistent with the rest of the cpu
table. Also, I'm adding new values for DD1 and DD1.1 (and maybe someday
DD2) that differ in the low-order word, but the logic in init_cpu_state
only uses the high-order bits in PVR_476, so I don't intend to add new
values for those
> >+ .cpu_name = "476",
> >+ .cpu_features = CPU_FTRS_47X,
> >+ .cpu_user_features = COMMON_USER_BOOKE |
> >+ PPC_FEATURE_HAS_FPU,
> >+ .mmu_features = MMU_FTR_TYPE_47x |
> >+ MMU_FTR_USE_TLBIVAX_BCAST | MMU_FTR_LOCK_BCAST_INVAL,
> >+ .icache_bsize = 32,
> >+ .dcache_bsize = 128,
> >+ .platform = "ppc470",
> >+ },
>
> <snip>
>
> >diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
> >index 7486bff..1dfc1c1 100644
> >--- a/arch/powerpc/platforms/44x/Kconfig
> >+++ b/arch/powerpc/platforms/44x/Kconfig
> >@@ -1,6 +1,17 @@
> >+config PPC_44x_46x
> >+ bool "Support for 44x and 46x variants"
> >+ depends on 44x
> >+ default n
>
> Why do this? All it seems to do is add a bunch of churn to the Kconfig here.
> If the intention was to try and prevent selecting both 44x and 47x kernel
> options, then maybe I could see that. However nothing prevents both from being
> enabled.
I'm not really sure about this. If Ben doesn't convince me there's a
reason for it, I think I'll remove it.
> Maybe PPC_47x should:
>
> depends on !PPC_44x_46x && 44x
Eventually, we want to resolve compiler-time differences in these
platforms and have a binary kernel that could run on both 44x and 47x,
so we'd just have to rip this out later. I'm not convinced we want this
at all. We may want something for the time being to keep from breaking
47x from being accidentally selected, but I'm not sure this is the best
thing.
> josh
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox