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
-
- fix NAND_CMD_READID command for ONFI detect.
- add NAND_CMD_PARAM command to read the ONFI parameter page.
Signed-off-by: Shengzhou Liu
---
v2: no changes
drivers/mtd/nand/fsl_elbc_nand.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/n
>
> 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 controlle
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 gue
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
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote:
> From: Liu Shuo
>
> 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_
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 wort
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
Hi Finn,
On Tue, Dec 6, 2011 at 16:13, Finn Thain 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-
On Wed, 7 Dec 2011 02:13:41 +1100 (EST)
Finn Thain 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 dis
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_
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 se
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(s
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
---
drivers/rapidio/devices/tsi721.c | 20 +++-
drivers/rapidio/devices/tsi721.h |2 ++
2 f
Report support of four RapidIO mailboxes (MBOX0 - MBOX3) instead of MBOX0
only.
Signed-off-by: Alexandre Bounine
---
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
in
On Tue, 6 Dec 2011 14:01:27 -0500
Alexandre Bounine 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
On Thu, Nov 17, 2011 at 8:32 AM, Kumar Gala wrote:
>
> @@ -585,30 +222,11 @@
> };
>
> pci1: pcie@fffe0a000 {
> - compatible = "fsl,p1022-pcie";
> - device_type = "pci";
> - #interrupt-cells = <1>;
> - #size-cells = <2>;
> -
On 12/03/2011 10:31 PM, shuo@freescale.com wrote:
> From: Liu Shuo
>
> 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
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 :00:03.1: enabling device (0144 -> 0145)
scsi1 : pata_sl82c10
On Tue, 6 Dec 2011, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Tue, Dec 6, 2011 at 16:13, Finn Thain wrote:
> > +static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
> > +{
> > + if (enable) {
> > + uap->curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
> > +
On Wed, 2011-12-07 at 02:15 +0100, acrux...@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 th
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.or
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
于 2011年12月07日 08:09, Scott Wood 写道:
On 12/03/2011 10:31 PM, shuo@freescale.com wrote:
From: Liu Shuo
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
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: linux
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, December 07, 2011 1:17 AM
> To: Liu Shengzhou-B36685
> Cc: linuxppc-dev@lists.ozlabs.org; linux-...@lists.infradead.org;
> dw...@infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH 2/2 v2] mtd/nand: Add ONFI support for F
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, December 07, 2011 1:16 AM
> To: Liu Shengzhou-B36685
> Cc: linuxppc-dev@lists.ozlabs.org; linux-...@lists.infradead.org;
> dw...@infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initiali
Is this the patch you mentioned?
http://patchwork.ozlabs.org/patch/128806/
I applied this patch but the issue was still there.
-Original Message-
From: Tabi Timur-B04825
Sent: Friday, December 02, 2011 11:56 AM
To: Jia Hongtao-B38951
Cc: Kumar Gala; linuxppc-dev@lists.ozlabs.org; Li Yang
On Thu, 2011-12-01 at 10:41 +0100, Wolfgang Grandegger wrote:
> This patch enables or updates support for the CC770 and AN82527
> CAN controller on the TQM8548 and TQM8xx boards.
I'm a bit confused by the net-next prefix here. Those patches seem to
be only touching arch/powerpc and seem to be sent
From: Benjamin Herrenschmidt
Date: Wed, 07 Dec 2011 18:34:28 +1100
> Let me know if I should just remove them from powerpc patchwork.
These are DT entries for CAN devices for which drivers only exist in
the net-next tree, I already included this patch into the net-next
tree so you do not have to
On Wed, 2011-12-07 at 02:39 -0500, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Wed, 07 Dec 2011 18:34:28 +1100
>
> > Let me know if I should just remove them from powerpc patchwork.
>
> These are DT entries for CAN devices for which drivers only exist in
> the net-next tree, I alr
31 matches
Mail list logo
