* RE: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Liu Shengzhou-B36685 @ 2011-12-07 6:30 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linux-mtd@lists.infradead.org, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org, dwmw2@infradead.org
In-Reply-To: <4EDE4DEC.7010308@freescale.com>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDcsIDIwMTEgMToxNiBBTQ0KPiBUbzogTGl1
IFNoZW5nemhvdS1CMzY2ODUNCj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBs
aW51eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsNCj4gZHdtdzJAaW5mcmFkZWFkLm9yZzsgR2Fs
YSBLdW1hci1CMTE3ODANCj4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzIgdjJdIG10ZC9uYW5kOiBm
aXh1cCBmb3IgZm1yIGluaXRpYWxpemF0aW9uIG9mDQo+IEZyZWVzY2FsZSBOQU5EIGNvbnRyb2xs
ZXINCj4gDQo+IE9uIDEyLzA2LzIwMTEgMDI6NTQgQU0sIFNoZW5nemhvdSBMaXUgd3JvdGU6DQo+
ID4gVGhlcmUgd2FzIGEgYnVnIGZvciBmbXIgaW5pdGlhbGl6YXRpb24sIHdoaWNoIGxlYWQgdG8g
IGZtciB3YXMgYWx3YXlzDQo+ID4gMHgxMDAgaW4gZnNsX2VsYmNfY2hpcF9pbml0KCkgYW5kIGNh
dXNlZCBGQ00gY29tbWFuZCB0aW1lb3V0IGJlZm9yZQ0KPiA+IGNhbGxpbmcgZnNsX2VsYmNfY2hp
cF9pbml0X3RhaWwoKSwgbm93IHdlIGluaXRpYWxpemUgQ1dUTyB0byBtYXhpbXVtDQo+ID4gdGlt
ZW91dCB2YWx1ZSBhbmQgbm90IHJlbHlpbmcgb24gdGhlIHNldHRpbmcgb2YgYm9vdGxvYWRlci4N
Cj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFNoZW5nemhvdSBMaXUgPFNoZW5nemhvdS5MaXVAZnJl
ZXNjYWxlLmNvbT4NCj4gPiAtLS0NCj4gPiB2MjogbWFrZSBmbXIgbm90IHJlbHlpbmcgb24gdGhl
IHNldHRpbmcgb2YgYm9vdGxvYWRlci4NCj4gPg0KPiA+ICBkcml2ZXJzL210ZC9uYW5kL2ZzbF9l
bGJjX25hbmQuYyB8ICAgMTAgKysrKystLS0tLQ0KPiA+ICAxIGZpbGVzIGNoYW5nZWQsIDUgaW5z
ZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJz
L210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KPiA+IGIvZHJpdmVycy9tdGQvbmFuZC9mc2xfZWxi
Y19uYW5kLmMNCj4gPiBpbmRleCBlZWRkOGVlLi40ZjQwNWEwIDEwMDY0NA0KPiA+IC0tLSBhL2Ry
aXZlcnMvbXRkL25hbmQvZnNsX2VsYmNfbmFuZC5jDQo+ID4gKysrIGIvZHJpdmVycy9tdGQvbmFu
ZC9mc2xfZWxiY19uYW5kLmMNCj4gPiBAQCAtNjU5LDkgKzY1OSw3IEBAIHN0YXRpYyBpbnQgZnNs
X2VsYmNfY2hpcF9pbml0X3RhaWwoc3RydWN0IG10ZF9pbmZvDQo+ICptdGQpDQo+ID4gIAlpZiAo
Y2hpcC0+cGFnZW1hc2sgJiAweGZmMDAwMDAwKQ0KPiA+ICAJCWFsKys7DQo+ID4NCj4gPiAtCS8q
IGFkZCB0byBFQ0NNIG1vZGUgc2V0IGluIGZzbF9lbGJjX2luaXQgKi8NCj4gPiAtCXByaXYtPmZt
ciB8PSAoMTIgPDwgRk1SX0NXVE9fU0hJRlQpIHwgIC8qIFRpbWVvdXQgPiAxMiBtcyAqLw0KPiA+
IC0JICAgICAgICAgICAgIChhbCA8PCBGTVJfQUxfU0hJRlQpOw0KPiA+ICsJcHJpdi0+Zm1yIHw9
IGFsIDw8IEZNUl9BTF9TSElGVDsNCj4gPg0KPiA+ICAJZGV2X2RiZyhwcml2LT5kZXYsICJmc2xf
ZWxiY19pbml0OiBuYW5kLT5udW1jaGlwcyA9ICVkXG4iLA0KPiA+ICAJICAgICAgICBjaGlwLT5u
dW1jaGlwcyk7DQo+ID4gQEAgLTc2NCw4ICs3NjIsMTAgQEAgc3RhdGljIGludCBmc2xfZWxiY19j
aGlwX2luaXQoc3RydWN0IGZzbF9lbGJjX210ZA0KPiAqcHJpdikNCj4gPiAgCXByaXYtPm10ZC5w
cml2ID0gY2hpcDsNCj4gPiAgCXByaXYtPm10ZC5vd25lciA9IFRISVNfTU9EVUxFOw0KPiA+DQo+
ID4gLQkvKiBTZXQgdGhlIEVDQ00gYWNjb3JkaW5nIHRvIHRoZSBzZXR0aW5ncyBpbiBib290bG9h
ZGVyLiovDQo+ID4gLQlwcml2LT5mbXIgPSBpbl9iZTMyKCZsYmMtPmZtcikgJiBGTVJfRUNDTTsN
Cj4gPiArCS8qIHNldCB0aW1lb3V0IHRvIG1heGltdW0gKi8NCj4gPiArCXByaXYtPmZtciA9IDE1
IDw8IEZNUl9DV1RPX1NISUZUOw0KPiA+ICsJaWYgKGluX2JlMzIoJmxiYy0+YmFua1twcml2LT5i
YW5rXS5vcikgJiBPUl9GQ01fUEdTKQ0KPiA+ICsJCXByaXYtPmZtciB8PSBGTVJfRUNDTTsNCj4g
DQo+IFBsZWFzZSBkbyBub3QgY2hhbmdlIHRoZSB3YXkgRUNDTSBpcyBoYW5kbGVkLiAgV2UgcHJv
YmFibHkgc2hvdWxkIGhhdmUNCj4gZG9uZSBpdCB0aGlzIHdheSBmcm9tIHRoZSBzdGFydCwgYnV0
IGF0IHRoaXMgcG9pbnQgaXQgYnJlYWtzDQo+IGNvbXBhdGliaWxpdHkgaWYgeW91IGhhdmUgYSBs
YXJnZSBwYWdlIGZsYXNoIGFuZCB0aGUgZmlybXdhcmUgZGlkbid0DQo+IHRvdWNoIE5BTkQuDQo+
IA0KPiAtU2NvdHQNCltTaGVuZ3pob3VdIFRoaXMgcGF0Y2ggZG9lc24ndCBjaGFuZ2UgdGhlIHdh
eSBFQ0NNIGlzIGhhbmRsZWQsIGl0J3Mgc3RpbGwgc2FtZSBhcyBiZWZvcmUsIGp1c3QgbWFrZSBz
dXJlIENXVE8gdGltZW91dCBpcyBzZXQgdG8gbWF4aW11bS4gIA0K
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-12-07 3:55 UTC (permalink / raw)
To: Scott Wood
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <4EDEAEB9.6020703@freescale.com>
=E4=BA=8E 2011=E5=B9=B412=E6=9C=8807=E6=97=A5 08:09, Scott Wood =E5=86=99=
=E9=81=93:
> On 12/03/2011 10:31 PM, shuo.liu@freescale.com wrote:
>> From: Liu Shuo<shuo.liu@freescale.com>
>>
>> Freescale FCM controller has a 2K size limitation of buffer RAM. In or=
der
>> to support the Nand flash chip whose page size is larger than 2K bytes=
,
>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and sa=
ve
>> them to a large buffer.
>>
>> Signed-off-by: Liu Shuo<shuo.liu@freescale.com>
>> ---
>> v3:
>> -remove page_size of struct fsl_elbc_mtd.
>> -do a oob write by NAND_CMD_RNDIN.
>>
>> drivers/mtd/nand/fsl_elbc_nand.c | 243 ++++++++++++++++++++++++++++=
++++++----
>> 1 files changed, 218 insertions(+), 25 deletions(-)
> What is the plan for bad block marker migration?
This patch has been ported to uboot now, I think we can make a special=20
uboot image for bad
block marker migration when first use the chip.
>> @@ -473,13 +568,72 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mt=
d, unsigned int command,
>> * write so the HW generates the ECC.
>> */
>> if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column !=3D 0 ||
>> - elbc_fcm_ctrl->index !=3D mtd->writesize + mtd->oobsize)
>> - out_be32(&lbc->fbcr,
>> - elbc_fcm_ctrl->index - elbc_fcm_ctrl->column);
>> - else
>> + elbc_fcm_ctrl->index !=3D mtd->writesize + mtd->oobsize) {
>> + if (elbc_fcm_ctrl->oob&& mtd->writesize> 2048) {
>> + out_be32(&lbc->fbcr, 64);
>> + } else {
>> + out_be32(&lbc->fbcr, elbc_fcm_ctrl->index
>> + - elbc_fcm_ctrl->column);
>> + }
> We need to limit ourselves to the regions that have actually been
> written to in the buffer. fbcr needs to be set separately for first an=
d
> last subpages, with intermediate subpages having 0, 64, or 2112 as
> appropriate. Subpages that are entirely before column or entirely afte=
r
> column + index should be skipped.
I have considered this case, but I don't think it is useful.
1.There isn't a 'length' parameter in driver interface, although we=20
can get it from 'index - column'.
2.To see nand_do_write_oob() in nand_base.c, it fill '0xff' to=20
entire oob area first and write the user data by nand_fill_oob(), then=20
call ecc.write_oob (default is nand_write_oob_std()). 'column' is=20
mtd->writesize and 'length' of write_buf() is mtd->oobsize. So I don't=20
think we need to deal with it there.
>> + } else {
>> + out_be32(&lbc->fir, FIR_OP_WB<< FIR_OP1_SHIFT);
>> + for (i =3D 1; i< n; i++) {
>> + if (i =3D=3D n - 1) {
>> + elbc_fcm_ctrl->use_mdr =3D 1;
>> + out_be32(&lbc->fir,
>> + (FIR_OP_WB<< FIR_OP1_SHIFT) |
>> + (FIR_OP_CM3<< FIR_OP2_SHIFT) |
>> + (FIR_OP_CW1<< FIR_OP3_SHIFT) |
>> + (FIR_OP_RS<< FIR_OP4_SHIFT));
> Please explicitly show the (FIR_OP_NOP<< FIR_OP0_SHIFT) compenent.
>
>> + } else if (mtd->writesize>=3D 2048&& mtd->writesize<=3D 16 * 1024) =
{
>> +
>> setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
> Don't insert a blank line here.
>
Ok.
-LiuShuo
> -Scott
^ permalink raw reply
* [PATCH 01/16 v3] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-12-07 3:49 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev, linux-serial
In-Reply-To: <alpine.LNX.2.00.1112070203310.14968@nippy.intranet>
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
For example, the serial debugging code in arch/m68k/kernel/head.S may be
used beforehand. It disables the SCC interrupts at the chip but doesn't
ack them. Then when a pmac_zilog port is used, the machine locks up with
"unexpected interrupt".
This can happen in pmz_shutdown() since the irq is freed before the
channel interrupts are disabled.
Fix this by clearing interrupt enable bits before the handler is
uninstalled. Also move the interrupt control bit flipping into a separate
pmz_interrupt_control() routine. Replace all instances of these operations
with calls to this routine. Omit the zssync() calls that seem to serve no
purpose.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Acked-by: Alan Cox <alan@linux.intel.com>
---
Re-implemented as v2 using a simpler approach that avoids messing with the
Master Interrupt Enable bit. As well as the ifdef problem, it turns out
that v1 was not sufficient to entirely fix the problem.
v3 avoids needless changes to the logic and locking in the suspend and
shutdown code and tries to keep register writes closer to their original
sequence.
This patch has been tested on a PowerBook 520 but no PowerMacs yet.
Index: linux-git/drivers/tty/serial/pmac_zilog.c
===================================================================
--- linux-git.orig/drivers/tty/serial/pmac_zilog.c 2011-12-07 12:36:32.000000000 +1100
+++ linux-git/drivers/tty/serial/pmac_zilog.c 2011-12-07 14:29:21.000000000 +1100
@@ -216,6 +216,18 @@ static void pmz_maybe_update_regs(struct
}
}
+static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
+{
+ if (enable) {
+ uap->curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
+ if (!ZS_IS_EXTCLK(uap))
+ uap->curregs[1] |= EXT_INT_ENAB;
+ } else {
+ uap->curregs[1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
+ }
+ write_zsreg(uap, R1, uap->curregs[1]);
+}
+
static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *uap)
{
struct tty_struct *tty = NULL;
@@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
return tty;
flood:
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
- zssync(uap);
+ pmz_interrupt_control(uap, 0);
pmz_error("pmz: rx irq flood !\n");
return tty;
}
@@ -990,12 +1000,9 @@ static int pmz_startup(struct uart_port
if (ZS_IS_IRDA(uap))
pmz_irda_reset(uap);
- /* Enable interrupts emission from the chip */
+ /* Enable interrupt requests for the channel */
spin_lock_irqsave(&port->lock, flags);
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
+ pmz_interrupt_control(uap, 1);
spin_unlock_irqrestore(&port->lock, flags);
pmz_debug("pmz: startup() done.\n");
@@ -1015,6 +1022,25 @@ static void pmz_shutdown(struct uart_por
mutex_lock(&pmz_irq_mutex);
+ spin_lock_irqsave(&port->lock, flags);
+
+ if (!ZS_IS_ASLEEP(uap)) {
+ /* Disable interrupt requests for the channel */
+ pmz_interrupt_control(uap, 0);
+
+ if (!ZS_IS_CONS(uap)) {
+ /* Disable receiver and transmitter */
+ uap->curregs[R3] &= ~RxENABLE;
+ uap->curregs[R5] &= ~TxENABLE;
+
+ /* Disable break assertion */
+ uap->curregs[R5] &= ~SND_BRK;
+ pmz_maybe_update_regs(uap);
+ }
+ }
+
+ spin_unlock_irqrestore(&port->lock, flags);
+
/* Release interrupt handler */
free_irq(uap->port.irq, uap);
@@ -1025,29 +1051,8 @@ static void pmz_shutdown(struct uart_por
if (!ZS_IS_OPEN(uap->mate))
pmz_get_port_A(uap)->flags &= ~PMACZILOG_FLAG_IS_IRQ_ON;
- /* Disable interrupts */
- if (!ZS_IS_ASLEEP(uap)) {
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
- zssync(uap);
- }
-
- if (ZS_IS_CONS(uap) || ZS_IS_ASLEEP(uap)) {
- spin_unlock_irqrestore(&port->lock, flags);
- mutex_unlock(&pmz_irq_mutex);
- return;
- }
-
- /* Disable receiver and transmitter. */
- uap->curregs[R3] &= ~RxENABLE;
- uap->curregs[R5] &= ~TxENABLE;
-
- /* Disable all interrupts and BRK assertion. */
- uap->curregs[R5] &= ~SND_BRK;
- pmz_maybe_update_regs(uap);
-
- /* Shut the chip down */
- pmz_set_scc_power(uap, 0);
+ if (!ZS_IS_ASLEEP(uap) && !ZS_IS_CONS(uap))
+ pmz_set_scc_power(uap, 0); /* Shut the chip down */
spin_unlock_irqrestore(&port->lock, flags);
@@ -1352,19 +1357,15 @@ static void pmz_set_termios(struct uart_
spin_lock_irqsave(&port->lock, flags);
/* Disable IRQs on the port */
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
+ pmz_interrupt_control(uap, 0);
/* Setup new port configuration */
__pmz_set_termios(port, termios, old);
/* Re-enable IRQs on the port */
- if (ZS_IS_OPEN(uap)) {
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
- }
+ if (ZS_IS_OPEN(uap))
+ pmz_interrupt_control(uap, 1);
+
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -1671,14 +1672,17 @@ static int pmz_suspend(struct macio_dev
spin_lock_irqsave(&uap->port.lock, flags);
if (ZS_IS_OPEN(uap) || ZS_IS_CONS(uap)) {
- /* Disable receiver and transmitter. */
+ /* Disable interrupt requests for the channel */
+ pmz_interrupt_control(uap, 0);
+
+ /* Disable receiver and transmitter */
uap->curregs[R3] &= ~RxENABLE;
uap->curregs[R5] &= ~TxENABLE;
- /* Disable all interrupts and BRK assertion. */
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
+ /* Disable break assertion */
uap->curregs[R5] &= ~SND_BRK;
pmz_load_zsregs(uap, uap->curregs);
+
uap->flags |= PMACZILOG_FLAG_IS_ASLEEP;
mb();
}
@@ -1738,14 +1742,6 @@ static int pmz_resume(struct macio_dev *
/* Take care of config that may have changed while asleep */
__pmz_set_termios(&uap->port, &uap->termios_cache, NULL);
- if (ZS_IS_OPEN(uap)) {
- /* Enable interrupts */
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
- }
-
spin_unlock_irqrestore(&uap->port.lock, flags);
if (ZS_IS_CONS(uap))
@@ -1757,6 +1753,12 @@ static int pmz_resume(struct macio_dev *
enable_irq(uap->port.irq);
}
+ if (ZS_IS_OPEN(uap)) {
+ spin_lock_irqsave(&uap->port.lock, flags);
+ pmz_interrupt_control(uap, 1);
+ spin_unlock_irqrestore(&uap->port.lock, flags);
+ }
+
bail:
mutex_unlock(&state->port.mutex);
mutex_unlock(&pmz_irq_mutex);
^ permalink raw reply
* [GIT PULL] tty-next: Fix Fsl 8250 BRK bug
From: Paul Gortmaker @ 2011-12-07 3:39 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, linuxppc-dev, linux-serial, alan
Hi Greg,
This is the Freescale hardware bug fix which turned into a
six-pack of 8250 updates. This is exactly what was posted
in the v2 review, with just Alan's ack added[1]. Since nobody
else has had any follow-on comments since then, I'm assuming
that it is now good to go.
[1] https://lkml.org/lkml/2011/12/5/156
Thanks,
Paul.
---
Please pull for tty-next to get:
The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416:
Linux 3.2-rc4 (2011-12-01 14:56:01 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux fsl-uart-fix
Paul Gortmaker (6):
serial: move struct uart_8250_port from 8250.c to 8250.h
serial: clean up parameter passing for 8250 Rx IRQ handling
serial: export the key functions for an 8250 IRQ handler
serial: make 8250 timeout use the specified IRQ handler
serial: manually inline serial8250_handle_port
serial: add irq handler for Freescale 16550 errata.
arch/powerpc/kernel/legacy_serial.c | 3 +
drivers/tty/serial/8250.c | 92 ++++++++++++-----------------------
drivers/tty/serial/8250.h | 26 ++++++++++
drivers/tty/serial/8250_fsl.c | 63 ++++++++++++++++++++++++
drivers/tty/serial/Kconfig | 5 ++
drivers/tty/serial/Makefile | 1 +
include/linux/serial_8250.h | 5 ++
7 files changed, 134 insertions(+), 61 deletions(-)
create mode 100644 drivers/tty/serial/8250_fsl.c
^ permalink raw reply
* RE: [PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND controller
From: Liu Shengzhou-B36685 @ 2011-12-07 3:16 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linux-mtd@lists.infradead.org, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org, dwmw2@infradead.org
In-Reply-To: <4EDE4E1D.4030408@freescale.com>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDcsIDIwMTEgMToxNyBBTQ0KPiBUbzogTGl1
IFNoZW5nemhvdS1CMzY2ODUNCj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBs
aW51eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsNCj4gZHdtdzJAaW5mcmFkZWFkLm9yZzsgR2Fs
YSBLdW1hci1CMTE3ODANCj4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzIgdjJdIG10ZC9uYW5kOiBB
ZGQgT05GSSBzdXBwb3J0IGZvciBGU0wgTkFORA0KPiBjb250cm9sbGVyDQo+IA0KPiBPbiAxMi8w
Ni8yMDExIDAyOjU0IEFNLCBTaGVuZ3pob3UgTGl1IHdyb3RlOg0KPiA+IGRpZmYgLS1naXQgYS9k
cml2ZXJzL210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KPiBiL2RyaXZlcnMvbXRkL25hbmQvZnNs
X2VsYmNfbmFuZC5jDQo+ID4gaW5kZXggNGY0MDVhMC4uYjRkYjQwNyAxMDA2NDQNCj4gPiAtLS0g
YS9kcml2ZXJzL210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KPiA+ICsrKyBiL2RyaXZlcnMvbXRk
L25hbmQvZnNsX2VsYmNfbmFuZC5jDQo+ID4gQEAgLTM0OSwxOSArMzQ5LDI0IEBAIHN0YXRpYyB2
b2lkIGZzbF9lbGJjX2NtZGZ1bmMoc3RydWN0IG10ZF9pbmZvICptdGQsDQo+IHVuc2lnbmVkIGlu
dCBjb21tYW5kLA0KPiA+ICAJCWZzbF9lbGJjX3J1bl9jb21tYW5kKG10ZCk7DQo+ID4gIAkJcmV0
dXJuOw0KPiA+DQo+ID4gLQkvKiBSRUFESUQgbXVzdCByZWFkIGFsbCA1IHBvc3NpYmxlIGJ5dGVz
IHdoaWxlIENFQiBpcyBhY3RpdmUgKi8NCj4gPiAgCWNhc2UgTkFORF9DTURfUkVBRElEOg0KPiA+
IC0JCWRldl92ZGJnKHByaXYtPmRldiwgImZzbF9lbGJjX2NtZGZ1bmM6IE5BTkRfQ01EX1JFQURJ
RC5cbiIpOw0KPiA+ICsJY2FzZSBOQU5EX0NNRF9QQVJBTToNCj4gPiArCQlkZXZfdmRiZyhwcml2
LT5kZXYsICJmc2xfZWxiY19jbWRmdW5jOiBOQU5EX0NNRCAleFxuIiwNCj4gY29tbWFuZCk7DQo+
ID4NCj4gPiAgCQlvdXRfYmUzMigmbGJjLT5maXIsIChGSVJfT1BfQ00wIDw8IEZJUl9PUDBfU0hJ
RlQpIHwNCj4gPiAgCQkgICAgICAgICAgICAgICAgICAgIChGSVJfT1BfVUEgIDw8IEZJUl9PUDFf
U0hJRlQpIHwNCj4gPiAgCQkgICAgICAgICAgICAgICAgICAgIChGSVJfT1BfUkJXIDw8IEZJUl9P
UDJfU0hJRlQpKTsNCj4gPiAtCQlvdXRfYmUzMigmbGJjLT5mY3IsIE5BTkRfQ01EX1JFQURJRCA8
PCBGQ1JfQ01EMF9TSElGVCk7DQo+ID4gLQkJLyogbmFuZF9nZXRfZmxhc2hfdHlwZSgpIHJlYWRz
IDggYnl0ZXMgb2YgZW50aXJlIElEIHN0cmluZyAqLw0KPiA+IC0JCW91dF9iZTMyKCZsYmMtPmZi
Y3IsIDgpOw0KPiA+IC0JCWVsYmNfZmNtX2N0cmwtPnJlYWRfYnl0ZXMgPSA4Ow0KPiA+ICsJCW91
dF9iZTMyKCZsYmMtPmZjciwgY29tbWFuZCA8PCBGQ1JfQ01EMF9TSElGVCk7DQo+ID4gKwkJLyog
cmVhZHMgOCBieXRlcyBvZiBlbnRpcmUgSUQgc3RyaW5nICovDQo+ID4gKwkJaWYgKE5BTkRfQ01E
X1JFQURJRCA9PSBjb21tYW5kKSB7DQo+IA0KPiBpZiAoY29tbWFuZCA9PSBOQU5EX0NNRF9SRUFE
SUQpIHsNCj4gDQo+ID4gKwkJCW91dF9iZTMyKCZsYmMtPmZiY3IsIDgpOw0KPiA+ICsJCQllbGJj
X2ZjbV9jdHJsLT5yZWFkX2J5dGVzID0gODsNCj4gPiArCQl9IGVsc2Ugew0KPiA+ICsJCQlvdXRf
YmUzMigmbGJjLT5mYmNyLCAyNTYpOw0KPiA+ICsJCQllbGJjX2ZjbV9jdHJsLT5yZWFkX2J5dGVz
ID0gMjU2Ow0KPiA+ICsJCX0NCj4gDQo+IEFueSBoYXJtIGluIGFsd2F5cyB1c2luZyAyNTY/DQo+
IA0KPiAtU2NvdHQNCltTaGVuZ3pob3VdIEZvciBOQU5EX0NNRF9SRUFESUQgY29tbWFuZCwgdGhl
IHRvdGFsIGJ5dGVzIG9mIGVudGlyZSBJRCBzdHJpbmcgYXJlIDgsIHRoZXJlIGFyZSBub3QgMjU2
IGJ5dGVzIHNvIG1hbnksIGl0J3MgdW5uZWNlc3NhcnkgYW5kIGxvb2tzIG5vdCBzbyB3ZWxsIGxv
Z2ljYWxseSB0byBhbHdheXMgdXNpbmcgMjU2LCB0aG91Z2ggaXQgd29ya3MuDQoNCg0K
^ permalink raw reply
* RE: [PATCH] rapidio/tsi721: Fix mailbox resource reporting
From: Bounine, Alexandre @ 2011-12-07 2:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20111206143638.12598c7b.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]
Tsi721 patches are applicable to 3.2-rc1 and newer only. Sorry for not describing it properly.
This and following patch are fixes for issues found since 3.2-rc1.
I will update changelogs for these patches with more details and resubmit them tomorrow.
________________________________
From: linuxppc-dev-bounces+alexandre.bounine=idt.com@lists.ozlabs.org on behalf of Andrew Morton
Sent: Tue 12/6/2011 5:36 PM
To: Bounine, Alexandre
Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rapidio/tsi721: Fix mailbox resource reporting
On Tue, 6 Dec 2011 14:01:27 -0500
Alexandre Bounine <alexandre.bounine@idt.com> wrote:
> Report support of four RapidIO mailboxes (MBOX0 - MBOX3) instead of MBOX0
> only.
I don't know how important these changes are and I don't know what
their end user visible effects are. Hence I am unable to decide which
kernel version(s) we should merge the patches into.
That's why these things should always be explained in changelogs,
please.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 1916 bytes --]
^ permalink raw reply
* Re: pata_sl82c105 is unable to properly handle dma (indeed it try to use mwdma2)
From: Benjamin Herrenschmidt @ 2011-12-07 2:21 UTC (permalink / raw)
To: acrux_it@libero.it; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <28546010.491181323220500482.JavaMail.defaultUser@defaultHost>
On Wed, 2011-12-07 at 02:15 +0100, acrux_it@libero.it wrote:
> New pata_sl82c105 is unable to properly handle dma (indeed it try to use
> mwdma2).
> Old ide driver instead worked fine.
>
> Tested on IBM 9114-275 where to use it i must boot with dma disabled i.e. with
> libata.dma=0
Adding the linux-ide list on CC. Can you also send a dmesg with the old
IDE driver ? It might be useful to compare the values programmed by the
2 versions of the driver in the timing registers.
Cheers,
Ben.
> [...]
> pata_sl82c105 0000:00:03.1: enabling device (0144 -> 0145)
> scsi1 : pata_sl82c105
> scsi2 : pata_sl82c105
> ata1: PATA max MWDMA2 cmd 0x1f000 ctl 0x1f010 bmdma 0x1f040 irq 165
> ata2: PATA max MWDMA2 cmd 0x1f020 ctl 0x1f030 bmdma 0x1f048 irq 165
> ata1.00: ATAPI: IBM DROM00205, NR38, max UDMA/33
> ata1.00: configured for MWDMA2
> [...]
> scsi 1:0:0:0: CD-ROM IBM DROM00205 NR38 PQ: 0 ANSI: 2
> sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
> cdrom: Uniform CD-ROM driver Revision: 3.20
> sr 1:0:0:0: Attached scsi generic sg3 type 5
> [...]
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA2
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Xdread, Read track info: 52 01 00 00 00 01 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA2
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Xdread, Read track info 52 01 00 00 00 01
> 00 000
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA2
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: limiting speed to MWDMA1:PIO4
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
>
>
>
>
>
>
>
> cheers,
> --nico
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 01/16 v2] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-12-07 1:26 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev, linux-serial
In-Reply-To: <CAMuHMdUB-jQQB=ieumYTehdZz1EnoSazEAhsnEunHSnK2o=k8Q@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2634 bytes --]
On Tue, 6 Dec 2011, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Tue, Dec 6, 2011 at 16:13, Finn Thain <fthain@telegraphics.com.au> wrote:
> > +static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
> > +{
> > + if (enable) {
> > + uap->curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
> > + if (!ZS_IS_EXTCLK(uap))
> > + uap->curregs[1] |= EXT_INT_ENAB;
> > + } else {
> > + uap->curregs[1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
>
> Should there be a call to zssync() here?
I don't think so. Though I should have mentioned the change in the patch
header.
> The old code always did that after disabling interrupts.
pmz_load_zsregs(), pmz_set_termios() and pmz_suspend() don't do it.
sunzilog only does it on sparc64 and only when writing to the data
register or writing command modifiers to the control register ("On 64-bit
sparc we only need to flush single writes to ensure completion.")
I can't find any purpose for control register reads in the chip manual.
The zssync() calls following some WR1 writes originate here:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=9e9d9f693c7def3900725c04c6b64311655eea51
So I don't see any need for control register reads but hopefully Ben can
say for sure.
Reading the patch now I notice that I dropped a pmz_maybe_update_regs() or
pmz_load_zsregs() in the suspend path. I will send a new patch.
Finn
>
> > + }
> > + write_zsreg(uap, R1, uap->curregs[1]);
> > +}
> > +
> > static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *uap)
> > {
> > struct tty_struct *tty = NULL;
> > @@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
> >
> > return tty;
> > flood:
> > - uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
> > - write_zsreg(uap, R1, uap->curregs[R1]);
> > - zssync(uap);
>
> Cfr. e.g. here.
>
> > + pmz_interrupt_control(uap, 0);
> > pmz_error("pmz: rx irq flood !\n");
> > return tty;
> > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply
* pata_sl82c105 is unable to properly handle dma (indeed it try to use mwdma2)
From: acrux_it @ 2011-12-07 1:15 UTC (permalink / raw)
To: linuxppc-dev
New pata_sl82c105 is unable to properly handle dma (indeed it try to use
mwdma2).
Old ide driver instead worked fine.
Tested on IBM 9114-275 where to use it i must boot with dma disabled i.e. with
libata.dma=0
[...]
pata_sl82c105 0000:00:03.1: enabling device (0144 -> 0145)
scsi1 : pata_sl82c105
scsi2 : pata_sl82c105
ata1: PATA max MWDMA2 cmd 0x1f000 ctl 0x1f010 bmdma 0x1f040 irq 165
ata2: PATA max MWDMA2 cmd 0x1f020 ctl 0x1f030 bmdma 0x1f048 irq 165
ata1.00: ATAPI: IBM DROM00205, NR38, max UDMA/33
ata1.00: configured for MWDMA2
[...]
scsi 1:0:0:0: CD-ROM IBM DROM00205 NR38 PQ: 0 ANSI: 2
sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi generic sg3 type 5
[...]
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA2
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Xdread, Read track info: 52 01 00 00 00 01 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA2
ata1: EH complete
sr0: CDROM (ioctl) error, command: Xdread, Read track info 52 01 00 00 00 01
00 000
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA2
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: limiting speed to MWDMA1:PIO4
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
cheers,
--nico
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-12-07 0:09 UTC (permalink / raw)
To: shuo.liu
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd, akpm,
dwmw2
In-Reply-To: <1322973098-2528-3-git-send-email-shuo.liu@freescale.com>
On 12/03/2011 10:31 PM, shuo.liu@freescale.com wrote:
> From: Liu Shuo <shuo.liu@freescale.com>
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
> them to a large buffer.
>
> Signed-off-by: Liu Shuo <shuo.liu@freescale.com>
> ---
> v3:
> -remove page_size of struct fsl_elbc_mtd.
> -do a oob write by NAND_CMD_RNDIN.
>
> drivers/mtd/nand/fsl_elbc_nand.c | 243 ++++++++++++++++++++++++++++++++++----
> 1 files changed, 218 insertions(+), 25 deletions(-)
What is the plan for bad block marker migration?
> @@ -473,13 +568,72 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
> * write so the HW generates the ECC.
> */
> if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column != 0 ||
> - elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize)
> - out_be32(&lbc->fbcr,
> - elbc_fcm_ctrl->index - elbc_fcm_ctrl->column);
> - else
> + elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize) {
> + if (elbc_fcm_ctrl->oob && mtd->writesize > 2048) {
> + out_be32(&lbc->fbcr, 64);
> + } else {
> + out_be32(&lbc->fbcr, elbc_fcm_ctrl->index
> + - elbc_fcm_ctrl->column);
> + }
We need to limit ourselves to the regions that have actually been
written to in the buffer. fbcr needs to be set separately for first and
last subpages, with intermediate subpages having 0, 64, or 2112 as
appropriate. Subpages that are entirely before column or entirely after
column + index should be skipped.
> + } else {
> + out_be32(&lbc->fir, FIR_OP_WB << FIR_OP1_SHIFT);
> + for (i = 1; i < n; i++) {
> + if (i == n - 1) {
> + elbc_fcm_ctrl->use_mdr = 1;
> + out_be32(&lbc->fir,
> + (FIR_OP_WB << FIR_OP1_SHIFT) |
> + (FIR_OP_CM3 << FIR_OP2_SHIFT) |
> + (FIR_OP_CW1 << FIR_OP3_SHIFT) |
> + (FIR_OP_RS << FIR_OP4_SHIFT));
Please explicitly show the (FIR_OP_NOP << FIR_OP0_SHIFT) compenent.
> + } else if (mtd->writesize >= 2048 && mtd->writesize <= 16 * 1024) {
> +
> setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
Don't insert a blank line here.
-Scott
^ permalink raw reply
* Re: [PATCH][v2] powerpc/85xx: Rework P1022DS device tree
From: Tabi Timur-B04825 @ 2011-12-06 22:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1321540377-3672-1-git-send-email-galak@kernel.crashing.org>
On Thu, Nov 17, 2011 at 8:32 AM, Kumar Gala <galak@kernel.crashing.org> wro=
te:=0A=
>=0A=
> @@ -585,30 +222,11 @@=0A=
> =A0 =A0 =A0 =A0};=0A=
>=0A=
> =A0 =A0 =A0 =A0pci1: pcie@fffe0a000 {=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,p1022-pcie";=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "pci";=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 #interrupt-cells =3D <1>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <2>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <3>;=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xf 0xffe0a000 0 0x1000>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 bus-range =3D <0 255>;=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ranges =3D <0x2000000 0x0 0xc0000000 0xc 0=
x40000000 0x0 0x20000000=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x1000000 0x0 0x000000=
00 0xf 0xffc20000 0x0 0x10000>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock-frequency =3D <33333333>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupts =3D <16 2 0 0>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-map-mask =3D <0xf800 0 0 7>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-map =3D <=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* IDSEL 0x0 */=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0000 0 0 1 &mpic 0 1=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0000 0 0 2 &mpic 1 1=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0000 0 0 3 &mpic 2 1=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0000 0 0 4 &mpic 3 1=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >;=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pcie@0 {=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x0 0x0 0x0 0x0 0=
x0>;=0A=
=0A=
Did you forget to delete this 'reg' line?=0A=
=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <2>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <3>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "pci";=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ranges =3D <0x2000000 0x0 =
0xe0000000=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x2000=
000 0x0 0xe0000000=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x0 0x=
20000000=0A=
=0A=
-- =0A=
Timur Tabi=0A=
Linux kernel developer at Freescale=0A=
^ permalink raw reply
* Re: [PATCH] rapidio/tsi721: Fix mailbox resource reporting
From: Andrew Morton @ 2011-12-06 22:36 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1323198088-11669-1-git-send-email-alexandre.bounine@idt.com>
On Tue, 6 Dec 2011 14:01:27 -0500
Alexandre Bounine <alexandre.bounine@idt.com> wrote:
> Report support of four RapidIO mailboxes (MBOX0 - MBOX3) instead of MBOX0
> only.
I don't know how important these changes are and I don't know what
their end user visible effects are. Hence I am unable to decide which
kernel version(s) we should merge the patches into.
That's why these things should always be explained in changelogs,
please.
^ permalink raw reply
* [PATCH] rapidio/tsi721: Fix mailbox resource reporting
From: Alexandre Bounine @ 2011-12-06 19:01 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
Report support of four RapidIO mailboxes (MBOX0 - MBOX3) instead of MBOX0
only.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
---
drivers/rapidio/devices/tsi721.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 514c28c..83ac8728 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -2107,8 +2107,8 @@ static int __devinit tsi721_setup_mport(struct tsi721_device *priv)
INIT_LIST_HEAD(&mport->dbells);
rio_init_dbell_res(&mport->riores[RIO_DOORBELL_RESOURCE], 0, 0xffff);
- rio_init_mbox_res(&mport->riores[RIO_INB_MBOX_RESOURCE], 0, 0);
- rio_init_mbox_res(&mport->riores[RIO_OUTB_MBOX_RESOURCE], 0, 0);
+ rio_init_mbox_res(&mport->riores[RIO_INB_MBOX_RESOURCE], 0, 3);
+ rio_init_mbox_res(&mport->riores[RIO_OUTB_MBOX_RESOURCE], 0, 3);
strcpy(mport->name, "Tsi721 mport");
/* Hook up interrupt handler */
--
1.7.6
^ permalink raw reply related
* [PATCH] rapidio/tsi721: modify PCIe capability settings
From: Alexandre Bounine @ 2011-12-06 19:01 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
In-Reply-To: <1323198088-11669-1-git-send-email-alexandre.bounine@idt.com>
Change Completion Timeout Value to avoid data transfer aborts during
intensive data transfers.
Remove hardcoded offset for PCIe capability registers.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
---
drivers/rapidio/devices/tsi721.c | 20 +++++++++++++++-----
drivers/rapidio/devices/tsi721.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 83ac8728..691b1ab 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -2154,7 +2154,7 @@ static int __devinit tsi721_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct tsi721_device *priv;
- int i;
+ int i, cap;
int err;
u32 regval;
@@ -2262,10 +2262,20 @@ static int __devinit tsi721_probe(struct pci_dev *pdev,
dev_info(&pdev->dev, "Unable to set consistent DMA mask\n");
}
- /* Clear "no snoop" and "relaxed ordering" bits. */
- pci_read_config_dword(pdev, 0x40 + PCI_EXP_DEVCTL, ®val);
- regval &= ~(PCI_EXP_DEVCTL_RELAX_EN | PCI_EXP_DEVCTL_NOSNOOP_EN);
- pci_write_config_dword(pdev, 0x40 + PCI_EXP_DEVCTL, regval);
+ cap = pci_pcie_cap(pdev);
+ BUG_ON(cap == 0);
+
+ /* Clear "no snoop" and "relaxed ordering" bits, use default MRRS. */
+ pci_read_config_dword(pdev, cap + PCI_EXP_DEVCTL, ®val);
+ regval &= ~(PCI_EXP_DEVCTL_READRQ | PCI_EXP_DEVCTL_RELAX_EN |
+ PCI_EXP_DEVCTL_NOSNOOP_EN);
+ regval |= 0x2 << MAX_READ_REQUEST_SZ_SHIFT;
+ pci_write_config_dword(pdev, cap + PCI_EXP_DEVCTL, regval);
+
+ /* Adjust PCIe completion timeout. */
+ pci_read_config_dword(pdev, cap + PCI_EXP_DEVCTL2, ®val);
+ regval &= ~(0x0f);
+ pci_write_config_dword(pdev, cap + PCI_EXP_DEVCTL2, regval | 0x2);
/*
* FIXUP: correct offsets of MSI-X tables in the MSI-X Capability Block
diff --git a/drivers/rapidio/devices/tsi721.h b/drivers/rapidio/devices/tsi721.h
index 58be4de..822e54c 100644
--- a/drivers/rapidio/devices/tsi721.h
+++ b/drivers/rapidio/devices/tsi721.h
@@ -72,6 +72,8 @@
#define TSI721_MSIXPBA_OFFSET 0x2a000
#define TSI721_PCIECFG_EPCTL 0x400
+#define MAX_READ_REQUEST_SZ_SHIFT 12
+
/*
* Event Management Registers
*/
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND controller
From: Scott Wood @ 2011-12-06 17:17 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-mtd, kumar.gala, linuxppc-dev, dwmw2
In-Reply-To: <1323161655-19050-2-git-send-email-Shengzhou.Liu@freescale.com>
On 12/06/2011 02:54 AM, Shengzhou Liu wrote:
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index 4f405a0..b4db407 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -349,19 +349,24 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
> fsl_elbc_run_command(mtd);
> return;
>
> - /* READID must read all 5 possible bytes while CEB is active */
> case NAND_CMD_READID:
> - dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD_READID.\n");
> + case NAND_CMD_PARAM:
> + dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD %x\n", command);
>
> out_be32(&lbc->fir, (FIR_OP_CM0 << FIR_OP0_SHIFT) |
> (FIR_OP_UA << FIR_OP1_SHIFT) |
> (FIR_OP_RBW << FIR_OP2_SHIFT));
> - out_be32(&lbc->fcr, NAND_CMD_READID << FCR_CMD0_SHIFT);
> - /* nand_get_flash_type() reads 8 bytes of entire ID string */
> - out_be32(&lbc->fbcr, 8);
> - elbc_fcm_ctrl->read_bytes = 8;
> + out_be32(&lbc->fcr, command << FCR_CMD0_SHIFT);
> + /* reads 8 bytes of entire ID string */
> + if (NAND_CMD_READID == command) {
if (command == NAND_CMD_READID) {
> + out_be32(&lbc->fbcr, 8);
> + elbc_fcm_ctrl->read_bytes = 8;
> + } else {
> + out_be32(&lbc->fbcr, 256);
> + elbc_fcm_ctrl->read_bytes = 256;
> + }
Any harm in always using 256?
-Scott
^ permalink raw reply
* Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Scott Wood @ 2011-12-06 17:16 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-mtd, kumar.gala, linuxppc-dev, dwmw2
In-Reply-To: <1323161655-19050-1-git-send-email-Shengzhou.Liu@freescale.com>
On 12/06/2011 02:54 AM, Shengzhou Liu wrote:
> There was a bug for fmr initialization, which lead to fmr was always 0x100
> in fsl_elbc_chip_init() and caused FCM command timeout before calling
> fsl_elbc_chip_init_tail(), now we initialize CWTO to maximum timeout value
> and not relying on the setting of bootloader.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> v2: make fmr not relying on the setting of bootloader.
>
> drivers/mtd/nand/fsl_elbc_nand.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index eedd8ee..4f405a0 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -659,9 +659,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
> if (chip->pagemask & 0xff000000)
> al++;
>
> - /* add to ECCM mode set in fsl_elbc_init */
> - priv->fmr |= (12 << FMR_CWTO_SHIFT) | /* Timeout > 12 ms */
> - (al << FMR_AL_SHIFT);
> + priv->fmr |= al << FMR_AL_SHIFT;
>
> dev_dbg(priv->dev, "fsl_elbc_init: nand->numchips = %d\n",
> chip->numchips);
> @@ -764,8 +762,10 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
> priv->mtd.priv = chip;
> priv->mtd.owner = THIS_MODULE;
>
> - /* Set the ECCM according to the settings in bootloader.*/
> - priv->fmr = in_be32(&lbc->fmr) & FMR_ECCM;
> + /* set timeout to maximum */
> + priv->fmr = 15 << FMR_CWTO_SHIFT;
> + if (in_be32(&lbc->bank[priv->bank].or) & OR_FCM_PGS)
> + priv->fmr |= FMR_ECCM;
Please do not change the way ECCM is handled. We probably should have
done it this way from the start, but at this point it breaks
compatibility if you have a large page flash and the firmware didn't
touch NAND.
-Scott
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Miche Baker-Harvey @ 2011-12-06 17:05 UTC (permalink / raw)
To: Amit Shah
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk, Rusty Russell,
linux-kernel, virtualization, Anton Blanchard, Mike Waychison,
ppc-dev, Greg Kroah-Hartman, Eric Northrup
In-Reply-To: <20111205105452.GB27683@amit-x200.redhat.com>
Amit,
Ah, indeed. I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
calls vp_request_intx() and sets up an interrupt callback. From
there, when an interrupt occurs, the stack looks something like this:
virtio_pci::vp_interrupt()
virtio_pci::vp_vring_interrupt()
virtio_ring::vring_interrupt()
vq->vq.callback() <-- in this case, that's virtio_console::control_i=
ntr()
workqueue::schedule_work()
workqueue::queue_work()
queue_work_on(get_cpu()) <-- queues the work on the current CP=
U.
I'm not doing anything to keep multiple control message from being
sent concurrently to the guest, and we will take those interrupts on
any CPU. I've confirmed that the two instances of
handle_control_message() are occurring on different CPUs.
Should this work? I don't see anywhere that QEMU is serializing the
sending of data to the control queue in the guest, and there's no
serialization in
the control_intr. I don't understand why you are not seeing the
concurrent execution of handle_control_message(). Are you taking all
your interrupts on a single CPU, maybe? Or is there some other
serialization in user space?
Miche
On Mon, Dec 5, 2011 at 2:54 AM, Amit Shah <amit.shah@redhat.com> wrote:
> On (Tue) 29 Nov 2011 [09:50:41], Miche Baker-Harvey wrote:
>> Good grief! =A0Sorry for the spacing mess-up! =A0Here's a resend with re=
formatting.
>>
>> Amit,
>> We aren't using either QEMU or kvmtool, but we are using KVM. =A0All
>
> So it's a different userspace? =A0Any chance this different userspace is
> causing these problems to appear? =A0Esp. since I couldn't reproduce
> with qemu.
>
>> the issues we are seeing happen when we try to establish multiple
>> virtioconsoles at boot time. =A0The command line isn't relevant, but I
>> can tell you the protocol that's passing between the host (kvm) and
>> the guest (see the end of this message).
>>
>> We do go through the control_work_handler(), but it's not
>> providing synchronization. =A0Here's a trace of the
>> control_work_handler() and handle_control_message() calls; note that
>> there are two concurrent calls to control_work_handler().
>
> Ah; how does that happen? =A0control_work_handler() should just be
> invoked once, and if there are any more pending work items to be
> consumed, they should be done within the loop inside
> control_work_handler().
>
>> I decorated control_work_handler() with a "lifetime" marker, and
>> passed this value to handle_control_message(), so we can see which
>> control messages are being handled from which instance of
>> the control_work_handler() thread.
>>
>> Notice that we enter control_work_handler() a second time before
>> the handling of the second PORT_ADD message is complete. The
>> first CONSOLE_PORT message is handled by the second
>> control_work_handler() call, but the second is handled by the first
>> control_work_handler() call.
>>
>> root@myubuntu:~# dmesg | grep MBH
>> [3371055.808738] control_work_handler #1
>> [3371055.809372] + #1 handle_control_message PORT_ADD
>> [3371055.810169] - handle_control_message PORT_ADD
>> [3371055.810170] + #1 handle_control_message PORT_ADD
>> [3371055.810244] =A0control_work_handler #2
>> [3371055.810245] + #2 handle_control_message CONSOLE_PORT
>> [3371055.810246] =A0got hvc_ports_mutex
>> [3371055.810578] - handle_control_message PORT_ADD
>> [3371055.810579] + #1 handle_control_message CONSOLE_PORT
>> [3371055.810580] =A0trylock of hvc_ports_mutex failed
>> [3371055.811352] =A0got hvc_ports_mutex
>> [3371055.811370] - handle_control_message CONSOLE_PORT
>> [3371055.816609] - handle_control_message CONSOLE_PORT
>>
>> So, I'm guessing the bug is that there shouldn't be two instances of
>> control_work_handler() running simultaneously?
>
> Yep, I assumed we did that but apparently not. =A0Do you plan to chase
> this one down?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit
>
^ permalink raw reply
* Re: [PATCH 01/16 v2] pmac_zilog: fix unexpected irq
From: Alan Cox @ 2011-12-06 15:39 UTC (permalink / raw)
To: Finn Thain; +Cc: linux-m68k, Geert Uytterhoeven, linuxppc-dev, linux-serial
In-Reply-To: <alpine.LNX.2.00.1112070203310.14968@nippy.intranet>
On Wed, 7 Dec 2011 02:13:41 +1100 (EST)
Finn Thain <fthain@telegraphics.com.au> wrote:
>
> On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
> masked. This can be a problem when pmac_zilog starts up.
>
> For example, the serial debugging code in arch/m68k/kernel/head.S may be
> used beforehand. It disables the SCC interrupts at the chip but doesn't
> ack them. Then when a pmac_zilog port is opened and SCC chip interrupts
> become enabled, the machine locks up with "unexpected interrupt" because
> request_irq() hasn't happened yet.
>
> Fix this by setting the interrupt enable bits only after the handler is
> installed and before it is uninstalled. Also move this bit flipping into a
> separate pmz_interrupt_control() routine. Replace all instances of these
> operations with calls to this routine.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Nice
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Re: [PATCH 01/16 v2] pmac_zilog: fix unexpected irq
From: Geert Uytterhoeven @ 2011-12-06 15:27 UTC (permalink / raw)
To: Finn Thain; +Cc: linux-m68k, linuxppc-dev, linux-serial
In-Reply-To: <alpine.LNX.2.00.1112070203310.14968@nippy.intranet>
Hi Finn,
On Tue, Dec 6, 2011 at 16:13, Finn Thain <fthain@telegraphics.com.au> wrote=
:
> +static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable=
)
> +{
> + =C2=A0 =C2=A0 =C2=A0 if (enable) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uap->curregs[1] |=3D I=
NT_ALL_Rx | TxINT_ENAB;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!ZS_IS_EXTCLK(uap)=
)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 uap->curregs[1] |=3D EXT_INT_ENAB;
> + =C2=A0 =C2=A0 =C2=A0 } else {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uap->curregs[1] &=3D ~=
(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
Should there be a call to zssync() here?
The old code always did that after disabling interrupts.
> + =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 write_zsreg(uap, R1, uap->curregs[1]);
> +}
> +
> =C2=A0static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *=
uap)
> =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0struct tty_struct *tty =3D NULL;
> @@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0return tty;
> =C2=A0flood:
> - =C2=A0 =C2=A0 =C2=A0 uap->curregs[R1] &=3D ~(EXT_INT_ENAB | TxINT_ENAB =
| RxINT_MASK);
> - =C2=A0 =C2=A0 =C2=A0 write_zsreg(uap, R1, uap->curregs[R1]);
> - =C2=A0 =C2=A0 =C2=A0 zssync(uap);
Cfr. e.g. here.
> + =C2=A0 =C2=A0 =C2=A0 pmz_interrupt_control(uap, 0);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0pmz_error("pmz: rx irq flood !\n");
> =C2=A0 =C2=A0 =C2=A0 =C2=A0return tty;
> =C2=A0}
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* [PATCH 01/16 v2] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-12-06 15:13 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev, linux-serial
In-Reply-To: <20111023141115.208699274@telegraphics.com.au>
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
For example, the serial debugging code in arch/m68k/kernel/head.S may be
used beforehand. It disables the SCC interrupts at the chip but doesn't
ack them. Then when a pmac_zilog port is opened and SCC chip interrupts
become enabled, the machine locks up with "unexpected interrupt" because
request_irq() hasn't happened yet.
Fix this by setting the interrupt enable bits only after the handler is
installed and before it is uninstalled. Also move this bit flipping into a
separate pmz_interrupt_control() routine. Replace all instances of these
operations with calls to this routine.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Re-implemented since v1 using a simpler approach that avoids messing with
the Master Interrupt Enable bit. As well as the ifdef problem, it turns
out that v1 was not sufficient to entirely fix the problem.
This patch has been tested on a PowerBook 520 but no PowerMacs yet.
Index: linux-git/drivers/tty/serial/pmac_zilog.c
===================================================================
--- linux-git.orig/drivers/tty/serial/pmac_zilog.c 2011-12-07 01:56:43.000000000 +1100
+++ linux-git/drivers/tty/serial/pmac_zilog.c 2011-12-07 01:56:55.000000000 +1100
@@ -216,6 +216,18 @@ static void pmz_maybe_update_regs(struct
}
}
+static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
+{
+ if (enable) {
+ uap->curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
+ if (!ZS_IS_EXTCLK(uap))
+ uap->curregs[1] |= EXT_INT_ENAB;
+ } else {
+ uap->curregs[1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
+ }
+ write_zsreg(uap, R1, uap->curregs[1]);
+}
+
static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *uap)
{
struct tty_struct *tty = NULL;
@@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
return tty;
flood:
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
- zssync(uap);
+ pmz_interrupt_control(uap, 0);
pmz_error("pmz: rx irq flood !\n");
return tty;
}
@@ -990,12 +1000,9 @@ static int pmz_startup(struct uart_port
if (ZS_IS_IRDA(uap))
pmz_irda_reset(uap);
- /* Enable interrupts emission from the chip */
+ /* Enable interrupt requests for the channel */
spin_lock_irqsave(&port->lock, flags);
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
+ pmz_interrupt_control(uap, 1);
spin_unlock_irqrestore(&port->lock, flags);
pmz_debug("pmz: startup() done.\n");
@@ -1015,6 +1022,25 @@ static void pmz_shutdown(struct uart_por
mutex_lock(&pmz_irq_mutex);
+ if (!ZS_IS_ASLEEP(uap)) {
+ spin_lock_irqsave(&port->lock, flags);
+
+ if (!ZS_IS_CONS(uap)) {
+ /* Disable receiver and transmitter */
+ uap->curregs[R3] &= ~RxENABLE;
+ uap->curregs[R5] &= ~TxENABLE;
+
+ /* Disable BRK assertion */
+ uap->curregs[R5] &= ~SND_BRK;
+ pmz_maybe_update_regs(uap);
+ }
+
+ /* Disable interrupt requests for the channel */
+ pmz_interrupt_control(uap, 0);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+ }
+
/* Release interrupt handler */
free_irq(uap->port.irq, uap);
@@ -1025,29 +1051,8 @@ static void pmz_shutdown(struct uart_por
if (!ZS_IS_OPEN(uap->mate))
pmz_get_port_A(uap)->flags &= ~PMACZILOG_FLAG_IS_IRQ_ON;
- /* Disable interrupts */
- if (!ZS_IS_ASLEEP(uap)) {
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
- zssync(uap);
- }
-
- if (ZS_IS_CONS(uap) || ZS_IS_ASLEEP(uap)) {
- spin_unlock_irqrestore(&port->lock, flags);
- mutex_unlock(&pmz_irq_mutex);
- return;
- }
-
- /* Disable receiver and transmitter. */
- uap->curregs[R3] &= ~RxENABLE;
- uap->curregs[R5] &= ~TxENABLE;
-
- /* Disable all interrupts and BRK assertion. */
- uap->curregs[R5] &= ~SND_BRK;
- pmz_maybe_update_regs(uap);
-
- /* Shut the chip down */
- pmz_set_scc_power(uap, 0);
+ if (!ZS_IS_ASLEEP(uap) && !ZS_IS_CONS(uap))
+ pmz_set_scc_power(uap, 0); /* Shut the chip down */
spin_unlock_irqrestore(&port->lock, flags);
@@ -1352,19 +1357,15 @@ static void pmz_set_termios(struct uart_
spin_lock_irqsave(&port->lock, flags);
/* Disable IRQs on the port */
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
+ pmz_interrupt_control(uap, 0);
/* Setup new port configuration */
__pmz_set_termios(port, termios, old);
/* Re-enable IRQs on the port */
- if (ZS_IS_OPEN(uap)) {
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
- }
+ if (ZS_IS_OPEN(uap))
+ pmz_interrupt_control(uap, 1);
+
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -1670,15 +1671,13 @@ static int pmz_suspend(struct macio_dev
spin_lock_irqsave(&uap->port.lock, flags);
+ /* Disable receiver and transmitter. */
+ uap->curregs[R3] &= ~RxENABLE;
+ uap->curregs[R5] &= ~TxENABLE;
+
+ pmz_interrupt_control(uap, 0);
+
if (ZS_IS_OPEN(uap) || ZS_IS_CONS(uap)) {
- /* Disable receiver and transmitter. */
- uap->curregs[R3] &= ~RxENABLE;
- uap->curregs[R5] &= ~TxENABLE;
-
- /* Disable all interrupts and BRK assertion. */
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- uap->curregs[R5] &= ~SND_BRK;
- pmz_load_zsregs(uap, uap->curregs);
uap->flags |= PMACZILOG_FLAG_IS_ASLEEP;
mb();
}
@@ -1738,14 +1737,6 @@ static int pmz_resume(struct macio_dev *
/* Take care of config that may have changed while asleep */
__pmz_set_termios(&uap->port, &uap->termios_cache, NULL);
- if (ZS_IS_OPEN(uap)) {
- /* Enable interrupts */
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
- }
-
spin_unlock_irqrestore(&uap->port.lock, flags);
if (ZS_IS_CONS(uap))
@@ -1757,6 +1748,12 @@ static int pmz_resume(struct macio_dev *
enable_irq(uap->port.irq);
}
+ if (ZS_IS_OPEN(uap)) {
+ spin_lock_irqsave(&uap->port.lock, flags);
+ pmz_interrupt_control(uap, 1);
+ spin_unlock_irqrestore(&uap->port.lock, flags);
+ }
+
bail:
mutex_unlock(&state->port.mutex);
mutex_unlock(&pmz_irq_mutex);
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-12-06 11:49 UTC (permalink / raw)
To: Scott Wood
Cc: Artem.Bityutskiy, dwmw2, linux-kernel, shuo.liu, linux-mtd, akpm,
linuxppc-dev
In-Reply-To: <4EDD1F90.300@freescale.com>
On Mon, 2011-12-05 at 13:46 -0600, Scott Wood wrote:
> Because this is a controller resource, shared by multiple NAND chips
> that may be different page sizes (even if not, it's adding another point
> of synchronization required between initialization of different chips).
> I don't think it's worth the gymnastics to save a few KiB.
OK, I see.
Artem.
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-12-06 11:49 UTC (permalink / raw)
To: shuo.liu
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd,
scottwood, akpm, dwmw2
In-Reply-To: <1322973098-2528-3-git-send-email-shuo.liu@freescale.com>
On Sun, 2011-12-04 at 12:31 +0800, shuo.liu@freescale.com wrote:
> From: Liu Shuo <shuo.liu@freescale.com>
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
> them to a large buffer.
>
> Signed-off-by: Liu Shuo <shuo.liu@freescale.com>
This patch does not apply on top of my l2-mtd-2.6.git tree. Could you
please send a patch that applies cleanly?
Thanks!
^ permalink raw reply
* Re: "KVM: PPC: booke: Improve timer register emulation" breaks Book3s HV
From: Alexander Graf @ 2011-12-06 11:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Scott Wood, linuxppc-dev, kvm-ppc
In-Reply-To: <20111206114347.GA14832@bloggs.ozlabs.ibm.com>
On 06.12.2011, at 12:43, Paul Mackerras wrote:
> On Tue, Dec 06, 2011 at 03:03:00PM +1100, Paul Mackerras wrote:
>> I'm not sure why yet, but commit 8a97c432 ("KVM: PPC: booke: Improve
>> timer register emulation") in Alex's kvm-ppc-next branch is breaking
>> Book3S HV KVM on POWER7. Guest cpus fail to spin up, and even with
>> just one cpu, the guest stalls every so often. If I stop the guest
>> and inspect the state with qemu, PC is at 0x900. Reverting 8a97c432
>> makes it work properly again.
>=20
> This fixes it:
>=20
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 534cbe1..83bcb44 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -560,7 +560,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, =
struct kvm_run *run)
>=20
> void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
> {
> - if (waitqueue_active(&vcpu->wq)) {
> + if (waitqueue_active(vcpu->arch.wqp)) {
:(
> wake_up_interruptible(vcpu->arch.wqp);
> vcpu->stat.halt_wakeup++;
> } else if (vcpu->cpu !=3D -1) {
>=20
> Alex, do you want to roll that in with Scott's patch, or do you want =
me
> to send a separate patch on top?
I usually like praise where praise belongs, so I'll put this right after =
Scott's patch if you give me a nice and shiny patch description with a =
signed-off-by line :)
Alex
^ permalink raw reply
* Re: "KVM: PPC: booke: Improve timer register emulation" breaks Book3s HV
From: Paul Mackerras @ 2011-12-06 11:43 UTC (permalink / raw)
To: Alexander Graf, Scott Wood; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20111206040300.GA12018@drongo>
On Tue, Dec 06, 2011 at 03:03:00PM +1100, Paul Mackerras wrote:
> I'm not sure why yet, but commit 8a97c432 ("KVM: PPC: booke: Improve
> timer register emulation") in Alex's kvm-ppc-next branch is breaking
> Book3S HV KVM on POWER7. Guest cpus fail to spin up, and even with
> just one cpu, the guest stalls every so often. If I stop the guest
> and inspect the state with qemu, PC is at 0x900. Reverting 8a97c432
> makes it work properly again.
This fixes it:
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 534cbe1..83bcb44 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -560,7 +560,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
{
- if (waitqueue_active(&vcpu->wq)) {
+ if (waitqueue_active(vcpu->arch.wqp)) {
wake_up_interruptible(vcpu->arch.wqp);
vcpu->stat.halt_wakeup++;
} else if (vcpu->cpu != -1) {
Alex, do you want to roll that in with Scott's patch, or do you want me
to send a separate patch on top?
Paul.
^ permalink raw reply related
* Re: Problem with eLBC?
From: Joakim Tjernlund @ 2011-12-06 9:30 UTC (permalink / raw)
To: Scott Wood; +Cc: Alexander Lyasin, linuxppc-dev
In-Reply-To: <4EDD32E1.7080009@freescale.com>
>
> On 12/05/2011 08:02 AM, Alexander Lyasin wrote:
> > In reply to your Service Request SR 1-807899446:
> >
> > Yes, due to several design peculiarities in local bus nand controller,
> > simultaneous accesses to nand flash and to other local bus memory
> > controller may cause nand flash controller access failure. Our linux
> > team suggested to use "software lock" method to avoid this problem -
> > please do not use other local bus controllers, when nand flash is accessed.
>
> What kernel version are you using? The latest mainline kernel should
> not have this issue.
>
> Make sure you have these patches:
>
> commit d08e44570ed611c527a1062eb4f8c6ac61832e6e
> Author: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> Date: Thu May 19 18:48:01 2011 +0800
>
> powerpc/fsl_lbc: Add workaround for ELBC-A001 erratum
>
> Simultaneous FCM and GPCM or UPM operation may erroneously trigger
> bus monitor timeout.
>
> Set the local bus monitor timeout value to the maximum by setting
> LBCR[BMT] = 0 and LBCR[BMTPS] = 0xF.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> and
>
> commit 476459a6cf46d20ec73d9b211f3894ced5f9871e
> Author: Scott Wood <scottwood@freescale.com>
> Date: Fri Nov 13 14:13:01 2009 -0600
>
> mtd: eLBC NAND: use recommended command sequences
>
> Currently, the program and erase sequences do not wait for completion,
> instead relying on a subsequent waitfunc() callback. However, this
> causes
> the chipselect to be deasserted while the NAND chip is still
> asserting the
> busy pin, which can corrupt activity on other chipselects.
>
> This patch switches to using the sequences recommended by the manual,
> in which a wait is performed within the initial command sequence.
> We can
> now re-use the status byte from the initial command sequence, rather
> than
> having to do another status read in the waitfunc.
>
> Since we're already touching the command sequences, it also cleans
> up some
> cruft in SEQIN that isn't needed since we cannot program partial pages
> outside of OOB.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Reported-by: Suchit Lepcha <suchit.lepcha@freescale.com>
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>
> -Scott
Scott, you seem know something about eLBC and NAND. I have been told
that using NAND and other memory mapped devices on the same LB may
stall accesses to the other devices as the FCM may hold the bus for
long periods(a whole write or erase op.), is this so?
If still true, I guess the whole CPU "freezes" until the NAND op.
is complete?
Jocke
^ 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