* Re: [PATCH 1/3]arch:powerpc:sysdev:mpic.c Remove extra semicolon.
From: Justin Mattock @ 2011-12-15 19:26 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1112151845550.23478@pobox.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
Ill check through the commits.. Thank you for applying..
On Dec 15, 2011 9:46 AM, "Jiri Kosina" <jkosina@suse.cz> wrote:
> On Thu, 15 Dec 2011, Justin P. Mattock wrote:
>
> > what would be the status of these? should I resend/rebase to the current
> > etc?..
>
> Check linux-next, it's already there.
>
> >
> > On 11/21/2011 08:43 AM, Justin P. Mattock wrote:
> > > From: "Justin P. Mattock"<justinmattock@gmail.com>
> > >
> > > The patch below removes an extra semicolon.
> > >
> > > Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
> > > CC: linuxppc-dev@lists.ozlabs.org
> > > CC: Paul Mackerras<paulus@samba.org>
> > > ---
> > > arch/powerpc/sysdev/mpic.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > > index 8c7e852..b3fa3d7 100644
> > > --- a/arch/powerpc/sysdev/mpic.c
> > > +++ b/arch/powerpc/sysdev/mpic.c
> > > @@ -901,7 +901,7 @@ int mpic_set_irq_type(struct irq_data *d, unsigned
> int
> > > flow_type)
> > > if (vold != vnew)
> > > mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI), vnew);
> > >
> > > - return IRQ_SET_MASK_OK_NOCOPY;;
> > > + return IRQ_SET_MASK_OK_NOCOPY;
> > > }
> > >
> > > void mpic_set_vector(unsigned int virq, unsigned int vector)
> >
>
> --
> Jiri Kosina
> SUSE Labs
>
[-- Attachment #2: Type: text/html, Size: 2048 bytes --]
^ permalink raw reply
* Help needed with porting ether-net driver from ADS5121 to TWR-MPC5125
From: G.H.Lee @ 2011-12-16 0:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]
Hello, all
I am a new user of the board TWR-MPC5125 made by freescale. Now I am trying to porting the new kernel, i.e. the version 3.0.4, to this board. I have porting the serial driver and the nand flash driver successfully. And I can also mount the root file system. But I can not use the ether-net interface now. I have tried to port the ether-net driver based on the ether-net driver for ADS 5121, which is provided by the new kernel 3.0.4. The only thing I have to do in the porting is that I should change the MII mode in ADS5121 board to RMII mode in my board. And I find that I can send packages out if I use the "ping" command. But I can not receive any package for responding. And I also found that the interrupt routine for sending packages was running but the interrupt routine for receiving message was not called by the kernel. I don't know why.
Can anyone help me? Should I change some other codes beyond the ether-net driver? Someone told me that I should regulate the kernel because of the differences among the different kerenl versions if the MAC was integrated inside the SOC, which was the fatto in my board. But I don't know how to regulate.
B.T.W. : The hardware is good enough because I can use the ether net interface in u-boot and if using the kernel provided by freescale. Moreover, the u-boot is also good and I have not change it. So the ether net pins are configured correctly. But I have not porting the driver for DMA. But I think it is Ok because the "ping" command can be used correctly if using the kernel provided by freescale when I cancel the DMA driver when configuring the kernel.
Thanks.
Guohu Li
[-- Attachment #2: Type: text/html, Size: 2965 bytes --]
^ permalink raw reply
* Re: Linux port availability for p5010 processor
From: tiejun.chen @ 2011-12-16 1:57 UTC (permalink / raw)
To: Vineeth; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <CAFbQSaA6yK7d+O0C6-BguKamRcBNnsU-yimO48cQV8G_evmJjw@mail.gmail.com>
Vineeth wrote:
> found p5020_ds.c in platforms/85xx;
> why is it a part of 85xx directory ? the core of P5020 is E5500 where the
> core of 85xx is e500;
>
e5500 is e500mc-64bit Power Architecture core.
> Do we have the processor initialization code (start.S, head.S) files, port
> available with linux ?
>
So it should go head_64.S/entry_64.S with CONFIG_PPC_BOOK3E.
Tiejun
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-12-16 2:44 UTC (permalink / raw)
To: Scott Wood, dedekind1
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <4EE903CE.1010903@freescale.com>
=E4=BA=8E 2011=E5=B9=B412=E6=9C=8815=E6=97=A5 04:15, Scott Wood =E5=86=99=
=E9=81=93:
> On 12/14/2011 02:41 AM, LiuShuo wrote:
>> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=
=E9=81=93:
>>> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=
=99=E9=81=93:
>>>> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
>>>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
>>>>>> NAND chips come from the factory with bad blocks marked at a certa=
in
>>>>>> offset into each page. This offset is normally in the OOB area, b=
ut
>>>>>> since we change the layout from "4k data, 128 byte oob" to "2k
>>>>>> data, 64
>>>>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the
>>>>>> oob. On
>>>>>> first use we need to migrate the markers so that they are still in
>>>>>> the oob.
>>>>> Ah, I see, thanks. Are you planning to implement in-kernel migratio=
n or
>>>>> use a user-space tool?
>>>> That's the kind of answer I was hoping to get from Shuo. :-)
>>> OK, I try to do this. Wait for a couple of days.
>>>
>>> -LiuShuo
>> I found it's too complex to do the migration in Linux driver.
>>
>> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once =
is
>> enough.
> Any reason not to do it automatically on the first U-Boot bad block
> scan, if the flash isn't marked as already migrated?
>
> Further discussion on the details of how to do it in U-Boot should move
> to the U-Boot list.
>
>> And let user ensure it been completed before linux use the Nand flash =
chip.
> I don't want to trust the user here. It's too easy to skip it, and
> things will appear to work, but have subtle problems.
>
>> Even if we don't do the migration, the bad block also can be marked as=
bad
>> by wearing. So, do we really need to take much time to implement it ?
>> (code looks too complex.)
> It is not acceptable to ignore factory bad block markers just because
> some methods of using the flash may eventually detect an error (possibl=
y
> after data is lost -- no guarantee that the badness is ECC-correctable)
> and mark the block bad again.
>
> If you don't feel up to the task, I can look at it, but won't have time
> until January.
hi Scott,
It's really hard to me and I have much other works to do now. Thanks for=20
your help.
hi Artem,
Could this patch be applied now and we make a independent patch for bad=20
block information
migration later?
-LiuShuo
> -Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Benjamin Herrenschmidt @ 2011-12-16 3:12 UTC (permalink / raw)
To: Matthew McClintock; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <1322540669-6834-1-git-send-email-msm@freescale.com>
On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
> boot_cpuid and init_thread_info.cpu are redundant, just use the
> var that stays around longer and add a define to make boot_cpuid
> point at the correct value
>
> boot_cpudid_phys is not needed and can completly go away from the
> SMP case, we leave it there for the non-SMP case since the paca
> struct is not around to store this info
>
> This patch also has the effect of having the logical cpu number
> of the boot cpu be updated correctly independently of the ordering
> of the cpu nodes in the device tree.
So what about head_fsl_booke.S comparing boot_cpuid to -1 ? That seems
to be broken now in at least 2 ways, boot_cpuid doesn't exist anymore
and you don't initialize it to -1 either...
Cheers,
Ben.
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> v2: Fix compile issue for peries
> Remove '-1' initial value
>
> arch/powerpc/include/asm/smp.h | 2 +-
> arch/powerpc/kernel/setup_32.c | 5 +++--
> arch/powerpc/kernel/setup_64.c | 1 -
> arch/powerpc/sysdev/xics/xics-common.c | 1 +
> 4 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index adba970..f26c554 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -29,7 +29,7 @@
> #endif
> #include <asm/percpu.h>
>
> -extern int boot_cpuid;
> +#define boot_cpuid (init_thread_info.cpu)
> extern int spinning_secondaries;
>
> extern void cpu_die(void);
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> index ac76108..8d4df4c 100644
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -46,10 +46,11 @@
>
> extern void bootx_init(unsigned long r4, unsigned long phys);
>
> -int boot_cpuid = -1;
> -EXPORT_SYMBOL_GPL(boot_cpuid);
> +/* we need a place to store phys cpu for non-SMP case */
> +#ifndef CONFIG_SMP
> int boot_cpuid_phys;
> EXPORT_SYMBOL_GPL(boot_cpuid_phys);
> +#endif
>
> int smp_hw_index[NR_CPUS];
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index fb9bb46..6d0f00f 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -73,7 +73,6 @@
> #define DBG(fmt...)
> #endif
>
> -int boot_cpuid = 0;
> int __initdata spinning_secondaries;
> u64 ppc64_pft_size;
>
> diff --git a/arch/powerpc/sysdev/xics/xics-common.c b/arch/powerpc/sysdev/xics/xics-common.c
> index d72eda6..8998b7a 100644
> --- a/arch/powerpc/sysdev/xics/xics-common.c
> +++ b/arch/powerpc/sysdev/xics/xics-common.c
> @@ -20,6 +20,7 @@
> #include <linux/of.h>
> #include <linux/slab.h>
> #include <linux/spinlock.h>
> +#include <linux/sched.h>
>
> #include <asm/prom.h>
> #include <asm/io.h>
^ permalink raw reply
* Re: [PATCH v2] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: McClintock Matthew-B29882 @ 2011-12-16 3:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1324005174.4875.0.camel@pasglop>
On Thu, Dec 15, 2011 at 9:12 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
>> boot_cpuid and init_thread_info.cpu are redundant, just use the
>> var that stays around longer and add a define to make boot_cpuid
>> point at the correct value
>>
>> boot_cpudid_phys is not needed and can completly go away from the
>> SMP case, we leave it there for the non-SMP case since the paca
>> struct is not around to store this info
>>
>> This patch also has the effect of having the logical cpu number
>> of the boot cpu be updated correctly independently of the ordering
>> of the cpu nodes in the device tree.
>
> So what about head_fsl_booke.S comparing boot_cpuid to -1 ? That seems
> to be broken now in at least 2 ways, boot_cpuid doesn't exist anymore
> and you don't initialize it to -1 either...
This is 4/5 which is also waiting for your review.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-October/093474.html
-M=
^ permalink raw reply
* Re: [PATCH v2] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Benjamin Herrenschmidt @ 2011-12-16 3:35 UTC (permalink / raw)
To: McClintock Matthew-B29882
Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAEsOVNcZPH_MJUdy0q7AjwomHTZhg2DoHSV+y9xatq-2SohC2A@mail.gmail.com>
On Fri, 2011-12-16 at 03:29 +0000, McClintock Matthew-B29882 wrote:
> On Thu, Dec 15, 2011 at 9:12 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
> >> boot_cpuid and init_thread_info.cpu are redundant, just use the
> >> var that stays around longer and add a define to make boot_cpuid
> >> point at the correct value
> >>
> >> boot_cpudid_phys is not needed and can completly go away from the
> >> SMP case, we leave it there for the non-SMP case since the paca
> >> struct is not around to store this info
> >>
> >> This patch also has the effect of having the logical cpu number
> >> of the boot cpu be updated correctly independently of the ordering
> >> of the cpu nodes in the device tree.
> >
> > So what about head_fsl_booke.S comparing boot_cpuid to -1 ? That seems
> > to be broken now in at least 2 ways, boot_cpuid doesn't exist anymore
> > and you don't initialize it to -1 either...
>
> This is 4/5 which is also waiting for your review.
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-October/093474.html
Ah missed that. This is FSL specific, I'd need Kumar and/or Scott's ack
for that one.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: McClintock Matthew-B29882 @ 2011-12-16 3:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: McClintock Matthew-B29882, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1324006543.4875.1.camel@pasglop>
On Thu, Dec 15, 2011 at 9:35 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>> This is 4/5 which is also waiting for your review.
>>
>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-October/093474.html
>
> Ah missed that. This is FSL specific, I'd need Kumar and/or Scott's ack
> for that one.
I believe Kumar was waiting on your review of 5/5. I'll let you guys discus=
s.
-M=
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Amit Shah @ 2011-12-16 6:00 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: <CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> 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_intr()
> workqueue::schedule_work()
> workqueue::queue_work()
> queue_work_on(get_cpu()) <-- queues the work on the current CPU.
>
> 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.
Hi Miche,
Here's a quick-and-dirty hack that should help. I've not tested this,
and it's not yet signed-off-by. Let me know if this helps.
>From 16708fa247c0dd34aa55d78166d65e463f9be6d6 Mon Sep 17 00:00:00 2001
Message-Id: <16708fa247c0dd34aa55d78166d65e463f9be6d6.1324015123.git.amit.shah@redhat.com>
From: Amit Shah <amit.shah@redhat.com>
Date: Fri, 16 Dec 2011 11:27:04 +0530
Subject: [PATCH 1/1] virtio: console: Serialise control work
We currently allow multiple instances of the control work handler to run
in parallel. This isn't expected to work; serialise access by disabling
interrupts on new packets from the Host and enable them when all the
existing ones are consumed.
---
drivers/char/virtio_console.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8e3c46d..72d396c 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1466,6 +1466,7 @@ static void control_work_handler(struct work_struct *work)
portdev = container_of(work, struct ports_device, control_work);
vq = portdev->c_ivq;
+ start:
spin_lock(&portdev->cvq_lock);
while ((buf = virtqueue_get_buf(vq, &len))) {
spin_unlock(&portdev->cvq_lock);
@@ -1483,6 +1484,10 @@ static void control_work_handler(struct work_struct *work)
}
}
spin_unlock(&portdev->cvq_lock);
+ if (unlikely(!virtqueue_enable_cb(vq))) {
+ virtqueue_disable_cb(vq);
+ goto start;
+ }
}
static void out_intr(struct virtqueue *vq)
@@ -1533,6 +1538,7 @@ static void control_intr(struct virtqueue *vq)
{
struct ports_device *portdev;
+ virtqueue_disable_cb(vq);
portdev = vq->vdev->priv;
schedule_work(&portdev->control_work);
}
--
1.7.7.4
Amit
^ permalink raw reply related
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-12-16 17:59 UTC (permalink / raw)
To: LiuShuo
Cc: Artem.Bityutskiy, dedekind1, linuxppc-dev, linux-kernel, shuo.liu,
linux-mtd, akpm, dwmw2
In-Reply-To: <4EEAB076.30000@freescale.com>
On 12/15/2011 08:44 PM, LiuShuo wrote:
> hi Artem,
> Could this patch be applied now and we make a independent patch for bad
> block information
> migration later?
This patch is not safe to use without migration.
-Scott
^ permalink raw reply
* Re: [PATCH] phylib: update mdiobus_alloc() to allocate extra private space
From: David Miller @ 2011-12-16 20:31 UTC (permalink / raw)
To: timur; +Cc: netdev, afleming, linuxppc-dev
In-Reply-To: <1323967895-5205-1-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Thu, 15 Dec 2011 10:51:35 -0600
> Augment mdiobus_alloc() to take a parameter indicating the number of extra
> bytes to allocate for private data. Almost all callers of mdiobus_alloc()
> separately allocate a private data structure. By allowing mdiobus_alloc()
> to allocate extra memory, the two allocations can be merged into one.
>
> This patch does not change any of the callers to actually take advantage
> of this feature, however. That change can be made by the individual
> maintainers at their leisure. For now, all callers ask for zero additional
> bytes, which mimics the previous behavior.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Come on...
Not one driver even uses the new facility, and on top of it you edit
all of these drivers for no reason at all.
You could edit only two source files instead of more than 30 by simply
doing:
struct mii_bus *mdiobus_alloc_size(size_t size);
static inline struct mii_bus *mdiobus_alloc(void)
{
return mdiobus_alloc_size(0):
}
^ permalink raw reply
* Re: [PATCH] phylib: update mdiobus_alloc() to allocate extra private space
From: David Miller @ 2011-12-16 20:32 UTC (permalink / raw)
To: timur; +Cc: netdev, afleming, linuxppc-dev
In-Reply-To: <4EEA2A61.8050302@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Thu, 15 Dec 2011 11:12:01 -0600
> Andy Fleming wrote:
>> Why? Doesn't this just obfuscate things a little, while providing no immediate benefit?
>
> I see code like this frequently:
>
> bus = mdiobus_alloc();
> if (bus == NULL)
> return -ENOMEM;
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> if (priv == NULL) {
> err = -ENOMEM;
> goto out_free;
> }
> bus->priv = priv;
Where "frequently", all of the mdiobus_alloc() call sites in your patch just
get translated to pass "0" for the private size.
Make the change how I suggested, where mdiobus_alloc() retains it's current
function signature and semantics. Then you can edit drivers as needed rather
than from the beginning.
^ permalink raw reply
* Re: [PATCH] phylib: update mdiobus_alloc() to allocate extra private space
From: Timur Tabi @ 2011-12-16 20:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, afleming, linuxppc-dev
In-Reply-To: <20111216.153254.1998330487051662169.davem@davemloft.net>
David Miller wrote:
> Make the change how I suggested, where mdiobus_alloc() retains it's current
> function signature and semantics. Then you can edit drivers as needed rather
> than from the beginning.
Yes, your approach makes much more sense. I should have thought of it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Scott Wood @ 2011-12-16 21:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: McClintock Matthew-B29882, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1324006543.4875.1.camel@pasglop>
On 12/15/2011 09:35 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2011-12-16 at 03:29 +0000, McClintock Matthew-B29882 wrote:
>> On Thu, Dec 15, 2011 at 9:12 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>>> On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
>>>> boot_cpuid and init_thread_info.cpu are redundant, just use the
>>>> var that stays around longer and add a define to make boot_cpuid
>>>> point at the correct value
>>>>
>>>> boot_cpudid_phys is not needed and can completly go away from the
>>>> SMP case, we leave it there for the non-SMP case since the paca
>>>> struct is not around to store this info
>>>>
>>>> This patch also has the effect of having the logical cpu number
>>>> of the boot cpu be updated correctly independently of the ordering
>>>> of the cpu nodes in the device tree.
Where does the ordering matter currently?
>>> So what about head_fsl_booke.S comparing boot_cpuid to -1 ? That seems
>>> to be broken now in at least 2 ways, boot_cpuid doesn't exist anymore
>>> and you don't initialize it to -1 either...
>>
>> This is 4/5 which is also waiting for your review.
>>
>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-October/093474.html
>
> Ah missed that. This is FSL specific, I'd need Kumar and/or Scott's ack
> for that one.
It would be nice if we could eliminate all usage of the boot cpu dtb
field -- it's easy to forget to set it, especially if you're not making
an AMP config. The default -1 means this patch would break booting with
such a tree.
If we don't want to record the PIR of the first CPU to enter as the boot
CPU (is the concern implementations where the CPU node's reg is not the
same as what's in PIR?), how about just having a variable that gets set
before releasing secondaries? If you're in the boot entry code and that
variable is set, you're a secondary. Or, use a distinct release address
for secondaries rather than __early_start.
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Benjamin Herrenschmidt @ 2011-12-16 22:09 UTC (permalink / raw)
To: Scott Wood
Cc: McClintock Matthew-B29882, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EEBB84C.2050001@freescale.com>
On Fri, 2011-12-16 at 15:29 -0600, Scott Wood wrote:
> It would be nice if we could eliminate all usage of the boot cpu dtb
> field -- it's easy to forget to set it, especially if you're not making
> an AMP config. The default -1 means this patch would break booting with
> such a tree.
>
> If we don't want to record the PIR of the first CPU to enter as the boot
> CPU (is the concern implementations where the CPU node's reg is not the
> same as what's in PIR?), how about just having a variable that gets set
> before releasing secondaries? If you're in the boot entry code and that
> variable is set, you're a secondary. Or, use a distinct release address
> for secondaries rather than __early_start.
Of course you can only do that on processors that have a reliable
PIR :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-12-17 14:35 UTC (permalink / raw)
To: Scott Wood
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <4EE6725C.3050706@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]
On Mon, 2011-12-12 at 15:30 -0600, Scott Wood wrote:
> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
> > On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
> >> NAND chips come from the factory with bad blocks marked at a certain
> >> offset into each page. This offset is normally in the OOB area, but
> >> since we change the layout from "4k data, 128 byte oob" to "2k data, 64
> >> byte oob, 2k data, 64 byte oob" the marker is no longer in the oob. On
> >> first use we need to migrate the markers so that they are still in the oob.
> >
> > Ah, I see, thanks. Are you planning to implement in-kernel migration or
> > use a user-space tool?
>
> That's the kind of answer I was hoping to get from Shuo. :-)
>
> Most likely is a firmware-based tool, but I'd like there to be some way
> for the tool to mark that this has happened, so that the Linux driver
> can refuse to do non-raw accesses to a chip that isn't marked as having
> been migrated (or at least yell loudly in the log).
>
> Speaking of raw accesses, these are currently broken in the eLBC
> driver... we need some way for the generic layer to tell us what kind of
> access it is before the transaction starts, not once it wants to read
> out the buffer (unless we add more hacks to delay the start of a read
> transaction until first buffer access...). We'd be better off with a
> high-level "read page/write page" function that does the whole thing
> (not just buffer access, but command issuance as well).
It looks like currently you can re-define chip->read_page, so I guess
you should rework MTD and make chip->write_page re-definable?
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Artem Bityutskiy @ 2011-12-17 14:44 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: scottwood, dwmw2, kumar.gala, linuxppc-dev, linux-mtd
In-Reply-To: <1323682853-10750-1-git-send-email-Shengzhou.Liu@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
On Mon, 2011-12-12 at 17:40 +0800, 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>
Pushed both to l2-mtd-2.6.git, thanks!
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH v2] Integrated Flash Controller support
From: Artem Bityutskiy @ 2011-12-17 16:40 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org list,
Liu Shuo-B35362, linux-kernel@vger.kernel.org Kernel,
linux-mtd@lists.infradead.org, Andrew Morton, David Woodhouse
In-Reply-To: <94F013E7935FF44C83EBE7784D62AD3F056964B0@039-SN2MPN1-023.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
On Wed, 2011-12-14 at 11:13 +0000, Li Yang-R58472 wrote:
> >-----Original Message-----
> >From: Artem Bityutskiy [mailto:dedekind1@gmail.com]
> >Sent: Wednesday, November 30, 2011 4:51 PM
> >To: Kumar Gala
> >Cc: Wood Scott-B07421; Li Yang-R58472; Liu Shuo-B35362; linux-
> >kernel@vger.kernel.org Kernel; linux-mtd@lists.infradead.org; Andrew
> >Morton; David Woodhouse; linuxppc-dev@lists.ozlabs.org list
> >Subject: Re: [PATCH v2] Integrated Flash Controller support
> >
> >On Tue, 2011-11-29 at 19:47 -0600, Kumar Gala wrote:
> >> As Scott said, I was more asking about the 2nd patch in the
> sequence
> >> which did touch MTD. Since that one is dependent on this patch,
> >> wondering how we wanted to handle them.
> >
> >I do not have time to review it, but it looks OK, so I'd suggest to
> >merge it vie the same tree as the rest of the patches.
>
> Hi Artem,
>
> So what is your suggestion on this patch? Can we regard your previous
> email as an ACK and merge it through the powerpc tree? Or do you
> prefer to merge them through the MTD tree with Kumar's ACK instead?
I am fine if it is merged via PPC tree. I do not have bandwith to look
at it closely, so I cannot ack it, although I also do not have reasons
to nack it :-)
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH powerpc] fix unpaired probe_hcall_entry and probe_hcall_exit
From: Li Zhong @ 2011-12-19 2:03 UTC (permalink / raw)
To: linux-kernel; +Cc: paulmck, paulus, anton, linuxppc-dev
Unpaired calling of probe_hcall_entry and probe_hcall_exit might happen
as following, which could cause incorrect preempt count.
__trace_hcall_entry => trace_hcall_entry -> probe_hcall_entry =>
get_cpu_var => preempt_disable
__trace_hcall_exit => trace_hcall_exit -> probe_hcall_exit =>
put_cpu_var => preempt_enable
where:
A => B and A -> B means A calls B, but
=> means A will call B through function name, and B will definitely be
called.
-> means A will call B through function pointer, so B might not be
called if the function pointer is not set.
So error happens when only one of probe_hcall_entry and probe_hcall_exit
get called during a hcall.
This patch tries to move the preempt count operations from
probe_hcall_entry and probe_hcall_exit to its callers.
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hvCall_inst.c | 4 +---
arch/powerpc/platforms/pseries/lpar.c | 2 ++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c b/arch/powerpc/platforms/pseries/hvCall_inst.c
index f106662..c9311cf 100644
--- a/arch/powerpc/platforms/pseries/hvCall_inst.c
+++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
@@ -109,7 +109,7 @@ static void probe_hcall_entry(void *ignored, unsigned long opcode, unsigned long
if (opcode > MAX_HCALL_OPCODE)
return;
- h = &get_cpu_var(hcall_stats)[opcode / 4];
+ h = &__get_cpu_var(hcall_stats)[opcode / 4];
h->tb_start = mftb();
h->purr_start = mfspr(SPRN_PURR);
}
@@ -126,8 +126,6 @@ static void probe_hcall_exit(void *ignored, unsigned long opcode, unsigned long
h->num_calls++;
h->tb_total += mftb() - h->tb_start;
h->purr_total += mfspr(SPRN_PURR) - h->purr_start;
-
- put_cpu_var(hcall_stats);
}
static int __init hcall_inst_init(void)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 27a4950..dc36ea6 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -554,6 +554,7 @@ void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
goto out;
(*depth)++;
+ preempt_disable();
trace_hcall_entry(opcode, args);
(*depth)--;
@@ -576,6 +577,7 @@ void __trace_hcall_exit(long opcode, unsigned long retval,
(*depth)++;
trace_hcall_exit(opcode, retval, retbuf);
+ preempt_enable();
(*depth)--;
out:
--
1.7.5.4
^ permalink raw reply related
* [PATCH powerpc] fix unpaired __trace_hcall_entry and __trace_hcall_exit
From: Li Zhong @ 2011-12-19 2:06 UTC (permalink / raw)
To: LKML; +Cc: Paul E. McKenney, Paul Mackerras, PowerPC email list,
Anton Blanchard
Unpaired calling of __trace_hcall_entry and __trace_hcall_exit could
cause incorrect preempt count. And it might happen as the global
variable hcall_tracepoint_refcount is checked separately before calling
them.
I don't know much about the powerpc arch. But the idea here is to store
the hcall_tracepoint_refcount locally, so __trace_hcall_entry and
__trace_hcall_exit will be called or not called in pair by checking the
same value.
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hvCall.S | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S
index fd05fde..1240bd2 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -14,6 +14,7 @@
#include <asm/ptrace.h>
#define STK_PARM(i) (48 + ((i)-3)*8)
+#define REG_SIZE (2*8)
#ifdef CONFIG_TRACEPOINTS
@@ -32,11 +33,12 @@ hcall_tracepoint_refcount:
* unconditional cpu feature.
*/
#define HCALL_INST_PRECALL(FIRST_REG) \
+ std r31,-8(r1); \
BEGIN_FTR_SECTION; \
b 1f; \
END_FTR_SECTION(0, 1); \
- ld r12,hcall_tracepoint_refcount@toc(r2); \
- cmpdi r12,0; \
+ ld r31,hcall_tracepoint_refcount@toc(r2); \
+ cmpdi r31,0; \
beq+ 1f; \
mflr r0; \
std r3,STK_PARM(r3)(r1); \
@@ -49,9 +51,9 @@ END_FTR_SECTION(0, 1); \
std r10,STK_PARM(r10)(r1); \
std r0,16(r1); \
addi r4,r1,STK_PARM(FIRST_REG); \
- stdu r1,-STACK_FRAME_OVERHEAD(r1); \
+ stdu r1,-STACK_FRAME_OVERHEAD-REG_SIZE(r1); \
bl .__trace_hcall_entry; \
- addi r1,r1,STACK_FRAME_OVERHEAD; \
+ addi r1,r1,STACK_FRAME_OVERHEAD+REG_SIZE; \
ld r0,16(r1); \
ld r3,STK_PARM(r3)(r1); \
ld r4,STK_PARM(r4)(r1); \
@@ -74,8 +76,7 @@ END_FTR_SECTION(0, 1); \
BEGIN_FTR_SECTION; \
b 1f; \
END_FTR_SECTION(0, 1); \
- ld r12,hcall_tracepoint_refcount@toc(r2); \
- cmpdi r12,0; \
+ cmpdi r31,0; \
beq+ 1f; \
mflr r0; \
ld r6,STK_PARM(r3)(r1); \
@@ -83,13 +84,14 @@ END_FTR_SECTION(0, 1); \
mr r4,r3; \
mr r3,r6; \
std r0,16(r1); \
- stdu r1,-STACK_FRAME_OVERHEAD(r1); \
+ stdu r1,-STACK_FRAME_OVERHEAD-REG_SIZE(r1); \
bl .__trace_hcall_exit; \
- addi r1,r1,STACK_FRAME_OVERHEAD; \
+ addi r1,r1,STACK_FRAME_OVERHEAD+REG_SIZE; \
ld r0,16(r1); \
ld r3,STK_PARM(r3)(r1); \
mtlr r0; \
-1:
+1: \
+ ld r31,-8(r1);
#define HCALL_INST_POSTCALL_NORETS \
li r5,0; \
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
From: Benjamin Herrenschmidt @ 2011-12-19 3:00 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Michael Neuling, paulus, sukadev, linuxppc-dev
In-Reply-To: <20111208171145.3ab3c423@kryten>
On Thu, 2011-12-08 at 17:11 +1100, Anton Blanchard wrote:
> Implement a POWER7 optimised copy_to_user/copy_from_user using VMX.
> For large aligned copies this new loop is over 10% faster, and for
> large unaligned copies it is over 200% faster.
Breaks !CONFIG_ALTIVEC build an pops some WARN's with preempt & lockdep,
this seems to fix them:
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index b90b3e7..7735a2c 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -17,13 +17,14 @@ obj-$(CONFIG_HAS_IOMEM) += devres.o
obj-$(CONFIG_PPC64) += copypage_64.o copyuser_64.o \
memcpy_64.o usercopy_64.o mem_64.o string.o \
checksum_wrappers_64.o hweight_64.o \
- copyuser_power7.o copyuser_power7_vmx.o
+ copyuser_power7.o
obj-$(CONFIG_XMON) += sstep.o ldstfp.o
obj-$(CONFIG_KPROBES) += sstep.o ldstfp.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += sstep.o ldstfp.o
ifeq ($(CONFIG_PPC64),y)
obj-$(CONFIG_SMP) += locks.o
+obj-$(CONFIG_ALTIVEC) += copyuser_power7_vmx.o
endif
obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
diff --git a/arch/powerpc/lib/copyuser_power7.S b/arch/powerpc/lib/copyuser_power7.S
index 4395939..9a21b08 100644
--- a/arch/powerpc/lib/copyuser_power7.S
+++ b/arch/powerpc/lib/copyuser_power7.S
@@ -85,6 +85,7 @@
_GLOBAL(__copy_tofrom_user_power7)
+#ifdef CONFIG_ALTIVEC
cmpldi r5,16
cmpldi cr1,r5,4096
@@ -94,6 +95,15 @@ _GLOBAL(__copy_tofrom_user_power7)
blt .Lshort_copy
bgt cr1,.Lvmx_copy
+#else
+ cmpldi r5,16
+
+ std r3,48(r1)
+ std r4,56(r1)
+ std r5,64(r1)
+
+ blt .Lshort_copy
+#endif
.Lnonvmx_copy:
/* Get the source 8B aligned */
@@ -273,6 +283,7 @@ err1; stb r0,0(r3)
addi r1,r1,STACKFRAMESIZE
b .Lnonvmx_copy
+#ifdef CONFIG_ALTIVEC
.Lvmx_copy:
mflr r0
std r0,16(r1)
@@ -667,3 +678,4 @@ err3; stb r0,0(r3)
15: addi r1,r1,STACKFRAMESIZE
b .exit_vmx_copy /* tail call optimise */
+#endif /* CONFiG_ALTIVEC */
diff --git a/arch/powerpc/lib/copyuser_power7_vmx.c b/arch/powerpc/lib/copyuser_power7_vmx.c
index c37b949..6e1efad 100644
--- a/arch/powerpc/lib/copyuser_power7_vmx.c
+++ b/arch/powerpc/lib/copyuser_power7_vmx.c
@@ -26,10 +26,16 @@ int enter_vmx_copy(void)
if (in_interrupt())
return 0;
- enable_kernel_altivec();
-
+ /* This acts as preempt_disable() as well and will make
+ * enable_kernel_altivec(). We need to disable page faults
+ * as they can call schedule and thus make us lose the VMX
+ * context. So on page faults, we just fail which will cause
+ * a fallback to the normal non-vmx copy.
+ */
pagefault_disable();
+ enable_kernel_altivec();
+
return 1;
}
^ permalink raw reply related
* Re: [PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
From: Benjamin Herrenschmidt @ 2011-12-19 3:19 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Michael Neuling, paulus, sukadev, linuxppc-dev
In-Reply-To: <1324263652.30454.13.camel@pasglop>
On Mon, 2011-12-19 at 14:00 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2011-12-08 at 17:11 +1100, Anton Blanchard wrote:
> > Implement a POWER7 optimised copy_to_user/copy_from_user using VMX.
> > For large aligned copies this new loop is over 10% faster, and for
> > large unaligned copies it is over 200% faster.
>
> Breaks !CONFIG_ALTIVEC build an pops some WARN's with preempt & lockdep,
> this seems to fix them:
And it's missing another ifdef actually for !CONFIG_ALTIVEC, I'll fix it
locally and will put a fixed version in -next.
Cheers,
Ben.
^ permalink raw reply
* RapidIO Direct I/O Support?
From: Daniel Ng @ 2011-12-19 6:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 369 bytes --]
Hi,
Is there RapidIO Direct Memory I/O Support in the latest kernel?
I've seen these patches from Freescale, but it seems they were never
integrated-
http://kerneltrap.org/mailarchive/linux-netdev/2009/5/12/5686954
Does anyone know why these weren't integrated?
What is the latest state of these patches? Do they work?
Answers much appreciated....
Cheers,
Daniel
[-- Attachment #2: Type: text/html, Size: 506 bytes --]
^ permalink raw reply
* Re: Help needed with porting ether-net driver from ADS5121 to TWR-MPC5125
From: Anatolij Gustschin @ 2011-12-19 8:08 UTC (permalink / raw)
To: liguohu; +Cc: linuxppc-dev
In-Reply-To: <BLU0-SMTP14243F8B3BC45B200DD0EF8C6A00@phx.gbl>
Hi,
On Fri, 16 Dec 2011 08:38:58 +0800
G.H.Lee <liguohu@live.com> wrote:
...
> I am a new user of the board TWR-MPC5125 made by freescale. Now I am trying to porting the new kernel, i.e. the version 3.0.4, to this board. I have porting the serial driver and the nand flash driver successfully. And I can also mount the root file system. But I can not use the ether-net interface now. I have tried to port the ether-net driver based on the ether-net driver for ADS 5121, which is provided by the new kernel 3.0.4. The only thing I have to do in the porting is that I should change the MII mode in ADS5121 board to RMII mode in my board. And I find that I can send packages out if I use the "ping" command. But I can not receive any package for responding. And I also found that the interrupt routine for sending packages was running but the interrupt routine for receiving message was not called by the kernel. I don't know why.
>
> Can anyone help me? Should I change some other codes beyond the ether-net driver? Someone told me that I should regulate the kernel because of the differences among the different kerenl versions if the MAC was integrated inside the SOC, which was the fatto in my board. But I don't know how to regulate.
Please try following patch for fs_enet driver:
http://patchwork.ozlabs.org/patch/87320/
There are also other patches for TWR-MPC5125 support:
http://patchwork.ozlabs.org/patch/87925/
http://patchwork.ozlabs.org/patch/87926/
http://patchwork.ozlabs.org/patch/87321/
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Li Yang @ 2011-12-19 11:05 UTC (permalink / raw)
To: Scott Wood
Cc: Artem.Bityutskiy, dedekind1, linuxppc-dev, LiuShuo, linux-kernel,
shuo.liu, linux-mtd, akpm, dwmw2
In-Reply-To: <4EEB8704.8030201@freescale.com>
On Sat, Dec 17, 2011 at 1:59 AM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 12/15/2011 08:44 PM, LiuShuo wrote:
>> hi Artem,
>> Could this patch be applied now and we make a independent patch for =C2=
=A0bad
>> block information
>> migration later?
>
> This patch is not safe to use without migration.
Hi Scott,
We agree it's not entirely safe without migrating the bad block flag.
But let's consider two sides of the situation.
Firstly, it's only unsafe when there is a need to re-built the Bad
Block Table from scratch(old BBT broken). But currently there is no
easy way to do that(re-build BBT on demand), which means it's not a
common problem that we can easily address now.
Secondly, even if the previous said problem happens(BBT broken). We
can still recover all the data if we overrule the bad block flag.
Only the card is not so good to be used again, however, it can be used
if we take the risk of losing data from errors that ECC can't
notice(low possibility too).
Finally, I don't think this is a blocker issue but a better to have enhance=
ment.
- Leo
^ 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