* Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
From: Jesse Barnes @ 2012-03-09 18:28 UTC (permalink / raw)
To: Anton Blanchard; +Cc: sfr, yinghai, linuxppc-dev, linux-kernel
In-Reply-To: <20120309144645.5b5997d2@kryten>
On Fri, 9 Mar 2012 14:46:45 +1100
Anton Blanchard <anton@samba.org> wrote:
>
> Hi Ben,
>
> > Looks like something that got fixed but the new patches from Bjorn
> > aren't in next yet. I'll fwd you the patch separately to apply on
> > top of what you have see if that helps (to confirm that's indeed the
> > issue).
>
> Thanks, confirmed that it fixes it. Patch below in case anyone else is
> hitting it.
>
> Anton
>
> --
>
> On Sat, 2012-03-03 at 08:52 +1100, Benjamin Herrenschmidt wrote:
>
> > Or give me a chance to dig :-) I'll have a look next week.
>
> This is indeed what bjorn suspected on irc, this patch fixes it:
>
> (Bjorn, please fold it in the original offending patch)
Thanks guys; I'll push the fixes to -next when I get to a real network
(at the airport now about to run out of battery with a crappy
connection).
Jesse
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Rob Herring @ 2012-03-09 16:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Michael Neuling, Paul Mundt, linux-sh,
linux-kernel, linux-next, Paul Mackerras, linuxppc-dev,
Russell King
In-Reply-To: <1331262821.3105.47.camel@pasglop>
On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
>> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
>>> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
>>> I remove it, then I get Kconfig warnings:
>>>
>>> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
>>> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
>>
>> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
>
> Nope, Grant patch didn't mention a dependency.
My opinion is that SPARSE_IRQ shouldn't be user visible option, and the
simple solution was to just make it hidden. It wasn't clear if this was
desired or not for other arches at the time. There is a mixture of
settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves
it user selectable for 64-bit.
I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ
a hidden option. It really just needs the okay from SuperH folks.
Rob
^ permalink raw reply
* Re: linux-next: manual merge of the driver-core tree with the powerpc tree
From: Greg KH @ 2012-03-09 15:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, linux-next, Alan Stern, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20120309164025.dc16cfacaa2ee35cbeea14a8@canb.auug.org.au>
On Fri, Mar 09, 2012 at 04:40:25PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/base/driver.c between commit fcd6f7620202 ("driver-core: remove
> legacy iSeries hack") from the powerpc tree and commit 9875bb480cc8
> ("Eliminate get_driver() and put_driver()") from the driver-core tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Looks good to me, thanks for doing this.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
From: Josh Boyer @ 2012-03-09 11:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Neuling, open-source-review, Tirumala R Marri,
linux-kernel, Josh Boyer, Anton Blanchard, Mai La, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1331264145.3105.56.camel@pasglop>
On Thu, Mar 8, 2012 at 10:35 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2012-03-09 at 10:17 +0700, Mai La wrote:
>> This patch consists of:
>> - Enable PCI MSI as default for Bluestone board
>> - Define number of MSI interrupt for Maui APM821xx SoC using in Blueston=
e board
>> - Fix returning ENODEV as finding MSI node
>> - Fix MSI physical high and low address
>> - Keep MSI data logically
>>
>> Signed-off-by: Mai La <mla@apm.com>
>> ---
>
>> index 7b4df37..c86231e 100644
>> --- a/arch/powerpc/sysdev/Kconfig
>> +++ b/arch/powerpc/sysdev/Kconfig
>> @@ -20,6 +20,12 @@ config PPC_MSI_BITMAP
>> =A0 =A0 =A0 default y if FSL_PCI
>> =A0 =A0 =A0 default y if PPC4xx_MSI
>>
>> +config PPC4xx_NR_MSI_IRQS
>> + =A0 =A0 int "Number of PCI MSI interrupts"
>> + =A0 =A0 depends on PCI_MSI && PPC4xx_MSI
>> + =A0 =A0 default "4" if !APM821xx
>> + =A0 =A0 default "8" if APM821xx
>> +
>
> =A0.../...
>
>> +#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS
>
> ARGH.
>
> We asked to -NOT MAKE THIS A COMPILE TIME OPTION-
Actually, I asked for basically exactly above. I was _wrong_ in asking,
but it was asked for.
> CONFIG_foo is as bad as your previous ifdef, in fact you just added a
> useless config option here.
>
> Make that number dynamic. Count the entries in the device-tree (or add
> a property with the number in it, whatever you fancy the most) but make
> it something detected at RUNTIME !!!!!
My apologies Mai. Ben is correct here and I should have thought more
about my suggestion before I made it.
josh
^ permalink raw reply
* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Shawn Guo @ 2012-03-09 8:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Vinod Koul,
Barry Song, Dan Williams, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120306223321.GD15201@n2100.arm.linux.org.uk>
On Tue, Mar 06, 2012 at 10:33:21PM +0000, Russell King - ARM Linux wrote:
...
> drivers/dma/imx-sdma.c | 23 ++------
...
> drivers/dma/mxs-dma.c | 23 ++------
Tested-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* [PATCH v3] powerpc/srio: Fix the compile errors when building with 64bit
From: Liu Gang @ 2012-03-09 8:10 UTC (permalink / raw)
To: linuxppc-dev, Alexandre.Bounine
Cc: r58472, linux-kernel, r61911, paul.gortmaker, Liu Gang, akpm,
Shaohui Xie
For the file "arch/powerpc/sysdev/fsl_rmu.c", there will be some compile
errors while using the corenet64_smp_defconfig:
.../fsl_rmu.c:315: error: cast from pointer to integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:330: error: cast to pointer from integer of different size
.../fsl_rmu.c:332: error: cast to pointer from integer of different size
.../fsl_rmu.c:339: error: cast to pointer from integer of different size
.../fsl_rmu.c:340: error: cast to pointer from integer of different size
.../fsl_rmu.c:341: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:659: error: cast from pointer to integer of different size
.../fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int',
but argument 5 has type 'size_t'
.../fsl_rmu.c:985: error: cast from pointer to integer of different size
.../fsl_rmu.c:997: error: cast to pointer from integer of different size
Rewrote the corresponding code with the support of 64bit building.
Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Changes in v2:
- Add the struct "rio_dbell_msg" to instead of some DBELL_* macros.
- Change the "virt_buf" to be "void *" type.
- Change "Signed-off-by" to "Reported-by" for Paul.
Changes in v3:
- Change the "%8.8lx" to be "%p" and remove the cast of the "buffer"
arch/powerpc/sysdev/fsl_rmu.c | 42 +++++++++++++++++++++-------------------
1 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 1548578..14bd522 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -100,14 +100,8 @@
#define DOORBELL_DSR_TE 0x00000080
#define DOORBELL_DSR_QFI 0x00000010
#define DOORBELL_DSR_DIQI 0x00000001
-#define DOORBELL_TID_OFFSET 0x02
-#define DOORBELL_SID_OFFSET 0x04
-#define DOORBELL_INFO_OFFSET 0x06
#define DOORBELL_MESSAGE_SIZE 0x08
-#define DBELL_SID(x) (*(u16 *)(x + DOORBELL_SID_OFFSET))
-#define DBELL_TID(x) (*(u16 *)(x + DOORBELL_TID_OFFSET))
-#define DBELL_INF(x) (*(u16 *)(x + DOORBELL_INFO_OFFSET))
struct rio_msg_regs {
u32 omr;
@@ -193,6 +187,13 @@ struct fsl_rmu {
int rxirq;
};
+struct rio_dbell_msg {
+ u16 pad1;
+ u16 tid;
+ u16 sid;
+ u16 info;
+};
+
/**
* fsl_rio_tx_handler - MPC85xx outbound message interrupt handler
* @irq: Linux interrupt number
@@ -311,8 +312,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
/* XXX Need to check/dispatch until queue empty */
if (dsr & DOORBELL_DSR_DIQI) {
- u32 dmsg =
- (u32) fsl_dbell->dbell_ring.virt +
+ struct rio_dbell_msg *dmsg =
+ fsl_dbell->dbell_ring.virt +
(in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
struct rio_dbell *dbell;
int found = 0;
@@ -320,25 +321,25 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
("RIO: processing doorbell,"
" sid %2.2x tid %2.2x info %4.4x\n",
- DBELL_SID(dmsg), DBELL_TID(dmsg), DBELL_INF(dmsg));
+ dmsg->sid, dmsg->tid, dmsg->info);
for (i = 0; i < MAX_PORT_NUM; i++) {
if (fsl_dbell->mport[i]) {
list_for_each_entry(dbell,
&fsl_dbell->mport[i]->dbells, node) {
if ((dbell->res->start
- <= DBELL_INF(dmsg))
+ <= dmsg->info)
&& (dbell->res->end
- >= DBELL_INF(dmsg))) {
+ >= dmsg->info)) {
found = 1;
break;
}
}
if (found && dbell->dinb) {
dbell->dinb(fsl_dbell->mport[i],
- dbell->dev_id, DBELL_SID(dmsg),
- DBELL_TID(dmsg),
- DBELL_INF(dmsg));
+ dbell->dev_id, dmsg->sid,
+ dmsg->tid,
+ dmsg->info);
break;
}
}
@@ -348,8 +349,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
("RIO: spurious doorbell,"
" sid %2.2x tid %2.2x info %4.4x\n",
- DBELL_SID(dmsg), DBELL_TID(dmsg),
- DBELL_INF(dmsg));
+ dmsg->sid, dmsg->tid,
+ dmsg->info);
}
setbits32(&fsl_dbell->dbell_regs->dmr, DOORBELL_DMR_DI);
out_be32(&fsl_dbell->dbell_regs->dsr, DOORBELL_DSR_DIQI);
@@ -657,7 +658,7 @@ fsl_add_outb_message(struct rio_mport *mport, struct rio_dev *rdev, int mbox,
int ret = 0;
pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d buffer " \
- "%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer, len);
+ "%p len %8.8zx\n", rdev->destid, mbox, buffer, len);
if ((len < 8) || (len > RIO_MAX_MSG_SIZE)) {
ret = -EINVAL;
goto out;
@@ -972,7 +973,8 @@ out:
void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
{
struct fsl_rmu *rmu = GET_RMM_HANDLE(mport);
- u32 phys_buf, virt_buf;
+ u32 phys_buf;
+ void *virt_buf;
void *buf = NULL;
int buf_idx;
@@ -982,7 +984,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
if (phys_buf == in_be32(&rmu->msg_regs->ifqepar))
goto out2;
- virt_buf = (u32) rmu->msg_rx_ring.virt + (phys_buf
+ virt_buf = rmu->msg_rx_ring.virt + (phys_buf
- rmu->msg_rx_ring.phys);
buf_idx = (phys_buf - rmu->msg_rx_ring.phys) / RIO_MAX_MSG_SIZE;
buf = rmu->msg_rx_ring.virt_buffer[buf_idx];
@@ -994,7 +996,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
}
/* Copy max message size, caller is expected to allocate that big */
- memcpy(buf, (void *)virt_buf, RIO_MAX_MSG_SIZE);
+ memcpy(buf, virt_buf, RIO_MAX_MSG_SIZE);
/* Clear the available buffer */
rmu->msg_rx_ring.virt_buffer[buf_idx] = NULL;
--
1.7.0.4
^ permalink raw reply related
* linux-next: manual merge of the irqdomain tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 6:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-next, Paul Mackerras, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
Hi Grant,
Today's linux-next merge of the irqdomain tree got a conflict in
arch/powerpc/platforms/iseries/irq.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the tree
and three commits from the irqdomain tree.
I just removed the file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 6:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, linux-next, paulus, joe, linuxppc-dev
In-Reply-To: <20120308.221534.712157352097242982.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
Hi Dave,
On Thu, 08 Mar 2012 22:15:34 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 9 Mar 2012 13:36:46 +1100
>
> > Today's linux-next merge of the net-next tree got a conflict in
> > drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
> > ("net: powerpc: remove the legacy iSeries ethernet driver") from the
> > powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
> > error messages") from the net-next tree.
> >
> > I just removed the file.
>
> If it makes life easier for anyone I can put the driver removal patch
> into net-next.
In this case, I think it will actually help, thanks. Note that it won;t
apply cleanly to your tree, but the fixup is easy :-)
And I discovered that "git am" doesn't like the style of patch I did
(without the body of the deleted file). If you just delete
drivers/net/ethernet/ibm/iseries_veth.c before trying to apply the patch
it will probably work.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the powerpc tree
From: David Miller @ 2012-03-09 6:15 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-kernel, linux-next, paulus, joe, linuxppc-dev
In-Reply-To: <20120309133646.fb8cc30d8c2fd0ef7784d72c@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 9 Mar 2012 13:36:46 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
> ("net: powerpc: remove the legacy iSeries ethernet driver") from the
> powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
> error messages") from the net-next tree.
>
> I just removed the file.
If it makes life easier for anyone I can put the driver removal patch
into net-next.
^ permalink raw reply
* linux-next: manual merge of the driver-core tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 5:40 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-next, Alan Stern, Paul Mackerras,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
drivers/base/driver.c between commit fcd6f7620202 ("driver-core: remove
legacy iSeries hack") from the powerpc tree and commit 9875bb480cc8
("Eliminate get_driver() and put_driver()") from the driver-core tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/base/driver.c
index db4f54c,60e4f77..0000000
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@@ -123,34 -123,36 +123,6 @@@ void driver_remove_file(struct device_d
}
EXPORT_SYMBOL_GPL(driver_remove_file);
--/**
- * get_driver - increment driver reference count.
- * @drv: driver.
- */
- struct device_driver *get_driver(struct device_driver *drv)
- {
- if (drv) {
- struct driver_private *priv;
- struct kobject *kobj;
-
- kobj = kobject_get(&drv->p->kobj);
- priv = to_driver(kobj);
- return priv->driver;
- }
- return NULL;
- }
- EXPORT_SYMBOL_GPL(get_driver);
-
- /**
- * put_driver - decrement driver's refcount.
- * @drv: driver.
- */
- void put_driver(struct device_driver *drv)
- {
- kobject_put(&drv->p->kobj);
- }
- EXPORT_SYMBOL_GPL(put_driver);
-
- * driver_add_kobj - add a kobject below the specified driver
- * @drv: requesting device driver
- * @kobj: kobject to add below this driver
- * @fmt: format string that names the kobject
- *
- * You really don't want to do this, this is only here due to one looney
- * iseries driver, go poke those developers if you are annoyed about
- * this...
- */
-int driver_add_kobj(struct device_driver *drv, struct kobject *kobj,
- const char *fmt, ...)
-{
- va_list args;
- char *name;
- int ret;
-
- va_start(args, fmt);
- name = kvasprintf(GFP_KERNEL, fmt, args);
- va_end(args);
-
- if (!name)
- return -ENOMEM;
-
- ret = kobject_add(kobj, &drv->p->kobj, "%s", name);
- kfree(name);
- return ret;
-}
-EXPORT_SYMBOL_GPL(driver_add_kobj);
-
static int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups)
{
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the tip tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 4:40 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, Paul Mackerras, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/powerpc/platforms/iseries/setup.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the powerpc
tree and commit bd2f55361f18 ("sched/rt: Use schedule_preempt_disabled()")
from the tip tree.
The former removed the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
From: Anton Blanchard @ 2012-03-09 3:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: sfr, linuxppc-dev, yinghai, linux-kernel, jbarnes
In-Reply-To: <1331263785.3105.52.camel@pasglop>
Hi Ben,
> Looks like something that got fixed but the new patches from Bjorn
> aren't in next yet. I'll fwd you the patch separately to apply on top
> of what you have see if that helps (to confirm that's indeed the
> issue).
Thanks, confirmed that it fixes it. Patch below in case anyone else is
hitting it.
Anton
--
On Sat, 2012-03-03 at 08:52 +1100, Benjamin Herrenschmidt wrote:
> Or give me a chance to dig :-) I'll have a look next week.
This is indeed what bjorn suspected on irc, this patch fixes it:
(Bjorn, please fold it in the original offending patch)
Cheers,
Ben.
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index b37d0b5..5dd63f1 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -75,6 +75,7 @@ static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
{
u64 base, size;
unsigned int flags;
+ struct pci_bus_region region;
struct resource *res;
const u32 *addrs;
u32 i;
@@ -106,10 +107,12 @@ static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
printk(KERN_ERR "PCI: bad cfg reg num 0x%x\n", i);
continue;
}
- res->start = base;
- res->end = base + size - 1;
+
res->flags = flags;
res->name = pci_name(dev);
+ region.start = base;
+ region.end = base + size - 1;
+ pcibios_bus_to_resource(dev, res, ®ion);
}
}
@@ -209,6 +212,7 @@ void __devinit of_scan_pci_bridge(struct pci_dev *dev)
struct pci_bus *bus;
const u32 *busrange, *ranges;
int len, i, mode;
+ struct pci_bus_region region;
struct resource *res;
unsigned int flags;
u64 size;
@@ -270,9 +274,10 @@ void __devinit of_scan_pci_bridge(struct pci_dev *dev)
res = bus->resource[i];
++i;
}
- res->start = of_read_number(&ranges[1], 2);
- res->end = res->start + size - 1;
res->flags = flags;
+ region.start = of_read_number(&ranges[1], 2);
+ region.end = region.start + size - 1;
+ pcibios_bus_to_resource(dev, res, ®ion);
}
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
bus->number);
--=-aDzdhtAsqTK5gqnOark/--
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
From: Benjamin Herrenschmidt @ 2012-03-09 3:35 UTC (permalink / raw)
To: Mai La
Cc: Michael Neuling, open-source-review, Tirumala R Marri,
linux-kernel, Josh Boyer, Anton Blanchard, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1331263072-9612-1-git-send-email-mla@apm.com>
On Fri, 2012-03-09 at 10:17 +0700, Mai La wrote:
> This patch consists of:
> - Enable PCI MSI as default for Bluestone board
> - Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone board
> - Fix returning ENODEV as finding MSI node
> - Fix MSI physical high and low address
> - Keep MSI data logically
>
> Signed-off-by: Mai La <mla@apm.com>
> ---
> index 7b4df37..c86231e 100644
> --- a/arch/powerpc/sysdev/Kconfig
> +++ b/arch/powerpc/sysdev/Kconfig
> @@ -20,6 +20,12 @@ config PPC_MSI_BITMAP
> default y if FSL_PCI
> default y if PPC4xx_MSI
>
> +config PPC4xx_NR_MSI_IRQS
> + int "Number of PCI MSI interrupts"
> + depends on PCI_MSI && PPC4xx_MSI
> + default "4" if !APM821xx
> + default "8" if APM821xx
> +
.../...
> +#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS
ARGH.
We asked to -NOT MAKE THIS A COMPILE TIME OPTION-
CONFIG_foo is as bad as your previous ifdef, in fact you just added a
useless config option here.
Make that number dynamic. Count the entries in the device-tree (or add
a property with the number in it, whatever you fancy the most) but make
it something detected at RUNTIME !!!!!
Ben.
^ permalink raw reply
* Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
From: Benjamin Herrenschmidt @ 2012-03-09 3:29 UTC (permalink / raw)
To: Anton Blanchard; +Cc: sfr, linuxppc-dev, yinghai, linux-kernel, jbarnes
In-Reply-To: <20120309142555.7ec5e0ac@kryten>
On Fri, 2012-03-09 at 14:25 +1100, Anton Blanchard wrote:
> Hi,
>
> I'm seeing this on a POWER7 blade booting 3.3.0-rc6-next-20120308:
Looks like something that got fixed but the new patches from Bjorn
aren't in next yet. I'll fwd you the patch separately to apply on top of
what you have see if that helps (to confirm that's indeed the issue).
Cheers,
Ben.
>
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x100000-0x10ffff] (bus address [0xf0000-0xfffff])
> pci_bus 0000:00: root bus resource [mem 0x3b0000000000-0x3b001fffffff] (bus address [0xe0000000-0xffffffff])
> IOMMU table initialized, virtual merging enabled
> PCI host bridge to bus 0001:00
> pci_bus 0001:00: root bus resource [io 0x210000-0x21ffff] (bus address [0xf0000-0xfffff])
> pci_bus 0001:00: root bus resource [mem 0x3b0080000000-0x3b00ffffffff] (bus address [0x80000000-0xffffffff])
> PCI host bridge to bus 0002:01
> pci_bus 0002:01: root bus resource [io 0x320000-0x32ffff] (bus address [0xf0000-0xfffff])
> pci_bus 0002:01: root bus resource [mem 0x3b0400000000-0x3b041fefffff] (bus address [0xe0000000-0xffefffff])
> PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
> PCI: Cannot allocate resource region 2 of device 0000:00:01.0, will remap
> PCI: Cannot allocate resource region 6 of device 0000:00:01.0, will remap
> PCI: Cannot allocate resource region 0 of device 0001:00:01.0, will remap
> PCI: Cannot allocate resource region 0 of device 0001:00:01.1, will remap
> PCI: Cannot allocate resource region 0 of device 0001:00:01.2, will remap
> PCI: Cannot allocate resource region 0 of device 0002:01:00.0, will remap
> PCI: Cannot allocate resource region 2 of device 0002:01:00.0, will
> remap
>
> ...
>
> pci 0001:00:01.0: device not available (can't reserve [mem 0x00000000-0x00000fff])
> pci 0001:00:01.0: Can't enable PCI device, BIOS handoff failed.
> pci 0001:00:01.1: device not available (can't reserve [mem 0x00000000-0x00000fff])
> pci 0001:00:01.1: Can't enable PCI device, BIOS handoff failed.
> pci 0001:00:01.2: device not available (can't reserve [mem 0x00000000-0x000000ff])
> pci 0001:00:01.2: Can't enable PCI device, BIOS handoff failed.
>
>
> Then we fail to find the root device. I haven't had a chance
> to chase the cause of it down yet.
>
> Anton
^ permalink raw reply
* 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
From: Anton Blanchard @ 2012-03-09 3:25 UTC (permalink / raw)
To: sfr, benh, yinghai, jbarnes; +Cc: linuxppc-dev, linux-kernel
Hi,
I'm seeing this on a POWER7 blade booting 3.3.0-rc6-next-20120308:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x100000-0x10ffff] (bus address [0xf0000-0xfffff])
pci_bus 0000:00: root bus resource [mem 0x3b0000000000-0x3b001fffffff] (bus address [0xe0000000-0xffffffff])
IOMMU table initialized, virtual merging enabled
PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [io 0x210000-0x21ffff] (bus address [0xf0000-0xfffff])
pci_bus 0001:00: root bus resource [mem 0x3b0080000000-0x3b00ffffffff] (bus address [0x80000000-0xffffffff])
PCI host bridge to bus 0002:01
pci_bus 0002:01: root bus resource [io 0x320000-0x32ffff] (bus address [0xf0000-0xfffff])
pci_bus 0002:01: root bus resource [mem 0x3b0400000000-0x3b041fefffff] (bus address [0xe0000000-0xffefffff])
PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
PCI: Cannot allocate resource region 2 of device 0000:00:01.0, will remap
PCI: Cannot allocate resource region 6 of device 0000:00:01.0, will remap
PCI: Cannot allocate resource region 0 of device 0001:00:01.0, will remap
PCI: Cannot allocate resource region 0 of device 0001:00:01.1, will remap
PCI: Cannot allocate resource region 0 of device 0001:00:01.2, will remap
PCI: Cannot allocate resource region 0 of device 0002:01:00.0, will remap
PCI: Cannot allocate resource region 2 of device 0002:01:00.0, will
remap
...
pci 0001:00:01.0: device not available (can't reserve [mem 0x00000000-0x00000fff])
pci 0001:00:01.0: Can't enable PCI device, BIOS handoff failed.
pci 0001:00:01.1: device not available (can't reserve [mem 0x00000000-0x00000fff])
pci 0001:00:01.1: Can't enable PCI device, BIOS handoff failed.
pci 0001:00:01.2: device not available (can't reserve [mem 0x00000000-0x000000ff])
pci 0001:00:01.2: Can't enable PCI device, BIOS handoff failed.
Then we fail to find the root device. I haven't had a chance
to chase the cause of it down yet.
Anton
^ permalink raw reply
* [PATCH 2/2] powerpc/44x: Add PCI MSI node for Maui APM821xx SoC and Bluestone board in DTS
From: Mai La @ 2012-03-09 3:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Josh Boyer, Matt Porter,
Tirumala R Marri, Grant Likely, Michael Neuling, Kumar Gala,
Anton Blanchard, linuxppc-dev, linux-kernel
Cc: open-source-review, Mai La
Signed-off-by: Mai La <mla@apm.com>
---
arch/powerpc/boot/dts/bluestone.dts | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index 2a56a0d..8ea6325 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -250,5 +250,29 @@
};
};
+ MSI: ppc4xx-msi@C10000000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0xC 0x10000000 0x100
+ 0xC 0x10000000 0x100>;
+ sdr-base = <0x36C>;
+ msi-data = <0x00004440>;
+ msi-mask = <0x0000ffe0>;
+ interrupts =<0 1 2 3 4 5 6 7>;
+ interrupt-parent = <&MSI>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ msi-available-ranges = <0x0 0x100>;
+ interrupt-map = <
+ 0 &UIC3 0x18 1
+ 1 &UIC3 0x19 1
+ 2 &UIC3 0x1A 1
+ 3 &UIC3 0x1B 1
+ 4 &UIC3 0x1C 1
+ 5 &UIC3 0x1D 1
+ 6 &UIC3 0x1E 1
+ 7 &UIC3 0x1F 1
+ >;
+ };
};
};
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
From: Mai La @ 2012-03-09 3:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Josh Boyer, Matt Porter,
Tirumala R Marri, Grant Likely, Michael Neuling, Kumar Gala,
Anton Blanchard, linuxppc-dev, linux-kernel
Cc: open-source-review, Mai La
This patch consists of:
- Enable PCI MSI as default for Bluestone board
- Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone board
- Fix returning ENODEV as finding MSI node
- Fix MSI physical high and low address
- Keep MSI data logically
Signed-off-by: Mai La <mla@apm.com>
---
arch/powerpc/platforms/44x/Kconfig | 2 ++
arch/powerpc/sysdev/Kconfig | 6 ++++++
arch/powerpc/sysdev/ppc4xx_msi.c | 27 ++++++++++++++++-----------
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index fcf6bf2..9f04ce3 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -23,6 +23,8 @@ config BLUESTONE
default n
select PPC44x_SIMPLE
select APM821xx
+ select PCI_MSI
+ select PPC4xx_MSI
select IBM_EMAC_RGMII
help
This option enables support for the APM APM821xx Evaluation board.
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 7b4df37..c86231e 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -20,6 +20,12 @@ config PPC_MSI_BITMAP
default y if FSL_PCI
default y if PPC4xx_MSI
+config PPC4xx_NR_MSI_IRQS
+ int "Number of PCI MSI interrupts"
+ depends on PCI_MSI && PPC4xx_MSI
+ default "4" if !APM821xx
+ default "8" if APM821xx
+
source "arch/powerpc/sysdev/xics/Kconfig"
config PPC_SCOM
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 1c2d7af..3359237 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -28,10 +28,11 @@
#include <linux/of_platform.h>
#include <linux/interrupt.h>
#include <linux/export.h>
+#include <linux/kernel.h>
#include <asm/prom.h>
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
-#include <boot/dcr.h>
+#include <asm/dcr.h>
#include <asm/dcr-regs.h>
#include <asm/msi_bitmap.h>
@@ -43,7 +44,8 @@
#define PEIH_FLUSH0 0x30
#define PEIH_FLUSH1 0x38
#define PEIH_CNTRST 0x48
-#define NR_MSI_IRQS 4
+
+#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS
struct ppc4xx_msi {
u32 msi_addr_lo;
@@ -150,12 +152,11 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
if (!sdr_addr)
return -1;
- SDR0_WRITE(sdr_addr, (u64)res.start >> 32); /*HIGH addr */
- SDR0_WRITE(sdr_addr + 1, res.start & 0xFFFFFFFF); /* Low addr */
-
+ mtdcri(SDR0, *sdr_addr, upper_32_bits(res.start)); /*HIGH addr */
+ mtdcri(SDR0, *sdr_addr + 1, lower_32_bits(res.start)); /* Low addr */
msi->msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
- if (msi->msi_dev)
+ if (!msi->msi_dev)
return -ENODEV;
msi->msi_regs = of_iomap(msi->msi_dev, 0);
@@ -167,9 +168,12 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
(u32) (msi->msi_regs + PEIH_TERMADH), (u32) (msi->msi_regs));
msi_virt = dma_alloc_coherent(&dev->dev, 64, &msi_phys, GFP_KERNEL);
- msi->msi_addr_hi = 0x0;
- msi->msi_addr_lo = (u32) msi_phys;
- dev_dbg(&dev->dev, "PCIE-MSI: msi address 0x%x\n", msi->msi_addr_lo);
+ if (!msi_virt)
+ return -ENOMEM;
+ msi->msi_addr_hi = (u32)(msi_phys >> 32);
+ msi->msi_addr_lo = (u32)(msi_phys & 0xffffffff);
+ dev_dbg(&dev->dev, "PCIE-MSI: msi address high 0x%x, low 0x%x\n",
+ msi->msi_addr_hi, msi->msi_addr_lo);
/* Progam the Interrupt handler Termination addr registers */
out_be32(msi->msi_regs + PEIH_TERMADH, msi->msi_addr_hi);
@@ -185,6 +189,8 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
out_be32(msi->msi_regs + PEIH_MSIED, *msi_data);
out_be32(msi->msi_regs + PEIH_MSIMK, *msi_mask);
+ dma_free_coherent(&dev->dev, 64, msi_virt, msi_phys);
+
return 0;
}
@@ -215,8 +221,6 @@ static int __devinit ppc4xx_msi_probe(struct platform_device *dev)
struct resource res;
int err = 0;
- msi = &ppc4xx_msi;/*keep the msi data for further use*/
-
dev_dbg(&dev->dev, "PCIE-MSI: Setting up MSI support...\n");
msi = kzalloc(sizeof(struct ppc4xx_msi), GFP_KERNEL);
@@ -242,6 +246,7 @@ static int __devinit ppc4xx_msi_probe(struct platform_device *dev)
dev_err(&dev->dev, "Error allocating MSI bitmap\n");
goto error_out;
}
+ ppc4xx_msi = *msi;
ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
--
1.7.3.4
^ permalink raw reply related
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-09 3:13 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, Michael Neuling, linux-kernel, Rob Herring,
linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120309003937.GC8680@flint.arm.linux.org.uk>
On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> > Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> > I remove it, then I get Kconfig warnings:
> >
> > warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> > (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
>
> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
Nope, Grant patch didn't mention a dependency.
Cheers,
Ben.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 2:36 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-kernel, linux-next, Paul Mackerras, Joe Perches,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
("net: powerpc: remove the legacy iSeries ethernet driver") from the
powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
error messages") from the net-next tree.
I just removed the file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the pci tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 1:32 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-kernel, linux-next, Paul Mackerras, Bjorn Helgaas,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
arch/powerpc/platforms/iseries/pci.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the powerpc
tree and commit 673c97562489 ("powerpc/PCI: replace pci_probe_only with
pci_flags") from the pci tree.
The former removed the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Russell King @ 2012-03-09 0:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Michael Neuling, linux-kernel, Rob Herring,
linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <1331249746.3105.40.camel@pasglop>
On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> I remove it, then I get Kconfig warnings:
>
> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-08 23:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michael Neuling, linux-kernel, Rob Herring, linux-next,
Paul Mackerras, linuxppc-dev, Russell King
In-Reply-To: <1331185951.3105.29.camel@pasglop>
On Thu, 2012-03-08 at 16:52 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-03-08 at 14:51 +1100, Stephen Rothwell wrote:
> > Hi Mikey,
> >
> > On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling <mikey@neuling.org> wrote:
> > >
> > > Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.
> > >
> > > In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
> > > selectable, which we don't want anymore since ad5b7f1350c2.
> >
> > Yes, indeed. I will fix up the merge resolution for tomorrow.
>
> This is my fault. Grant's patch had a collision and I manually fixed it
> up. While doing that, I put back MAY_HAVE_SPARSE_IRQ which the patch
> originally took out.
Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
I remove it, then I get Kconfig warnings:
warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 19/38] KVM: PPC: e500mc: add load inst fixup
From: Marcelo Tosatti @ 2012-03-08 22:36 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1330474206-14794-20-git-send-email-agraf@suse.de>
On Wed, Feb 29, 2012 at 01:09:47AM +0100, Alexander Graf wrote:
> There's always a chance we're unable to read a guest instruction. The guest
> could have its TLB mapped execute-, but not readable, something odd happens
> and our TLB gets flushed. So it's a good idea to be prepared for that case
> and have a fallback that allows us to fix things up in that case.
>
> Add fixup code that keeps guest code from potentially crashing our host kernel.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
> - fix whitespace
Still broken.
> - use explicit preempt counts
> ---
> arch/powerpc/kvm/bookehv_interrupts.S | 30 +++++++++++++++++++++++++++++-
> 1 files changed, 29 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
> index 63023ae..f7dc3f6 100644
> --- a/arch/powerpc/kvm/bookehv_interrupts.S
> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
> @@ -28,6 +28,7 @@
> #include <asm/asm-compat.h>
> #include <asm/asm-offsets.h>
> #include <asm/bitsperlong.h>
> +#include <asm/thread_info.h>
>
> #include "../kernel/head_booke.h" /* for THREAD_NORMSAVE() */
>
> @@ -171,9 +172,36 @@
> PPC_STL r30, VCPU_GPR(r30)(r4)
> PPC_STL r31, VCPU_GPR(r31)(r4)
> mtspr SPRN_EPLC, r8
> +
> + /* disable preemption, so we are sure we hit the fixup handler */
> +#ifdef CONFIG_PPC64
> + clrrdi r8,r1,THREAD_SHIFT
> +#else
> + rlwinm r8,r1,0,0,31-THREAD_SHIFT /* current thread_info */
> +#endif
> + li r7, 1
> + stw r7, TI_PREEMPT(r8)
> +
> isync
> - lwepx r9, 0, r5
> +
> + /*
> + * In case the read goes wrong, we catch it and write an invalid value
> + * in LAST_INST instead.
> + */
> +1: lwepx r9, 0, r5
> +2:
> +.section .fixup, "ax"
> +3: li r9, KVM_INST_FETCH_FAILED
> + b 2b
> +.previous
> +.section __ex_table,"a"
> + PPC_LONG_ALIGN
> + PPC_LONG 1b,3b
> +.previous
> +
> mtspr SPRN_EPLC, r3
> + li r7, 0
> + stw r7, TI_PREEMPT(r8)
> stw r9, VCPU_LAST_INST(r4)
> .endif
^ permalink raw reply
* Re: [PATCH] PPC: Don't sync timebase when inside VM
From: McClintock Matthew-B29882 @ 2012-03-08 18:46 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Wood Scott-B07421, kvm list, Alexander Graf,
<kvm-ppc@vger.kernel.org>, McClintock Matthew-B29882,
linuxppc-dev
In-Reply-To: <4F58FDC4.2080909@freescale.com>
On Thu, Mar 8, 2012 at 12:43 PM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote:
>> On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood <scottwood@freescale.com> wr=
ote:
>>> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote:
>>>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@freescale.com> =
wrote:
>>>>> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>>>>>
>>>>>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>>>>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>>>>>> hypervisor or no.
>>>>>>
>>>>>> The code says "if the kexec config option is enabled, do the sync". =
I'm fairly sure it's there for a reason.
>>>>>
>>>>> Sigh. =A0I forgot about that. =A0It's because instead of doing kexec =
the
>>>>> simple way, we actually physically reset the core. =A0We really shoul=
dn't
>>>>> do that. =A0And we *really* shouldn't do it just because CONFIG_KEXEC=
is
>>>>> defined, regardless of whether we're actually booting from kexec.
>>>>
>>>> How would one rocver a core that's off in the weeds?
>>>
>>> System reset?
>>
>> kdump restarts a kernel using a reserved memory region to inspect the
>> memory of the crashed kernel. Wouldn't system reset cause issues here?
>
> Oh, kdump.
>
> Maybe in that case, go ahead and reset the other cores (or halt them via
> some other means), but don't do anything with them. =A0Just boot a single
> core in the dump kernel, do the dumping, then reset the system?
Yes, we could do one core here... but is it worthwhile to do kexec and
kdump differently?
> Or if you must sync the timebase in Linux, do it the way U-Boot does
> (and skip it if you don't have access to the relevant CCSR bits).
Ok - I've never even looked at how the timebase sync was done in Linux
or u-boot. Just enabled the timebase sync
> Are I/O devices a problem with kdump and not resetting the system,
> especially on some of our chips where certain I/O devices are difficult
> to reset?
Anything still occurring will be problematic and *possibly* prevent us
from determining what caused the actual crash.
-M=
^ permalink raw reply
* Re: [PATCH] PPC: Don't sync timebase when inside VM
From: Scott Wood @ 2012-03-08 18:43 UTC (permalink / raw)
To: McClintock Matthew-B29882
Cc: <kvm-ppc@vger.kernel.org>, Wood Scott-B07421, linuxppc-dev,
Alexander Graf, kvm list
In-Reply-To: <CAEsOVNcqSBh0hmgUQcJJjD28JbreBqYygHF7Q6Y8uaFzdj2PYw@mail.gmail.com>
On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote:
> On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood <scottwood@freescale.com> wrote:
>> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote:
>>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@freescale.com> wrote:
>>>> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>>>>
>>>>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>>>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>>>>> hypervisor or no.
>>>>>
>>>>> The code says "if the kexec config option is enabled, do the sync". I'm fairly sure it's there for a reason.
>>>>
>>>> Sigh. I forgot about that. It's because instead of doing kexec the
>>>> simple way, we actually physically reset the core. We really shouldn't
>>>> do that. And we *really* shouldn't do it just because CONFIG_KEXEC is
>>>> defined, regardless of whether we're actually booting from kexec.
>>>
>>> How would one rocver a core that's off in the weeds?
>>
>> System reset?
>
> kdump restarts a kernel using a reserved memory region to inspect the
> memory of the crashed kernel. Wouldn't system reset cause issues here?
Oh, kdump.
Maybe in that case, go ahead and reset the other cores (or halt them via
some other means), but don't do anything with them. Just boot a single
core in the dump kernel, do the dumping, then reset the system?
Or if you must sync the timebase in Linux, do it the way U-Boot does
(and skip it if you don't have access to the relevant CCSR bits).
Are I/O devices a problem with kdump and not resetting the system,
especially on some of our chips where certain I/O devices are difficult
to reset?
-Scott
^ 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