* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-12-05 6:47 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:
> + /*
> + * Freescale FCM controller has a 2K size limitation of buffer
> + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> + * of chip is greater than 2048.
> + * We malloc a large enough buffer (maximum page size is 16K).
> + */
> + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL);
> + if (!elbc_fcm_ctrl->buffer) {
> + dev_err(dev, "failed to allocate memory\n");
> + mutex_unlock(&fsl_elbc_nand_mutex);
> + ret = -ENOMEM;
> + goto err;
> + }
Sorry for returning to this again and agian - I do not have time to dig
suggest you the right solutions on the one hand, you do not provide me a
good answer on the other hand (or I forgot?).
16KiB pages do not even exist I believe. And you kmalloc 33KiB or RAM
although in most cases you need only 5KiB. I think this is wrong - what
is the very strong reason of wasting RAM you have?
Why you cannot allocate exactly the required amount of RAM after
'nand_scan_ident()' finishes and you know the page size?
Artem.
^ permalink raw reply
* Re: [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR
From: Artem Bityutskiy @ 2011-12-05 6:50 UTC (permalink / raw)
To: shuo.liu
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd,
scottwood, akpm, dwmw2
In-Reply-To: <1322973098-2528-1-git-send-email-shuo.liu@freescale.com>
On Sun, 2011-12-04 at 12:31 +0800, shuo.liu@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
>
> On both of large-page chip and small-page chip, we always should use
> 'elbc_fcm_ctrl->oob' to set the FPAR_LP_MS/FPAR_SP_MS bit of FPAR, don't
> use a overflowed 'column' to set it.
>
> Signed-off-by: Liu Shuo <b35362@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
Pushed patches 1 and 2 to l2-mtd-2.6.git, thanks!
Artem.
^ permalink raw reply
* Re: [PATCH 1/1] Punch a hole in /dev/mem for librtas
From: Segher Boessenkool @ 2011-12-05 7:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, sbest, Sukadev Bhattiprolu, paulus, anton
In-Reply-To: <1323040701.11728.27.camel@pasglop>
>>> +static inline int page_is_rtas_user_buf(unsigned long pfn)
>>> +{
>>> + unsigned long paddr = (pfn << PAGE_SHIFT);
>>> + if (paddr >= rtas_rmo_buf && paddr < (rtas_rmo_buf +
>>> RTAS_RMOBUF_MAX))
>>
>> It probably cannot overflow with actual values of rtas_rmo_buf
>> and RTAS_RMOBUF_MAX, but otherwise it is an incorrect test;
>> please write
>>
>> if (paddr >= rtas_rmo_buf && paddr - rtas_rmo_buf < RTAS_RMOBUF_MAX)
>>
>> (and, _MAX? Shouldn't it be the actual size here? Or is _MAX
>> just a confusing name :-) )
>
> The original code is a lot more readable and perfectly correct for all
> possible values of rtas_rmo_buf :-)
You have to consider those possible values before you see it cannot
overflow. So no, it's a lot _less_ readable IMHO.
It's also a dangerous habit to get into. Just say no :-)
Segher
^ permalink raw reply
* Re: Re: Re: [PATCHv5] atomic: add *_dec_not_zero
From: Sven Eckelmann @ 2011-12-05 7:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-m32r-ja, linux-mips, linux-ia64, linux-doc, Heiko Carstens,
Randy Dunlap, Paul Mackerras, H. Peter Anvin, sparclinux,
linux-arch, linux-s390, Russell King - ARM Linux, Arnd Bergma nn,
linux-hexagon, Helge Deller, x86, James E.J. Bottomley,
linux-arm-kernel, Ingo Molnar, Matt Turner, Fenghua Yu,
user-mode-linux-devel, Jeff Dike, linux-alpha, Chris Metcalf,
Tony Luck, Ivan Kokshaysky, fradead.org, Thomas Gleixner,
Richard Henderson, linux-m32r, linux-parisc, b.a.t.m.a.n,
linux-kernel, Ralf Baechle, David S. Miller, Kyle McMartin,
Richard Weinberger, Martin Schwidefsky, linux390, Andrew Morton,
linuxppc-dev, Hirokazu Takata
In-Reply-To: <1323038515.11728.26.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]
On Monday 05 December 2011 09:41:55 Benjamin Herrenschmidt wrote:
> On Sun, 2011-12-04 at 22:18 +0000, Russell King - ARM Linux wrote:
>
> .../...
>
> > And really, I believe it would be a good cleanup if all the standard
> > definitions for atomic64 ops (like atomic64_add_negative) were also
> > defined in include/linux/atomic.h rather than individually in every
> > atomic*.h header throughout the kernel source, except where an arch
> > wants to explicitly override it. Yet again, virtually all architectures
> > define these in exactly the same way.
> >
> > We have more than enough code in arch/ for any architecture to worry
> > about, we don't need schemes to add more when there's simple and
> > practical solutions to avoiding doing so if the right design were
> > chosen (preferably from the outset.)
> >
> > So, I'm not going to offer my ack for a change which I don't believe
> > is the correct approach.
>
> I agree with Russell, his approach is a lot easier to maintain long run,
> we should even consider converting existing definitions.
I would rather go with "the existing definitions have to converted" and this
means "not by this patch". At the moment, the atomic64 stuff exist only as
separate generic or arch specific implementation. It is fine that Russell King
noticed that people like Arun Sharma did a lot of work to made it true for
atomic_t, but atomic64_t is a little bit different right now (at least as I
understand it).
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Re: Re: [PATCHv5] atomic: add *_dec_not_zero
From: Benjamin Herrenschmidt @ 2011-12-05 8:26 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-m32r-ja, linux-mips, linux-ia64, linux-doc, Heiko Carstens,
Randy Dunlap, Paul Mackerras, H. Peter Anvin, sparclinux,
linux-arch, linux-s390, Russell King - ARM Linux, Arnd Bergma nn,
linux-hexagon, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Matt Turner, Fenghua Yu, user-mode-linux-devel,
Jeff Dike, linux-alpha, Chris Metcalf, Tony Luck, Ivan Kokshaysky,
Thomas Gleixner, linux-arm-kernel, Richard Henderson, linux-m32r,
linux-parisc, b.a.t.m.a.n, linux-kernel, Ralf Baechle,
David S. Miller, Kyle McMartin, Richard Weinberger,
Martin Schwidefsky, linux390, Andrew Morton, linuxppc-dev,
Hirokazu Takata
In-Reply-To: <3836467.I5Tqg6MFf9@sven-laptop.home.narfation.org>
On Mon, 2011-12-05 at 08:57 +0100, Sven Eckelmann wrote:
> On Monday 05 December 2011 09:41:55 Benjamin Herrenschmidt wrote:
> > On Sun, 2011-12-04 at 22:18 +0000, Russell King - ARM Linux wrote:
> >
> > .../...
> >
> > > And really, I believe it would be a good cleanup if all the standard
> > > definitions for atomic64 ops (like atomic64_add_negative) were also
> > > defined in include/linux/atomic.h rather than individually in every
> > > atomic*.h header throughout the kernel source, except where an arch
> > > wants to explicitly override it. Yet again, virtually all architectures
> > > define these in exactly the same way.
> > >
> > > We have more than enough code in arch/ for any architecture to worry
> > > about, we don't need schemes to add more when there's simple and
> > > practical solutions to avoiding doing so if the right design were
> > > chosen (preferably from the outset.)
> > >
> > > So, I'm not going to offer my ack for a change which I don't believe
> > > is the correct approach.
> >
> > I agree with Russell, his approach is a lot easier to maintain long run,
> > we should even consider converting existing definitions.
>
> I would rather go with "the existing definitions have to converted" and this
> means "not by this patch".
Right. I didn't suggest -you- had to do it as a pre-req to your patch.
> At the moment, the atomic64 stuff exist only as
> separate generic or arch specific implementation. It is fine that Russell King
> noticed that people like Arun Sharma did a lot of work to made it true for
> atomic_t, but atomic64_t is a little bit different right now (at least as I
> understand it).
Cheers,
Ben.
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Joakim Tjernlund @ 2011-12-05 8:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Robert Richter, linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <1322198672.32635.24.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2011/11/25 06:24:32:
>
> On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
>
> > I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
> > correct backtrace but I cannot turn on frame pointers for the ppc kernel.
> > Isn't frame pointers needed for pcc? what about user space?
>
> PowerPC always has frame pointers, ignore that :-)
A bit late but consider this:
int leaf(int x)
{
return x+3;
}
which yields(with gcc -O2 -S):
.file "leaf.c"
.section ".text"
.align 2
.globl leaf
.type leaf, @function
leaf:
addi 3,3,3
blr
.size leaf, .-leaf
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
Here there is with frame pointer(I guess that the messing around with r11 and r31 is a defect?):
(With gcc -O2 -S -fno-omit-frame-pointer)
.file "leaf.c"
.section ".text"
.align 2
.globl leaf
.type leaf, @function
leaf:
stwu 1,-16(1)
addi 3,3,3
lwz 11,0(1)
stw 31,12(1)
mr 31,1
lwz 31,-4(11)
mr 1,11
blr
.size leaf, .-leaf
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Benjamin Herrenschmidt @ 2011-12-05 9:01 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Robert Richter, linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <OFE1FEF3EC.6B76BECC-ONC125795D.002F3766-C125795D.00308AEE@transmode.se>
On Mon, 2011-12-05 at 09:50 +0100, Joakim Tjernlund wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2011/11/25 06:24:32:
> >
> > On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
> >
> > > I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
> > > correct backtrace but I cannot turn on frame pointers for the ppc kernel.
> > > Isn't frame pointers needed for pcc? what about user space?
> >
> > PowerPC always has frame pointers, ignore that :-)
>
> A bit late but consider this:
.../...
Right I wasn't clear. We do have frame pointers for non-leaf functions,
and we can trace from LR when we are on a leaf function, we can use
__builtin_return_address as well.
We also explicitely prevent -fno-omit-frame-pointer, iirc, due to a bug
with older versions of gcc which could cause miscompiles under some
circumstances (though I don't remember the details).
Cheers,
Ben.
> int leaf(int x)
> {
> return x+3;
> }
>
> which yields(with gcc -O2 -S):
> .file "leaf.c"
> .section ".text"
> .align 2
> .globl leaf
> .type leaf, @function
> leaf:
> addi 3,3,3
> blr
> .size leaf, .-leaf
> .section .note.GNU-stack,"",@progbits
> .ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
>
>
> Here there is with frame pointer(I guess that the messing around with r11 and r31 is a defect?):
> (With gcc -O2 -S -fno-omit-frame-pointer)
>
> .file "leaf.c"
> .section ".text"
> .align 2
> .globl leaf
> .type leaf, @function
> leaf:
> stwu 1,-16(1)
> addi 3,3,3
> lwz 11,0(1)
> stw 31,12(1)
> mr 31,1
> lwz 31,-4(11)
> mr 1,11
> blr
> .size leaf, .-leaf
> .section .note.GNU-stack,"",@progbits
> .ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
^ permalink raw reply
* [PATCH] mmc: sdhci-pltfm: Added sdhci-adjust-timeout quirk
From: Xie Xiaobo @ 2011-12-05 8:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: avorontsov, linux-mmc, Xie Xiaobo
Some controller provides an incorrect timeout value for transfers,
So it need the quirk to adjust timeout value to 0xE.
E.g. eSDHC of MPC8536, P1010, and P2020.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
drivers/mmc/host/sdhci-pltfm.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index a9e12ea..b5d6b3f 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -2,7 +2,7 @@
* sdhci-pltfm.c Support for SDHCI platform devices
* Copyright (c) 2009 Intel Corporation
*
- * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007, 2011 Freescale Semiconductor, Inc.
* Copyright (c) 2009 MontaVista Software, Inc.
*
* Authors: Xiaobo Xie <X.Xie@freescale.com>
@@ -68,6 +68,9 @@ void sdhci_get_of_property(struct platform_device *pdev)
if (of_get_property(np, "sdhci,1-bit-only", NULL))
host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
+ if (of_get_property(np, "sdhci,sdhci-adjust-timeout", NULL))
+ host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
+
if (sdhci_of_wp_inverted(np))
host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
--
1.6.4
^ permalink raw reply related
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Amit Shah @ 2011-12-05 10:54 UTC (permalink / raw)
To: Miche Baker-Harvey
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: <CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
On (Tue) 29 Nov 2011 [09:50:41], Miche Baker-Harvey wrote:
> Good grief! Sorry for the spacing mess-up! Here's a resend with reformatting.
>
> Amit,
> We aren't using either QEMU or kvmtool, but we are using KVM. All
So it's a different userspace? Any chance this different userspace is
causing these problems to appear? Esp. since I couldn't reproduce
with qemu.
> the issues we are seeing happen when we try to establish multiple
> virtioconsoles at boot time. The 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. Here'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? control_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] control_work_handler #2
> [3371055.810245] + #2 handle_control_message CONSOLE_PORT
> [3371055.810246] got hvc_ports_mutex
> [3371055.810578] - handle_control_message PORT_ADD
> [3371055.810579] + #1 handle_control_message CONSOLE_PORT
> [3371055.810580] trylock of hvc_ports_mutex failed
> [3371055.811352] got 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. Do you plan to chase
this one down?
Amit
^ permalink raw reply
* [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Shengzhou Liu @ 2011-12-05 10:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, dwmw2, kumar.gala, linux-mtd, Shengzhou Liu
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().
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index eedd8ee..742bf73 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,8 @@ 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 fmr according to the settings in bootloader.*/
+ priv->fmr = in_be32(&lbc->fmr);
/* fill in nand_chip structure */
/* set up function call table */
--
1.6.4
^ permalink raw reply related
* [PATCH 2/2] mtd/nand: Add ONFI support for FSL NAND controller
From: Shengzhou Liu @ 2011-12-05 10:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, dwmw2, kumar.gala, linux-mtd, Shengzhou Liu
In-Reply-To: <1323082493-22617-1-git-send-email-Shengzhou.Liu@freescale.com>
- fix NAND_CMD_READID command for ONFI detect.
- add NAND_CMD_PARAM command to read the ONFI parameter page.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 742bf73..08a3aba 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) {
+ out_be32(&lbc->fbcr, 8);
+ elbc_fcm_ctrl->read_bytes = 8;
+ } else {
+ out_be32(&lbc->fbcr, 256);
+ elbc_fcm_ctrl->read_bytes = 256;
+ }
elbc_fcm_ctrl->use_mdr = 1;
- elbc_fcm_ctrl->mdr = 0;
+ elbc_fcm_ctrl->mdr = column;
set_addr(mtd, 0, 0, 0);
fsl_elbc_run_command(mtd);
--
1.6.4
^ permalink raw reply related
* RE: Re: [PATCHv5] atomic: add *_dec_not_zero
From: David Laight @ 2011-12-05 11:44 UTC (permalink / raw)
To: Russell King - ARM Linux, Sven Eckelmann
Cc: linux-m32r-ja, linux-mips, linux-ia64, linux-doc, Heiko Carstens,
Randy Dunlap, Paul Mackerras, H. Peter Anvin, sparclinux,
linux-arch, linux-s390, user-mode-linux-devel, linux-hexagon,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar, Matt Turner,
Fenghua Yu, Arnd Bergma nn, Jeff Dike, linux-alpha, Chris Metcalf,
Tony Luck, Ivan Kokshaysky, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, linux-m32r, linux-parisc, b.a.t.m.a.n,
linux-kernel, Ralf Baechle, David S. Miller, Kyle McMartin,
Richard Weinberger, Martin Schwidefsky, linux390, Andrew Morton,
linuxppc-dev, Hirokazu Takata
In-Reply-To: <20111204221850.GC14542@n2100.arm.linux.org.uk>
Looking at this:
> #ifndef atomic_inc_unless_negative
> static inline int atomic_inc_unless_negative(atomic_t *p)
> {
> int v, v1;
> for (v =3D 0; v >=3D 0; v =3D v1) {
> v1 =3D atomic_cmpxchg(p, v, v + 1);
> if (likely(v1 =3D=3D v))
> return 1;
> }
> return 0;
> }
> #endif
why is it optimised for '*p' being zero??
I'd have though the initial assignment to 'v' should
be made by reading '*p' without any memory barriers (etc).
David
^ permalink raw reply
* Re: [PATCH 0/6] RFCv2 Fix Fsl 8250 BRK bug
From: Alan Cox @ 2011-12-05 12:18 UTC (permalink / raw)
To: Paul Gortmaker
Cc: gregkh, linux-kernel, linux-serial, scottwood, linuxppc-dev
In-Reply-To: <1323042143-25330-1-git-send-email-paul.gortmaker@windriver.com>
> Anyway, have a look and see if this version of things is acceptable
> to all. (Again, the dts update from Kumar isn't shown here).
>
> Thanks to all who provided the feedback on v1.
Looks good to me
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Problem with eLBC?
From: Alexander Lyasin @ 2011-12-05 14:02 UTC (permalink / raw)
To: galak, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5705 bytes --]
Dear Kumar Gala!
Our company is a client Freescale company, we use mpc8308, mpc8321 and other
microprocessors.
I have a board on the mpc8308 chip. This board runs the Linux kernel.
On this board there is NAND flash and DSP proc. on the Local Bus.
Chunk from DTS-file is below:
localbus@e0005000 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "fsl,mpc8315-elbc", "fsl,elbc", "simple-bus";
reg = <0xe0005000 0x1000>;
interrupts = <77 0x8>;
interrupt-parent = <&ipic>;
// CS0 and CS1 are swapped when
// booting from nand, but the
// addresses are the same.
ranges = <0x0 0x0 0xfe000000 0x00800000
0x1 0x0 0xe0600000 0x00002000
0x2 0x0 0xf0000000 0x00020000
0x3 0x0 0xfa000000 0x00008000>;
nand@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8315-fcm-nand",
"fsl,elbc-fcm-nand";
reg = <0x1 0x0 0x2000>;
u-boot@0 {
reg = <0x0 0x100000>;
read-only;
label = "U-Boot-NAND";
};
dtb@100000 {
reg = <0x100000 0x40000>;
read-only;
label = "DTB-NAND";
};
kernel@140000 {
reg = <0x140000 0x200000>;
read-only;
label = "Kernel-NAND";
};
jffs2@340000 {
reg = <0x00340000 0x01c00000>;
label = "JFFS2-NAND";
};
reserve@1f40000 {
reg = <0x01f40000 0x000c0000>;
label = "Reserve";
};
};
dsp0@D0020000 {
reg = <0xD0020000 0x10000>;
interrupts = <18 0x8>;
interrupt-parent = <&ipic>;
dsp0;
};
dsp1@D0030000 {
reg = <0xD0030000 0x10000>;
interrupts = <19 0x8>;
interrupt-parent = <&ipic>;
dsp1;
};
User-level application periodically reads data from the DSP and writes the
data to the DSP via a character device. When the application is reading from
DSP or writing to the DSP, file system calls to cause errors:
[root@mpc8308-kd-124 /root]# ls -l
mtd->read(0xdc bytes from 0x8af524) returned ECC error
mtd->read(0x1fc bytes from 0x8aee04) returned ECC error
mtd->read(0xac bytes from 0x8ae554) returned ECC error
mtd->read(0x200 bytes from 0x8adc00) returned ECC error
..............
..............
...............
when writing to flash errors occur following items:
Write of 1662 bytes at 0x01935244 failed. returned -5, retlen 0
Not marking the space at 0x01935244 as dirty because the flash driver returned
retlen zero
Write of 1662 bytes at 0x01930000 failed. returned -5, retlen 0
Not marking the space at 0x01930000 as dirty because the flash driver returned
retlen zero
nand_erase: start = 0x000001c70000, len = 16384
nand_isbad_bbt(): bbt info for offs 0x01c70000: (block 1820) 0x00
nand_write_oob: to = 0x01c70000, len = 8
cannot write OOB for EB at 01930000, requested 8 bytes, read 0 bytes, error -5
I write to support this problem and I was told the following:
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.
Thank you for your interest in Freescale Semiconductor products and for
the opportunity to serve you.
Best regards.
Do you think, Kumar, how can solve this problem? Perhaps this problem is not
in eLBS?
Alexander V. Lyasin <alexander.lyasin@gmail.com>
Linux system developer
TAKT Inc
[-- Attachment #2: Type: text/html, Size: 20689 bytes --]
^ permalink raw reply
* Powerbook G4 and sound
From: Петр метель @ 2011-12-05 15:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jrnieder, alsa-devel
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
Hello,
I've got problem with sound on my Powerbook G4 Titanium
(PowerBook3,5). Sound always cranks and skips when I moving my
touchpad, regardless of the source of sound. It happens in all my
programs, including vlc, mplayer, e-uae and ioquake3 - they show in
the log messeges like "underrun occured" and "broken pipe".
If I remember correctly, this bug appears on kernel 2.6.32-5 (from
Debian Sqeeze) and later. On kernel 2.6.38 from Ubuntu sound works
_almost_ normally (cranks occur rarely).
I used also mpd server, but it breaks after sound cranks (ncmpc shows
"Timeout") and I can only restart mpd server (/etc/init.d/mpd restart)
to get mpd working (for some time).
Log from alsa-test.sh in attachement.
Sorry for my English :)
Best regards,
Петр метель
[-- Attachment #2: alsa-info.txt.zUlUP5eQPO --]
[-- Type: application/octet-stream, Size: 8046 bytes --]
upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.60
!!################################
!!Script ran on: Mon Dec 5 15:32:32 UTC 2011
!!Linux Distribution
!!------------------
Debian GNU/Linux wheezy/sid \n \l
!!DMI Information
!!---------------
Manufacturer:
Product Name:
Product Version:
!!Kernel Information
!!------------------
Kernel release: 3.1.0-1-powerpc
Operating System: GNU/Linux
Architecture: ppc
Processor: unknown
SMP Enabled: No
!!ALSA Version
!!------------
Driver version: 1.0.24
Library version: 1.0.24.1
Utilities version: 1.0.24.2
!!Loaded ALSA modules
!!-------------------
snd_powermac
!!Sound Servers on this system
!!----------------------------
No sound servers found.
!!Soundcards recognised by ALSA
!!-----------------------------
0 [Snapper ]: PMac Snapper - PowerMac Snapper
PowerMac Snapper (Dev 26) Sub-frame 0
!!PCI Soundcards installed in the system
!!--------------------------------------
!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!--------------------------------------------------------
!!Modprobe options (Sound related)
!!--------------------------------
snd-atiixp-modem: index=-2
snd-intel8x0m: index=-2
snd-via82xx-modem: index=-2
snd-pcsp: index=-2
snd-usb-audio: index=-2
!!Loaded sound module options
!!--------------------------
!!Module: snd_powermac
enable_beep : Y
id : (null)
index : -1
!!ALSA Device nodes
!!-----------------
crw-rw---T 1 root audio 116, 4 Dec 5 15:14 /dev/snd/controlC0
crw-rw---T 1 root audio 116, 3 Dec 5 15:14 /dev/snd/pcmC0D0c
crw-rw---T 1 root audio 116, 2 Dec 5 16:08 /dev/snd/pcmC0D0p
crw-rw---T 1 root audio 116, 1 Dec 5 15:14 /dev/snd/seq
crw-rw---T 1 root audio 116, 33 Dec 5 15:14 /dev/snd/timer
/dev/snd/by-path:
total 0
drwxr-xr-x 2 root root 60 Dec 5 15:14 .
drwxr-xr-x 3 root root 160 Dec 5 15:14 ..
lrwxrwxrwx 1 root root 12 Dec 5 15:14 platform-snd_powermac -> ../controlC0
!!Aplay/Arecord output
!!------------
APLAY
**** List of PLAYBACK Hardware Devices ****
card 0: Snapper [PowerMac Snapper], device 0: PMac Snapper [PowerMac Snapper]
Subdevices: 0/1
Subdevice #0: subdevice #0
ARECORD
**** List of CAPTURE Hardware Devices ****
card 0: Snapper [PowerMac Snapper], device 0: PMac Snapper [PowerMac Snapper]
Subdevices: 1/1
Subdevice #0: subdevice #0
!!Amixer output
!!-------------
!!-------Mixer controls for card 0 [Snapper]
Card hw:0 'Snapper'/'PowerMac Snapper (Dev 26) Sub-frame 0'
Mixer name : 'PowerMac Snapper'
Components : ''
Controls : 15
Simple ctrls : 14
Simple mixer control 'Master',0
Capabilities: pvolume pswitch penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 176
Mono:
Front Left: Playback 128 [73%] [on]
Front Right: Playback 128 [73%] [on]
Simple mixer control 'Headphone',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'Headphone Detection',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'Speaker',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [off]
Simple mixer control 'Bass',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 72
Mono: 0 [0%]
Simple mixer control 'Treble',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 72
Mono: 0 [0%]
Simple mixer control 'PCM',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 176
Mono:
Front Left: Playback 124 [70%]
Front Right: Playback 124 [70%]
Simple mixer control 'Mic',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 176
Mono:
Front Left: Playback 0 [0%]
Front Right: Playback 0 [0%]
Simple mixer control 'Beep',0
Capabilities: pvolume pvolume-joined penum
Playback channels: Mono
Limits: Playback 0 - 100
Mono: Playback 15 [15%]
Simple mixer control 'Auto Mute',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'DRC',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [off]
Simple mixer control 'DRC Range',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 239
Mono: 143 [60%]
Simple mixer control 'Input Source',0
Capabilities: cenum
Items: 'Line' 'Mic'
Item0: 'Line'
Simple mixer control 'Monitor Mix',0
Capabilities: volume penum
Playback channels: Front Left - Front Right
Capture channels: Front Left - Front Right
Limits: 0 - 176
Front Left: 0 [0%]
Front Right: 0 [0%]
!!Alsactl output
!!-------------
--startcollapse--
state.Snapper {
control.1 {
iface MIXER
name 'Master Playback Volume'
value.0 128
value.1 128
comment {
access 'read write'
type INTEGER
count 2
range '0 - 176'
}
}
control.2 {
iface MIXER
name 'Master Playback Switch'
value.0 true
value.1 true
comment {
access 'read write'
type BOOLEAN
count 2
}
}
control.3 {
iface MIXER
name 'PCM Playback Volume'
value.0 124
value.1 124
comment {
access 'read write'
type INTEGER
count 2
range '0 - 176'
}
}
control.4 {
iface MIXER
name 'Mic Playback Volume'
value.0 0
value.1 0
comment {
access 'read write'
type INTEGER
count 2
range '0 - 176'
}
}
control.5 {
iface MIXER
name 'Monitor Mix Volume'
value.0 0
value.1 0
comment {
access 'read write'
type INTEGER
count 2
range '0 - 176'
}
}
control.6 {
iface MIXER
name 'Tone Control - Bass'
value 0
comment {
access 'read write'
type INTEGER
count 1
range '0 - 72'
}
}
control.7 {
iface MIXER
name 'Tone Control - Treble'
value 0
comment {
access 'read write'
type INTEGER
count 1
range '0 - 72'
}
}
control.8 {
iface MIXER
name 'DRC Range'
value 143
comment {
access 'read write'
type INTEGER
count 1
range '0 - 239'
}
}
control.9 {
iface MIXER
name 'Input Source'
value Line
comment {
access 'read write'
type ENUMERATED
count 1
item.0 Line
item.1 Mic
}
}
control.10 {
iface MIXER
name 'Headphone Playback Switch'
value true
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.11 {
iface MIXER
name 'Speaker Playback Switch'
value false
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.12 {
iface MIXER
name 'DRC Switch'
value false
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.13 {
iface MIXER
name 'Auto Mute Switch'
value true
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.14 {
iface MIXER
name 'Headphone Detection'
value true
comment {
access read
type BOOLEAN
count 1
}
}
control.15 {
iface MIXER
name 'Beep Playback Volume'
value 15
comment {
access 'read write'
type INTEGER
count 1
range '0 - 100'
}
}
}
--endcollapse--
!!All Loaded Modules
!!------------------
Module
usbhid
hid
aes_generic
uinput
cpufreq_conservative
cpufreq_powersave
cpufreq_ondemand
cpufreq_userspace
cpufreq_stats
nls_utf8
hfsplus
snd_powermac
loop
firewire_sbp2
arc4
b43
mac80211
cfg80211
rfkill
bcma
rng_core
ssb
mmc_core
snd_aoa_i2sbus
snd_pcm_oss
snd_mixer_oss
snd_pcm
snd_page_alloc
snd_seq_midi
snd_rawmidi
snd_seq_midi_event
snd_seq
radeon
ttm
snd_timer
drm_kms_helper
snd_seq_device
pcmcia
evdev
snd
drm
i2c_powermac
soundcore
power_supply
snd_aoa_soundbus
yenta_socket
pcmcia_rsrc
pcmcia_core
ext4
mbcache
jbd2
crc16
sr_mod
cdrom
sd_mod
crc_t10dif
ohci_hcd
ehci_hcd
usbcore
firewire_ohci
sungem
sungem_phy
firewire_core
crc_itu_t
!!ALSA/HDA dmesg
!!------------------
^ permalink raw reply
* [PATCH] sbc834x: put full compat string in board match check
From: Paul Gortmaker @ 2011-12-05 16:41 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The commit 883c2cfc8bcc0fd00c5d9f596fb8870f481b5bda:
"fix of_flat_dt_is_compatible() to match the full compatible string"
causes silent boot death on the sbc8349 board because it was
just looking for 8349 and not 8349E -- as originally there
were non-E (no SEC/encryption) chips available. Just add the
E to the board detection string since all boards I've seen
were manufactured with the E versions.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/arch/powerpc/platforms/83xx/sbc834x.c b/arch/powerpc/platforms/83xx/sbc834x.c
index af41d8c..f5a783a 100644
--- a/arch/powerpc/platforms/83xx/sbc834x.c
+++ b/arch/powerpc/platforms/83xx/sbc834x.c
@@ -102,11 +102,11 @@ static int __init sbc834x_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- return of_flat_dt_is_compatible(root, "SBC834x");
+ return of_flat_dt_is_compatible(root, "SBC834xE");
}
define_machine(sbc834x) {
- .name = "SBC834x",
+ .name = "SBC834xE",
.probe = sbc834x_probe,
.setup_arch = sbc834x_setup_arch,
.init_IRQ = sbc834x_init_IRQ,
--
1.7.7
^ permalink raw reply related
* Re: [PATCH v3 02/10] powerpc: Consolidate mpic_alloc() OF address translation
From: Moffett, Kyle D @ 2011-12-05 18:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Mackerras, linuxppc-dev, Michael Ellerman
In-Reply-To: <6AB1179B-FB0B-4E43-AE94-43D3D6FF80CE@kernel.crashing.org>
On Dec 03, 2011, at 10:53, Kumar Gala wrote:
> On Dec 2, 2011, at 10:27 AM, Kyle Moffett wrote:
>> Instead of using the open-coded "reg" property lookup and address
>> translation in mpic_alloc(), directly call of_address_to_resource().
>> This includes various workarounds for special cases which the naive
>> of_address_translate() does not.
>>=20
>> Afterwards it is possible to remove the copiously copy-pasted calls to
>> of_address_translate() from the 85xx/86xx/powermac platforms.
>>=20
>> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> arch/powerpc/platforms/85xx/corenet_ds.c | 9 +----
>> arch/powerpc/platforms/85xx/ksi8560.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc8536_ds.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 11 +----
>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 11 +----
>> arch/powerpc/platforms/85xx/p1010rdb.c | 9 +----
>> arch/powerpc/platforms/85xx/p1022_ds.c | 9 +----
>> arch/powerpc/platforms/85xx/p1023_rds.c | 9 +----
>> arch/powerpc/platforms/85xx/sbc8548.c | 9 +----
>> arch/powerpc/platforms/85xx/sbc8560.c | 9 +----
>> arch/powerpc/platforms/85xx/socrates.c | 9 +----
>> arch/powerpc/platforms/85xx/stx_gp3.c | 9 +----
>> arch/powerpc/platforms/85xx/tqm85xx.c | 9 +----
>> arch/powerpc/platforms/85xx/xes_mpc85xx.c | 9 +----
>> arch/powerpc/platforms/86xx/pic.c | 4 +-
>> arch/powerpc/platforms/powermac/pic.c | 8 +---
>> arch/powerpc/sysdev/mpic.c | 61 ++++++++++++++++-------=
------
>> 20 files changed, 55 insertions(+), 175 deletions(-)
>=20
> What about cleaning up:
>=20
> arch/powerpc/platforms/chrp/setup.c: chrp_mpic =3D mpic_alloc(np, opad=
dr, MPIC_PRIMARY,
> arch/powerpc/platforms/embedded6xx/holly.c: mpic =3D mpic_alloc(tsi_p=
ic, mpic_paddr,
> arch/powerpc/platforms/embedded6xx/linkstation.c: mpic =3D mpic_all=
oc(dnp, paddr, MPIC_PRIMARY | MPIC
> arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c: mpic =3D mpic_all=
oc(tsi_pic, mpic_paddr,
> arch/powerpc/platforms/embedded6xx/storcenter.c: mpic =3D mpic_all=
oc(dnp, paddr, MPIC_PRIMARY | MPIC
> arch/powerpc/platforms/maple/setup.c: mpic =3D mpic_alloc(mpic_node, op=
enpic_addr, flags,
> arch/powerpc/platforms/pasemi/setup.c: mpic =3D mpic_alloc(mpic_node, op=
enpic_addr,
> arch/powerpc/platforms/pseries/setup.c: mpic =3D mpic_alloc(pSeries_mpic_=
node, openpic_addr,
>=20
> Seems like we should be able to remove the 'phys_addr' argument altogethe=
r.
Well, ideally the MPIC code would just be a OF platform_driver with a
bit of supplementary platform_data to deal with device-tree flaws.
Unfortunately it's quite a long way from that.
Some platforms seem to prefer to use a "platform-open-pic" property on
the root node instead of setting up the "reg" node of the open-pic
itself.
Furthermore, the ISU configuration seems to be board-specific. pSeries
seems to have all of the ISUs configured as additional cells in the
"platform-open-pic" property, but almost all of the rest are just
hard-coded offsets from the PIC address in the board-support code.
If it was possible to fix the device-trees on the systems with hardcoded
offsets then we could put the ISU addresses into the "platform-open-pic"
property and test that in mpic_alloc().
Otherwise there's still going to be a fair amount of hardcoding for
specific boards.
Regardless, I think this patch series is a good first cut and cleaning
up some of the more egregious code duplication there.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v3 02/10] powerpc: Consolidate mpic_alloc() OF address translation
From: Kumar Gala @ 2011-12-05 19:22 UTC (permalink / raw)
To: Moffett, Kyle D; +Cc: Paul Mackerras, linuxppc-dev, Michael Ellerman
In-Reply-To: <14B81DE9-6C77-4914-873B-050C33876FF2@boeing.com>
On Dec 5, 2011, at 12:41 PM, Moffett, Kyle D wrote:
> On Dec 03, 2011, at 10:53, Kumar Gala wrote:
>> On Dec 2, 2011, at 10:27 AM, Kyle Moffett wrote:
>>> Instead of using the open-coded "reg" property lookup and address
>>> translation in mpic_alloc(), directly call of_address_to_resource().
>>> This includes various workarounds for special cases which the naive
>>> of_address_translate() does not.
>>>=20
>>> Afterwards it is possible to remove the copiously copy-pasted calls =
to
>>> of_address_translate() from the 85xx/86xx/powermac platforms.
>>>=20
>>> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Cc: Paul Mackerras <paulus@samba.org>
>>> Cc: Grant Likely <grant.likely@secretlab.ca>
>>> Cc: Kumar Gala <galak@kernel.crashing.org>
>>> ---
>>> arch/powerpc/platforms/85xx/corenet_ds.c | 9 +----
>>> arch/powerpc/platforms/85xx/ksi8560.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc8536_ds.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 11 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 9 +----
>>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 11 +----
>>> arch/powerpc/platforms/85xx/p1010rdb.c | 9 +----
>>> arch/powerpc/platforms/85xx/p1022_ds.c | 9 +----
>>> arch/powerpc/platforms/85xx/p1023_rds.c | 9 +----
>>> arch/powerpc/platforms/85xx/sbc8548.c | 9 +----
>>> arch/powerpc/platforms/85xx/sbc8560.c | 9 +----
>>> arch/powerpc/platforms/85xx/socrates.c | 9 +----
>>> arch/powerpc/platforms/85xx/stx_gp3.c | 9 +----
>>> arch/powerpc/platforms/85xx/tqm85xx.c | 9 +----
>>> arch/powerpc/platforms/85xx/xes_mpc85xx.c | 9 +----
>>> arch/powerpc/platforms/86xx/pic.c | 4 +-
>>> arch/powerpc/platforms/powermac/pic.c | 8 +---
>>> arch/powerpc/sysdev/mpic.c | 61 =
++++++++++++++++-------------
>>> 20 files changed, 55 insertions(+), 175 deletions(-)
>>=20
>> What about cleaning up:
>>=20
>> arch/powerpc/platforms/chrp/setup.c: chrp_mpic =3D mpic_alloc(np, =
opaddr, MPIC_PRIMARY,
>> arch/powerpc/platforms/embedded6xx/holly.c: mpic =3D =
mpic_alloc(tsi_pic, mpic_paddr,
>> arch/powerpc/platforms/embedded6xx/linkstation.c: mpic =3D =
mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC
>> arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c: mpic =3D =
mpic_alloc(tsi_pic, mpic_paddr,
>> arch/powerpc/platforms/embedded6xx/storcenter.c: mpic =3D =
mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC
>> arch/powerpc/platforms/maple/setup.c: mpic =3D =
mpic_alloc(mpic_node, openpic_addr, flags,
>> arch/powerpc/platforms/pasemi/setup.c: mpic =3D =
mpic_alloc(mpic_node, openpic_addr,
>> arch/powerpc/platforms/pseries/setup.c: mpic =3D =
mpic_alloc(pSeries_mpic_node, openpic_addr,
>>=20
>> Seems like we should be able to remove the 'phys_addr' argument =
altogether.
>=20
> Well, ideally the MPIC code would just be a OF platform_driver with a
> bit of supplementary platform_data to deal with device-tree flaws.
> Unfortunately it's quite a long way from that.
>=20
> Some platforms seem to prefer to use a "platform-open-pic" property on
> the root node instead of setting up the "reg" node of the open-pic
> itself.
>=20
> Furthermore, the ISU configuration seems to be board-specific. =
pSeries
> seems to have all of the ISUs configured as additional cells in the
> "platform-open-pic" property, but almost all of the rest are just
> hard-coded offsets from the PIC address in the board-support code.
>=20
> If it was possible to fix the device-trees on the systems with =
hardcoded
> offsets then we could put the ISU addresses into the =
"platform-open-pic"
> property and test that in mpic_alloc().
>=20
> Otherwise there's still going to be a fair amount of hardcoding for
> specific boards.
>=20
> Regardless, I think this patch series is a good first cut and cleaning
> up some of the more egregious code duplication there.
>=20
> Cheers,
> Kyle Moffett
Agreed its a good first pass cleanup but it doesn't seem like we're that =
far off from remove the 'phys_addr' being passed in.
- k=
^ permalink raw reply
* Re: [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Scott Wood @ 2011-12-05 19:31 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-mtd, kumar.gala, linuxppc-dev, dwmw2
In-Reply-To: <1323082493-22617-1-git-send-email-Shengzhou.Liu@freescale.com>
On 12/05/2011 04: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().
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> drivers/mtd/nand/fsl_elbc_nand.c | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index eedd8ee..742bf73 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,8 @@ 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 fmr according to the settings in bootloader.*/
> + priv->fmr = in_be32(&lbc->fmr);
>
> /* fill in nand_chip structure */
> /* set up function call table */
We shouldn't be relying on the bootloader to provide a sane value here
-- the bootloader may not have used/initialized NAND at all.
It's sort of OK for ECCM, since unless you're trying to match an
externally programmed flash, or the bootloader uses the flash, all we
really care about is that the value stay consistent. The timeout, OTOH,
must not be set too low or things won't work.
We should just set a value that we believe to be high enough for all uses.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-12-05 19:46 UTC (permalink / raw)
To: dedekind1
Cc: Artem.Bityutskiy, dwmw2, linux-kernel, shuo.liu, linux-mtd, akpm,
linuxppc-dev
In-Reply-To: <1323067628.2316.29.camel@koala>
On 12/05/2011 12:47 AM, Artem Bityutskiy wrote:
> On Sun, 2011-12-04 at 12:31 +0800, shuo.liu@freescale.com wrote:
>> + /*
>> + * Freescale FCM controller has a 2K size limitation of buffer
>> + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
>> + * of chip is greater than 2048.
>> + * We malloc a large enough buffer (maximum page size is 16K).
>> + */
>> + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL);
>> + if (!elbc_fcm_ctrl->buffer) {
>> + dev_err(dev, "failed to allocate memory\n");
>> + mutex_unlock(&fsl_elbc_nand_mutex);
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>
> Sorry for returning to this again and agian - I do not have time to dig
> suggest you the right solutions on the one hand, you do not provide me a
> good answer on the other hand (or I forgot?).
>
> 16KiB pages do not even exist I believe.
Googling turns up some hints of it, but nothing concrete such as a
datasheet. We can assume 8K max for now and adjust it later, as the
need becomes clear.
> And you kmalloc 33KiB or RAM
17KiB, or 9KiB if we forget about 16K-page NAND.
> although in most cases you need only 5KiB. I think this is wrong -
> what is the very strong reason of wasting RAM you have?
>
> Why you cannot allocate exactly the required amount of RAM after
> 'nand_scan_ident()' finishes and you know the page size?
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.
-Scott
^ permalink raw reply
* Re: Problem with eLBC?
From: Scott Wood @ 2011-12-05 21:08 UTC (permalink / raw)
To: Alexander Lyasin; +Cc: linuxppc-dev
In-Reply-To: <201112051902.35285.alexander.lyasin@gmail.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
^ permalink raw reply
* [PATCH] rapidio/tsi721: switch to dma_zalloc_coherent
From: Alexandre Bounine @ 2011-12-05 22:33 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
Replaces pair dma_alloc_coherent()+memset() with new dma_zalloc_coherent()
added by Andrew Morton for kernel version 3.2
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
---
drivers/rapidio/devices/tsi721.c | 17 ++++-------------
1 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 5225930..514c28c 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -851,14 +851,12 @@ static int tsi721_doorbell_init(struct tsi721_device *priv)
INIT_WORK(&priv->idb_work, tsi721_db_dpc);
/* Allocate buffer for inbound doorbells queue */
- priv->idb_base = dma_alloc_coherent(&priv->pdev->dev,
+ priv->idb_base = dma_zalloc_coherent(&priv->pdev->dev,
IDB_QSIZE * TSI721_IDB_ENTRY_SIZE,
&priv->idb_dma, GFP_KERNEL);
if (!priv->idb_base)
return -ENOMEM;
- memset(priv->idb_base, 0, IDB_QSIZE * TSI721_IDB_ENTRY_SIZE);
-
dev_dbg(&priv->pdev->dev, "Allocated IDB buffer @ %p (phys = %llx)\n",
priv->idb_base, (unsigned long long)priv->idb_dma);
@@ -904,7 +902,7 @@ static int tsi721_bdma_ch_init(struct tsi721_device *priv, int chnum)
*/
/* Allocate space for DMA descriptors */
- bd_ptr = dma_alloc_coherent(&priv->pdev->dev,
+ bd_ptr = dma_zalloc_coherent(&priv->pdev->dev,
bd_num * sizeof(struct tsi721_dma_desc),
&bd_phys, GFP_KERNEL);
if (!bd_ptr)
@@ -913,8 +911,6 @@ static int tsi721_bdma_ch_init(struct tsi721_device *priv, int chnum)
priv->bdma[chnum].bd_phys = bd_phys;
priv->bdma[chnum].bd_base = bd_ptr;
- memset(bd_ptr, 0, bd_num * sizeof(struct tsi721_dma_desc));
-
dev_dbg(&priv->pdev->dev, "DMA descriptors @ %p (phys = %llx)\n",
bd_ptr, (unsigned long long)bd_phys);
@@ -922,7 +918,7 @@ static int tsi721_bdma_ch_init(struct tsi721_device *priv, int chnum)
sts_size = (bd_num >= TSI721_DMA_MINSTSSZ) ?
bd_num : TSI721_DMA_MINSTSSZ;
sts_size = roundup_pow_of_two(sts_size);
- sts_ptr = dma_alloc_coherent(&priv->pdev->dev,
+ sts_ptr = dma_zalloc_coherent(&priv->pdev->dev,
sts_size * sizeof(struct tsi721_dma_sts),
&sts_phys, GFP_KERNEL);
if (!sts_ptr) {
@@ -938,8 +934,6 @@ static int tsi721_bdma_ch_init(struct tsi721_device *priv, int chnum)
priv->bdma[chnum].sts_base = sts_ptr;
priv->bdma[chnum].sts_size = sts_size;
- memset(sts_ptr, 0, sts_size);
-
dev_dbg(&priv->pdev->dev,
"desc status FIFO @ %p (phys = %llx) size=0x%x\n",
sts_ptr, (unsigned long long)sts_phys, sts_size);
@@ -1400,7 +1394,7 @@ static int tsi721_open_outb_mbox(struct rio_mport *mport, void *dev_id,
/* Outbound message descriptor status FIFO allocation */
priv->omsg_ring[mbox].sts_size = roundup_pow_of_two(entries + 1);
- priv->omsg_ring[mbox].sts_base = dma_alloc_coherent(&priv->pdev->dev,
+ priv->omsg_ring[mbox].sts_base = dma_zalloc_coherent(&priv->pdev->dev,
priv->omsg_ring[mbox].sts_size *
sizeof(struct tsi721_dma_sts),
&priv->omsg_ring[mbox].sts_phys, GFP_KERNEL);
@@ -1412,9 +1406,6 @@ static int tsi721_open_outb_mbox(struct rio_mport *mport, void *dev_id,
goto out_desc;
}
- memset(priv->omsg_ring[mbox].sts_base, 0,
- entries * sizeof(struct tsi721_dma_sts));
-
/*
* Configure Outbound Messaging Engine
*/
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/85xx: add a 32-bit P1022DS device tree
From: Timur Tabi @ 2011-12-05 23:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <D5BD2D7D-4549-42A7-8BA6-9B3C84DB5E85@freescale.com>
Kumar Gala wrote:
> look at how mpc8572ds handles 36b.dts we put common definitions in a shared file.
Ok, I've made those changes, but when I boot the kernel, I'm seeing this. Can you give me a clue as to what's wrong?
PCI: Probing PCI hardware
pci 0000:00:00.0: [1957:0110] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0001:02:00.0: [1957:0110] type 1 class 0x000b20
pci 0001:02:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:02:00.0: supports D1 D2
pci 0001:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0001:02:00.0: PME# disabled
pci 0001:02:00.0: PCI bridge to [bus 03-ff]
pci 0002:04:00.0: [1957:0110] type 1 class 0x000b20
pci 0002:04:00.0: ignoring class b20 (doesn't match header type 01)
pci 0002:04:00.0: supports D1 D2
pci 0002:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0002:04:00.0: PME# disabled
pci 0002:05:00.0: [8086:10d3] type 0 class 0x000200
pci 0002:05:00.0: reg 10: [mem 0x80000000-0x8001ffff]
pci 0002:05:00.0: reg 14: [mem 0x80080000-0x800fffff]
pci 0002:05:00.0: reg 18: [io 0x1000-0x101f]
pci 0002:05:00.0: reg 1c: [mem 0x80100000-0x80103fff]
pci 0002:05:00.0: reg 30: [mem 0x00000000-0x0003ffff pref]
pci 0002:05:00.0: PME# supported from D0 D3hot D3cold
pci 0002:05:00.0: PME# disabled
pci 0002:04:00.0: PCI bridge to [bus 05-ff]
pci 0002:04:00.0: bridge window [mem 0x80000000-0x801fffff]
PCI: Cannot allocate resource region 0 of device 0002:05:00.0, will remap
PCI: Cannot allocate resource region 1 of device 0002:05:00.0, will remap
PCI: Cannot allocate resource region 3 of device 0002:05:00.0, will remap
PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
PCI 0001:02 Cannot reserve Legacy IO [io 0xffbdb000-0xffbdbfff]
PCI 0002:04 Cannot reserve Legacy IO [io 0xffbc9000-0xffbc9fff]
PCI: max bus depth: 1 pci_try_num: 2
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0001:02:00.0: PCI bridge to [bus 03-03]
pci 0001:02:00.0: bridge window [io 0xffbdb000-0xffbeafff]
pci 0001:02:00.0: bridge window [mem 0xc0000000-0xdfffffff]
pci 0002:04:00.0: BAR 9: can't assign mem pref (size 0x100000)
pci 0002:05:00.0: BAR 1: assigned [mem 0x80000000-0x8007ffff]
pci 0002:05:00.0: BAR 1: set to [mem 0x80000000-0x8007ffff] (PCI address [0xe000
0000-0xe007ffff])
pci 0002:05:00.0: BAR 6: assigned [mem 0x80080000-0x800bffff pref]
pci 0002:05:00.0: BAR 0: assigned [mem 0x800c0000-0x800dffff]
pci 0002:05:00.0: BAR 0: set to [mem 0x800c0000-0x800dffff] (PCI address [0xe00c
0000-0xe00dffff])
pci 0002:05:00.0: BAR 3: assigned [mem 0x800e0000-0x800e3fff]
pci 0002:05:00.0: BAR 3: set to [mem 0x800e0000-0x800e3fff] (PCI address [0xe00e
0000-0xe00e3fff])
pci 0002:04:00.0: PCI bridge to [bus 05-05]
pci 0002:04:00.0: bridge window [io 0xffbc9000-0xffbd8fff]
pci 0002:04:00.0: bridge window [mem 0x80000000-0x9fffffff]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:02:00.0: enabling device (0106 -> 0107)
pci 0002:04:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:00: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:01: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0001:02: resource 0 [io 0xffbdb000-0xffbeafff]
pci_bus 0001:02: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0001:03: resource 0 [io 0xffbdb000-0xffbeafff]
pci_bus 0001:03: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0002:04: resource 0 [io 0xffbc9000-0xffbd8fff]
pci_bus 0002:04: resource 1 [mem 0x80000000-0x9fffffff]
pci_bus 0002:05: resource 0 [io 0xffbc9000-0xffbd8fff]
pci_bus 0002:05: resource 1 [mem 0x80000000-0x9fffffff]
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* next BUG: using smp_processor_id() in preemptible
From: Hugh Dickins @ 2011-12-05 23:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec 4 20:03:19 thorn kernel: Call Trace:
Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.
Hugh
^ permalink raw reply
* "KVM: PPC: booke: Improve timer register emulation" breaks Book3s HV
From: Paul Mackerras @ 2011-12-06 4:03 UTC (permalink / raw)
To: Alexander Graf, Scott Wood; +Cc: linuxppc-dev, kvm-ppc
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.
Paul.
^ 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