Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
On Jul 22, 2010, at 4:11 PM, Ilya Yanok wrote: > 23.07.2010 1:09, Ilya Yanok wrote: >> I hope to disturb you but I haven't got any reply for my first posting... > > I shouldn't be working at night... It's 'hate' not 'hope'... > > Regards, Ilya. I have a fix, can you test? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Relocating bootwrapper causes kernel panic
>> The flat tree located at 0xbe4300 as the kerne message showed. Why >> cannot the kernel access this area? No TLB set for this area? >> >> <1>Unable to handle kernel paging request for data at address 0xc0be4308 >> <1>Faulting instruction address: 0xc01fdabc >> <4>Oops: Kernel access of bad area, sig: 11 [#1] > > Before the flat tree was accessed, I checked the DTLB and didn't find > any entry related to 0xc0be4300. After the exception, I found the > following DTLBs. > > 30 : 02 c0be4000 4KB -- -> > 31 : 00 fa00 8MB VI-S-M -> fa00 > > The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this > should be something like 00be4000? When the early_debug is enabled, the kernel can boot successfully. I checked the TLB settings and found the following. 28 : 00 c000 8MB V--S-M -> 29 : 00 fa00 8MB VI-S-M -> fa00 30 : 00 c080 8MB V--S-M -> 0080 31 : 14 04919000 ?KB V---WM -> 00e45000 So the kernel can access the dtb at 0xbe4300 because of the pinned down DTLB#30. I think the cause is clear now. But how to fix it? Two questions: 1. Should this DTLB miss exception properly set a new TLB entry for the new dtb address 0xbe4300? 2. If the DTLB miss exception handler is not the right guy to load a proper TLB entry, how can I set one entry based on the link_address and the address of the flat dt blob? Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/27] KVM PPC PV framework v3
On 08/03/2010 07:16 PM, Scott Wood wrote: On Sun, 1 Aug 2010 22:21:37 +0200 Alexander Graf wrote: On 01.08.2010, at 16:02, Avi Kivity wrote: Looks reasonable. Since it's fair to say I understand nothing about powerpc, I'd like someone who does to review it and ack, please, with an emphasis on the interfaces. Sounds good. Preferably someone with access to the ePAPR spec :). The ePAPR-relevant stuff in patches 7, 16, and 17 looks reasonable. Did I miss any ePAPR-relevant stuff in the other patches? Shall I take this as an ACK? -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Fix compile error in mpc85xx_mds.c
arch/powerpc/platforms/85xx/mpc85xx_mds.c: In function 'mpc85xx_mds_setup_arch':
arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: 'np' undeclared (first
use in this function)
arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: (Each undeclared
identifier is reported only once
arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: for each function it
appears in.)
Some code cleaned dropped need decleration of 'np'.
Signed-off-by: Kumar Gala
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index c8be7b5..ebd2b2f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -357,6 +357,7 @@ static void __init mpc85xx_mds_setup_arch(void)
{
#ifdef CONFIG_PCI
struct pci_controller *hose;
+ struct device_node *np = NULL;
#endif
dma_addr_t max = 0x;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/27] KVM PPC PV framework v3
On 05.08.2010, at 09:57, Avi Kivity wrote: > On 08/03/2010 07:16 PM, Scott Wood wrote: >> On Sun, 1 Aug 2010 22:21:37 +0200 >> Alexander Graf wrote: >> >>> On 01.08.2010, at 16:02, Avi Kivity wrote: >>> Looks reasonable. Since it's fair to say I understand nothing about powerpc, I'd like someone who does to review it and ack, please, with an emphasis on the interfaces. >>> Sounds good. Preferably someone with access to the ePAPR spec :). >> The ePAPR-relevant stuff in patches 7, 16, and 17 looks reasonable. >> Did I miss any ePAPR-relevant stuff in the other patches? > > Shall I take this as an ACK? Hollis wanted to take a look at it too. But given the fact that I have another ~10 patches lying here I'd appreciate if things could get committed. If changes are so dramatic that they'd render things incompatible, we can always just release both patches for an actual kernel release, right? Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-pci: Fix MSI support on 83xx platforms
The following commit broke 83xx because it assumed the 83xx platforms
exposed the "IMMR" address in BAR0 like the 85xx/86xx/QoriQ devices do:
commit 3da34aae03d498ee62f75aa7467de93cce3030fd
Author: Kumar Gala
Date: Tue May 12 15:51:56 2009 -0500
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
However that is not true, so we have to search through the inbound
window settings on 83xx to find which one matches the IMMR address to
determine its PCI address.
Reported-by: Ilya Yanok
Signed-off-by: Kumar Gala
---
arch/powerpc/sysdev/fsl_msi.c |9 +++
arch/powerpc/sysdev/fsl_pci.c | 43 -
arch/powerpc/sysdev/fsl_pci.h |1 +
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 962c2d8..dcd244d 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -24,6 +24,7 @@
#include
#include
#include "fsl_msi.h"
+#include "fsl_pci.h"
LIST_HEAD(msi_head);
@@ -125,13 +126,11 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int
hwirq,
{
struct fsl_msi *msi_data = fsl_msi_data;
struct pci_controller *hose = pci_bus_to_host(pdev->bus);
- u32 base = 0;
+ u64 base = fsl_pci_immrbar_base(hose);
- pci_bus_read_config_dword(hose->bus,
- PCI_DEVFN(0, 0), PCI_BASE_ADDRESS_0, &base);
+ msg->address_lo = msi_data->msi_addr_lo + lower_32_bits(base);
+ msg->address_hi = msi_data->msi_addr_hi + upper_32_bits(base);
- msg->address_lo = msi_data->msi_addr_lo + base;
- msg->address_hi = msi_data->msi_addr_hi;
msg->data = hwirq;
pr_debug("%s: allocated srs: %d, ibs: %d\n",
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 7e900ec..0c28d93 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1,7 +1,7 @@
/*
* MPC83xx/85xx/86xx PCI/PCIE support routing.
*
- * Copyright 2007-2009 Freescale Semiconductor, Inc.
+ * Copyright 2007-2010 Freescale Semiconductor, Inc.
* Copyright 2008-2009 MontaVista Software, Inc.
*
* Initial author: Xianghua Xiao
@@ -310,6 +310,16 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
}
}
+u64 fsl_pci_immrbar_base(struct pci_controller *hose)
+{
+ u32 base;
+
+ pci_bus_read_config_dword(hose->bus,
+ PCI_DEVFN(0, 0), PCI_BASE_ADDRESS_0, &base);
+
+ return base;
+}
+
int __init fsl_add_bridge(struct device_node *dev, int is_primary)
{
int len;
@@ -428,6 +438,13 @@ struct mpc83xx_pcie_priv {
u32 dev_base;
};
+struct pex_inbound_window {
+ u32 ar;
+ u32 tar;
+ u32 barl;
+ u32 barh;
+};
+
/*
* With the convention of u-boot, the PCIE outbound window 0 serves
* as configuration transactions outbound.
@@ -435,6 +452,8 @@ struct mpc83xx_pcie_priv {
#define PEX_OUTWIN0_BAR0xCA4
#define PEX_OUTWIN0_TAL0xCA8
#define PEX_OUTWIN0_TAH0xCAC
+#define PEX_RC_INWIN_BASE 0xE60
+#define PEX_RCIWARn_EN 0x1
static int mpc83xx_pcie_exclude_device(struct pci_bus *bus, unsigned int devfn)
{
@@ -461,6 +480,28 @@ static int mpc83xx_pcie_exclude_device(struct pci_bus
*bus, unsigned int devfn)
return PCIBIOS_SUCCESSFUL;
}
+/* Walk the Root Complex Inbound windows to match IMMR base */
+u64 fsl_pci_immrbar_base(struct pci_controller *hose)
+{
+ struct mpc83xx_pcie_priv *pcie = hose->dn->data;
+ struct pex_inbound_window *in = pcie->cfg_type0 + PEX_RC_INWIN_BASE;
+ int i;
+
+ for (i = 0; i < 4; i++) {
+ /* not enabled, skip */
+ if (!in_le32(&in[i].ar) & PEX_RCIWARn_EN)
+continue;
+
+ if (get_immrbase() == in_le32(&in[i].tar))
+ return (u64)in_le32(&in[i].barh) << 32 |
+ in_le32(&in[i].barl);
+ }
+
+ printk(KERN_WARNING "could not find PCI BAR matching IMMR\n");
+
+ return 0;
+}
+
static void __iomem *mpc83xx_pcie_remap_cfg(struct pci_bus *bus,
unsigned int devfn, int offset)
{
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index a9d8bbe..8ad72a1 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -88,6 +88,7 @@ struct ccsr_pci {
extern int fsl_add_bridge(struct device_node *dev, int is_primary);
extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
extern int mpc83xx_add_bridge(struct device_node *dev);
+u64 fsl_pci_immrbar_base(struct pci_controller *hose);
#endif /* __POWERPC_FSL_PCI_H */
#endif /* __KERNEL__ */
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/27] KVM PPC PV framework v3
On 08/05/2010 11:01 AM, Alexander Graf wrote: Shall I take this as an ACK? Hollis wanted to take a look at it too. But given the fact that I have another ~10 patches lying here I'd appreciate if things could get committed. If changes are so dramatic that they'd render things incompatible, we can always just release both patches for an actual kernel release, right? That's true, we have some time to get it right. Hollis, please let us know either way once you've reviewed things. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
Hi Kumar, 05.08.2010 11:01, Kumar Gala пишет: I have a fix, can you test? Surely. Where can I find it? Thanks. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/27] KVM PPC PV framework v3
On 07/29/2010 03:47 PM, Alexander Graf wrote:
On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the
hypervisor extensions.
While that is all great to show that virtualization is possible, there are
quite some cases where the emulation overhead of privileged instructions is
killing performance.
This patchset tackles exactly that issue. It introduces a paravirtual framework
using which KVM and Linux share a page to exchange register state with. That
way we don't have to switch to the hypervisor just to change a value of a
privileged register.
To prove my point, I ran the same test I did for the MMU optimizations against
the PV framework. Here are the results:
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
real0m14.659s
user0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
real0m7.557s
user0m4.121s
sys 0m3.426s
So this is a significant performance improvement! I'm quite happy how fast this
whole thing becomes :)
I tried to take all comments I've heard from people so far about such a PV
framework into account. In case you told me something before that is a no-go
and I still did it, please just tell me again.
To make use of this whole thing you also need patches to qemu and openbios. I
have them in my queue, but want to see this set upstream first before I start
sending patches to the other projects.
Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and start
experiencing the power yourself. - heh
Applied this and your follow on 7-part series, thanks.
--
error compiling committee.c: too many arguments to function
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/2] powerpc: cleanup APIs for cpu/thread/core mappings
* Benjamin Herrenschmidt [2010-08-03 14:44:13]:
> On Thu, 2010-07-22 at 06:27 +0530, Vaidyanathan Srinivasan wrote:
> > These APIs take logical cpu number as input
> > Change cpu_first_thread_in_core() to cpu_leftmost_thread_sibling()
> > Change cpu_last_thread_in_core() to cpu_rightmost_thread_sibling()
>
> I'm still not happy here.
>
> I don't find leftmost/rightmost to be a "progress" from the previous
> naming. If you really want to change to avoid in_core() at the end, then
> call them first_thread_sibling() and last_thread_sibling().
Hi Ben,
The naming is based on our discussion during the first RFC:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-April/081610.html
I am fine with first_thread_sibling() name instead of
cpu_{left,right}most_thread_sibling(). The goal is to distinguish
between APIs returning logical cpu numbers and core indexes.
first_thread_sibling() implies that the parameter and return value are
logical cpu (thread) number.
I will change the name as per your suggestion and post an update.
> Then you change:
>
> > -static inline int cpu_thread_to_core(int cpu)
> > -{
> > - return cpu >> threads_shift;
> > -}
>
> .../... to:
>
> > -/* Must be called when no change can occur to cpu_present_mask,
> > +/* Helper routines for cpu to core mapping */
> > +int cpu_core_of_thread(int cpu)
> > +{
> > + return cpu >> threads_shift;
> > +}
> > +EXPORT_SYMBOL_GPL(cpu_core_of_thread);
The cpu_core_of_thread() name implies that the return type is a core index
and not a logical cpu number.
cpu_core_of_thread(5) = 1
cpu_first_thread_of_core(1) = 4
Do you think cpu_core_number_of_thread() will explain the return type
better?
> Any reason you are making it out of line other than gratuituous
> bloat ? :-)
>
> > +int cpu_first_thread_of_core(int core)
> > +{
> > + return core << threads_shift;
> > +}
> > +EXPORT_SYMBOL_GPL(cpu_first_thread_of_core);
>
> Same.
The reason behind out of line is to avoid exporting threads_shift or
other variables like threads_per_core and have this API exported so
that modules can read them. If we make these wrapper inline, then we
will have to export the variables themselves which is not a good idea.
Thanks for the review.
--Vaidy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
* Darren Hart [2010-08-04 21:45:51]: > On 07/23/2010 12:07 AM, Vaidyanathan Srinivasan wrote: > >* Benjamin Herrenschmidt [2010-07-23 15:11:00]: > > > >>On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote: > >>>Yes. extended_cede_processor() will return with interrupts enabled in > >>>the cpu. (This is done by the hypervisor). Under normal cases we > >>>cannot be interrupted because no IO interrupts are routed to us after > >>>xics_teardown_cpu() and since the CPU is out of the map, nobody will > >>>send us IPIs. > >> > >>What about decrementer ? > > > >Decrementer expiry event handling is bit complex. The event as such > >may not bring back the extended_cede_processor() cpu, but may be > >marked pending when we get out of this state eventually. I will find > >more information on this event and update. > > Hi Vaidy, have you been able to dig anything up about the > decrementer expiry? Hi Darren, Yes, it is possible that the cpu in extended_cede_processor() can be woken up by the decrementer. But the expectation is that we will return back to this context since we will not have any pending timers. Our stack should not change even if we get the decrementer interrupts. --Vaidy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
On Wed, Aug 04, 2010 at 05:51:08PM -0500, Timur Tabi wrote: > Add support for adding "status = disabled" to an SSI node to incidate that it > is not wired on the board. This replaces the not-so-intuitive previous method > of omitting a codec-handle property. > > Signed-off-by: Timur Tabi Acked-by: Mark Brown ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
On Thu, 5 Aug 2010, Vaidyanathan Srinivasan wrote: > * Darren Hart [2010-08-04 21:45:51]: > > > On 07/23/2010 12:07 AM, Vaidyanathan Srinivasan wrote: > > >* Benjamin Herrenschmidt [2010-07-23 15:11:00]: > > > > > >>On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote: > > >>>Yes. extended_cede_processor() will return with interrupts enabled in > > >>>the cpu. (This is done by the hypervisor). Under normal cases we > > >>>cannot be interrupted because no IO interrupts are routed to us after > > >>>xics_teardown_cpu() and since the CPU is out of the map, nobody will > > >>>send us IPIs. > > >> > > >>What about decrementer ? > > > > > >Decrementer expiry event handling is bit complex. The event as such > > >may not bring back the extended_cede_processor() cpu, but may be > > >marked pending when we get out of this state eventually. I will find > > >more information on this event and update. > > > > Hi Vaidy, have you been able to dig anything up about the > > decrementer expiry? > > Hi Darren, > > Yes, it is possible that the cpu in extended_cede_processor() can be > woken up by the decrementer. But the expectation is that we will > return back to this context since we will not have any pending timers. The problem is that you might get woken _before_ the timers have been migrated away. > Our stack should not change even if we get the decrementer interrupts. But you should not execute kernel code when you got offlined either. Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
On Thu, 2010-08-05 at 12:42 +0100, Mark Brown wrote: > On Wed, Aug 04, 2010 at 05:51:08PM -0500, Timur Tabi wrote: > > Add support for adding "status = disabled" to an SSI node to incidate that > > it > > is not wired on the board. This replaces the not-so-intuitive previous > > method > > of omitting a codec-handle property. > > > > Signed-off-by: Timur Tabi > > Acked-by: Mark Brown Applied. Thanks Liam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
On Thu, Aug 05, 2010 at 12:04:26PM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2010-08-04 at 10:49 -0400, Neil Horman wrote: > > Ping yet again. Ben, This needs review/acceptance from you or Paul > > Neil > > Isn't it already in powerpc-next about to be pulled by Linus ? > Yes, there it is. Apologies. For whatever reason, I was looking on the main branch of your tree. It didn't occur to me to check your next branch. Sorry. > In general, I recommend you check the status of your patches on > patchwork. I'm nagging Jeremy to add a feature so it emails the > submitter when the patch status changes :-) > Noted, I'll remember that. Email from patchwork would be a nice feature. +1 from me. Thanks & Regards Neil > Cheers, > Ben. > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
> -Original Message- > From: linuxppc-dev-bounces+emillbrandt=dekaresearch@lists.ozlabs.org > [mailto:linuxppc-dev- > bounces+emillbrandt=dekaresearch@lists.ozlabs.org] On Behalf Of Mark > Brown > Sent: Tuesday, August 03, 2010 01:52 > To: Grant Likely > Cc: linuxppc-dev@lists.ozlabs.org; Eric Millbrandt > Subject: Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset > > On Sat, Jul 31, 2010 at 10:42:15PM -0600, Grant Likely wrote: > > On Sun, Jun 27, 2010 at 4:01 PM, Mark Brown > > > > I'm a little concerned with a collision with multi codec here. It'd > > > be handy if you could keep it separate in case it needs merging > > > into both trees (or we could merge via ASoC only). > > > Hmmm. Yeah, probably better to take it via your tree then. I've > > currently got patch 1 in linux-next, but I'll drop it before asking > > benh to pull. Go ahead and add my acked-by. > > Looks like multi-component is slightly too late for .36 and I don't have > the original patch any more since it looked like you were going to be > carrying it... could you restore the patch to your tree please? Grant, are you going to pick up this series for .36? Eric -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: ONLINE to OFFLINE CPU state transition during removal
* Nathan Fontenot [2010-07-26 14:13:35]: > On 07/22/2010 11:13 PM, Vaidyanathan Srinivasan wrote: > > * Robert Jennings [2010-07-22 21:43:44]: > > > >> If a CPU remove is attempted using the 'release' interface on hardware > >> which supports extended cede, the CPU will be put in the INACTIVE state > >> rather than the OFFLINE state due to the default preferred_offline_state > >> in that situation. In the INACTIVE state it will fail to be removed. > >> > >> This patch changes the preferred offline state to OFFLINE when an CPU is > >> in the ONLINE state. After cpu_down() is called in dlpar_offline_cpu() > >> the CPU will be OFFLINE and CPU removal can continue. > > > > Hi Robert, > > > > Thanks for the patch. In dlpar operation, we would offline the CPU > > first using the sysfs online file and then write to the sysfs release > > file to complete the sequence right? The current code in > > dlpar_offline_cpu() would work as long as the cpu is in either > > inactive state or offline state (in case of unsupported platform). > > > > Is the dlpar tools being changed to complete the operation with one > > sysfs write to release file? > > The dlpar tools were updated so that a single write to the 'release' file > would offline the cpu and remove it from the system. Given this, I think > Robert's patch should go forward to maintain compatability. Hi Nathan, Thanks for clarifying. One concern that I have is that this change could race with sysfs write to cpuN/online file. dlpar_offline_cpu() is called with cpu_hotplug_driver_lock() held so the sysfs operation on online file should wait. However by the time the cpu_hotplug_driver_unlock() happens the dlpar operation should have completed and we should not be able to online or offline the cpu from sysfs online file. I wanted to confirm whether any concurrent sysfs write will not cause the dlpar operation to fail in the middle of the operation. The previous code will work fine for platforms not supporting cede_offline where we have only two states for the cpu. When cede_offline is supported, we have three states and the state transitions are controlled by online file and the release file in two steps so that the failures can be retried in user space. This patch will work and I do not see any problem as such, but we still need to carefully evaluate the retry and error handling paths before switching over to a single sysfs write based dlpar operation. --Vaidy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
On Aug 5, 2010, at 3:24 AM, Ilya Yanok wrote: > Hi Kumar, > > 05.08.2010 11:01, Kumar Gala пишет: >> I have a fix, can you test? > > Surely. Where can I find it? > > Thanks. > > Regards, Ilya. http://patchwork.ozlabs.org/patch/60934/ - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
On Aug 4, 2010, at 5:51 PM, Timur Tabi wrote: > Add support for adding "status = disabled" to an SSI node to incidate that it > is not wired on the board. This replaces the not-so-intuitive previous method > of omitting a codec-handle property. > > Signed-off-by: Timur Tabi > --- > > Kumar, would you please ACK the device-tree portion of this patch? I want > it to go through the ALSA tree. > > arch/powerpc/boot/dts/mpc8610_hpcd.dts |1 + > sound/soc/fsl/fsl_ssi.c| 13 ++--- > 2 files changed, 11 insertions(+), 3 deletions(-) Acked-by: Kumar Gala - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
We have a long standing issues with platform devices not have a valid
dma_mask pointer. This hasn't been an issue to date as no platform
device has tried to set its dma_mask value to a non-default value.
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/platform_device.h | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/platform_device.h
b/arch/powerpc/include/asm/platform_device.h
index 01452c3..a379500 100644
--- a/arch/powerpc/include/asm/platform_device.h
+++ b/arch/powerpc/include/asm/platform_device.h
@@ -1 +1,15 @@
-#include
+#ifndef __ASM_PLATFORM_DEVICE_H_
+#define __ASM_PLATFORM_DEVICE_H_
+
+#include
+
+#define ARCH_HAS_PDEV_ARCHDATA_SETUP
+
+static inline void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+ pdev->dev.dma_mask = &pdev->archdata.dma_mask;
+
+ return;
+}
+
+#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: Dont require a dma_ops struct to set dma mask
The only reason to require a dma_ops struct is to see if it has
implemented set_dma_mask. If not we can fall back to setting the mask
directly.
This resolves an issue with how to sequence the setting of a DMA mask
for platform devices. Before we had an issue in that we have no way of
setting the DMA mask before the various low level bus notifiers get
called that might check it (swiotlb).
So now we can do:
pdev = platform_device_alloc("foobar", 0);
dma_set_mask(&pdev->dev, DMA_BIT_MASK(37));
platform_device_register(pdev);
And expect the right thing to happen with the bus notifiers get called
via platform_device_register.
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/dma-mapping.h |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index c85ef23..952208a 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -131,12 +131,10 @@ static inline int dma_set_mask(struct device *dev, u64
dma_mask)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
- if (unlikely(dma_ops == NULL))
- return -EIO;
- if (dma_ops->set_dma_mask != NULL)
- return dma_ops->set_dma_mask(dev, dma_mask);
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
+ if (dma_ops && (dma_ops->set_dma_mask != NULL))
+ return dma_ops->set_dma_mask(dev, dma_mask);
*dev->dma_mask = dma_mask;
return 0;
}
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
On some architectures we need to setup pdev_archdata before we add the device. Waiting til a bus_notifier is too late since we might need the pdev_archdata in the bus notifier. One example is setting up of dma_mask pointers such that it can be used in a bus_notifier. We add ARCH_HAS_PDEV_ARCHDATA_SETUP and a dummy header to allow the arch code to have an inline implementation of arch_setup_pdev_archdata() and being able to access the full definitions of struct device, struct platform_device, and struct pdev_archdata. Signed-off-by: Kumar Gala --- arch/alpha/include/asm/platform_device.h |1 + arch/arm/include/asm/platform_device.h|1 + arch/avr32/include/asm/platform_device.h |1 + arch/blackfin/include/asm/platform_device.h |1 + arch/cris/include/asm/platform_device.h |1 + arch/frv/include/asm/platform_device.h|1 + arch/h8300/include/asm/platform_device.h |1 + arch/ia64/include/asm/platform_device.h |1 + arch/m32r/include/asm/platform_device.h |1 + arch/m68k/include/asm/platform_device.h |1 + arch/microblaze/include/asm/platform_device.h |1 + arch/mips/include/asm/platform_device.h |1 + arch/mn10300/include/asm/platform_device.h|1 + arch/parisc/include/asm/platform_device.h |1 + arch/powerpc/include/asm/platform_device.h|1 + arch/s390/include/asm/platform_device.h |1 + arch/score/include/asm/platform_device.h |1 + arch/sh/include/asm/platform_device.h |1 + arch/sparc/include/asm/platform_device.h |1 + arch/x86/include/asm/platform_device.h|1 + arch/xtensa/include/asm/platform_device.h |1 + drivers/base/platform.c |4 include/asm-generic/platform_device.h |7 +++ 23 files changed, 32 insertions(+), 0 deletions(-) create mode 100644 arch/alpha/include/asm/platform_device.h create mode 100644 arch/arm/include/asm/platform_device.h create mode 100644 arch/avr32/include/asm/platform_device.h create mode 100644 arch/blackfin/include/asm/platform_device.h create mode 100644 arch/cris/include/asm/platform_device.h create mode 100644 arch/frv/include/asm/platform_device.h create mode 100644 arch/h8300/include/asm/platform_device.h create mode 100644 arch/ia64/include/asm/platform_device.h create mode 100644 arch/m32r/include/asm/platform_device.h create mode 100644 arch/m68k/include/asm/platform_device.h create mode 100644 arch/microblaze/include/asm/platform_device.h create mode 100644 arch/mips/include/asm/platform_device.h create mode 100644 arch/mn10300/include/asm/platform_device.h create mode 100644 arch/parisc/include/asm/platform_device.h create mode 100644 arch/powerpc/include/asm/platform_device.h create mode 100644 arch/s390/include/asm/platform_device.h create mode 100644 arch/score/include/asm/platform_device.h create mode 100644 arch/sh/include/asm/platform_device.h create mode 100644 arch/sparc/include/asm/platform_device.h create mode 100644 arch/x86/include/asm/platform_device.h create mode 100644 arch/xtensa/include/asm/platform_device.h create mode 100644 include/asm-generic/platform_device.h diff --git a/arch/alpha/include/asm/platform_device.h b/arch/alpha/include/asm/platform_device.h new file mode 100644 index 000..01452c3 --- /dev/null +++ b/arch/alpha/include/asm/platform_device.h @@ -0,0 +1 @@ +#include diff --git a/arch/arm/include/asm/platform_device.h b/arch/arm/include/asm/platform_device.h new file mode 100644 index 000..01452c3 --- /dev/null +++ b/arch/arm/include/asm/platform_device.h @@ -0,0 +1 @@ +#include diff --git a/arch/avr32/include/asm/platform_device.h b/arch/avr32/include/asm/platform_device.h new file mode 100644 index 000..01452c3 --- /dev/null +++ b/arch/avr32/include/asm/platform_device.h @@ -0,0 +1 @@ +#include diff --git a/arch/blackfin/include/asm/platform_device.h b/arch/blackfin/include/asm/platform_device.h new file mode 100644 index 000..01452c3 --- /dev/null +++ b/arch/blackfin/include/asm/platform_device.h @@ -0,0 +1 @@ +#include diff --git a/arch/cris/include/asm/platform_device.h b/arch/cris/include/asm/platform_device.h new file mode 100644 index 000..01452c3 --- /dev/null +++ b/arch/cris/include/asm/platform_device.h @@ -0,0 +1 @@ +#include diff --git a/arch/frv/include/asm/platform_device.h b/arch/frv/include/asm/platform_device.h new file mode 100644 index 000..01452c3 --- /dev/null +++ b/arch/frv/include/asm/platform_device.h @@ -0,0 +1 @@ +#include diff --git a/arch/h8300/include/asm/platform_device.h b/arch/h8300/include/asm/platform_device.h new file mode 100644 index 000..01452c3 --- /dev/null +++ b/arch/h8300/include/asm/platform_device.h @@ -0,0 +1 @@ +#include diff --git a/arch/ia64/include/asm/platform_device.h b/arch/ia64/include/asm/platform_device.h new file mode 100644 index 000..01452c3 --- /dev/null +++ b/ar
[PATCH 0/3] driver core: Add ability for arch code to setup pdev_archdata
On PPC we need to set the dma_mask pointer for platform_devices to point to the pdev_archdata. We can't wait for a bus_notifier as we need the dma_mask setup before the platform_device_add happens so that the bus_notifiers can check the dma_mask to determine if we need things like the SWIOTLB dma_ops. The patch series introduces an arch specific call out (arch_setup_pdev_archdata) and provide an implementation on PPC to handle our specific issue. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
Hi Kumar,
On Thu, 5 Aug 2010 10:15:45 -0500 Kumar Gala wrote:
>
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include "base.h"
>
> @@ -170,6 +171,9 @@ struct platform_device *platform_device_alloc(const char
> *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> +#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
> + arch_setup_pdev_archdata(&pa->pdev);
> +#endif
> }
>
> return pa ? &pa->pdev : NULL;
> diff --git a/include/asm-generic/platform_device.h
> b/include/asm-generic/platform_device.h
> new file mode 100644
> index 000..64806dc
> --- /dev/null
> +++ b/include/asm-generic/platform_device.h
> @@ -0,0 +1,7 @@
> +#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
> +#define __ASM_GENERIC_PLATFORM_DEVICE_H_
> +/*
> + * an architecture can override to define arch_setup_pdev_archdata
> + */
> +
> +#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
Why not do:
#include
#ifndef arch_setup_pdev_archdata
static inline void arch_setup_pdev_archdata(struct platform_device *pdev) { }
#endif
in asm-generic/platform-device.h
and the the call in platform_device_alloc() can be unconditional. If the arch
wants to override arch_setup_pdev_archdata, it defines the function and then
does
#define arch_setup_pdev_archdata arch_setup_pdev_archdata
before still including asm-generic/platform_device.h
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpSkm1jKhLGJ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
Hi Kumar,
On Thu, 5 Aug 2010 10:15:46 -0500 Kumar Gala wrote:
>
> +static inline void arch_setup_pdev_archdata(struct platform_device *pdev)
> +{
> + pdev->dev.dma_mask = &pdev->archdata.dma_mask;
> +
> + return;
> +}
The blank line and "return;" don't add anything.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpuxNjakiLhv.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: implement arch_setup_pdev_archdata
On Aug 5, 2010, at 10:44 AM, Stephen Rothwell wrote:
> Hi Kumar,
>
> On Thu, 5 Aug 2010 10:15:46 -0500 Kumar Gala
> wrote:
>>
>> +static inline void arch_setup_pdev_archdata(struct platform_device *pdev)
>> +{
>> +pdev->dev.dma_mask = &pdev->archdata.dma_mask;
>> +
>> +return;
>> +}
>
> The blank line and "return;" don't add anything.
Will fix.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
On Aug 5, 2010, at 10:43 AM, Stephen Rothwell wrote:
> Hi Kumar,
>
> On Thu, 5 Aug 2010 10:15:45 -0500 Kumar Gala
> wrote:
>>
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -19,6 +19,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "base.h"
>>
>> @@ -170,6 +171,9 @@ struct platform_device *platform_device_alloc(const char
>> *name, int id)
>> pa->pdev.id = id;
>> device_initialize(&pa->pdev.dev);
>> pa->pdev.dev.release = platform_device_release;
>> +#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
>> +arch_setup_pdev_archdata(&pa->pdev);
>> +#endif
>> }
>>
>> return pa ? &pa->pdev : NULL;
>> diff --git a/include/asm-generic/platform_device.h
>> b/include/asm-generic/platform_device.h
>> new file mode 100644
>> index 000..64806dc
>> --- /dev/null
>> +++ b/include/asm-generic/platform_device.h
>> @@ -0,0 +1,7 @@
>> +#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
>> +#define __ASM_GENERIC_PLATFORM_DEVICE_H_
>> +/*
>> + * an architecture can override to define arch_setup_pdev_archdata
>> + */
>> +
>> +#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
>
> Why not do:
>
> #include
>
> #ifndef arch_setup_pdev_archdata
> static inline void arch_setup_pdev_archdata(struct platform_device *pdev) { }
> #endif
>
> in asm-generic/platform-device.h
>
> and the the call in platform_device_alloc() can be unconditional. If the
> arch wants to override arch_setup_pdev_archdata, it defines the function and
> then does
>
> #define arch_setup_pdev_archdata arch_setup_pdev_archdata
>
> before still including asm-generic/platform_device.h
I've got no issues with the style change.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linux-next] build failure
divya wrote: Yestersday's linux-next(2.6.35_next_20100802) build fails with the following error on both system p and x. drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_select_queue': drivers/net/ixgbe/ixgbe_main.c:6159: error: 'struct ixgbe_fcoe' has no member named 'up' drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_xmit_frame': drivers/net/ixgbe/ixgbe_main.c:6221: error: 'struct ixgbe_fcoe' has no member named 'up' make[3]: *** [drivers/net/ixgbe/ixgbe_main.o] Error 1 make[2]: *** [drivers/net/ixgbe] Error 2 make[2]: *** Waiting for unfinished jobs make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Thanks Divya Hi Divya, Jeff should have a fix for this in his queue already. This is caused by building with CONFIG_FCOE and without CONFIG_IXGBE_DCB. Thanks, John. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 17/27] KVM: PPC: KVM PV guest stubs
On 07/29/2010 05:47 AM, Alexander Graf wrote:
We will soon start and replace instructions from the text section with
other, paravirtualized versions. To ease the readability of those patches
I split out the generic looping and magic page mapping code out.
This patch still only contains stubs. But at least it loops through the
text section :).
Signed-off-by: Alexander Graf
---
v1 -> v2:
- kvm guest patch framework: introduce patch_ins
v2 -> v3:
- add self-test in guest code
- remove superfluous new lines in generic guest code
---
arch/powerpc/kernel/kvm.c | 95 +
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
index a5ece71..e93366f 100644
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -33,6 +33,62 @@
#define KVM_MAGIC_PAGE(-4096L)
#define magic_var(x) KVM_MAGIC_PAGE + offsetof(struct kvm_vcpu_arch_shared, x)
+#define KVM_MASK_RT0x03e0
+
+static bool kvm_patching_worked = true;
+
+static inline void kvm_patch_ins(u32 *inst, u32 new_inst)
+{
+ *inst = new_inst;
+ flush_icache_range((ulong)inst, (ulong)inst + 4);
+}
+
+static void kvm_map_magic_page(void *data)
+{
+ kvm_hypercall2(KVM_HC_PPC_MAP_MAGIC_PAGE,
+ KVM_MAGIC_PAGE, /* Physical Address */
+ KVM_MAGIC_PAGE); /* Effective Address */
+}
+
+static void kvm_check_ins(u32 *inst)
+{
+ u32 _inst = *inst;
+ u32 inst_no_rt = _inst& ~KVM_MASK_RT;
+ u32 inst_rt = _inst& KVM_MASK_RT;
+
+ switch (inst_no_rt) {
+ }
+
+ switch (_inst) {
+ }
+}
+
+static void kvm_use_magic_page(void)
+{
+ u32 *p;
+ u32 *start, *end;
+ u32 tmp;
+
+ /* Tell the host to map the magic page to -4096 on all CPUs */
+ on_each_cpu(kvm_map_magic_page, NULL, 1);
+
+ /* Quick self-test to see if the mapping works */
+ if (__get_user(tmp, (u32*)KVM_MAGIC_PAGE)) {
+ kvm_patching_worked = false;
+ return;
+ }
+
+ /* Now loop through all code and find instructions */
+ start = (void*)_stext;
+ end = (void*)_etext;
+
+ for (p = start; p< end; p++)
+ kvm_check_ins(p);
+
+ printk(KERN_INFO "KVM: Live patching for a fast VM %s\n",
+kvm_patching_worked ? "worked" : "failed");
+}
Rather than have the guest loop through every instruction in its text,
why can't you use the existing cputable self-patching mechanism? The
kernel already uses that in a number of places to patch itself at
runtime in fast paths... see Documentation/powerpc/cpu_features.txt for
some background.
Since we already know (at build time) the location of code that needs
patching, we don't need to scan at all. (I also shudder to think of the
number of page faults this scan will incur.)
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
Below is a copy of Leo's message with pointers to the patches. Alex. >Subject: [PATCH] RapidIO,powerpc/85xx: remove MCSR_MASK in fsl_rio > >Fixes compile problem caused by MCSR_MASK removal from book-E definitions. Hi Alex, Only with your patch, there will still be problem on SRIO platforms other than MPC85xx. I have posted a patch series to fix this together with several compatibility issues a month before. http://patchwork.ozlabs.org/patch/56135/ http://patchwork.ozlabs.org/patch/56136/ http://patchwork.ozlabs.org/patch/56138/ http://patchwork.ozlabs.org/patch/56137/ Can anyone pick the patch series quickly as currently there is a compile error when SRIO is enabled. - Leo > -Original Message- > From: Michael Neuling [mailto:mi...@neuling.org] > Sent: Wednesday, August 04, 2010 11:34 PM > To: Bounine, Alexandre > Cc: Timur Tabi; Alexandre Bounine; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; > thomas.m...@sysgo.com; Kumar Gala > Subject: Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port > > > > In message <0ce8b6be3c4ad74ab97d9d29bd24e55201143...@corpexch1.na.ads.idt.com> you wrote: > > Yang Li pointed to these patches in his post from July 23, 2010. > > It would be nice to have these patches in mainline code.=20 > > This is still broken in Kumar's latest tree. Do you guys wanna repost > them so Kumar can pick them up easily? > > Mikey > > > > > > -Original Message- > > > From: timur.t...@gmail.com [mailto:timur.t...@gmail.com] On Behalf Of > > Timur Tabi > > > Sent: Tuesday, August 03, 2010 9:02 AM > > > To: Bounine, Alexandre > > > Cc: Michael Neuling; Alexandre Bounine; linuxppc-dev@lists.ozlabs.org; > > linux-ker...@vger.kernel.org; > > > thomas.m...@sysgo.com; Kumar Gala > > > Subject: Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO > > port > > >=20 > > > On Tue, Aug 3, 2010 at 7:17 AM, Bounine, Alexandre > > > wrote: > > > > This happened after change to book-e definitions. > > > > There are patches that address this issue. > > >=20 > > > And those patches should have been applied before 2.6.35 was released. > > > Someone dropped the ball. 2.6.35 is broken for a number of PowerPC > > > boards: > > >=20 > > > $ make mpc85xx_defconfig > > > > > > $ make > > > > > > CC arch/powerpc/sysdev/fsl_rio.o > > > arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': > > > arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared > > > (first use in this function) > > > arch/powerpc/sysdev/fsl_rio.c:248: error: (Each undeclared identifier > > > is reported only once > > > arch/powerpc/sysdev/fsl_rio.c:248: error: for each function it appears > > in.) > > > make[1]: *** [arch/powerpc/sysdev/fsl_rio.o] Error 1 > > >=20 > > > -- > > > Timur Tabi > > > Linux kernel developer at Freescale > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/27] KVM: PPC: Introduce shared page
On 07/29/2010 05:47 AM, Alexander Graf wrote:
For transparent variable sharing between the hypervisor and guest, I introduce
a shared page. This shared page will contain all the registers the guest can
read and write safely without exiting guest context.
This patch only implements the stubs required for the basic structure of the
shared page. The actual register moving follows.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_host.h |2 ++
arch/powerpc/include/asm/kvm_para.h |5 +
arch/powerpc/kernel/asm-offsets.c |1 +
arch/powerpc/kvm/44x.c |7 +++
arch/powerpc/kvm/book3s.c |9 -
arch/powerpc/kvm/e500.c |7 +++
6 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index b0b23c0..53edacd 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#define KVM_MAX_VCPUS 1
@@ -290,6 +291,7 @@ struct kvm_vcpu_arch {
struct tasklet_struct tasklet;
u64 dec_jiffies;
unsigned long pending_exceptions;
+ struct kvm_vcpu_arch_shared *shared;
#ifdef CONFIG_PPC_BOOK3S
struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE];
diff --git a/arch/powerpc/include/asm/kvm_para.h
b/arch/powerpc/include/asm/kvm_para.h
index 2d48f6a..1485ba8 100644
--- a/arch/powerpc/include/asm/kvm_para.h
+++ b/arch/powerpc/include/asm/kvm_para.h
@@ -20,6 +20,11 @@
#ifndef __POWERPC_KVM_PARA_H__
#define __POWERPC_KVM_PARA_H__
+#include
+
+struct kvm_vcpu_arch_shared {
+};
+
#ifdef __KERNEL__
static inline int kvm_para_available(void)
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 496cc5b..944f593 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -400,6 +400,7 @@ int main(void)
DEFINE(VCPU_SPRG6, offsetof(struct kvm_vcpu, arch.sprg6));
DEFINE(VCPU_SPRG7, offsetof(struct kvm_vcpu, arch.sprg7));
DEFINE(VCPU_SHADOW_PID, offsetof(struct kvm_vcpu, arch.shadow_pid));
+ DEFINE(VCPU_SHARED, offsetof(struct kvm_vcpu, arch.shared));
/* book3s */
#ifdef CONFIG_PPC_BOOK3S
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 73c0a3f..e7b1f3f 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -123,8 +123,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm,
unsigned int id)
if (err)
goto free_vcpu;
+ vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+ if (!vcpu->arch.shared)
+ goto uninit_vcpu;
+
return vcpu;
+uninit_vcpu:
+ kvm_vcpu_uninit(vcpu);
free_vcpu:
kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
out:
@@ -135,6 +141,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
{
struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
+ free_page((unsigned long)vcpu->arch.shared);
kvm_vcpu_uninit(vcpu);
kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
}
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index a3cef30..b3385dd 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -1242,6 +1242,10 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm
*kvm, unsigned int id)
if (err)
goto free_shadow_vcpu;
+ vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+ if (!vcpu->arch.shared)
+ goto uninit_vcpu;
+
vcpu->arch.host_retip = kvm_return_point;
vcpu->arch.host_msr = mfmsr();
#ifdef CONFIG_PPC_BOOK3S_64
@@ -1268,10 +1272,12 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm
*kvm, unsigned int id)
err = kvmppc_mmu_init(vcpu);
if (err< 0)
- goto free_shadow_vcpu;
+ goto uninit_vcpu;
return vcpu;
+uninit_vcpu:
+ kvm_vcpu_uninit(vcpu);
free_shadow_vcpu:
kfree(vcpu_book3s->shadow_vcpu);
free_vcpu:
@@ -1284,6 +1290,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
{
struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
+ free_page((unsigned long)vcpu->arch.shared);
kvm_vcpu_uninit(vcpu);
kfree(vcpu_book3s->shadow_vcpu);
vfree(vcpu_book3s);
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index e8a00b0..71750f2 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -117,8 +117,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm,
unsigned int id)
if (err)
goto uninit_vcpu;
+ vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+ if (!vcpu->arch.shared)
+ goto uninit_tlb;
+
return vcpu;
+uninit_tlb:
+ kvmppc_e500_tlb_uninit(vcpu_e500);
uninit_vcpu:
kvm_vcpu_uninit(vcpu);
free_vcp
Re: Relocating bootwrapper causes kernel panic
On Thu, 5 Aug 2010 00:23:17 -0700 Shawn Jin wrote: > >> The flat tree located at 0xbe4300 as the kerne message showed. Why > >> cannot the kernel access this area? No TLB set for this area? > >> > >> <1>Unable to handle kernel paging request for data at address 0xc0be4308 > >> <1>Faulting instruction address: 0xc01fdabc > >> <4>Oops: Kernel access of bad area, sig: 11 [#1] > > > > Before the flat tree was accessed, I checked the DTLB and didn't find > > any entry related to 0xc0be4300. After the exception, I found the > > following DTLBs. > > > > 30 : 02 c0be4000 4KB -- -> > > 31 : 00 fa00 8MB VI-S-M -> fa00 > > > > The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this > > should be something like 00be4000? Note that the valid bit is clear -- it's not mapping to anything. > When the early_debug is enabled, the kernel can boot successfully. I > checked the TLB settings and found the following. > > 28 : 00 c000 8MB V--S-M -> > 29 : 00 fa00 8MB VI-S-M -> fa00 > 30 : 00 c080 8MB V--S-M -> 0080 > 31 : 14 04919000 ?KB V---WM -> 00e45000 That last entry looks weird... might want to look into that. > So the kernel can access the dtb at 0xbe4300 because of the pinned down > DTLB#30. > > I think the cause is clear now. But how to fix it? Two questions: > 1. Should this DTLB miss exception properly set a new TLB entry for > the new dtb address 0xbe4300? Not if it doesn't find an entry in the page tables. > 2. If the DTLB miss exception handler is not the right guy to load a > proper TLB entry, how can I set one entry based on the link_address > and the address of the flat dt blob? Given how early in the boot process it is, it's probably going to need to be handled specially. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] fsl_rio: fix compile errors
On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
> Fixes the following compile problem on E500 platforms:
> arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
> arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared (first use
> in this function)
>
> Also fixes the compile problem on non-E500 platforms.
>
> Signed-off-by: Li Yang
> ---
> arch/powerpc/sysdev/fsl_rio.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
I'm confused is this handler not relevant for e500MC? The 2nd patch makes me
thing it is.
>
> diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
> index 30e1626..f908ba6 100644
> --- a/arch/powerpc/sysdev/fsl_rio.c
> +++ b/arch/powerpc/sysdev/fsl_rio.c
> @@ -240,12 +240,13 @@ struct rio_priv {
>
> static void __iomem *rio_regs_win;
>
> +#ifdef CONFIG_E500
> static int (*saved_mcheck_exception)(struct pt_regs *regs);
>
> static int fsl_rio_mcheck_exception(struct pt_regs *regs)
> {
> const struct exception_table_entry *entry = NULL;
> - unsigned long reason = (mfspr(SPRN_MCSR) & MCSR_MASK);
> + unsigned long reason = mfspr(SPRN_MCSR);
>
> if (reason & MCSR_BUS_RBERR) {
> reason = in_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR));
> @@ -269,6 +270,7 @@ static int fsl_rio_mcheck_exception(struct pt_regs *regs)
> else
> return cur_cpu_spec->machine_check(regs);
> }
> +#endif
>
> /**
> * fsl_rio_doorbell_send - Send a MPC85xx doorbell message
> @@ -1517,8 +1519,10 @@ int fsl_rio_setup(struct of_device *dev)
> fsl_rio_doorbell_init(port);
> fsl_rio_port_write_init(port);
>
> +#ifdef CONFIG_E500
> saved_mcheck_exception = ppc_md.machine_check_exception;
> ppc_md.machine_check_exception = fsl_rio_mcheck_exception;
> +#endif
> /* Ensure that RFXE is set */
> mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2));
>
> --
> 1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Correct smt_enabled=X boot option for > 2 threads per core
The 'smt_enabled=X' boot option does not handle values of X > 2.
For Power 7 processors with smt modes of 0,1,2,3, and 4 this does
not work. This patch allows the smt_enabled option to be set to
any value limited to a max equal to the number of threads per
core.
Signed-off-by: Nathan Fontenot
---
arch/powerpc/kernel/setup_64.c | 61 ---
arch/powerpc/platforms/pseries/smp.c | 11 --
2 files changed, 42 insertions(+), 30 deletions(-)
Index: powerpc/arch/powerpc/kernel/setup_64.c
===
--- powerpc.orig/arch/powerpc/kernel/setup_64.c 2010-08-05 10:57:04.0
-0500
+++ powerpc/arch/powerpc/kernel/setup_64.c 2010-08-05 11:20:49.0
-0500
@@ -95,7 +95,7 @@ int ucache_bsize;
#ifdef CONFIG_SMP
-static int smt_enabled_cmdline;
+static char *smt_enabled_cmdline;
/* Look for ibm,smt-enabled OF option */
static void check_smt_enabled(void)
@@ -103,37 +103,46 @@ static void check_smt_enabled(void)
struct device_node *dn;
const char *smt_option;
- /* Allow the command line to overrule the OF option */
- if (smt_enabled_cmdline)
- return;
-
- dn = of_find_node_by_path("/options");
+ /* Default to enabling all threads */
+ smt_enabled_at_boot = threads_per_core;
- if (dn) {
- smt_option = of_get_property(dn, "ibm,smt-enabled", NULL);
+ /* Allow the command line to overrule the OF option */
+ if (smt_enabled_cmdline) {
+ if (!strcmp(smt_enabled_cmdline, "on"))
+ smt_enabled_at_boot = threads_per_core;
+ else if (!strcmp(smt_enabled_cmdline, "off"))
+ smt_enabled_at_boot = 0;
+ else {
+ long smt;
+ int rc;
+
+ rc = strict_strtol(smt_enabled_cmdline, 10, &smt);
+ if (!rc)
+ smt_enabled_at_boot =
+ min(threads_per_core, (int)smt);
+ }
+ } else {
+ dn = of_find_node_by_path("/options");
+ if (dn) {
+ smt_option = of_get_property(dn, "ibm,smt-enabled",
+NULL);
+
+ if (smt_option) {
+ if (!strcmp(smt_option, "on"))
+ smt_enabled_at_boot = threads_per_core;
+ else if (!strcmp(smt_option, "off"))
+ smt_enabled_at_boot = 0;
+ }
-if (smt_option) {
- if (!strcmp(smt_option, "on"))
- smt_enabled_at_boot = 1;
- else if (!strcmp(smt_option, "off"))
- smt_enabled_at_boot = 0;
-}
-}
+ of_node_put(dn);
+ }
+ }
}
/* Look for smt-enabled= cmdline option */
static int __init early_smt_enabled(char *p)
{
- smt_enabled_cmdline = 1;
-
- if (!p)
- return 0;
-
- if (!strcmp(p, "on") || !strcmp(p, "1"))
- smt_enabled_at_boot = 1;
- else if (!strcmp(p, "off") || !strcmp(p, "0"))
- smt_enabled_at_boot = 0;
-
+ smt_enabled_cmdline = p;
return 0;
}
early_param("smt-enabled", early_smt_enabled);
@@ -390,8 +399,8 @@ void __init setup_system(void)
*/
xmon_setup();
- check_smt_enabled();
smp_setup_cpu_maps();
+ check_smt_enabled();
#ifdef CONFIG_SMP
/* Release secondary cpus out of their spinloops at 0x60 now that
Index: powerpc/arch/powerpc/platforms/pseries/smp.c
===
--- powerpc.orig/arch/powerpc/platforms/pseries/smp.c 2010-06-14
08:36:05.0 -0500
+++ powerpc/arch/powerpc/platforms/pseries/smp.c2010-08-05
11:20:49.0 -0500
@@ -182,10 +182,13 @@ static int smp_pSeries_cpu_bootable(unsi
/* Special case - we inhibit secondary thread startup
* during boot if the user requests it.
*/
- if (system_state < SYSTEM_RUNNING &&
- cpu_has_feature(CPU_FTR_SMT) &&
- !smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
- return 0;
+ if (system_state < SYSTEM_RUNNING && cpu_has_feature(CPU_FTR_SMT)) {
+ if (!smt_enabled_at_boot && cpu_thread_in_core(nr) != 0)
+ return 0;
+ if (smt_enabled_at_boot
+ && cpu_thread_in_core(nr) >= smt_enabled_at_boot)
+ return 0;
+ }
return 1;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-
Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
On Aug 5, 2010, at 12:25 PM, Bounine, Alexandre wrote: > Below is a copy of Leo's message with pointers to the patches. > > Alex. > >> Subject: [PATCH] RapidIO,powerpc/85xx: remove MCSR_MASK in fsl_rio >> >> Fixes compile problem caused by MCSR_MASK removal from book-E > definitions. > > Hi Alex, > > Only with your patch, there will still be problem on SRIO platforms > other than MPC85xx. > > I have posted a patch series to fix this together with several > compatibility issues a month before. > > http://patchwork.ozlabs.org/patch/56135/ > http://patchwork.ozlabs.org/patch/56136/ > http://patchwork.ozlabs.org/patch/56138/ > http://patchwork.ozlabs.org/patch/56137/ > > > Can anyone pick the patch series quickly as currently there is a compile > error when SRIO is enabled. > > - Leo I'm looking at this now and wondering what we added the mcheck handler for in the first place and what its trying to accomplish. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] fsl_rio: fix compile errors
On Thu, 5 Aug 2010 12:39:48 -0500 Kumar Gala wrote: > > On Jun 18, 2010, at 1:24 AM, Li Yang wrote: > > > Fixes the following compile problem on E500 platforms: > > arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': > > arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared (first use > > in this function) > > > > Also fixes the compile problem on non-E500 platforms. > > > > Signed-off-by: Li Yang > > --- > > arch/powerpc/sysdev/fsl_rio.c |6 +- > > 1 files changed, 5 insertions(+), 1 deletions(-) > > I'm confused is this handler not relevant for e500MC? The 2nd patch makes me > thing it is. It is, though it needs to use a different MCSR bit on e500mc. Are you referring to the #ifdef CONFIG_E500? CONFIG_PPC_E500MC depends on CONFIG_E500... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] fsl_rio: fix compile errors
On Aug 5, 2010, at 12:54 PM, Scott Wood wrote: > On Thu, 5 Aug 2010 12:39:48 -0500 > Kumar Gala wrote: > >> >> On Jun 18, 2010, at 1:24 AM, Li Yang wrote: >> >>> Fixes the following compile problem on E500 platforms: >>> arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': >>> arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared (first use >>> in this function) >>> >>> Also fixes the compile problem on non-E500 platforms. >>> >>> Signed-off-by: Li Yang >>> --- >>> arch/powerpc/sysdev/fsl_rio.c |6 +- >>> 1 files changed, 5 insertions(+), 1 deletions(-) >> >> I'm confused is this handler not relevant for e500MC? The 2nd patch makes >> me thing it is. > > It is, though it needs to use a different MCSR bit on e500mc. > > Are you referring to the #ifdef CONFIG_E500? CONFIG_PPC_E500MC depends > on CONFIG_E500... Ah, that makes a bit more sense now. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] driver core: Add ability for arch code to setup pdev_archdata
On Fri, Aug 06, 2010 at 01:43:51AM +1000, Stephen Rothwell wrote:
> Hi Kumar,
>
> On Thu, 5 Aug 2010 10:15:45 -0500 Kumar Gala
> wrote:
> >
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -19,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "base.h"
> >
> > @@ -170,6 +171,9 @@ struct platform_device *platform_device_alloc(const
> > char *name, int id)
> > pa->pdev.id = id;
> > device_initialize(&pa->pdev.dev);
> > pa->pdev.dev.release = platform_device_release;
> > +#ifdef ARCH_HAS_PDEV_ARCHDATA_SETUP
> > + arch_setup_pdev_archdata(&pa->pdev);
> > +#endif
> > }
> >
> > return pa ? &pa->pdev : NULL;
> > diff --git a/include/asm-generic/platform_device.h
> > b/include/asm-generic/platform_device.h
> > new file mode 100644
> > index 000..64806dc
> > --- /dev/null
> > +++ b/include/asm-generic/platform_device.h
> > @@ -0,0 +1,7 @@
> > +#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
> > +#define __ASM_GENERIC_PLATFORM_DEVICE_H_
> > +/*
> > + * an architecture can override to define arch_setup_pdev_archdata
> > + */
> > +
> > +#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
>
> Why not do:
>
> #include
>
> #ifndef arch_setup_pdev_archdata
> static inline void arch_setup_pdev_archdata(struct platform_device *pdev) { }
> #endif
>
> in asm-generic/platform-device.h
>
> and the the call in platform_device_alloc() can be unconditional. If the
> arch wants to override arch_setup_pdev_archdata, it defines the function and
> then does
>
> #define arch_setup_pdev_archdata arch_setup_pdev_archdata
>
> before still including asm-generic/platform_device.h
Yes, I'd prefer that method as well.
thanks,
greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
> I'm looking at this now and wondering what we added the mcheck handler for in the first place and what > its trying to accomplish. > > - k This protects system from hanging if RIO link fails or enters error state. In some situations following maintenance read may initiate link recovery from error state. As it is now, MCheck mostly prevents system from hanging, but it also adds sense to return status of maintenance read routine. I am using return status in my new set of patches to check if RIO link is valid during error recovery. Alex. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Relocating bootwrapper causes kernel panic
>> > Before the flat tree was accessed, I checked the DTLB and didn't find >> > any entry related to 0xc0be4300. After the exception, I found the >> > following DTLBs. >> > >> > 30 : 02 c0be4000 4KB -- -> >> > 31 : 00 fa00 8MB VI-S-M -> fa00 >> > >> > The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this >> > should be something like 00be4000? > > Note that the valid bit is clear -- it's not mapping to anything. Did the exception handler try to set a TLB here but the setting was not completed? >> I think the cause is clear now. But how to fix it? Two questions: >> 2. If the DTLB miss exception handler is not the right guy to load a >> proper TLB entry, how can I set one entry based on the link_address >> and the address of the flat dt blob? > > Given how early in the boot process it is, it's probably going to need > to be handled specially. What APIs can I use to set up DTLBs? Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Relocating bootwrapper causes kernel panic
On Thu, 5 Aug 2010 11:33:44 -0700 Shawn Jin wrote: > >> > Before the flat tree was accessed, I checked the DTLB and didn't find > >> > any entry related to 0xc0be4300. After the exception, I found the > >> > following DTLBs. > >> > > >> > 30 : 02 c0be4000 4KB -- -> > >> > 31 : 00 fa00 8MB VI-S-M -> fa00 > >> > > >> > The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this > >> > should be something like 00be4000? > > > > Note that the valid bit is clear -- it's not mapping to anything. > > Did the exception handler try to set a TLB here but the setting was > not completed? Probably. You won't have any page tables yet, much less an entry for the device tree. > >> I think the cause is clear now. But how to fix it? Two questions: > >> 2. If the DTLB miss exception handler is not the right guy to load a > >> proper TLB entry, how can I set one entry based on the link_address > >> and the address of the flat dt blob? > > > > Given how early in the boot process it is, it's probably going to need > > to be handled specially. > > What APIs can I use to set up DTLBs? I don't think there is one that works on 8xx. You'll could hack up initial_mmu, or else write some C code to insert an 8xx TLB entry. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
On 07/22/2010 10:09 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-22 at 21:44 -0700, Darren Hart wrote:
>
>> suggestion I updated the instrumentation to display the
>> local_save_flags and irqs_disabled_flags:
>
>> Jul 22 23:36:58 igoort1 kernel: local flags: 0, irqs disabled: 1
>> Jul 22 23:36:58 igoort1 kernel: before H_CEDE current->stack:
>> c0010e9e3ce0, pcnt: 1
>> Jul 22 23:36:58 igoort1 kernel: after H_CEDE current->stack:
>> c0010e9e3ce0, pcnt: 1
>>
>> I'm not sure if I'm reading that right, but I believe interrupts are
>> intended to be disabled here. If accomplished via the
>> spin_lock_irqsave() this would behave differently on RT. However, this
>> path disables the interrupts handled by xics, all but the IPIs anyway.
>> On RT I disabled the decrementer as well.
>>
>> Is it possible for RT to be receiving other interrupts here?
>
> Also you may want to call hard_irq_disable() to -really- disable
> interrupts ... since we do lazy-disable on powerpc
>
A quick update and request for direction wrt the cede hcall, interrupt
handling, and the stack pointer.
I've added patches one at a time, eliminating bugs with preempt_rt
(tip/rt/head). With my current patchset I have no crashes with a single run of
random_online.sh (stress testing to hit the hang will sees is my todo for
tomorrow).
Current patchset includes:
patches/0001-wms-fix01.patch # P7 lazy flushing thing
# next four are sent to / queued for mainline
patches/powerpc-increase-pseries_cpu_die-delay.patch
patches/powerpc-enable-preemption-before-cpu_die.patch
patches/powerpc-silence-__cpu_up-under-normal-operation.patch
patches/powerpc-silence-xics_migrate_irqs_away-during-cpu-offline.patch
# this one needs to be cleaned up and sent to mainline
patches/powerpc-wait-for-cpu-to-go-inactive.patch
patches/powerpc-disable-decrementer-on-offline.patch
patches/powerpc-cpu_die-preempt-hack.patch # reset preempt_count to 0 after cede
patches/powerpc-cede-processor-inst.patch # instrumentation
patches/powerpc-hard_irq_disable.patch # hard_irq_disable before cede
patches/powerpc-pad-thread_info.patch
I didn't include all the patches as the relevant bits are included below in
code form.
With the instrumentation, it's clear the change to preempt_count() is targeted
(since I added padding before and after preempt_count in the thread_info
struct) and preempt_count is still changed. It is also clear that it isn't just
a stray decrement since I set preempt_count() to 4 prior to calling cede and it
still is 0x after the hcall. Also note that the stack pointer doesn't
change across the cede call and neither does any other part of the thread_info
structure.
Adding hard_irq_disable() did seem to affect things somewhat. Rather than a
serialized list of before/after thread_info prints around cede, I see
several befores then several afters. But the preempt_count is still modified.
The relevant code looks like this (from pseries_mach_cpu_die())
hard_irq_disable(); /* this doesn't fix things... but
does change behavior a bit */
preempt_count() = 0x4;
asm("mr %0,1" : "=r" (sp)); /* stack pointer is in R1
*/
printk("before cede: sp=%lx pcnt=%x\n", sp,
preempt_count());
print_thread_info();
extended_cede_processor(cede_latency_hint);
asm("mr %0,1" : "=r" (sp));
printk("after cede: sp=%lx pcnt=%x\n", sp,
preempt_count());
print_thread_info();
preempt_count() = 0;
With these patches applied, the output across cede looks like:
before cede: sp=c0b57150 pcnt=4
*** current->thread_info ***
ti->task: c0aa1410
ti->exec_domain: c0a59958
ti->cpu: 0
ti->stomp_on_me: 57005 /* 0xDEAD - forgot to print in hex */
ti->preempt_count: 4
ti->stomp_on_me_too: 48879 /* 0xBEEF - forgot to print in hex */
ti->local_flags: 0
*** end thread_info ***
after cede: sp=c0b57150 pcnt=
*** current->thread_info ***
ti->task: c0aa1410
ti->exec_domain: c0a59958
ti->cpu: 0
ti->stomp_on_me: 57005
ti->preempt_count:
ti->stomp_on_me_too: 48879
ti->local_flags: 0
*** end thread_info ***
Are there any additional thoughts on what might be causing preempt_count to
change?
I was thinking that cede might somehow force it to 0 (or perhaps one of the
preempt_count explicit value setters in irq.c) and then decrement it - but that
dec
should trigger an error in the dec_preempt_count() as I have
CONFIG_DEBUG_PREEMPT=y.
...
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3][MTD] P4080/nand: Fix the freescale lbc issue with 36bit mode
From: Lan Chunhe-B25806
When system uses 36bit physical address, res.start is 36bit
physical address. But the function of in_be32 returns 32bit
physical address. Then both of them compared each other is
wrong. So by converting the address of res.start into
the right format fixes this issue.
Signed-off-by: Lan Chunhe-B25806
Signed-off-by: Roy Zang
---
arch/powerpc/include/asm/fsl_lbc.h |1 +
arch/powerpc/sysdev/fsl_lbc.c | 33 -
drivers/mtd/nand/fsl_elbc_nand.c |2 +-
3 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index 9b95eab..28dcf63 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -249,6 +249,7 @@ struct fsl_upm {
int width;
};
+extern unsigned int convert_lbc_address(phys_addr_t addr_base);
extern int fsl_lbc_find(phys_addr_t addr_base);
extern int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm *upm);
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index 9c9e44f..08f98d8 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -31,6 +31,36 @@ struct fsl_lbc_ctrl *fsl_lbc_ctrl_dev;
EXPORT_SYMBOL(fsl_lbc_ctrl_dev);
/**
+ * convert_lbc_address - convert the base address
+ * @addr_base: base address of the memory bank
+ *
+ * This function converts a base address of lbc into the right format for the
BR
+ * registers. If the SOC has eLBC then it returns 32bit physical address else
+ * it returns 34bit physical address for local bus(Example: MPC8641).
+ */
+unsigned int convert_lbc_address(phys_addr_t addr_base)
+{
+ void *dev;
+ int compatible;
+
+ dev = of_find_node_by_name(NULL, "localbus");
+ if (!dev) {
+ printk(KERN_INFO "fsl-lbc: can't find localbus node\n");
+ of_node_put(dev);
+ return 0;
+ }
+
+ compatible = of_device_is_compatible(dev, "fsl,elbc");
+ of_node_put(dev);
+ if (compatible)
+ return addr_base & 0x8000;
+ else
+ return (addr_base & 0x08000ull) \
+ | ((addr_base & 0x3ull) >> 19);
+}
+EXPORT_SYMBOL(convert_lbc_address);
+
+/**
* fsl_lbc_find - find Localbus bank
* @addr_base: base address of the memory bank
*
@@ -50,7 +80,8 @@ int fsl_lbc_find(phys_addr_t addr_base)
__be32 br = in_be32(&fsl_lbc_ctrl_dev->regs->bank[i].br);
__be32 or = in_be32(&fsl_lbc_ctrl_dev->regs->bank[i].or);
- if (br & BR_V && (br & or & BR_BA) == addr_base)
+ if (br & BR_V && (br & or & BR_BA) \
+ == convert_lbc_address(addr_base))
return i;
}
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 7bbcb3f..0e8dc40 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -838,7 +838,7 @@ static int __devinit fsl_elbc_nand_probe(struct of_device
*dev,
(in_be32(&lbc->bank[bank].br) & BR_MSEL) == BR_MS_FCM &&
(in_be32(&lbc->bank[bank].br) &
in_be32(&lbc->bank[bank].or) & BR_BA)
-== res.start)
+== convert_lbc_address(res.start))
break;
if (bank >= MAX_BANKS) {
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Lan Chunhe-B25806
Move Freescale elbc interrupt from nand dirver to elbc driver.
Then all elbc devices can use the interrupt instead of ONLY nand.
Signed-off-by: Lan Chunhe-B25806
Signed-off-by: Roy Zang
---
send the patch to linux-...@lists.infradead.org
it has been posted to linuxppc-...@ozlabs.org and do not get any comment.
arch/powerpc/Kconfig |7 +-
arch/powerpc/include/asm/fsl_lbc.h | 34 +-
arch/powerpc/sysdev/fsl_lbc.c | 254 ++--
3 files changed, 253 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2031a28..5155b53 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -703,9 +703,12 @@ config 4xx_SOC
bool
config FSL_LBC
- bool
+ bool "Freescale Local Bus support"
+ depends on FSL_SOC
help
- Freescale Localbus support
+ Enables reporting of errors from the Freescale local bus
+ controller. Also contains some common code used by
+ drivers for specific local bus peripherals.
config FSL_GTM
bool
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index 1b5a210..9b95eab 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -1,9 +1,10 @@
/* Freescale Local Bus Controller
*
- * Copyright (c) 2006-2007 Freescale Semiconductor
+ * Copyright (c) 2006-2007, 2010 Freescale Semiconductor
*
* Authors: Nick Spence ,
* Scott Wood
+ * Jack Lan
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -27,6 +28,9 @@
#include
#include
+#include
+#include
+
struct fsl_lbc_bank {
__be32 br; /**< Base Register */
#define BR_BA 0x8000
@@ -125,13 +129,23 @@ struct fsl_lbc_regs {
#define LTESR_ATMW 0x0080
#define LTESR_ATMR 0x0040
#define LTESR_CS 0x0008
+#define LTESR_UPM 0x0002
#define LTESR_CC 0x0001
#define LTESR_NAND_MASK (LTESR_FCT | LTESR_PAR | LTESR_CC)
+#define LTESR_MASK (LTESR_BM | LTESR_FCT | LTESR_PAR | LTESR_WP \
+| LTESR_ATMW | LTESR_ATMR | LTESR_CS | LTESR_UPM \
+| LTESR_CC)
+#define LTESR_CLEAR0x
+#define LTECCR_CLEAR 0x
+#define LTESR_STATUS LTESR_MASK
+#define LTEIR_ENABLE LTESR_MASK
+#define LTEDR_ENABLE 0x
__be32 ltedr; /**< Transfer Error Disable Register */
__be32 lteir; /**< Transfer Error Interrupt Register */
__be32 lteatr; /**< Transfer Error Attributes Register */
__be32 ltear; /**< Transfer Error Address Register */
- u8 res6[0xC];
+ __be32 lteccr; /**< Transfer Error ECC Register */
+ u8 res6[0x8];
__be32 lbcr;/**< Configuration Register */
#define LBCR_LDIS 0x8000
#define LBCR_LDIS_SHIFT31
@@ -265,7 +279,23 @@ static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
cpu_relax();
}
+/* overview of the fsl lbc controller */
+
+struct fsl_lbc_ctrl {
+ /* device info */
+ struct device *dev;
+ struct fsl_lbc_regs __iomem *regs;
+ int irq;
+ wait_queue_head_t irq_wait;
+ spinlock_t lock;
+ void*nand;
+
+ /* status read from LTESR by irq handler */
+ unsigned intirq_status;
+};
+
extern int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base,
u32 mar);
+extern struct fsl_lbc_ctrl *fsl_lbc_ctrl_dev;
#endif /* __ASM_FSL_LBC_H */
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index dceb8d1..9c9e44f 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -5,6 +5,10 @@
*
* Author: Anton Vorontsov
*
+ * Copyright (c) 2010 Freescale Semiconductor
+ *
+ * Authors: Jack Lan
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -23,35 +27,8 @@
#include
static spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
-static struct fsl_lbc_regs __iomem *fsl_lbc_regs;
-
-static char __initdata *compat_lbc[] = {
- "fsl,pq2-localbus",
- "fsl,pq2pro-localbus",
- "fsl,pq3-localbus",
- "fsl,elbc",
-};
-
-static int __init fsl_lbc_init(void)
-{
- struct device_node *lbus;
- int i;
-
- for (i = 0; i < ARRAY_SIZE(compat_lbc); i++) {
- lbus = of_find_compatible_node(NULL, NULL, compat_lbc[i]);
- if (lbus)
- goto found;
- }
- return -ENODEV;
-
[PATCH 2/3][MTD] P4080/nand: Only make elbc nand driver detect nand flash partitions
From: Lan Chunhe-B25806
The former driver had the two functions:
1. detecting nand flash partitions;
2. registering elbc interrupt.
Now, second function is removed to fsl_lbc.c.
Signed-off-by: Lan Chunhe-B25806
Signed-off-by: Roy Zang
---
drivers/mtd/nand/Kconfig |1 +
drivers/mtd/nand/fsl_elbc_nand.c | 464 ++
2 files changed, 170 insertions(+), 295 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index ffc3720..4b4c82e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -459,6 +459,7 @@ config MTD_NAND_ORION
config MTD_NAND_FSL_ELBC
tristate "NAND support for Freescale eLBC controllers"
depends on MTD_NAND && PPC_OF
+ select FSL_LBC
help
Various Freescale chips, including the 8313, include a NAND Flash
Controller Module with built-in hardware ECC capabilities.
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 5084cc5..7bbcb3f 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -1,9 +1,10 @@
/* Freescale Enhanced Local Bus Controller NAND driver
*
- * Copyright (c) 2006-2007 Freescale Semiconductor
+ * Copyright (c) 2006-2007, 2010 Freescale Semiconductor
*
* Authors: Nick Spence ,
* Scott Wood
+ * Jack Lan
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -24,32 +25,21 @@
#include
#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
#include
-
-#include
#include
#define MAX_BANKS 8
#define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */
#define FCM_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait for FCM */
-struct fsl_elbc_ctrl;
-
/* mtd information per set */
struct fsl_elbc_mtd {
struct mtd_info mtd;
struct nand_chip chip;
- struct fsl_elbc_ctrl *ctrl;
+ struct fsl_lbc_ctrl *ctrl;
struct device *dev;
int bank; /* Chip select bank number */
@@ -58,18 +48,12 @@ struct fsl_elbc_mtd {
unsigned int fmr; /* FCM Flash Mode Register value */
};
-/* overview of the fsl elbc controller */
+/* Freescale eLBC FCM controller infomation */
-struct fsl_elbc_ctrl {
+struct fsl_elbc_fcm_ctrl {
struct nand_hw_control controller;
struct fsl_elbc_mtd *chips[MAX_BANKS];
- /* device info */
- struct device *dev;
- struct fsl_lbc_regs __iomem *regs;
- int irq;
- wait_queue_head_t irq_wait;
- unsigned int irq_status; /* status read from LTESR by irq handler */
u8 __iomem *addr;/* Address of assigned FCM buffer*/
unsigned int page; /* Last page written to / read from */
unsigned int read_bytes; /* Number of bytes read during command */
@@ -82,6 +66,8 @@ struct fsl_elbc_ctrl {
char *oob_poi; /* Place to write ECC after read back*/
};
+static struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl;
+
/* These map to the positions used by the FCM hardware ECC generator */
/* Small Page FLASH with FMR[ECCM] = 0 */
@@ -164,11 +150,11 @@ static void set_addr(struct mtd_info *mtd, int column,
int page_addr, int oob)
{
struct nand_chip *chip = mtd->priv;
struct fsl_elbc_mtd *priv = chip->priv;
- struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+ struct fsl_lbc_ctrl *ctrl = priv->ctrl;
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
int buf_num;
- ctrl->page = page_addr;
+ elbc_fcm_ctrl->page = page_addr;
out_be32(&lbc->fbar,
page_addr >> (chip->phys_erase_shift - chip->page_shift));
@@ -185,16 +171,18 @@ static void set_addr(struct mtd_info *mtd, int column,
int page_addr, int oob)
buf_num = page_addr & 7;
}
- ctrl->addr = priv->vbase + buf_num * 1024;
- ctrl->index = column;
+ elbc_fcm_ctrl->addr = priv->vbase + buf_num * 1024;
+ elbc_fcm_ctrl->index = column;
/* for OOB data point to the second half of the buffer */
if (oob)
- ctrl->index += priv->page_size ? 2048 : 512;
+ elbc_fcm_ctrl->index += priv->page_size ? 2048 : 512;
- dev_vdbg(ctrl->dev, "set_addr: bank=%d, ctrl->addr=0x%p (0x%p), "
+ dev_vdbg(priv->dev, "set_addr: bank=%d, "
+ "elbc_fcm_ctrl->addr=0x%p (0x%p), "
"index %x, pes %d ps %d\n",
-buf_num, ctrl->addr, priv->vbase, ctrl->index,
+buf_num, elbc_fcm_ctrl->addr, priv->vbase,
+elbc_fcm_ctrl->index,
chip->phys_erase_shift, chip->page_shift);
}
@@ -205,18 +193,18 @@ static int fsl_elbc_run_command(struct mtd_info *mtd)
{
struct nand_chip *chi
[PATCH] powerpc: inline ppc64_runlatch_off
I'm sick of seeing ppc64_runlatch_off in our profiles, so inline the
heavily used part of it into the callers. To avoid a mess of circular includes
I didn't add it as an inline function.
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/include/asm/reg.h
===
--- powerpc.git.orig/arch/powerpc/include/asm/reg.h 2010-08-04
19:55:38.910793475 +1000
+++ powerpc.git/arch/powerpc/include/asm/reg.h 2010-08-04 20:20:19.490751850
+1000
@@ -951,7 +951,14 @@
#ifdef CONFIG_PPC64
extern void ppc64_runlatch_on(void);
-extern void ppc64_runlatch_off(void);
+extern void __ppc64_runlatch_off(void);
+
+#define ppc64_runlatch_off() \
+ do {\
+ if (cpu_has_feature(CPU_FTR_CTRL) &&\
+ test_thread_flag(TIF_RUNLATCH)) \
+ __ppc64_runlatch_off(); \
+ } while (0);
extern unsigned long scom970_read(unsigned int address);
extern void scom970_write(unsigned int address, unsigned long value);
Index: powerpc.git/arch/powerpc/kernel/process.c
===
--- powerpc.git.orig/arch/powerpc/kernel/process.c 2010-08-04
19:55:38.890747120 +1000
+++ powerpc.git/arch/powerpc/kernel/process.c 2010-08-04 20:15:27.573241044
+1000
@@ -1198,19 +1198,17 @@ void ppc64_runlatch_on(void)
}
}
-void ppc64_runlatch_off(void)
+void __ppc64_runlatch_off(void)
{
unsigned long ctrl;
- if (cpu_has_feature(CPU_FTR_CTRL) && test_thread_flag(TIF_RUNLATCH)) {
- HMT_medium();
+ HMT_medium();
- clear_thread_flag(TIF_RUNLATCH);
+ clear_thread_flag(TIF_RUNLATCH);
- ctrl = mfspr(SPRN_CTRLF);
- ctrl &= ~CTRL_RUNLATCH;
- mtspr(SPRN_CTRLT, ctrl);
- }
+ ctrl = mfspr(SPRN_CTRLF);
+ ctrl &= ~CTRL_RUNLATCH;
+ mtspr(SPRN_CTRLT, ctrl);
}
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
* Darren Hart [2010-08-05 19:19:00]:
> On 07/22/2010 10:09 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2010-07-22 at 21:44 -0700, Darren Hart wrote:
> >
> >> suggestion I updated the instrumentation to display the
> >> local_save_flags and irqs_disabled_flags:
> >
> >> Jul 22 23:36:58 igoort1 kernel: local flags: 0, irqs disabled: 1
> >> Jul 22 23:36:58 igoort1 kernel: before H_CEDE current->stack:
> >> c0010e9e3ce0, pcnt: 1
> >> Jul 22 23:36:58 igoort1 kernel: after H_CEDE current->stack:
> >> c0010e9e3ce0, pcnt: 1
> >>
> >> I'm not sure if I'm reading that right, but I believe interrupts are
> >> intended to be disabled here. If accomplished via the
> >> spin_lock_irqsave() this would behave differently on RT. However, this
> >> path disables the interrupts handled by xics, all but the IPIs anyway.
> >> On RT I disabled the decrementer as well.
> >>
> >> Is it possible for RT to be receiving other interrupts here?
> >
> > Also you may want to call hard_irq_disable() to -really- disable
> > interrupts ... since we do lazy-disable on powerpc
> >
>
> A quick update and request for direction wrt the cede hcall, interrupt
> handling, and the stack pointer.
>
> I've added patches one at a time, eliminating bugs with preempt_rt
> (tip/rt/head). With my current patchset I have no crashes with a single run of
> random_online.sh (stress testing to hit the hang will sees is my todo for
> tomorrow).
>
> Current patchset includes:
> patches/0001-wms-fix01.patch # P7 lazy flushing thing
>
> # next four are sent to / queued for mainline
> patches/powerpc-increase-pseries_cpu_die-delay.patch
> patches/powerpc-enable-preemption-before-cpu_die.patch
> patches/powerpc-silence-__cpu_up-under-normal-operation.patch
> patches/powerpc-silence-xics_migrate_irqs_away-during-cpu-offline.patch
>
> # this one needs to be cleaned up and sent to mainline
> patches/powerpc-wait-for-cpu-to-go-inactive.patch
>
> patches/powerpc-disable-decrementer-on-offline.patch
> patches/powerpc-cpu_die-preempt-hack.patch # reset preempt_count to 0 after
> cede
> patches/powerpc-cede-processor-inst.patch # instrumentation
> patches/powerpc-hard_irq_disable.patch # hard_irq_disable before cede
> patches/powerpc-pad-thread_info.patch
>
> I didn't include all the patches as the relevant bits are included below in
> code form.
>
> With the instrumentation, it's clear the change to preempt_count() is targeted
> (since I added padding before and after preempt_count in the thread_info
> struct) and preempt_count is still changed. It is also clear that it isn't
> just
> a stray decrement since I set preempt_count() to 4 prior to calling cede and
> it
> still is 0x after the hcall. Also note that the stack pointer doesn't
> change across the cede call and neither does any other part of the thread_info
> structure.
>
> Adding hard_irq_disable() did seem to affect things somewhat. Rather than a
> serialized list of before/after thread_info prints around cede, I see
> several befores then several afters. But the preempt_count is still modified.
>
> The relevant code looks like this (from pseries_mach_cpu_die())
>
> hard_irq_disable(); /* this doesn't fix things... but
> does change behavior a bit */
> preempt_count() = 0x4;
> asm("mr %0,1" : "=r" (sp)); /* stack pointer is in
> R1 */
> printk("before cede: sp=%lx pcnt=%x\n", sp,
> preempt_count());
> print_thread_info();
> extended_cede_processor(cede_latency_hint);
> asm("mr %0,1" : "=r" (sp));
> printk("after cede: sp=%lx pcnt=%x\n", sp,
> preempt_count());
> print_thread_info();
> preempt_count() = 0;
>
>
> With these patches applied, the output across cede looks like:
>
> before cede: sp=c0b57150 pcnt=4
> *** current->thread_info ***
> ti->task: c0aa1410
> ti->exec_domain: c0a59958
> ti->cpu: 0
> ti->stomp_on_me: 57005 /* 0xDEAD - forgot to print in hex */
> ti->preempt_count: 4
> ti->stomp_on_me_too: 48879 /* 0xBEEF - forgot to print in hex */
> ti->local_flags: 0
> *** end thread_info ***
> after cede: sp=c0b57150 pcnt=
> *** current->thread_info ***
> ti->task: c0aa1410
> ti->exec_domain: c0a59958
> ti->cpu: 0
Is this print sufficient to prove that we did not jump CPU?
We agree that decrementer can possibly expire and we could have gone
to the handler and come back just like we would do in an idle loop.
This will not happen always, but I could see a window of time during
which this may happen. But that should not change the preempt_count
unconditionally to -1 with the same stack pointer.
> ti->stomp_on_me: 57005
> ti->preempt_count:
> ti->stomp_on_me_too: 48879
> ti->local_flags: 0
Is there a method
Re: [PATCH] powerpc: inline ppc64_runlatch_off
On Fri, 2010-08-06 at 14:53 +1000, Anton Blanchard wrote:
> I'm sick of seeing ppc64_runlatch_off in our profiles, so inline the
> heavily used part of it into the callers. To avoid a mess of circular includes
> I didn't add it as an inline function.
Considering that it's just an asm instruction or two, should we make it
inline asm and have it NOPed out instead using the feature sections ?
Cheers,
Ben.
> Signed-off-by: Anton Blanchard
> ---
>
> Index: powerpc.git/arch/powerpc/include/asm/reg.h
> ===
> --- powerpc.git.orig/arch/powerpc/include/asm/reg.h 2010-08-04
> 19:55:38.910793475 +1000
> +++ powerpc.git/arch/powerpc/include/asm/reg.h2010-08-04
> 20:20:19.490751850 +1000
> @@ -951,7 +951,14 @@
> #ifdef CONFIG_PPC64
>
> extern void ppc64_runlatch_on(void);
> -extern void ppc64_runlatch_off(void);
> +extern void __ppc64_runlatch_off(void);
> +
> +#define ppc64_runlatch_off() \
> + do {\
> + if (cpu_has_feature(CPU_FTR_CTRL) &&\
> + test_thread_flag(TIF_RUNLATCH)) \
> + __ppc64_runlatch_off(); \
> + } while (0);
>
> extern unsigned long scom970_read(unsigned int address);
> extern void scom970_write(unsigned int address, unsigned long value);
> Index: powerpc.git/arch/powerpc/kernel/process.c
> ===
> --- powerpc.git.orig/arch/powerpc/kernel/process.c2010-08-04
> 19:55:38.890747120 +1000
> +++ powerpc.git/arch/powerpc/kernel/process.c 2010-08-04 20:15:27.573241044
> +1000
> @@ -1198,19 +1198,17 @@ void ppc64_runlatch_on(void)
> }
> }
>
> -void ppc64_runlatch_off(void)
> +void __ppc64_runlatch_off(void)
> {
> unsigned long ctrl;
>
> - if (cpu_has_feature(CPU_FTR_CTRL) && test_thread_flag(TIF_RUNLATCH)) {
> - HMT_medium();
> + HMT_medium();
>
> - clear_thread_flag(TIF_RUNLATCH);
> + clear_thread_flag(TIF_RUNLATCH);
>
> - ctrl = mfspr(SPRN_CTRLF);
> - ctrl &= ~CTRL_RUNLATCH;
> - mtspr(SPRN_CTRLT, ctrl);
> - }
> + ctrl = mfspr(SPRN_CTRLF);
> + ctrl &= ~CTRL_RUNLATCH;
> + mtspr(SPRN_CTRLT, ctrl);
> }
> #endif
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: inline ppc64_runlatch_off
Hi Ben, > > I'm sick of seeing ppc64_runlatch_off in our profiles, so inline the > > heavily used part of it into the callers. To avoid a mess of circular > > includes I didn't add it as an inline function. > > Considering that it's just an asm instruction or two, should we make it > inline asm and have it NOPed out instead using the feature sections ? Unfortunately we still need to prevent continual writes to it with a per thread flag because on some CPUs a write to the SPR in low priority mode will stall another SMT thread. So we could get rid of the cpu feature comparison but we would still need the thread bit check (or perhaps replace it with a per cpu variable). Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: inline ppc64_runlatch_off
On Fri, 2010-08-06 at 15:56 +1000, Anton Blanchard wrote: > Unfortunately we still need to prevent continual writes to it with a per > thread > flag because on some CPUs a write to the SPR in low priority mode will stall > another SMT thread. So we could get rid of the cpu feature comparison but > we would still need the thread bit check (or perhaps replace it with a per cpu > variable). remind me why we need to do that runlatch thing on these CPUs at all ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: inline ppc64_runlatch_off
Hi, > remind me why we need to do that runlatch thing on these CPUs at all ? The PMU uses it so events can be constructed that count only non idle cycles. I think the power management hardware on POWER6 and POWER7 also use the runlatch state to determine how busy a CPU is. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
