* [PATCH 2/7] Add celleb_dma_dev_setup()
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
In-Reply-To: <2949748ba6ad7e14f0768ac3889267e42c050d7a.1200894155.git.michael@ellerman.id.au>
Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too
should set dma_data to dma_direct_offset.
Currently there's no pci_dma_dev_setup() routine for Celleb so add one.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/celleb/iommu.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/iommu.c b/arch/powerpc/platforms/celleb/iommu.c
index 41e1e6f..843a66f 100644
--- a/arch/powerpc/platforms/celleb/iommu.c
+++ b/arch/powerpc/platforms/celleb/iommu.c
@@ -72,6 +72,17 @@ static void __init celleb_init_direct_mapping(void)
dma_direct_offset = dma_base;
}
+static void celleb_dma_dev_setup(struct device *dev)
+{
+ dev->archdata.dma_ops = get_pci_dma_ops();
+ dev->archdata.dma_data = (void *)dma_direct_offset;
+}
+
+static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
+{
+ celleb_dma_dev_setup(&pdev->dev);
+}
+
static int celleb_of_bus_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -81,7 +92,7 @@ static int celleb_of_bus_notify(struct notifier_block *nb,
if (action != BUS_NOTIFY_ADD_DEVICE)
return 0;
- dev->archdata.dma_ops = get_pci_dma_ops();
+ celleb_dma_dev_setup(dev);
return 0;
}
@@ -94,6 +105,7 @@ static int __init celleb_init_iommu(void)
{
celleb_init_direct_mapping();
set_pci_dma_ops(&dma_direct_ops);
+ ppc_md.pci_dma_dev_setup = celleb_pci_dma_dev_setup;
bus_register_notifier(&of_platform_bus_type, &celleb_of_bus_notifier);
return 0;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 1/7] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
From: Michael Ellerman @ 2008-01-21 5:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, cbe-oss-dev
Store the direct_dma_offset in each device's dma_data in the case
where we're using the direct DMA ops.
We need to make sure we setup the ppc_md.pci_dma_dev_setup() callback
if we're using a non-zero offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index bceb5e1..9682b63 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct device *dev)
struct cbe_iommu *iommu;
struct dev_archdata *archdata = &dev->archdata;
- /* If we run without iommu, no need to do anything */
- if (get_pci_dma_ops() == &dma_direct_ops)
+ if (get_pci_dma_ops() == &dma_direct_ops) {
+ archdata->dma_data = (void *)dma_direct_offset;
return;
+ }
/* Current implementation uses the first window available in that
* node's iommu. We -might- do something smarter later though it may
@@ -690,6 +691,9 @@ static int __init cell_iommu_init_disabled(void)
dma_direct_offset += base;
+ if (dma_direct_offset != 0)
+ ppc_md.pci_dma_dev_setup = cell_pci_dma_dev_setup;
+
printk("iommu: disabled, direct DMA offset is 0x%lx\n",
dma_direct_offset);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Always hookup PHB IO resource even when empty
From: Michael Ellerman @ 2008-01-21 0:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080121003256.E1EBDDDDF0@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Mon, 2008-01-21 at 11:32 +1100, Benjamin Herrenschmidt wrote:
> We must always hookup the pci_bus resource 0 to the PHB io_resource even
> if the later is empty (the bus has no IO support). Otherwise, some other
> code will end up hooking it up to something bogus and the resource tree
> will end up being broken.
>
> This fixes boot on QS20 Cell blades where the IDE driver failed to allocate
> the IO resources due to breakage of the resource tree.
Tested-by: Michael Ellerman <michael@ellerman.id.au>
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] Always hookup PHB IO resource even when empty
From: Benjamin Herrenschmidt @ 2008-01-21 0:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We must always hookup the pci_bus resource 0 to the PHB io_resource even
if the later is empty (the bus has no IO support). Otherwise, some other
code will end up hooking it up to something bogus and the resource tree
will end up being broken.
This fixes boot on QS20 Cell blades where the IDE driver failed to allocate
the IO resources due to breakage of the resource tree.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This is for 2.6.25, fixes a bug in my PCI rework.
arch/powerpc/kernel/pci_64.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
--- linux-merge.orig/arch/powerpc/kernel/pci_64.c 2008-01-21 11:27:41.000000000 +1100
+++ linux-merge/arch/powerpc/kernel/pci_64.c 2008-01-21 11:28:07.000000000 +1100
@@ -357,7 +357,6 @@ void __devinit scan_phb(struct pci_contr
struct pci_bus *bus;
struct device_node *node = hose->dn;
int i, mode;
- struct resource *res;
DBG("PCI: Scanning PHB %s\n", node ? node->full_name : "<NO NAME>");
@@ -375,12 +374,10 @@ void __devinit scan_phb(struct pci_contr
pcibios_map_io_space(bus);
/* Wire up PHB bus resources */
- if (hose->io_resource.flags) {
- DBG("PCI: PHB IO resource = %016lx-%016lx [%lx]\n",
- hose->io_resource.start, hose->io_resource.end,
- hose->io_resource.flags);
- bus->resource[0] = res = &hose->io_resource;
- }
+ DBG("PCI: PHB IO resource = %016lx-%016lx [%lx]\n",
+ hose->io_resource.start, hose->io_resource.end,
+ hose->io_resource.flags);
+ bus->resource[0] = &hose->io_resource;
for (i = 0; i < 3; ++i) {
DBG("PCI: PHB MEM resource %d = %016lx-%016lx [%lx]\n", i,
hose->mem_resources[i].start,
^ permalink raw reply
* Fwd: MPIC ISU
From: vb @ 2008-01-20 20:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <f608b67d0801201216o60be67a1w3ead9714c3bba5aa@mail.gmail.com>
[add linuxppc-embedded@ozlabs.org,]
On Jan 19, 2008 8:19 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> >
> > what platform is linkstation and what kernel version can I find it in?
>
> arch/powerpc/platforms/embedded6xx/linkstation.c
>
> you should be able to find it 2.6.23 or newer.
>
Kumar, thank you for this clarification, I see this file in the latest kernel.
One more question, just out of curiosity - why is it in
platforms/embedded6xx and not in platforms/82xx - is there any
explicit reason for this distinction?
TIA,
/vb
> - k
>
>
^ permalink raw reply
* Re: [i2c] [PATCH 19 3/5] Clean up error returns
From: Jon Smirl @ 2008-01-20 15:39 UTC (permalink / raw)
To: Jean Delvare, Benjamin Herrenschmidt; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801200718q7304bc29q38e67580613189e4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
Here' s a version with the compares to zero switched to NO_IRQ. If I
understand how NO_IRQ works it is the correct change. My understanding
is that under ppc IRQ zero was legal and NO_IRQ was -1. But then the
whole kernel switched to NO_IRQ = zero. Powerpc updated to NO_IRQ=0
and used virtual IRQs to move a physical IRQ 0 to another IRQ number.
ppc was not changed. This driver does not appear to have been updated
to track this global change since it didn't initially use the NO_IRQ
define everywhere.
--
Jon Smirl
jonsmirl@gmail.com
[-- Attachment #2: jds-fix-err-returns --]
[-- Type: application/octet-stream, Size: 3562 bytes --]
Clean up error returns
Return errors that were being ignored in the mpc-i2c driver
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/i2c/busses/i2c-mpc.c | 38 +++++++++++++++++++++-----------------
1 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..a774cdf 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
u32 x;
int result = 0;
- if (i2c->irq == 0)
+ if (i2c->irq == NO_IRQ)
{
while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
schedule();
@@ -180,7 +180,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
static int mpc_write(struct mpc_i2c *i2c, int target,
const u8 * data, int length, int restart)
{
- int i;
+ int i, result;
unsigned timeout = i2c->adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
@@ -192,15 +192,17 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write target byte */
writeb((target << 1), i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
for (i = 0; i < length; i++) {
/* Write data byte */
writeb(data[i], i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
}
return 0;
@@ -210,7 +212,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
u8 * data, int length, int restart)
{
unsigned timeout = i2c->adap.timeout;
- int i;
+ int i, result;
u32 flags = restart ? CCR_RSTA : 0;
/* Start with MEN */
@@ -221,8 +223,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
/* Write target address byte - this time with the read flag set */
writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
if (length) {
if (length == 1)
@@ -234,8 +237,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i < length; i++) {
- if (i2c_wait(i2c, timeout, 0) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 0);
+ if (result < 0)
+ return result;
/* Generate txack on next to last byte */
if (i == length - 2)
@@ -321,12 +325,12 @@ static int fsl_i2c_probe(struct platform_device *pdev)
pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
- if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
+ i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
+ if (!i2c)
return -ENOMEM;
- }
i2c->irq = platform_get_irq(pdev, 0);
- if (i2c->irq < 0) {
+ if (i2c->irq < NO_IRQ) {
result = -ENXIO;
goto fail_get_irq;
}
@@ -341,7 +345,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
goto fail_map;
}
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
if ((result = request_irq(i2c->irq, mpc_i2c_isr,
IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
printk(KERN_ERR
@@ -364,7 +368,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return result;
fail_add:
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
fail_irq:
iounmap(i2c->base);
@@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(&i2c->adap);
platform_set_drvdata(pdev, NULL);
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
iounmap(i2c->base);
^ permalink raw reply related
* Re: [i2c] [PATCH 19 3/5] Clean up error returns
From: Jon Smirl @ 2008-01-20 15:18 UTC (permalink / raw)
To: Jean Delvare, Benjamin Herrenschmidt; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080120120730.06dd8a7f@hyperion.delvare>
On 1/20/08, Jean Delvare <khali@linux-fr.org> wrote:
> > @@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> > i2c_del_adapter(&i2c->adap);
> > platform_set_drvdata(pdev, NULL);
> >
> > - if (i2c->irq != 0)
> > + if (i2c->irq != NO_IRQ)
> > free_irq(i2c->irq, i2c);
> >
> > iounmap(i2c->base);
> >
> >
>
> Is this last chunk a cleanup or a bugfix? It seems that NO_IRQ can have
> value 0 or -1 depending on the architecture, so your change is real on
> some architectures.
I was confused by this too. Search the ppc list archives and there is
a thread about it where BenH tries to explain the correct way of
fixing it to me.
This is part of the ppc to powerpc conversion that has not been
completely cleaned up in this driver. NO_IRQ = -1 is ppc and NO_IRQ =
0 is powerpc. Since this driver didn't originally use the NO_IRQ
define it didn't get automatically converted. We need to identify the
right places where NO_IRQ should have been used.
>
> I have to admit that I'm a bit confused by the way IRQs are handled by
> this driver. On the one hand, there is code to handle polled-mode:
>
> static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> {
> (...)
> if (i2c->irq == 0)
I missed this one, it should have been NO_IRQ.
> {
> (...)
> } else {
> /* Interrupt mode */
>
> But on the other hand the initialization code bails out if the platform
> device doesn't provide an IRQ:
>
> static int fsl_i2c_probe(struct platform_device *pdev)
> {
> (...)
> i2c->irq = platform_get_irq(pdev, 0);
> if (i2c->irq < 0) {
> result = -ENXIO;
> goto fail_get_irq;
It is only bailing out on an error, not the NO_IRQ case. But maybe the
comparison needs to be with NO_IRQ instead of zero.
> }
>
> So it seems to me like the polling mode code is never actually used?
> Unless some platforms include an "empty" IRQ in their device
> definition. Which indeed seems to be the case... but then they set the
> IRQ to 0, NOT to NO_IRQ, so I'm wondering if the change you propose is
> really correct.
All of this is very confusing to me, There are physical IRQs and
virtual IRQs. Apparently zero is a legal physical IRQ but it is not a
legal virtual IRQ. We only get virtual IRQs in this code. We need to
get BenH to give us the right answer on these two cases.
>
> Either way, there are more places in the driver where the IRQ is
> compared to 0, so if your change is correct, it should be applied
> consistently. Thus I will revert this part for the time being, if any
> change is really needed with regards to interrupts in this driver,
> please send a separate patch. But please double-check first, as I said
> above it's trickier than it looks.
>
> --
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH 19 3/5] Clean up error returns
From: Jean Delvare @ 2008-01-20 11:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080112024743.7023.23630.stgit@terra.home>
Hi Jon,
On Fri, 11 Jan 2008 21:47:43 -0500, Jon Smirl wrote:
> Return errors that were being ignored in the mpc-i2c driver
This wording is a bit excessive. The errors were not being ignored,
only the error code was replaced with a less informative -1. Still,
that's a good fix, although totally unrelated with the patch set it was
hiding into. The only question I have is:
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> ---
>
> drivers/i2c/busses/i2c-mpc.c | 30 +++++++++++++++++-------------
> 1 files changed, 17 insertions(+), 13 deletions(-)
>
>
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index d8de4ac..7c35a8f 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -180,7 +180,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
> static int mpc_write(struct mpc_i2c *i2c, int target,
> const u8 * data, int length, int restart)
> {
> - int i;
> + int i, result;
> unsigned timeout = i2c->adap.timeout;
> u32 flags = restart ? CCR_RSTA : 0;
>
> @@ -192,15 +192,17 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
> /* Write target byte */
> writeb((target << 1), i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + result = i2c_wait(i2c, timeout, 1);
> + if (result < 0)
> + return result;
>
> for (i = 0; i < length; i++) {
> /* Write data byte */
> writeb(data[i], i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + result = i2c_wait(i2c, timeout, 1);
> + if (result < 0)
> + return result;
> }
>
> return 0;
> @@ -210,7 +212,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
> u8 * data, int length, int restart)
> {
> unsigned timeout = i2c->adap.timeout;
> - int i;
> + int i, result;
> u32 flags = restart ? CCR_RSTA : 0;
>
> /* Start with MEN */
> @@ -221,8 +223,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
> /* Write target address byte - this time with the read flag set */
> writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + result = i2c_wait(i2c, timeout, 1);
> + if (result < 0)
> + return result;
>
> if (length) {
> if (length == 1)
> @@ -234,8 +237,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
> }
>
> for (i = 0; i < length; i++) {
> - if (i2c_wait(i2c, timeout, 0) < 0)
> - return -1;
> + result = i2c_wait(i2c, timeout, 0);
> + if (result < 0)
> + return result;
>
> /* Generate txack on next to last byte */
> if (i == length - 2)
> @@ -321,9 +325,9 @@ static int fsl_i2c_probe(struct platform_device *pdev)
>
> pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
>
> - if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
> + i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
> + if (!i2c)
> return -ENOMEM;
> - }
>
> i2c->irq = platform_get_irq(pdev, 0);
> if (i2c->irq < 0) {
> @@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> i2c_del_adapter(&i2c->adap);
> platform_set_drvdata(pdev, NULL);
>
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> free_irq(i2c->irq, i2c);
>
> iounmap(i2c->base);
>
>
Is this last chunk a cleanup or a bugfix? It seems that NO_IRQ can have
value 0 or -1 depending on the architecture, so your change is real on
some architectures.
I have to admit that I'm a bit confused by the way IRQs are handled by
this driver. On the one hand, there is code to handle polled-mode:
static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
{
(...)
if (i2c->irq == 0)
{
(...)
} else {
/* Interrupt mode */
But on the other hand the initialization code bails out if the platform
device doesn't provide an IRQ:
static int fsl_i2c_probe(struct platform_device *pdev)
{
(...)
i2c->irq = platform_get_irq(pdev, 0);
if (i2c->irq < 0) {
result = -ENXIO;
goto fail_get_irq;
}
So it seems to me like the polling mode code is never actually used?
Unless some platforms include an "empty" IRQ in their device
definition. Which indeed seems to be the case... but then they set the
IRQ to 0, NOT to NO_IRQ, so I'm wondering if the change you propose is
really correct.
Either way, there are more places in the driver where the IRQ is
compared to 0, so if your change is correct, it should be applied
consistently. Thus I will revert this part for the time being, if any
change is really needed with regards to interrupts in this driver,
please send a separate patch. But please double-check first, as I said
above it's trickier than it looks.
--
Jean Delvare
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 7/8] Factor out 52xx dependencies from 52xx psc driver
From: John Rigby @ 2008-01-20 3:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801182259k22663ca9s74b109f0f15d11fd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
Do you get a "Can't open initial console" message or just no output?
On Jan 18, 2008 11:59 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/18/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 1/17/08, John Rigby <jrigby@freescale.com> wrote:
> > > PSCs change from 5200 to 5121
> > > this patch localizes the differences in
> > > preparation for adding 5121 support
> > >
> > > Signed-off-by: John Rigby <jrigby@freescale.com>
> >
> > This patch breaks the serial console on my Efika.
>
> Er, more specifically, I get console output, but I get no output from
> the init process (like when I add "init=/bin/sh" to the kernel
> parameters).
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 1583 bytes --]
^ permalink raw reply
* Re: MPIC ISU
From: Kumar Gala @ 2008-01-19 16:19 UTC (permalink / raw)
To: vb; +Cc: linuxppc-embedded
In-Reply-To: <f608b67d0801181044j352ee94dl50ea291164f4cb17@mail.gmail.com>
On Jan 18, 2008, at 12:44 PM, vb wrote:
> Kumar,
>
> thank you for your reply!
>
> On Jan 18, 2008 7:54 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>>>
>>> What is it, at the very least - what does ISU stand for?
>>>
>>> I would really appreciate any hints,
>>
>> Interrupt service unit. I believe its an IBM concept.
>>
>> For 8245 can you look at what the linkstation port is doing and mimic
>> that. I believe its an 8245 or 8241 so it should be close to what
>> you
>> need.
>>
>
> what platform is linkstation and what kernel version can I find it in?
arch/powerpc/platforms/embedded6xx/linkstation.c
you should be able to find it 2.6.23 or newer.
- k
^ permalink raw reply
* Re: [RFC/PATCH 1/2] [POWERPC] mpc5200: normalize compatible property bindings
From: Stephen Rothwell @ 2008-01-19 12:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, jrigby
In-Reply-To: <20080118170443.10592.97538.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Hi Grant,
On Fri, 18 Jan 2008 10:04:49 -0700 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> +++ b/arch/powerpc/platforms/52xx/lite5200.c
> @@ -44,9 +44,14 @@ lite5200_fix_clock_config(void)
> {
> struct device_node *np;
> struct mpc52xx_cdm __iomem *cdm;
> + struct of_device_id cdm_ids[] = {
Surely this should be static and __initdata?
> @@ -79,9 +84,14 @@ lite5200_fix_port_config(void)
> {
> struct device_node *np;
> struct mpc52xx_gpio __iomem *gpio;
> + struct of_device_id gpio_ids[] = {
And this?
> +++ b/arch/powerpc/platforms/52xx/lite5200_pm.c
> @@ -43,6 +43,12 @@ static int lite5200_pm_set_target(suspend_state_t state)
> static int lite5200_pm_prepare(void)
> {
> struct device_node *np;
> + struct of_device_id immr_ids[] = {
This should be static and const.
Similarly for the rest ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] Get rid of conditional includes of board specific setup
From: Arnd Bergmann @ 2008-01-19 12:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <4790B891.3050106@scram.de>
On Friday 18 January 2008, Jochen Friedrich wrote:
> Directly include mpc885ads.h from mpc885ads_setup.c. Now we can get rid
> of the arch dependent includes in mpc8xx.h.
Ah, very nice. How close are we to enabling an 8xx multiplatform
build after this?
> =A0#ifdef CONFIG_8xx
> =A0
> =A0extern void mpc8xx_restart(char *cmd);
> @@ -18,22 +20,9 @@ extern void mpc8xx_get_rtc_time(struct rtc_time *tm);
> =A0extern void mpc8xx_pics_init(void);
> =A0extern unsigned int mpc8xx_get_irq(void);
>=20
> #ifdef CONFIG_PCMCIA_M8XX
> extern struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
> #endif
=20
> =A0#endif /* CONFIG_8xx */
> =A0#endif /* __CONFIG_8xx_DEFS */
You can also kill the #ifdef CONFIG_8xx and the #ifdef CONFIG_PCMCIA_M8XX,
there is no point hiding extern declarations behind an #ifdef, but it
has the disadvantage of causing unnecessary rebuilds if the configuration
symbols change.
Arnd <><
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 7/8] Factor out 52xx dependencies from 52xx psc driver
From: Grant Likely @ 2008-01-19 6:59 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801182258r5a3b6465kf0e7918e0e56e0c4@mail.gmail.com>
On 1/18/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/17/08, John Rigby <jrigby@freescale.com> wrote:
> > PSCs change from 5200 to 5121
> > this patch localizes the differences in
> > preparation for adding 5121 support
> >
> > Signed-off-by: John Rigby <jrigby@freescale.com>
>
> This patch breaks the serial console on my Efika.
Er, more specifically, I get console output, but I get no output from
the init process (like when I add "init=/bin/sh" to the kernel
parameters).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 7/8] Factor out 52xx dependencies from 52xx psc driver
From: Grant Likely @ 2008-01-19 6:58 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <1200614738-25654-8-git-send-email-jrigby@freescale.com>
On 1/17/08, John Rigby <jrigby@freescale.com> wrote:
> PSCs change from 5200 to 5121
> this patch localizes the differences in
> preparation for adding 5121 support
>
> Signed-off-by: John Rigby <jrigby@freescale.com>
This patch breaks the serial console on my Efika.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-19 4:56 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel, Linux MM
In-Reply-To: <20080117202024.GA25090@aepfle.de>
On Thu, 17 Jan 2008, Olaf Hering wrote:
> On Thu, Jan 17, Olaf Hering wrote:
>
> > Since -mm boots further, what patch should I try?
>
> rc8-mm1 crashes as well, l3 passed to reap_alien() is NULL.
Sigh. It looks like we need alien cache structures in some cases for nodes
that have no memory. We must allocate structures for all nodes regardless
if they have allocatable memory or not.
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-19 4:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel, Linux MM
In-Reply-To: <20080118065621.GA27495@aepfle.de>
On Fri, 18 Jan 2008, Olaf Hering wrote:
> calls cache_grow with nodeid 0
> > [c00000000075bbd0] [c0000000000f82d0] .cache_alloc_refill+0x234/0x2c0
> calls cache_grow with nodeid 0
> > [c00000000075bbe0] [c0000000000f7f38] .____cache_alloc_node+0x17c/0x1e8
>
> calls cache_grow with nodeid 1
> > [c00000000075bbe0] [c0000000000f7d68] .fallback_alloc+0x1a0/0x1f4
Okay that makes sense. You have no node 0 with normal memory but the node
assigned to the executing processor is zero (correct?). Thus it needs to
fallback to node 1 and that is not possible during bootstrap. You need to
run kmem_cache_init() on a cpu on a processor with memory.
Or we need to revert the patch which would allocate control
structures again for all online nodes regardless if they have memory or
not.
Does reverting 04231b3002ac53f8a64a7bd142fde3fa4b6808c6 change the
situation? (However, we tried this on the other thread without success).
^ permalink raw reply
* [PATCH/RFC] [POWERPC] Allow multiple images to be built when CONFIG_DEFAULT_UIMAGE set
From: Grant Likely @ 2008-01-19 3:55 UTC (permalink / raw)
To: linuxppc-dev, paulus, scottwood, david
From: Grant Likely <grant.likely@secretlab.ca>
Most of the embedded board ports select CONFIG_DEFAULT_UIMAGE so that
uImage files get built by default. However, the current code casues
the arch/powerpc/boot/Makefile to be called with the 'uImage' target
and adds 'uImage' to the 'image-y' make variable. If CONFIG_DEFAULT_UIMAGE
is not set, then the boot makefile is called with target 'zImage'.
However, the zImage target already automatically causes all targets
listed in 'image-y' to be built, which includes uImage.
This patch makes the default build target alwasy call the boot makefile
using the 'zImage' target, regardless of if CONFIG_DEFAULT_UIMAGE is set.
Making this change allows multiple boot images to be built from a single
kernel compile. An example of where this is useful is with the Efika
and lite5200 boards. Both boards can use the same kernel image (vmlinux),
but they use different boot image files (zImage.chrp vs. uImage). By
making this change, the boot makefile now builds both by default so a
single defconfig can be used for testing both platforms.
This patch also eliminates the BOOTIMAGE variable because it doesn't
appear to be used anywhere. (Someone please correct me if I'm wrong)
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/Makefile | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f70df9b..6451c2f 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -151,10 +151,7 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/
drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
-defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
-KBUILD_IMAGE := $(defaultimage-y)
-all: $(KBUILD_IMAGE)
+all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
@@ -180,7 +177,7 @@ define archhelp
endef
install: vdso_install
- $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+ $(Q)$(MAKE) $(build)=$(boot) install
vdso_install:
ifeq ($(CONFIG_PPC64),y)
^ permalink raw reply related
* Re: ml310 kernel2.6 booting problems
From: Grant Likely @ 2008-01-19 1:23 UTC (permalink / raw)
To: Ron Sass; +Cc: Jean-Samuel Chenard, linuxppc-embedded
In-Reply-To: <200801190011.m0J0BCtr001286@rsass-homer.uncc.edu>
On 1/18/08, Ron Sass <rsass@uncc.edu> wrote:
> My question is this: Would it make sense to have a Kernel
> configuration something like "VIRTEX_PCI" and a platforms
> "XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
>
> XILINX_ML300
> XILINX_ML310
> XILINX_ML40x
> XILINX_ML410
The whole CONFIG_XILINX_ML*** stuff will be disappearing as part of
the migration from arch/ppc to arch/powerpc. Instead, the board
configuration will be described using a device tree file (dts). Feel
free to add stuff in your local tree, but be prepared to migrate your
drivers in the next 6 months or so.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: ml310 kernel2.6 booting problems
From: Ron Sass @ 2008-01-19 1:21 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20080119003518.25AC41CF8068@mail125-dub.bigfish.com>
Oops. I should have looked at git.xilinx.com. I've been using
secretlab's for a while and I saw xilinx site come up but never
took the time to investigate. Even if it not mainline suitable
code and 2.6.10-era, I would be interested. I'll explore in my
free time over the next couple of weeks and see what I can figure
out.
Thanks for the speedy response!
Ron
>
> Ron,
>
> It might be better to start with the kernel from git.xilinx.com, which
> already has an ML41x option. The current version of EDK will also
> generate support for ML410 with the PCI driver, if you are still using a
> 2.6.10-era kernel. =20
>
> I've refrained putting the PCI stuff on git.xilinx.com, because any
> non-trivial usage of it that I've tried has generated warnings. On top
> of that, the code has some interrupt values hardcoded in the ALI
> southbridge code. Since there is no way to have this code pushed into
> mainline, I'm not terribly interested in encouraging any work on it,
> either. Perhaps since there is so much interest in this code, someone
> would like to get it working in ARCH=3Dpowerpc? I'm happy to provide =
> some
> handholding to get someone started.
>
> Steve
>
> > -----Original Message-----
> > From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
> > bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Ron Sass
> > Sent: Friday, January 18, 2008 4:11 PM
> > To: Jean-Samuel Chenard
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: ml310 kernel2.6 booting problems
> >=20
> >=20
> > Hello All,
> >=20
> > I have a sidewise question related to this thread. We have
> > several ML-310 and ML-410 boards. At some point, we may need
> > PCI but right now it is not urgent so I am not ready to invest
> > a lot of time yet either. I imagine that 2.6 + PCI would be
> > relatively similiar for both ML-310 and ML-410...
> >=20
> > My question is this: Would it make sense to have a Kernel
> > configuration something like "VIRTEX_PCI" and a platforms
> > "XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
> >=20
> > XILINX_ML300
> > XILINX_ML310
> > XILINX_ML40x
> > XILINX_ML410
> >=20
> > I ask now because we are working on some device drivers for
> > the ML410 that may work on 40x and I wondering if I should
> > introduce a new ML410 platform option...
> >=20
> > Ron
> >=20
> > > > Date: Thu, 17 Jan 2008 21:19:04 +0100
> > > > From: Joachim Meyer
> > > > Hmmm... I'm not really ready to invest that much time into the PCI
> for ML=3D
> > > -310.
> > > >
> ------------------------------------------------------------------------
> -=3D
> > > -------
> > > >
> http://ozlabs.org/pipermail/linuxppc-embedded/2007-December/029211.html
> > > >
> > > > How much work would it be (approximated), and do you think I can
> success =3D
> > > (I'm a novice, like you know)?
> > > > Would you help me (Tell me where to start & what to do)?
> > >
> > > Hi Joachim,
> > >
> > > I was also interested in getting the PCI to run on the ML-310. I
> did
> > > spend an evening trying to integrate a patch sent over by Stephen
> > > Neuendorffer from Xilinx. I managed to get everything to compile
> > > (basically I fixed a few missing macros and had to search a bit to
> > > ensure that the memory mapping was correctly ported).
> Unfortunately,
> > > when I tried the new kernel, I think that I must have messed
> something
> > > up with the interrupt mappings (I am a newbie to PCI) and I had to
> > > remove some interrupt mapping from Stephen's patch.
> > >
> > > In any case, my ML-310 was booting the Linux kernel, but something
> was
> > > not right and I did not get anymore printouts from the UART Lite.
> > > Since I don't have the JTAG cable, I was stuck at this point with
> > > little means to debug the system. One day I'll spoil myself with
> one
> > > of those platform JTAG USB cables...
> > >
> > > I used Z-modem to transfer files to/from my workstation to my CF
> card
> > > on the ML-310 and this was an acceptable compromise.
> > >
> > > I'd still be interested in having the PCI bus working on the ML-310,
> > > but now that I got my BEE2 booting Linux 2.6, its not such a big
> > > priority for me. Let me know if you have some success in that
> > > direction.
> > >
> > > Regards,
> > >
> > > Jean-Samuel
> > > -- =3D
> > >
> > > Integrated Microsystems Laboratory
> > > McGill University, Montr=3DE9al, QC, CANADA
> > > Web Page: http://chaos.ece.mcgill.ca
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* RE: ml310 kernel2.6 booting problems
From: Stephen Neuendorffer @ 2008-01-19 0:35 UTC (permalink / raw)
To: Ron Sass, Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <200801190011.m0J0BCtr001286@rsass-homer.uncc.edu>
Ron,
It might be better to start with the kernel from git.xilinx.com, which
already has an ML41x option. The current version of EDK will also
generate support for ML410 with the PCI driver, if you are still using a
2.6.10-era kernel. =20
I've refrained putting the PCI stuff on git.xilinx.com, because any
non-trivial usage of it that I've tried has generated warnings. On top
of that, the code has some interrupt values hardcoded in the ALI
southbridge code. Since there is no way to have this code pushed into
mainline, I'm not terribly interested in encouraging any work on it,
either. Perhaps since there is so much interest in this code, someone
would like to get it working in ARCH=3Dpowerpc? I'm happy to provide =
some
handholding to get someone started.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Ron Sass
> Sent: Friday, January 18, 2008 4:11 PM
> To: Jean-Samuel Chenard
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: ml310 kernel2.6 booting problems
>=20
>=20
> Hello All,
>=20
> I have a sidewise question related to this thread. We have
> several ML-310 and ML-410 boards. At some point, we may need
> PCI but right now it is not urgent so I am not ready to invest
> a lot of time yet either. I imagine that 2.6 + PCI would be
> relatively similiar for both ML-310 and ML-410...
>=20
> My question is this: Would it make sense to have a Kernel
> configuration something like "VIRTEX_PCI" and a platforms
> "XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
>=20
> XILINX_ML300
> XILINX_ML310
> XILINX_ML40x
> XILINX_ML410
>=20
> I ask now because we are working on some device drivers for
> the ML410 that may work on 40x and I wondering if I should
> introduce a new ML410 platform option...
>=20
> Ron
>=20
> > > Date: Thu, 17 Jan 2008 21:19:04 +0100
> > > From: Joachim Meyer
> > > Hmmm... I'm not really ready to invest that much time into the PCI
for ML=3D
> > -310.
> > >
------------------------------------------------------------------------
-=3D
> > -------
> > >
http://ozlabs.org/pipermail/linuxppc-embedded/2007-December/029211.html
> > >
> > > How much work would it be (approximated), and do you think I can
success =3D
> > (I'm a novice, like you know)?
> > > Would you help me (Tell me where to start & what to do)?
> >
> > Hi Joachim,
> >
> > I was also interested in getting the PCI to run on the ML-310. I
did
> > spend an evening trying to integrate a patch sent over by Stephen
> > Neuendorffer from Xilinx. I managed to get everything to compile
> > (basically I fixed a few missing macros and had to search a bit to
> > ensure that the memory mapping was correctly ported).
Unfortunately,
> > when I tried the new kernel, I think that I must have messed
something
> > up with the interrupt mappings (I am a newbie to PCI) and I had to
> > remove some interrupt mapping from Stephen's patch.
> >
> > In any case, my ML-310 was booting the Linux kernel, but something
was
> > not right and I did not get anymore printouts from the UART Lite.
> > Since I don't have the JTAG cable, I was stuck at this point with
> > little means to debug the system. One day I'll spoil myself with
one
> > of those platform JTAG USB cables...
> >
> > I used Z-modem to transfer files to/from my workstation to my CF
card
> > on the ML-310 and this was an acceptable compromise.
> >
> > I'd still be interested in having the PCI bus working on the ML-310,
> > but now that I got my BEE2 booting Linux 2.6, its not such a big
> > priority for me. Let me know if you have some success in that
> > direction.
> >
> > Regards,
> >
> > Jean-Samuel
> > -- =3D
> >
> > Integrated Microsystems Laboratory
> > McGill University, Montr=3DE9al, QC, CANADA
> > Web Page: http://chaos.ece.mcgill.ca
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: ml310 kernel2.6 booting problems
From: Ron Sass @ 2008-01-19 0:11 UTC (permalink / raw)
To: Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <169c03cb0801171849i59d35893hda44a7f0c5417b58@mail.gmail.com>
Hello All,
I have a sidewise question related to this thread. We have
several ML-310 and ML-410 boards. At some point, we may need
PCI but right now it is not urgent so I am not ready to invest
a lot of time yet either. I imagine that 2.6 + PCI would be
relatively similiar for both ML-310 and ML-410...
My question is this: Would it make sense to have a Kernel
configuration something like "VIRTEX_PCI" and a platforms
"XILINX_ML4xx" / "XILINX_ML3xx" ... or create four platforms:
XILINX_ML300
XILINX_ML310
XILINX_ML40x
XILINX_ML410
I ask now because we are working on some device drivers for
the ML410 that may work on 40x and I wondering if I should
introduce a new ML410 platform option...
Ron
> > Date: Thu, 17 Jan 2008 21:19:04 +0100
> > From: Joachim Meyer
> > Hmmm... I'm not really ready to invest that much time into the PCI for ML=
> -310.
> > -------------------------------------------------------------------------=
> -------
> > http://ozlabs.org/pipermail/linuxppc-embedded/2007-December/029211.html
> >
> > How much work would it be (approximated), and do you think I can success =
> (I'm a novice, like you know)?
> > Would you help me (Tell me where to start & what to do)?
>
> Hi Joachim,
>
> I was also interested in getting the PCI to run on the ML-310. I did
> spend an evening trying to integrate a patch sent over by Stephen
> Neuendorffer from Xilinx. I managed to get everything to compile
> (basically I fixed a few missing macros and had to search a bit to
> ensure that the memory mapping was correctly ported). Unfortunately,
> when I tried the new kernel, I think that I must have messed something
> up with the interrupt mappings (I am a newbie to PCI) and I had to
> remove some interrupt mapping from Stephen's patch.
>
> In any case, my ML-310 was booting the Linux kernel, but something was
> not right and I did not get anymore printouts from the UART Lite.
> Since I don't have the JTAG cable, I was stuck at this point with
> little means to debug the system. One day I'll spoil myself with one
> of those platform JTAG USB cables...
>
> I used Z-modem to transfer files to/from my workstation to my CF card
> on the ML-310 and this was an acceptable compromise.
>
> I'd still be interested in having the PCI bus working on the ML-310,
> but now that I got my BEE2 booting Linux 2.6, its not such a big
> priority for me. Let me know if you have some success in that
> direction.
>
> Regards,
>
> Jean-Samuel
> -- =
>
> Integrated Microsystems Laboratory
> McGill University, Montr=E9al, QC, CANADA
> Web Page: http://chaos.ece.mcgill.ca
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: ping 127.0.0.1 takes too much
From: Scott Wood @ 2008-01-18 23:17 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8E264A1B@aquib01a>
DI BACCO ANTONIO - technolabs wrote:
>
> >Are you sure the timebase clock is what the kernel thinks it is? Does
> >the time-of-day clock progress at the correct rate?
>
> The kernel receives the CPU clock from the bdinfo structure and thus I
> think the kernel knows how fast the CPU is.
That wasn't what I asked. I asked whether you checked whether it was
actually correct or not. I've seen it be wrong quite often.
-Scott
^ permalink raw reply
* RE: ping 127.0.0.1 takes too much
From: DI BACCO ANTONIO - technolabs @ 2008-01-18 23:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <47912CDA.9020603@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]
>Are you sure the timebase clock is what the kernel thinks it is? Does
>the time-of-day clock progress at the correct rate?
The kernel receives the CPU clock from the bdinfo structure and thus I think the kernel knows how fast the CPU is.
Bye,
Antonio.
[-- Attachment #2: Type: text/html, Size: 683 bytes --]
^ permalink raw reply
* Re: [PATCH 05/10] powerpc: Add crash kernel support for 85xx
From: Dale Farnsworth @ 2008-01-18 23:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <96E82635-F660-4D42-8834-2AF6AD264C28@kernel.crashing.org>
On Fri, Jan 18, 2008 at 04:29:23PM -0600, Kumar Gala wrote:
> On Dec 14, 2007, at 11:23 AM, Dale Farnsworth wrote:
>> On Fri, Dec 14, 2007 at 10:48:58AM -0600, Kumar Gala wrote:
>>> On Nov 22, 2007, at 9:46 AM, Dale Farnsworth wrote:
>>>
>>>> Add the ability to build a ppc_85xx kernel to run at a physical
>>>> address of 32MB.
>>>>
>>>> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
>>>> ---
>>>> arch/powerpc/Kconfig | 2 +-
>>>> arch/powerpc/kernel/head_fsl_booke.S | 23 ++++++++++++++++++-----
>>>> arch/powerpc/mm/fsl_booke_mmu.c | 6 +++---
>>>> 3 files changed, 22 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>>> index 805b4d1..d405298 100644
>>>> --- a/arch/powerpc/Kconfig
>>>> +++ b/arch/powerpc/Kconfig
>>>> @@ -253,7 +253,7 @@ config KEXEC
>>>>
>>>> config CRASH_DUMP
>>>> bool "Build a kdump crash kernel (EXPERIMENTAL)"
>>>> - depends on PPC_MULTIPLATFORM && EXPERIMENTAL
>>>> + depends on (PPC_MULTIPLATFORM || PPC_85xx) && EXPERIMENTAL
>>>> help
>>>> Build a kernel suitable for use as a kdump capture kernel.
>>>> The kernel will be linked at a different address than normal, and
>>>> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/
>>>> kernel/head_fsl_booke.S
>>>> index 4b98227..1c9685f 100644
>>>> --- a/arch/powerpc/kernel/head_fsl_booke.S
>>>> +++ b/arch/powerpc/kernel/head_fsl_booke.S
>>>> @@ -41,6 +41,12 @@
>>>> #include <asm/asm-offsets.h>
>>>> #include "head_booke.h"
>>>>
>>>> +#ifdef CONFIG_CRASH_DUMP
>>>> +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_64M)
>>>> +#else
>>>> +#define INITIAL_BOOKE_PAGESZ (BOOKE_PAGESZ_16M)
>>>> +#endif
>>>
>>> I'm ok with bumping the first page to 64M in all cases.
>>
>> OK, I'll make that change in the next rev. Thanks.
>
> I'm about to commit a version of this patch, why did you need to bump to
> 64M?
See below.
>> <snip>
>>
>>> The rest looks good. Does this mean we can boot a e500 kernel at a
>>> non-zero physical address? (can we run or is the non-zero phy just
>>> for a short period of init time).
>>
>> Yes, with this series of patches, we can boot and run with a classic ppc
>> or e500 kernel at 32MB physical (0xc2000000 virtual). Note that on
>> classic, we still need memory at phys 0 for the exception vectors.
>> On e500 IIRC, we don't use the vectors at phys 0, but we still write
>> the trampoline vectors there. I just didn't bother making that
>> conditional.
>
> trampoline vectors?
Even though the kernel is loaded at 32M, the vectors still reside at 0
(at least on non-booke). There is code that saves the low 64K away, then
create_trampoline() in crash_dump.c fills each vector with a "b . + 32M"
sequence.
As to why 64M, since the kernel is loaded at 32M, and we still set up
the trampoline vectors at 0, we need more than 16M. It's possible
that we could skip writing the trampoline vectors on booke and
then just just initially map 16M at 32M. I haven't tried it and
can't prove that it won't work, but I don't know that it's worth doing.
>> I'll post an updated series soon, with hopes of getting it into 2.6.25
I think my time for doing it "soon" has passed. Still plan to do it.
Kumar, thanks for pursuing this.
-Dale
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Olaf Hering @ 2008-01-18 22:57 UTC (permalink / raw)
To: Christoph Lameter
Cc: lee.schermerhorn, Linux MM, Mel Gorman, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801181414200.8924@schroedinger.engr.sgi.com>
On Fri, Jan 18, Christoph Lameter wrote:
> Could you try this patch?
Does not help, same crash.
^ 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