Re: ioremap and vmalloc
The chip that I am using is a MPC7448. The Kernel version is 2.6.26. I am developping my own driver. I am making some tests Josh Boyer a écrit : On Fri, Sep 19, 2008 at 06:45:01PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: if I write : ioremap(0x2000,0x4) and ioremap(0x2000,0x5) Will it crash ? I have no idea. You haven't given us enough information to really answer that. Basic information needed would be: 1) What board/chip 2) What kernel version 3) What are you actually trying to do 4) What driver are you using 5) If you are writing your own, where is the code for it etc. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioremap and vmalloc
I made a mistake. The right code is : ioremap(0x2000,0x4) and ioremap(0x8000,0x5) Grant Likely a écrit : On Fri, Sep 19, 2008 at 10:58 AM, Josh Boyer <[EMAIL PROTECTED]> wrote: On Fri, Sep 19, 2008 at 06:45:01PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: if I write : ioremap(0x2000,0x4) and ioremap(0x2000,0x5) Will it crash ? I have no idea. You haven't given us enough information to really answer that. But I can say that the second ioremap() call makes the first ioremap() both redundant and inefficient. You're using exactly the same base address so the same region is getting mapped twice. Since the second call uses a bigger region than the first then the kernel will probably need to allocate another chunk of virtual address space to map it instead of reusing the first mapping. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioremap and vmalloc
if I write : ioremap(0x2000,0x4) and ioremap(0x2000,0x5) Will it crash ? Josh Boyer a écrit : On Fri, Sep 19, 2008 at 06:34:06PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: The first is ioremap(0x2000,0x1000); The second is ioremap(0x8000,0x1000); Is it too long The error message you are getting should have been a very strong hint that the answer is "yes." josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patchwork states and workflow
On Fri, 2008-09-19 at 15:59 -0700, Paul Mackerras wrote: > Kumar Gala writes: > > > I've always been a bit confused about some of the states we can put a > > patch in. For example, what does 'archiving' a patch mean? > > Archiving puts the patch away somewhere where it doesn't appear in the > normal pages and needs extra effort to get to, as I understand it. > > > What's the difference between 'deferred' and 'rejected'? Is 'Under > > Review' useful? > > Deferred usually means the patch depends on something else that isn't > upstream, such as patches that only apply against the RT tree. > Rejected means we just don't want to do what the patch does. > > > My biggest question is how to manage the transition of 'Accepted' and > > 'Awaiting Upstream' and having clear definitions of what we think > > these mean. > > I put patches into "awaiting upstream" when I put them in a bundle, so > it means that they have entered my QA process. When they're in my > public tree, I put them into "accepted" state. Note, Kumar, that I have a git hook that will generate a file that lists the sha1 and corresponding patchwork IDs when you use git-am. I can send that to you when I'm back. You can then use a little tool that automatically update patchwork based on that file, filing the SHA1 reference in the database and switching the patches to "accepted" state. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] edac: mpc85xx: Add support for MPC8572
From: Andrew Kilkenny <[EMAIL PROTECTED]>
This adds support for the dual-core MPC8572 processor. We have
to support making SPR changes on each core. Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.
Signed-off-by: Andrew Kilkenny <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/edac/mpc85xx_edac.c | 28 +++-
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..63bdc47 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];
/ MC SYSFS parts ***/
@@ -647,6 +648,9 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{
.compatible = "fsl,8568-l2-cache-controller",
},
+ {
+.compatible = "fsl,mpc8572-l2-cache-controller",
+},
{},
};
@@ -912,7 +916,8 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device
*op,
/* register interrupts */
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_mc_isr, IRQF_DISABLED,
+ mpc85xx_mc_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] MC err", mci);
if (res < 0) {
printk(KERN_ERR "%s: Unable to request irq %d for "
@@ -980,6 +985,9 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{
.compatible = "fsl,8568-memory-controller",
},
+ {
+.compatible = "fsl,mpc8572-memory-controller",
+},
{},
};
@@ -995,6 +1003,12 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+ orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x2));
+}
+
static int __init mpc85xx_mc_init(void)
{
int res = 0;
@@ -1031,8 +1045,7 @@ static int __init mpc85xx_mc_init(void)
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT) {
- orig_hid1 = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1 & ~0x2));
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
return 0;
@@ -1040,9 +1053,14 @@ static int __init mpc85xx_mc_init(void)
module_init(mpc85xx_mc_init);
+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+ mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
static void __exit mpc85xx_mc_exit(void)
{
- mtspr(SPRN_HID1, orig_hid1);
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.6.0.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
On Thu, 18 Sep 2008 19:17:46 +0400
Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> This patch adds support for the FHCI USB controller, as found
> in the Freescale MPC836x and MPC832x processors. It can support
> Full or Low speed modes.
>
> Quite a lot the hardware is doing by itself (SOF generation, CRC
> generation and checking), though scheduling and retransmission is on
> software's shoulders.
>
> This controller does not integrate the root hub, so this driver also
> fakes one-port hub. External hub is required to support more than
> one device.
>
> ...
>
Please, no.
> new file mode 100644
> index 000..23716fa
> --- /dev/null
> +++ b/drivers/usb/host/fhci-cq.c
> @@ -0,0 +1,105 @@
> +/*
> + * Freescale QUICC Engine USB Host Controller Driver
> + *
> + * Copyright (c) Freescale Semicondutor, Inc. 2006.
> + * Shlomi Gridish <[EMAIL PROTECTED]>
> + * Jerry Huang <[EMAIL PROTECTED]>
> + * Copyright (c) Logic Product Development, Inc. 2007
> + * Peter Barada <[EMAIL PROTECTED]>
> + * Copyright (c) MontaVista Software, Inc. 2008.
> + * Anton Vorontsov <[EMAIL PROTECTED]>
> + *
> + * 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 (at your
> + * option) any later version.
> + */
> +
> +/* circular queue structure */
Yet another private ringbuffer implementation. Sigh.
> +struct cir_q {
> + int max; /* size of queue */
> + int max_in; /* max items in queue */
> + int first;/* index of first in queue */
> + int last; /* index after last in queue */
> + int read; /* current reading position */
> + void *table[1]; /* fake size */
> +};
> +
> +/* circular queue handle */
> +static int cq_howmany(struct cir_q *cq)
> +{
> + int l = cq->last;
> + int f = cq->first;
> +
> + return l >= f ? l - f : l + cq->max - f;
> +}
> +
> +static struct cir_q *cq_new(int size)
> +{
> + struct cir_q *cq;
> +
> + cq = kzalloc((sizeof(*cq) + size * sizeof(void *)), GFP_KERNEL);
> + if (cq) {
> + cq->max = size;
> + cq->first = 0;
> + cq->last = 0;
> + cq->read = 0;
> + cq->max_in = 0;
The above four statements are unneeded.
> + }
> +
> + return cq;
> +}
>
> ...
>
> +++ b/drivers/usb/host/fhci-hcd.c
> @@ -0,0 +1,798 @@
> +/*
> + * Freescale QUICC Engine USB Host Controller Driver
> + *
> + * Copyright (c) Freescale Semicondutor, Inc. 2006.
> + * Shlomi Gridish <[EMAIL PROTECTED]>
> + * Jerry Huang <[EMAIL PROTECTED]>
> + * Copyright (c) Logic Product Development, Inc. 2007
> + * Peter Barada <[EMAIL PROTECTED]>
> + * Copyright (c) MontaVista Software, Inc. 2008.
> + * Anton Vorontsov <[EMAIL PROTECTED]>
> + *
> + * 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 (at your
> + * option) any later version.
> + */
> +
> +#if defined(CONFIG_FHCI_DEBUG) && !defined(DEBUG)
> +#define DEBUG
> +#endif
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "../core/hcd.h"
> +#include "fhci.h"
> +#include "fhci-hub.c"
> +#include "fhci-q.c"
> +#include "fhci-dbg.c"
> +#include "fhci-mem.c"
> +#include "fhci-cq.c"
> +#include "fhci-tds.c"
> +#include "fhci-sched.c"
hack, gack, nack.
We know that USB likes to prevertedly #include C files all over the
place, but this doesn't mean that it's a sane, tasteful or desirable
thing to do.
I stopped looking there. Guys - get a grip :(
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patchwork states and workflow
From: Paul Mackerras <[EMAIL PROTECTED]> Date: Fri, 19 Sep 2008 15:59:32 -0700 > [BTW, DaveM, you don't appear to be explicitly cc'd, so I couldn't > explicitly remove you. Presumably you are getting this thread through > the linuxppc-dev list.] Indeed, my bad :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patchwork states and workflow
Kumar Gala writes: > I've always been a bit confused about some of the states we can put a > patch in. For example, what does 'archiving' a patch mean? Archiving puts the patch away somewhere where it doesn't appear in the normal pages and needs extra effort to get to, as I understand it. > What's the difference between 'deferred' and 'rejected'? Is 'Under > Review' useful? Deferred usually means the patch depends on something else that isn't upstream, such as patches that only apply against the RT tree. Rejected means we just don't want to do what the patch does. > My biggest question is how to manage the transition of 'Accepted' and > 'Awaiting Upstream' and having clear definitions of what we think > these mean. I put patches into "awaiting upstream" when I put them in a bundle, so it means that they have entered my QA process. When they're in my public tree, I put them into "accepted" state. [BTW, DaveM, you don't appear to be explicitly cc'd, so I couldn't explicitly remove you. Presumably you are getting this thread through the linuxppc-dev list.] Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] edac: mpc85xx: Add support for MPC8572
On Fri, 2008-09-19 at 16:43 -0500, Kumar Gala wrote: > I don't have any issue with this, but why are you marking the PCI > error interrupt as shared? [snip] > this I'm a bit more skeptical about. The only one we really need to make shared is the memory controller interrupt. I'll drop it for the PCI and L2 interrupts in the next rev of the patch. > its fsl,mpc8572.. (we need to fix the others to match that convention > as its pretty standard for other device tree nodes) I actually started out with "fsl,mpc8572-*" but then somehow convinced myself I was wrong when I saw fsl,85xx in so many other places :) Thanks for the feedback. I'll correct these and re-submit. -- Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patchwork states and workflow
I'm not really interested in this dicussion, the states make sense to me and I know how I will use them. I'm also extremely backlogged as-is, and this will only compound things. Therefore, please drop me from the CC: list, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
patchwork states and workflow
Guys, I've always been a bit confused about some of the states we can put a patch in. For example, what does 'archiving' a patch mean? What's the difference between 'deferred' and 'rejected'? Is 'Under Review' useful? My biggest question is how to manage the transition of 'Accepted' and 'Awaiting Upstream' and having clear definitions of what we think these mean. My preference is 'Accepted' means its been applied to someone's tree (mine, josh's, paul's, etc.) and 'Awaiting Upstream' is the state it goes into if we are waiting for a pull by Paul or Linus. This does raise the issue of what state things should be in after the pull. Comments? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] edac: mpc85xx: Add support for MPC8572
On Sep 19, 2008, at 4:12 PM, Nate Case wrote:
From: Andrew Kilkenny <[EMAIL PROTECTED]>
This adds support for the dual-core MPC8572 processor. We have
to support making SPR changes on each core. Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.
Signed-off-by: Andrew Kilkenny <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/edac/mpc85xx_edac.c | 34 +++---
1 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..0668492 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];
/ MC SYSFS parts
***/
@@ -272,7 +273,8 @@ static int __devinit
mpc85xx_pci_err_probe(struct of_device *op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_pci_isr, IRQF_DISABLED,
+ mpc85xx_pci_isr,
+ IRQF_DISABLED | IRQF_SHARED,
I don't have any issue with this, but why are you marking the PCI
error interrupt as shared?
"[EDAC] PCI err", pci);
if (res < 0) {
printk(KERN_ERR
@@ -576,7 +578,8 @@ static int __devinit mpc85xx_l2_err_probe(struct
of_device *op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_l2_isr, IRQF_DISABLED,
+ mpc85xx_l2_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] L2 err", edac_dev);
this I'm a bit more skeptical about.
if (res < 0) {
printk(KERN_ERR
@@ -647,6 +650,9 @@ static struct of_device_id
mpc85xx_l2_err_of_match[] = {
{
.compatible = "fsl,8568-l2-cache-controller",
},
+ {
+.compatible = "fsl,8572-l2-cache-controller",
+},
its fsl,mpc8572.. (we need to fix the others to match that convention
as its pretty standard for other device tree nodes)
{},
};
@@ -912,7 +918,8 @@ static int __devinit mpc85xx_mc_err_probe(struct
of_device *op,
/* register interrupts */
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_mc_isr, IRQF_DISABLED,
+ mpc85xx_mc_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] MC err", mci);
if (res < 0) {
printk(KERN_ERR "%s: Unable to request irq %d for "
@@ -980,6 +987,9 @@ static struct of_device_id
mpc85xx_mc_err_of_match[] = {
{
.compatible = "fsl,8568-memory-controller",
},
+ {
+.compatible = "fsl,8572-memory-controller",
+},
ditto on 'fsl,mpc8572'
{},
};
@@ -995,6 +1005,12 @@ static struct of_platform_driver
mpc85xx_mc_err_driver = {
},
};
+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+ orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x2));
+}
+
static int __init mpc85xx_mc_init(void)
{
int res = 0;
@@ -1031,8 +1047,7 @@ static int __init mpc85xx_mc_init(void)
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT) {
- orig_hid1 = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1 & ~0x2));
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
return 0;
@@ -1040,9 +1055,14 @@ static int __init mpc85xx_mc_init(void)
module_init(mpc85xx_mc_init);
+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+ mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
static void __exit mpc85xx_mc_exit(void)
{
- mtspr(SPRN_HID1, orig_hid1);
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.6.0.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@o
Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting
Please repost and I'll look at it again.. I'm trying to be more diligent about patchworks.ozlabs.org and tracking things there. - k On Sep 19, 2008, at 4:28 PM, Matthias Fuchs wrote: Hi Kumar, should I resend this my patch? Is there chance to get it applied. It really fixes a bug! Matthias On Thursday 07 August 2008 15:19:10 Kumar Gala wrote: On Aug 7, 2008, at 7:48 AM, Matthias Fuchs wrote: This patch fixes the setting of the Book-E watchdog timer interval setup on initialization and by ioctl(). Tested on PPC440EPx sequoia evaluation board. Signed-off-by: Matthias Fuchs <[EMAIL PROTECTED]> --- drivers/watchdog/booke_wdt.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) can you be more explicit about what the bug was. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] edac: mpc85xx: Add support for MPC8572
Acked-by: Dave Jiang <[EMAIL PROTECTED]>
Nate Case wrote:
From: Andrew Kilkenny <[EMAIL PROTECTED]>
This adds support for the dual-core MPC8572 processor. We have
to support making SPR changes on each core. Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.
Signed-off-by: Andrew Kilkenny <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/edac/mpc85xx_edac.c | 34 +++---
1 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..0668492 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];
/ MC SYSFS parts ***/
@@ -272,7 +273,8 @@ static int __devinit mpc85xx_pci_err_probe(struct of_device *op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_pci_isr, IRQF_DISABLED,
+ mpc85xx_pci_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] PCI err", pci);
if (res < 0) {
printk(KERN_ERR
@@ -576,7 +578,8 @@ static int __devinit mpc85xx_l2_err_probe(struct of_device
*op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_l2_isr, IRQF_DISABLED,
+ mpc85xx_l2_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] L2 err", edac_dev);
if (res < 0) {
printk(KERN_ERR
@@ -647,6 +650,9 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{
.compatible = "fsl,8568-l2-cache-controller",
},
+ {
+.compatible = "fsl,8572-l2-cache-controller",
+},
{},
};
@@ -912,7 +918,8 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device *op,
/* register interrupts */
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_mc_isr, IRQF_DISABLED,
+ mpc85xx_mc_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] MC err", mci);
if (res < 0) {
printk(KERN_ERR "%s: Unable to request irq %d for "
@@ -980,6 +987,9 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{
.compatible = "fsl,8568-memory-controller",
},
+ {
+.compatible = "fsl,8572-memory-controller",
+},
{},
};
@@ -995,6 +1005,12 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+ orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x2));
+}
+
static int __init mpc85xx_mc_init(void)
{
int res = 0;
@@ -1031,8 +1047,7 @@ static int __init mpc85xx_mc_init(void)
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT) {
- orig_hid1 = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1 & ~0x2));
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
return 0;
@@ -1040,9 +1055,14 @@ static int __init mpc85xx_mc_init(void)
module_init(mpc85xx_mc_init);
+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+ mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
static void __exit mpc85xx_mc_exit(void)
{
- mtspr(SPRN_HID1, orig_hid1);
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
--
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting
Hi Kumar, should I resend this my patch? Is there chance to get it applied. It really fixes a bug! Matthias On Thursday 07 August 2008 15:19:10 Kumar Gala wrote: > On Aug 7, 2008, at 7:48 AM, Matthias Fuchs wrote: > > This patch fixes the setting of the Book-E watchdog timer interval > > setup > > on initialization and by ioctl(). > > > > Tested on PPC440EPx sequoia evaluation board. > > > > Signed-off-by: Matthias Fuchs <[EMAIL PROTECTED]> > > --- > > drivers/watchdog/booke_wdt.c |6 +- > > 1 files changed, 5 insertions(+), 1 deletions(-) > > can you be more explicit about what the bug was. > > - k > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] edac: mpc85xx: Add support for MPC8572
From: Andrew Kilkenny <[EMAIL PROTECTED]>
This adds support for the dual-core MPC8572 processor. We have
to support making SPR changes on each core. Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.
Signed-off-by: Andrew Kilkenny <[EMAIL PROTECTED]>
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
drivers/edac/mpc85xx_edac.c | 34 +++---
1 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..0668492 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];
/ MC SYSFS parts ***/
@@ -272,7 +273,8 @@ static int __devinit mpc85xx_pci_err_probe(struct of_device
*op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_pci_isr, IRQF_DISABLED,
+ mpc85xx_pci_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] PCI err", pci);
if (res < 0) {
printk(KERN_ERR
@@ -576,7 +578,8 @@ static int __devinit mpc85xx_l2_err_probe(struct of_device
*op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_l2_isr, IRQF_DISABLED,
+ mpc85xx_l2_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] L2 err", edac_dev);
if (res < 0) {
printk(KERN_ERR
@@ -647,6 +650,9 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{
.compatible = "fsl,8568-l2-cache-controller",
},
+ {
+.compatible = "fsl,8572-l2-cache-controller",
+},
{},
};
@@ -912,7 +918,8 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device
*op,
/* register interrupts */
pdata->irq = irq_of_parse_and_map(op->node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_mc_isr, IRQF_DISABLED,
+ mpc85xx_mc_isr,
+ IRQF_DISABLED | IRQF_SHARED,
"[EDAC] MC err", mci);
if (res < 0) {
printk(KERN_ERR "%s: Unable to request irq %d for "
@@ -980,6 +987,9 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{
.compatible = "fsl,8568-memory-controller",
},
+ {
+.compatible = "fsl,8572-memory-controller",
+},
{},
};
@@ -995,6 +1005,12 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+ orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x2));
+}
+
static int __init mpc85xx_mc_init(void)
{
int res = 0;
@@ -1031,8 +1047,7 @@ static int __init mpc85xx_mc_init(void)
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT) {
- orig_hid1 = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1 & ~0x2));
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
return 0;
@@ -1040,9 +1055,14 @@ static int __init mpc85xx_mc_init(void)
module_init(mpc85xx_mc_init);
+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+ mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
static void __exit mpc85xx_mc_exit(void)
{
- mtspr(SPRN_HID1, orig_hid1);
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.6.0.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] i2c: expand I2C's id.name to 23 characters
On Fri, Sep 19, 2008 at 10:03:08PM +0200, Jean Delvare wrote: > On Fri, 19 Sep 2008 22:03:39 +0400, Anton Vorontsov wrote: > > It was discussed[1] that we should match on the first (most specific) > > entry in the device tree. > > > > The most lengthy I2C compatible entry for the MPC8349E-mITX MCU > > devices is "mc9s08qg8-mpc8349emitx" (w/o vendor name). This means > > that we have to allow longer IDs to be used in the I2C subsystem. > > > > [1] http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21196.html > > Nack. Just come up with shorter names. "mc9s08qg8-mpc8349emitx" is > simply too long to start with. Looking at the mcu_mpc8349emitx driver > you just submitted, you are clearly abusing the i2c client name to pass > platform-specific information, and that's bad. I'm not even sure why > you do that, given that all the names are then handled the same as far > as I can see. The whole "matching on the first entry" thing is just a Linux-internal heuristic. If the heuristic breaks down (like it does here), then there is a mechanism to override it in of_base.c which has a compatible-->modalias translation table. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] i2c: expand I2C's id.name to 23 characters
On Fri, 19 Sep 2008 22:03:39 +0400, Anton Vorontsov wrote:
> It was discussed[1] that we should match on the first (most specific)
> entry in the device tree.
>
> The most lengthy I2C compatible entry for the MPC8349E-mITX MCU
> devices is "mc9s08qg8-mpc8349emitx" (w/o vendor name). This means
> that we have to allow longer IDs to be used in the I2C subsystem.
>
> [1] http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21196.html
Nack. Just come up with shorter names. "mc9s08qg8-mpc8349emitx" is
simply too long to start with. Looking at the mcu_mpc8349emitx driver
you just submitted, you are clearly abusing the i2c client name to pass
platform-specific information, and that's bad. I'm not even sure why
you do that, given that all the names are then handled the same as far
as I can see.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> include/linux/mod_devicetable.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index c4db582..9d9d1f5 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -379,7 +379,7 @@ struct virtio_device_id {
>
> /* i2c */
>
> -#define I2C_NAME_SIZE20
> +#define I2C_NAME_SIZE23
> #define I2C_MODULE_PREFIX "i2c:"
>
> struct i2c_device_id {
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs
On Sep 19, 2008, at 1:12 PM, Anton Vorontsov wrote: On Fri, Sep 19, 2008 at 01:02:11PM -0500, Kumar Gala wrote: [...] Anton> This is purposely. We also need support for 8610, and maybe Anton> later we'll find another chip with the same unit. So, to not touch Anton> the Kconfig for every new chip I just made it PPC32-wide. Other Anton> option is to depend on FSL_SOC, but the driver really does not Anton> depend on any fsl_soc stuff... Adding another symbol to the Kconfig once it is verified that a new SoC is compatible doesn't seem like a big deal - Figuring out all the knobs we already have is, without having options for stuff that is known to be irrelevant for the SoC. The other 83xx specific drivers also depend on PPC_83xx. Lets wait for Kumar's comments. We've already had a PPC_* mess for the USB_EHCI_FSL symbol. What I've learned from it, is that huge PPC_* list isn't perfect either. I've alone glanced over this, but some initial comments are.. lets rename the thing to not be 83xx specific since 8610 uses it and I'm sure we'll have other parts that do similar things. Ok, mpc8xxx_gpio.c would be fine? (Note that I'm agree with 8xxx, for the file name). With regards to the binding, lets make it generic like 'fsl,mpc8xxx- gpio", "fsl,CHIP-gpio" and than we can use cpm1/cpm2/pq1/pq2 as prefixes to distinguish and major differences. But for compatible entry, shouldn't we use the last compatiblle entry as a generic one? Then fsl,mpc8349-gpio is perfectly valid. I.e., for MPC8610 chips we will have: "fsl,mpc8610-gpio", "fsl,mpc8349-gpio" Yeah the order is correct.. should be: "fsl,CHIP-gpio", "fsl,mpc8xxx-gpio" The last entry is most generic, and 8610 is registers-compatible with the earlier (8349) chips. I thought that we tend to not do "made up" 8xxx things in the device tree... Am I wrong? You are correct we try to avoid this, but than I suggest we do it by family. I think its confusing to show 8610 and 8349 in the same dev tree. What we do in PCI is use the first in family. So lets take 8379 as an example it would look like: "fsl,mpc8379-gpio", "fsl-mpc8349-gpio" and 8610 would look like: "fsl,mpc8610-gpio" This way the compatiable binding in the code just lists something like "fsl,mpc8349-gpio", "fsl,mpc8610-gpio", "fsl,mpc8572-gpio". Does that make sense? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'powerpc-next'
Please pull from 'powerpc-next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next to receive the following updates: Documentation/powerpc/dts-bindings/fsl/ssi.txt | 15 arch/powerpc/boot/dts/gef_sbc610.dts| 260 +++ arch/powerpc/boot/dts/mgcoge.dts| 174 ++ arch/powerpc/boot/dts/mgsuvd.dts| 163 ++ arch/powerpc/boot/dts/mpc836x_mds.dts | 23 arch/powerpc/boot/dts/mpc8610_hpcd.dts |8 arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 79 + arch/powerpc/configs/86xx/gef_sbc610_defconfig | 1654 arch/powerpc/configs/mgcoge_defconfig | 900 + arch/powerpc/configs/mgsuvd_defconfig | 872 arch/powerpc/kernel/head_fsl_booke.S| 26 arch/powerpc/kernel/sysfs.c |6 arch/powerpc/mm/fsl_booke_mmu.c |5 arch/powerpc/platforms/82xx/Kconfig |8 arch/powerpc/platforms/82xx/Makefile|1 arch/powerpc/platforms/82xx/mgcoge.c| 129 + arch/powerpc/platforms/85xx/sbc8560.c |2 arch/powerpc/platforms/86xx/Kconfig |9 arch/powerpc/platforms/86xx/Makefile|1 arch/powerpc/platforms/86xx/gef_sbc610.c| 149 ++ arch/powerpc/platforms/8xx/Kconfig |6 arch/powerpc/platforms/8xx/Makefile |1 arch/powerpc/platforms/8xx/mgsuvd.c | 92 + arch/powerpc/sysdev/cpm1.c | 74 - drivers/serial/Kconfig | 36 drivers/serial/cpm_uart/cpm_uart_core.c |3 drivers/serial/cpm_uart/cpm_uart_cpm1.c |6 drivers/serial/cpm_uart/cpm_uart_cpm2.c |6 drivers/serial/ucc_uart.c |4 include/math-emu/op-2.h |2 include/math-emu/op-common.h| 12 include/math-emu/soft-fp.h | 19 32 files changed, 4656 insertions(+), 89 deletions(-) Anton Vorontsov (1): powerpc/83xx: mpc836x_mds: add support for the nor flash Becky Bruce (2): powerpc/85xx: fix build warning, remove silly cast cpm_uart: Pass actual dev ptr to dma_* in ucc and cpm_uart serial Heiko Schocher (2): powerpc: Add support for the MPC852 based mgsuvd board from keymile. powerpc: Add support for mpc8247 based board MGCOGE from keymile. Jochen Friedrich (1): powerpc/cpm1: Fix race condition in CPM1 GPIO library. Kumar Gala (5): serial/cpm_uart: Remove dead Kconfig options math-emu: Fix compiler warnings math-emu: Add support for reporting exact invalid exception powerpc: Fix build warnings introduced by PMC support on 32-bit powerpc/fsl-booke: Fixup 64-bit PTE reading for SMP support Martyn Welch (2): powerpc: Board support for GE Fanuc SBC610 powerpc: Default configuration for GE Fanuc SBC610 Paul Gortmaker (1): powerpc/sbc8560: fix compile warning on CPM pin array Timur Tabi (1): powerpc: add SSI-to-DMA properties to Freescale MPC8610 HPCD device tree ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] Pass actual dev ptr to dma_* in ucc and cpm_uart serial
On Sep 12, 2008, at 10:42 AM, Becky Bruce wrote: We're currently passing NULL, and really shouldn't be. Signed-off-by: Becky Bruce <[EMAIL PROTECTED]> --- drivers/serial/cpm_uart/cpm_uart_core.c |3 +++ drivers/serial/cpm_uart/cpm_uart_cpm1.c |6 +++--- drivers/serial/cpm_uart/cpm_uart_cpm2.c |6 +++--- drivers/serial/ucc_uart.c |4 ++-- 4 files changed, 11 insertions(+), 8 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix build warnings introduced by PMC support on 32-bit
arch/powerpc/kernel/sysfs.c:197:7: warning: "CONFIG_6xx" is not defined arch/powerpc/kernel/sysfs.c:141: warning: 'run_on_cpu' defined but not used Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/kernel/sysfs.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c index ef2ad92..86a2ffc 100644 --- a/arch/powerpc/kernel/sysfs.c +++ b/arch/powerpc/kernel/sysfs.c @@ -134,6 +134,7 @@ void ppc_enable_pmcs(void) } EXPORT_SYMBOL(ppc_enable_pmcs); +#if defined(CONFIG_6xx) || defined(CONFIG_PPC64) /* XXX convert to rusty's on_one_cpu */ static unsigned long run_on_cpu(unsigned long cpu, unsigned long (*func)(unsigned long), @@ -152,6 +153,7 @@ static unsigned long run_on_cpu(unsigned long cpu, return ret; } +#endif #define SYSFS_PMCSETUP(NAME, ADDRESS) \ static unsigned long read_##NAME(unsigned long junk) \ @@ -190,11 +192,11 @@ static ssize_t __used \ * that are implemented on the current processor */ -#ifdef CONFIG_PPC64 +#if defined(CONFIG_PPC64) #define HAS_PPC_PMC_CLASSIC1 #define HAS_PPC_PMC_IBM1 #define HAS_PPC_PMC_PA6T 1 -#elif CONFIG_6xx +#elif defined(CONFIG_6xx) #define HAS_PPC_PMC_CLASSIC1 #define HAS_PPC_PMC_IBM1 #define HAS_PPC_PMC_G4 1 -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs
On Fri, Sep 19, 2008 at 01:02:11PM -0500, Kumar Gala wrote: [...] >>> Anton> This is purposely. We also need support for 8610, and maybe >>> Anton> later we'll find another chip with the same unit. So, to not >>> touch >>> Anton> the Kconfig for every new chip I just made it PPC32-wide. >>> Other >>> Anton> option is to depend on FSL_SOC, but the driver really does not >>> Anton> depend on any fsl_soc stuff... >>> >>> Adding another symbol to the Kconfig once it is verified that a new >>> SoC is compatible doesn't seem like a big deal - Figuring out all the >>> knobs we already have is, without having options for stuff that is >>> known to be irrelevant for the SoC. >>> >>> The other 83xx specific drivers also depend on PPC_83xx. >> >> Lets wait for Kumar's comments. We've already had a PPC_* mess >> for the USB_EHCI_FSL symbol. What I've learned from it, is that >> huge PPC_* list isn't perfect either. > > I've alone glanced over this, but some initial comments are.. lets > rename the thing to not be 83xx specific since 8610 uses it and I'm sure > we'll have other parts that do similar things. Ok, mpc8xxx_gpio.c would be fine? (Note that I'm agree with 8xxx, for the file name). > With regards to the binding, lets make it generic like 'fsl,mpc8xxx- > gpio", "fsl,CHIP-gpio" and than we can use cpm1/cpm2/pq1/pq2 as prefixes > to distinguish and major differences. But for compatible entry, shouldn't we use the last compatiblle entry as a generic one? Then fsl,mpc8349-gpio is perfectly valid. I.e., for MPC8610 chips we will have: "fsl,mpc8610-gpio", "fsl,mpc8349-gpio" The last entry is most generic, and 8610 is registers-compatible with the earlier (8349) chips. I thought that we tend to not do "made up" 8xxx things in the device tree... Am I wrong? Thanks! -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: gpio driver for mpc831x/834x/837x with OF bindings
On Sep 5, 2008, at 10:08 AM, Peter Korsgaard wrote: Structured similar to the existing QE GPIO support. Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> --- .../powerpc/dts-bindings/fsl/83xx_gpio.txt | 33 + arch/powerpc/sysdev/Kconfig|9 ++ arch/powerpc/sysdev/Makefile |1 + arch/powerpc/sysdev/mpc83xx_gpio.c | 141 +++ + 4 files changed, 184 insertions(+), 0 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/fsl/ 83xx_gpio.txt create mode 100644 arch/powerpc/sysdev/mpc83xx_gpio.c So we need to make this mpc8xxx_gpio.c 83xx, 8610, 85xx all have the same GPIO hw. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver
On MPC8349E-mITX, MPC8315E-RDB and MPC837x-RDB boards there is a
Freescale MC9S08QG8 (MCU) chip with the custom firmware
pre-programmed. The chip is used to power-off the board by the
software, and to control some GPIO pins.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig| 11 ++
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/mcu_mpc8349emitx.c | 213 ++
3 files changed, 225 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index a95cb94..1735682 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -172,4 +172,15 @@ config MENELAUS
and other features that are often used in portable devices like
cell phones and PDAs.
+config MCU_MPC8349EMITX
+ tristate "MPC8349E-mITX MCU driver"
+ depends on I2C && PPC_83xx
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here to enable soft power-off functionality on the Freescale
+ boards with the MPC8349E-mITX-compatible MCU chips. This driver will
+ also register MCU GPIOs with the generic GPIO API, so you'll able
+ to use MCU pins as GPIOs.
+
endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 39e3e69..ca520fa 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_ISP1301_OMAP)+= isp1301_omap.o
obj-$(CONFIG_TPS65010) += tps65010.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
+obj-$(CONFIG_MCU_MPC8349EMITX) += mcu_mpc8349emitx.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/i2c/chips/mcu_mpc8349emitx.c
b/drivers/i2c/chips/mcu_mpc8349emitx.c
new file mode 100644
index 000..47b07b8
--- /dev/null
+++ b/drivers/i2c/chips/mcu_mpc8349emitx.c
@@ -0,0 +1,213 @@
+/*
+ * Power Management and GPIO expander driver for MPC8349E-mITX-compatible MCU
+ *
+ * Copyright (c) 2008 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * 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
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * I don't have specifications for the MCU firmware, I found this register
+ * and bits positions by the trial&error method.
+ */
+#define MCU_REG_CTRL 0x20
+#define MCU_CTRL_POFF 0x40
+
+#define MCU_NUM_GPIO 2
+
+struct mcu {
+ struct mutex lock;
+ struct device_node *np;
+ struct i2c_client *client;
+ struct of_gpio_chip of_gc;
+ u8 reg_ctrl;
+};
+
+static struct mcu *glob_mcu;
+
+static void mcu_power_off(void)
+{
+ struct mcu *mcu = glob_mcu;
+
+ pr_info("Sending power-off request to the MCU...\n");
+ mutex_lock(&mcu->lock);
+ i2c_smbus_write_byte_data(glob_mcu->client, MCU_REG_CTRL,
+ mcu->reg_ctrl | MCU_CTRL_POFF);
+ mutex_unlock(&mcu->lock);
+}
+
+static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_gpio_chip *of_gc = to_of_gpio_chip(gc);
+ struct mcu *mcu = container_of(of_gc, struct mcu, of_gc);
+ u8 bit = 1 << (4 + gpio);
+
+ mutex_lock(&mcu->lock);
+ if (val)
+ mcu->reg_ctrl &= ~bit;
+ else
+ mcu->reg_ctrl |= bit;
+
+ i2c_smbus_write_byte_data(mcu->client, MCU_REG_CTRL, mcu->reg_ctrl);
+ mutex_unlock(&mcu->lock);
+}
+
+static int mcu_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ mcu_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+static int mcu_gpiochip_add(struct mcu *mcu)
+{
+ struct device_node *np;
+ struct of_gpio_chip *of_gc = &mcu->of_gc;
+ struct gpio_chip *gc = &of_gc->gc;
+ int ret;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,mcu-mpc8349emitx");
+ if (!np)
+ return -ENODEV;
+
+ gc->owner = THIS_MODULE;
+ gc->label = np->full_name;
+ gc->can_sleep = 1;
+ gc->ngpio = MCU_NUM_GPIO;
+ gc->base = -1;
+ gc->set = mcu_gpio_set;
+ gc->direction_output = mcu_gpio_dir_out;
+ of_gc->gpio_cells = 2;
+ of_gc->xlate = of_gpio_simple_xlate;
+
+ np->data = of_gc;
+ mcu->np = np;
+
+ /*
+* We don't want to lose the node, its ->data and ->full_name...
+* So, if succeeded, we don't put the node here.
+*/
+ ret = gpiochip_add(gc);
+ if (ret)
+ of_node_put(np);
+ return ret;
+}
+
+static int mcu_gpiochip_remove(struct mcu *mcu)
+{
+
[PATCH 1/2] i2c: expand I2C's id.name to 23 characters
It was discussed[1] that we should match on the first (most specific)
entry in the device tree.
The most lengthy I2C compatible entry for the MPC8349E-mITX MCU
devices is "mc9s08qg8-mpc8349emitx" (w/o vendor name). This means
that we have to allow longer IDs to be used in the I2C subsystem.
[1] http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21196.html
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
include/linux/mod_devicetable.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index c4db582..9d9d1f5 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -379,7 +379,7 @@ struct virtio_device_id {
/* i2c */
-#define I2C_NAME_SIZE 20
+#define I2C_NAME_SIZE 23
#define I2C_MODULE_PREFIX "i2c:"
struct i2c_device_id {
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs
On Sep 19, 2008, at 10:33 AM, Anton Vorontsov wrote: On Fri, Sep 19, 2008 at 05:11:15PM +0200, Peter Korsgaard wrote: "Anton" == Anton Vorontsov <[EMAIL PROTECTED]> writes: Hi, It seems basically the same as my patch (gpio driver for mpc831x/mpc834x/mpc837x with OF bindings) from September 5th except you don't have any documentation Anton> Well, do we really need documentation for every trivial gpio Anton> controller? The bindings are the same, only different compatible Anton> entries... Well, we need some way of knowing that atleast. Having people grepping through arch/powerpc/boot/dts/ (and knowing that they should look for 8349 even though they might use 8313 or 8610) doesn't seem optimal to me - I take it that's why we created Documentation/powerpc/dts-bindings in the first place? Ok. Anton> If we do need the documentation for this, I can readily include it. and the Kconfig doesn't depend on 831x/834x/837x. Anton> This is purposely. We also need support for 8610, and maybe Anton> later we'll find another chip with the same unit. So, to not touch Anton> the Kconfig for every new chip I just made it PPC32-wide. Other Anton> option is to depend on FSL_SOC, but the driver really does not Anton> depend on any fsl_soc stuff... Adding another symbol to the Kconfig once it is verified that a new SoC is compatible doesn't seem like a big deal - Figuring out all the knobs we already have is, without having options for stuff that is known to be irrelevant for the SoC. The other 83xx specific drivers also depend on PPC_83xx. Lets wait for Kumar's comments. We've already had a PPC_* mess for the USB_EHCI_FSL symbol. What I've learned from it, is that huge PPC_* list isn't perfect either. I've alone glanced over this, but some initial comments are.. lets rename the thing to not be 83xx specific since 8610 uses it and I'm sure we'll have other parts that do similar things. With regards to the binding, lets make it generic like 'fsl,mpc8xxx- gpio", "fsl,CHIP-gpio" and than we can use cpm1/cpm2/pq1/pq2 as prefixes to distinguish and major differences. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Add AMCC Arches eval board support to platforms/44x
On Fri, 19 Sep 2008 10:31:34 -0700 "Victor Gallardo" <[EMAIL PROTECTED]> wrote: > > Hi Josh, > > See below... > > >> ... > >> @@ -83,9 +83,23 @@ config CANYONLANDS > >>select 460EX > >>select PCI > >>select PPC4xx_PCI_EXPRESS > >> + select IBM_NEW_EMAC_EMAC4 > >> + select IBM_NEW_EMAC_RGMII > >> + select IBM_NEW_EMAC_ZMII > >> + select IBM_NEW_EMAC_TAH > >>help > >> This option enables support for the AMCC PPC460EX evaluation board. > >> > >> +config ARCHES > >> + bool "Arches" > >> + depends on 44x > >> + default n > >> + select 460EX > >> + select IBM_NEW_EMAC_EMAC4 > >> + select IBM_NEW_EMAC_TAH > >> + help > >> +This option enables support for the AMCC PPC460GT evaluation board. > > > >This seems fine. > > > > ... > > > >> +obj-$(CONFIG_ARCHES) += canyonlands.o > >> obj-$(CONFIG_CANYONLANDS) += canyonlands.o > >> obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o > > > >Instead of modifying the Makefile, you should only have to add the > >"amcc,arches" > > string to the >"board" array in ppc44x_simple.c. > > > > We switched to doing this as opposed to having a somewhat bogus > > "board compatible" statement with >other boards. That is what was > > discussed at > > OLS, and this is the result. > > The reason for two different board types is to remove RGMII and ZMII from the > build. Arches does not use it. Right, and that part is fine. > > Where is ppc4xx_simple.c? I just pulled your git tree and did not find this > file. You need to look in the 'next' branch. http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=tree;f=arch/powerpc/platforms/44x;h=c5cae8d37f170193ed45b7b76e3cb2cbb8be927a;hb=next josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v2] Add AMCC Arches eval board support to platforms/44x
Hi Josh, See below... >> ... >> @@ -83,9 +83,23 @@ config CANYONLANDS >> select 460EX >> select PCI >> select PPC4xx_PCI_EXPRESS >> +select IBM_NEW_EMAC_EMAC4 >> +select IBM_NEW_EMAC_RGMII >> +select IBM_NEW_EMAC_ZMII >> +select IBM_NEW_EMAC_TAH >> help >>This option enables support for the AMCC PPC460EX evaluation board. >> >> +config ARCHES >> +bool "Arches" >> +depends on 44x >> +default n >> +select 460EX >> +select IBM_NEW_EMAC_EMAC4 >> +select IBM_NEW_EMAC_TAH >> +help >> + This option enables support for the AMCC PPC460GT evaluation board. > >This seems fine. > > ... > >> +obj-$(CONFIG_ARCHES)+= canyonlands.o >> obj-$(CONFIG_CANYONLANDS) += canyonlands.o >> obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o > >Instead of modifying the Makefile, you should only have to add the >"amcc,arches" > string to the >"board" array in ppc44x_simple.c. > > We switched to doing this as opposed to having a somewhat bogus > "board compatible" statement with >other boards. That is what was discussed > at > OLS, and this is the result. The reason for two different board types is to remove RGMII and ZMII from the build. Arches does not use it. Where is ppc4xx_simple.c? I just pulled your git tree and did not find this file. Thanks, Victor Gallardo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioremap and vmalloc
On Fri, Sep 19, 2008 at 10:58 AM, Josh Boyer <[EMAIL PROTECTED]> wrote: > On Fri, Sep 19, 2008 at 06:45:01PM +0200, > =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: >> if I write : >> ioremap(0x2000,0x4) and ioremap(0x2000,0x5) >> >> Will it crash ? > > I have no idea. You haven't given us enough information to really answer > that. But I can say that the second ioremap() call makes the first ioremap() both redundant and inefficient. You're using exactly the same base address so the same region is getting mapped twice. Since the second call uses a bigger region than the first then the kernel will probably need to allocate another chunk of virtual address space to map it instead of reusing the first mapping. 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
Re: ioremap and vmalloc
On Fri, Sep 19, 2008 at 06:45:01PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: > if I write : > ioremap(0x2000,0x4) and ioremap(0x2000,0x5) > > Will it crash ? I have no idea. You haven't given us enough information to really answer that. Basic information needed would be: 1) What board/chip 2) What kernel version 3) What are you actually trying to do 4) What driver are you using 5) If you are writing your own, where is the code for it etc. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioremap and vmalloc
On Fri, Sep 19, 2008 at 06:34:06PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: > The first is ioremap(0x2000,0x1000); > The second is ioremap(0x8000,0x1000); > Is it too long Well, you're trying to allocate two 256MB regions. That is very large. What kind of device are you trying to map? g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioremap and vmalloc
On Fri, Sep 19, 2008 at 06:34:06PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: > The first is ioremap(0x2000,0x1000); > The second is ioremap(0x8000,0x1000); > Is it too long The error message you are getting should have been a very strong hint that the answer is "yes." josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioremap and vmalloc
The first is ioremap(0x2000,0x1000); The second is ioremap(0x8000,0x1000); Is it too long Grant Likely a écrit : On Fri, Sep 19, 2008 at 01:15:20PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: Hello, When I use ioremap, the second time, I obtain this message : allocation failed: out of vmalloc space - use vmalloc= to increase size. What can I do in order to fix this problem ? How large are the regions that you are ioremapping? The kernel sets aside a fixed amount of the virtual address space for ioremaps, and if you exhaust that then more ioremaps will stop working. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs
On Fri, Sep 19, 2008 at 05:11:15PM +0200, Peter Korsgaard wrote: > > "Anton" == Anton Vorontsov <[EMAIL PROTECTED]> writes: > > Hi, > > >> It seems basically the same as my patch (gpio driver for > >> mpc831x/mpc834x/mpc837x with OF bindings) from September 5th except > >> you don't have any documentation > > Anton> Well, do we really need documentation for every trivial gpio > Anton> controller? The bindings are the same, only different compatible > Anton> entries... > > Well, we need some way of knowing that atleast. Having people grepping > through arch/powerpc/boot/dts/ (and knowing that they should look for > 8349 even though they might use 8313 or 8610) doesn't seem optimal to > me - I take it that's why we created > Documentation/powerpc/dts-bindings in the first place? Ok. > Anton> If we do need the documentation for this, I can readily include it. > > >> and the Kconfig doesn't depend on > >> 831x/834x/837x. > > Anton> This is purposely. We also need support for 8610, and maybe > Anton> later we'll find another chip with the same unit. So, to not touch > Anton> the Kconfig for every new chip I just made it PPC32-wide. Other > Anton> option is to depend on FSL_SOC, but the driver really does not > Anton> depend on any fsl_soc stuff... > > Adding another symbol to the Kconfig once it is verified that a new > SoC is compatible doesn't seem like a big deal - Figuring out all the > knobs we already have is, without having options for stuff that is > known to be irrelevant for the SoC. > > The other 83xx specific drivers also depend on PPC_83xx. Lets wait for Kumar's comments. We've already had a PPC_* mess for the USB_EHCI_FSL symbol. What I've learned from it, is that huge PPC_* list isn't perfect either. See this discussion: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01926.html And this one: http://fixunix.com/kernel/397972-patch-1-4-spi-powerpc-spi_mpc83xx-handles-freescale-mpc8610-well.html > >> Why do you need this when you have the lock? > > Anton> See this discussion: > > Anton> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12299.html > > Ahh, for open drain outputs. gpiolib doesn't actually provide an > interface to put the gpios in that mode, but it could ofcause have > been set up in the bootloader. I'll fix that and send an updated > patch. Pardon? Who will send an updated patch, and what patch exactly? ;-) -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Modify the Freescale Elo / Elo Plus DMA driver so that it can be compiled as
a module.
The primary change is to stop treating the DMA controller as a bus, and the
DMA channels as devices on the bus. This is because the Open Firmware (OF)
kernel code does not allow busses to be removed, so although we can call
of_platform_bus_probe() to probe the DMA channels, there is no
of_platform_bus_remove(). Therefore, the DMA channels must be manually probed.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
(Reposting because I forgot to CC: the maintainers)
This patch is for the 2.6.28 kernel. This patch exposes a bug in the dmatest
module, so my other patch "dmatest: properly handle duplicate DMA channels"
should be applied if this patch is applied.
drivers/dma/Kconfig | 10 ++--
drivers/dma/fsldma.c | 165 ++
drivers/dma/fsldma.h |2 +
3 files changed, 119 insertions(+), 58 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index cd30390..9dfd502 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -48,13 +48,13 @@ config DW_DMAC
can be integrated in chips such as the Atmel AT32ap7000.
config FSL_DMA
- bool "Freescale MPC85xx/MPC83xx DMA support"
- depends on PPC
+ tristate "Freescale Elo and Elo Plus DMA support"
+ depends on PPC_83xx || PPC_85xx || PPC_86xx
select DMA_ENGINE
---help---
- Enable support for the Freescale DMA engine. Now, it support
- MPC8560/40, MPC8555, MPC8548 and MPC8641 processors.
- The MPC8349, MPC8360 is also supported.
+ Enable support for the Freescale Elo and Elo Plus DMA controllers.
+ The Elo is the DMA controller on 83xx parts, and the Elo Plus is
+ the DMA controller on 85xx and 86xx parts.
config MV_XOR
bool "Marvell XOR engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index c0059ca..327c485 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -372,6 +372,10 @@ static int fsl_dma_alloc_chan_resources(struct dma_chan
*chan,
struct fsl_dma_chan *fsl_chan = to_fsl_chan(chan);
LIST_HEAD(tmp_list);
+ /* Has this channel already been allocated? */
+ if (fsl_chan->desc_pool)
+ return 1;
+
/* We need the descriptor to be aligned to 32bytes
* for meeting FSL DMA specification requirement.
*/
@@ -381,7 +385,7 @@ static int fsl_dma_alloc_chan_resources(struct dma_chan
*chan,
if (!fsl_chan->desc_pool) {
dev_err(fsl_chan->dev, "No memory for channel %d "
"descriptor dma pool.\n", fsl_chan->id);
- return 0;
+ return -ENOMEM;
}
return 1;
@@ -410,6 +414,8 @@ static void fsl_dma_free_chan_resources(struct dma_chan
*chan)
}
spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
dma_pool_destroy(fsl_chan->desc_pool);
+
+ fsl_chan->desc_pool = NULL;
}
static struct dma_async_tx_descriptor *
@@ -912,33 +918,37 @@ out:
return err;
}
-static int __devinit of_fsl_dma_chan_probe(struct of_device *dev,
- const struct of_device_id *match)
+static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev,
+ struct device_node *node, u32 feature, const char *compatible)
{
- struct fsl_dma_device *fdev;
struct fsl_dma_chan *new_fsl_chan;
+ const u32 *iprop;
int err;
- fdev = dev_get_drvdata(dev->dev.parent);
- BUG_ON(!fdev);
-
/* alloc channel */
new_fsl_chan = kzalloc(sizeof(struct fsl_dma_chan), GFP_KERNEL);
if (!new_fsl_chan) {
- dev_err(&dev->dev, "No free memory for allocating "
+ dev_err(fdev->dev, "No free memory for allocating "
"dma channels!\n");
return -ENOMEM;
}
+ new_fsl_chan->of_dev = of_platform_device_create(node, NULL, fdev->dev);
+ if (!new_fsl_chan->of_dev) {
+ dev_err(fdev->dev, "cannot create platform device\n");
+ err = -EINVAL;
+ goto err_no_dev;
+ }
+
/* get dma channel register base */
- err = of_address_to_resource(dev->node, 0, &new_fsl_chan->reg);
+ err = of_address_to_resource(node, 0, &new_fsl_chan->reg);
if (err) {
- dev_err(&dev->dev, "Can't get %s property 'reg'\n",
- dev->node->full_name);
+ dev_err(fdev->dev, "Can't get %s property 'reg'\n",
+ node->full_name);
goto err_no_reg;
}
- new_fsl_chan->feature = *(u32 *)match->data;
+ new_fsl_chan->feature = feature;
if (!fdev->feature)
fdev->feature = new_fsl_chan->feature;
@@ -948,17 +958,22 @@ static int __devinit of_fsl_dma_chan_probe(struct
of_device *dev,
*/
Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs
> "Anton" == Anton Vorontsov <[EMAIL PROTECTED]> writes: Hi, >> It seems basically the same as my patch (gpio driver for >> mpc831x/mpc834x/mpc837x with OF bindings) from September 5th except >> you don't have any documentation Anton> Well, do we really need documentation for every trivial gpio Anton> controller? The bindings are the same, only different compatible Anton> entries... Well, we need some way of knowing that atleast. Having people grepping through arch/powerpc/boot/dts/ (and knowing that they should look for 8349 even though they might use 8313 or 8610) doesn't seem optimal to me - I take it that's why we created Documentation/powerpc/dts-bindings in the first place? Anton> If we do need the documentation for this, I can readily include it. >> and the Kconfig doesn't depend on >> 831x/834x/837x. Anton> This is purposely. We also need support for 8610, and maybe Anton> later we'll find another chip with the same unit. So, to not touch Anton> the Kconfig for every new chip I just made it PPC32-wide. Other Anton> option is to depend on FSL_SOC, but the driver really does not Anton> depend on any fsl_soc stuff... Adding another symbol to the Kconfig once it is verified that a new SoC is compatible doesn't seem like a big deal - Figuring out all the knobs we already have is, without having options for stuff that is known to be irrelevant for the SoC. The other 83xx specific drivers also depend on PPC_83xx. >> Why do you need this when you have the lock? Anton> See this discussion: Anton> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12299.html Ahh, for open drain outputs. gpiolib doesn't actually provide an interface to put the gpios in that mode, but it could ofcause have been set up in the bootloader. I'll fix that and send an updated patch. -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioremap and vmalloc
On Fri, Sep 19, 2008 at 01:15:20PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: > Hello, > > When I use ioremap, the second time, I obtain this message : > > allocation failed: out of vmalloc space - use vmalloc= to increase > size. > What can I do in order to fix this problem ? How large are the regions that you are ioremapping? The kernel sets aside a fixed amount of the virtual address space for ioremaps, and if you exhaust that then more ioremaps will stop working. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove obsolete junk in Documentation/powerpc
On Tue, 16 Sep 2008 11:44:42 -0700 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > We have all sort of totally rotten pieces of documentation > in there, let's get rid of them > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Geert's two patches for ppc_htab.txt and smp.txt are more complete as they remove the references in 00-INDEX as well. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] bootwrapper: support u-boot multi component images
On Fri, Sep 19, 2008 at 10:50:10AM +0200, Peter Korsgaard wrote:
> From: peter Korsgaard <[EMAIL PROTECTED]>
>
> Support uImage., which are U-Boot multi component images
> containing a kernel, dtb and possibly an initrd.
>
> Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
> ---
> v2: Incorporated Grant Likely's feedback.
>
> Documentation/powerpc/bootwrapper.txt |4
> arch/powerpc/boot/Makefile| 11 +--
> arch/powerpc/boot/wrapper | 20 +++-
> 3 files changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/powerpc/bootwrapper.txt
> b/Documentation/powerpc/bootwrapper.txt
> index d60fced..fa2e014 100644
> --- a/Documentation/powerpc/bootwrapper.txt
> +++ b/Documentation/powerpc/bootwrapper.txt
> @@ -91,6 +91,10 @@ Currently, the following image format targets exist:
> a device tree to the kernel at boot. If using an older
> version of U-Boot, then you need to use a cuImage
> instead.
> + uImage.%: U-Boot multi component image. Similar to uImage,
> + except device tree blob is embedded inside the
> + image together with the kernel (and potentially
> + an initrd).
> zImage.%: Image format which does not embed a device tree.
> Used by OpenFirmware and other firmware interfaces
> which are able to supply a device tree. This image
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 717a3bc..8d2e789 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -282,8 +282,9 @@ image-y += $(subst ",,$(CONFIG_EXTRA_TARGETS))
> initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
> initrd-y := $(patsubst zImage%, zImage.initrd%, \
> $(patsubst dtbImage%, dtbImage.initrd%, \
> + $(patsubst uImage.%, uImage.initrd.%, \
> $(patsubst simpleImage%, simpleImage.initrd%, \
> - $(patsubst treeImage%, treeImage.initrd%, $(image-y)
> + $(patsubst treeImage%, treeImage.initrd%, $(image-y))
> initrd-y := $(filter-out $(image-y), $(initrd-y))
> targets += $(image-y) $(initrd-y)
>
> @@ -316,6 +317,12 @@ $(obj)/zImage.iseries: vmlinux
> $(obj)/uImage: vmlinux $(wrapperbits)
> $(call if_changed,wrap,uboot)
>
> +$(obj)/uImage.initrd.%: vmlinux $(wrapperbits) $(obj)/%.dtb
> + $(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
> +
> +$(obj)/uImage.%: vmlinux $(wrapperbits) $(obj)/%.dtb
> + $(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb)
> +
> $(obj)/cuImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> $(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb)
>
> @@ -352,7 +359,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
> clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
> zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
> zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
> - otheros.bld *.dtb
> + otheros.bld uImage* *.dtb
>
> # clean up files cached by wrapper
> clean-kernel := vmlinux.strip vmlinux.bin
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index 965c237..548b087 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -153,7 +153,7 @@ coff)
> lds=$object/zImage.coff.lds
> link_address='0x50'
> ;;
> -miboot|uboot)
> +miboot|uboot*)
> # miboot and U-boot want just the bare bits, not an ELF binary
> ext=bin
> objflags="-O binary"
> @@ -262,6 +262,24 @@ uboot)
> fi
> exit 0
> ;;
> +uboot-*)
> +rm -f "$ofile"
> +# we always need an initrd - create a dummy initrd if none provided
> +if [ ! -f "initrd" ]; then
> + initrd="$tmpdir/dummy.initrd"
> + echo -n fill >$initrd
> +fi
> +mkimage -A ppc -O linux -T multi -C gzip -a $membase -e $membase \
> + $uboot_version -d "$vmz:$initrd:$dtb" "$ofile"
> +if [ "$initrd" == "$tmpdir/dummy.initrd" ]; then
> + rm $initrd;
> +fi
> +if [ -z "$cacheit" ]; then
> + rm -f "$vmz"
> +fi
> +exit 0
> +;;
> +
> esac
>
> addsec() {
> --
> 1.5.6.3
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] bootwrapper: support u-boot multi component images
> "Gerhard" == Gerhard Pircher <[EMAIL PROTECTED]> writes: Hi, >> Support uImage., which are U-Boot multi component images >> containing a kernel, dtb and possibly an initrd. Gerhard> Just out of interest: Do you intend to replace the code for building Gerhard> cuImage. (zImage target) with this new build target? No, they are for different use cases. cuImages are interesting when you cannot upgrade uboot to add device tree support and you want to use a new kernel - uImage.% is interesting when you want to use device trees but you want the simplicity of having a single file (And you acknowledge the fact that the device tree as it is today is pretty much kernel version dependent so it makes most sense to keep them in sync). -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] bootwrapper: support u-boot multi component images
Original-Nachricht > Datum: Fri, 19 Sep 2008 10:50:10 +0200 > Von: Peter Korsgaard <[EMAIL PROTECTED]> > An: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED] > Betreff: [PATCH v2] bootwrapper: support u-boot multi component images > From: peter Korsgaard <[EMAIL PROTECTED]> > > Support uImage., which are U-Boot multi component images > containing a kernel, dtb and possibly an initrd. Just out of interest: Do you intend to replace the code for building cuImage. (zImage target) with this new build target? regards, Gerhard -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ioremap and vmalloc
Hello, When I use ioremap, the second time, I obtain this message : allocation failed: out of vmalloc space - use vmalloc= to increase size. What can I do in order to fix this problem ? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] bootwrapper: support u-boot multi component images
From: peter Korsgaard <[EMAIL PROTECTED]>
Support uImage., which are U-Boot multi component images
containing a kernel, dtb and possibly an initrd.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
v2: Incorporated Grant Likely's feedback.
Documentation/powerpc/bootwrapper.txt |4
arch/powerpc/boot/Makefile| 11 +--
arch/powerpc/boot/wrapper | 20 +++-
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/bootwrapper.txt
b/Documentation/powerpc/bootwrapper.txt
index d60fced..fa2e014 100644
--- a/Documentation/powerpc/bootwrapper.txt
+++ b/Documentation/powerpc/bootwrapper.txt
@@ -91,6 +91,10 @@ Currently, the following image format targets exist:
a device tree to the kernel at boot. If using an older
version of U-Boot, then you need to use a cuImage
instead.
+ uImage.%: U-Boot multi component image. Similar to uImage,
+ except device tree blob is embedded inside the
+ image together with the kernel (and potentially
+ an initrd).
zImage.%: Image format which does not embed a device tree.
Used by OpenFirmware and other firmware interfaces
which are able to supply a device tree. This image
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 717a3bc..8d2e789 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -282,8 +282,9 @@ image-y += $(subst ",,$(CONFIG_EXTRA_TARGETS))
initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
initrd-y := $(patsubst zImage%, zImage.initrd%, \
$(patsubst dtbImage%, dtbImage.initrd%, \
+ $(patsubst uImage.%, uImage.initrd.%, \
$(patsubst simpleImage%, simpleImage.initrd%, \
- $(patsubst treeImage%, treeImage.initrd%, $(image-y)
+ $(patsubst treeImage%, treeImage.initrd%, $(image-y))
initrd-y := $(filter-out $(image-y), $(initrd-y))
targets+= $(image-y) $(initrd-y)
@@ -316,6 +317,12 @@ $(obj)/zImage.iseries: vmlinux
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
+$(obj)/uImage.initrd.%: vmlinux $(wrapperbits) $(obj)/%.dtb
+ $(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
+
+$(obj)/uImage.%: vmlinux $(wrapperbits) $(obj)/%.dtb
+ $(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb)
+
$(obj)/cuImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb)
@@ -352,7 +359,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
- otheros.bld *.dtb
+ otheros.bld uImage* *.dtb
# clean up files cached by wrapper
clean-kernel := vmlinux.strip vmlinux.bin
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 965c237..548b087 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -153,7 +153,7 @@ coff)
lds=$object/zImage.coff.lds
link_address='0x50'
;;
-miboot|uboot)
+miboot|uboot*)
# miboot and U-boot want just the bare bits, not an ELF binary
ext=bin
objflags="-O binary"
@@ -262,6 +262,24 @@ uboot)
fi
exit 0
;;
+uboot-*)
+rm -f "$ofile"
+# we always need an initrd - create a dummy initrd if none provided
+if [ ! -f "initrd" ]; then
+ initrd="$tmpdir/dummy.initrd"
+ echo -n fill >$initrd
+fi
+mkimage -A ppc -O linux -T multi -C gzip -a $membase -e $membase \
+ $uboot_version -d "$vmz:$initrd:$dtb" "$ofile"
+if [ "$initrd" == "$tmpdir/dummy.initrd" ]; then
+ rm $initrd;
+fi
+if [ -z "$cacheit" ]; then
+ rm -f "$vmz"
+fi
+exit 0
+;;
+
esac
addsec() {
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] bootwrapper: support u-boot multi component images
> "Grant" == Grant Likely <[EMAIL PROTECTED]> writes: Hi, Grant> On Mon, Sep 15, 2008 at 08:53:53PM +0200, Peter Korsgaard wrote: >> + uImage.thinx: U-Boot multi component image. Similar to uImage, Grant> Change this to "uImage.%:" to match the rest of this document. Argh, guess what my platform is called ;) >> - otheros.bld *.dtb >> + otheros.bld uImage.* *.dtb Grant> Actually, you can probably make this "uImage*" instead because plain Grant> 'uImage' targets are missing from this list. Ok, will do. >> -miboot|uboot) >> +miboot|uboot|uboot-*) Grant> Similarly, uboot and uboot-* can probably be collapsed to 'uboot*' Yeah, I kept it like this to keep it clear that it doesn't impact the normal uImage support - Will fix. I'll send an updated patch. -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] bootwrapper: support u-boot multi component images
On Mon, Sep 15, 2008 at 08:53:53PM +0200, Peter Korsgaard wrote: > From: peter Korsgaard <[EMAIL PROTECTED]> > > Support uImage., which are U-Boot multi component images > containing a kernel, dtb and possibly an initrd. > > Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> > --- > Documentation/powerpc/bootwrapper.txt |4 > arch/powerpc/boot/Makefile| 11 +-- > arch/powerpc/boot/wrapper | 20 +++- > 3 files changed, 32 insertions(+), 3 deletions(-) > > diff --git a/Documentation/powerpc/bootwrapper.txt > b/Documentation/powerpc/bootwrapper.txt > index d60fced..f0b34b3 100644 > --- a/Documentation/powerpc/bootwrapper.txt > +++ b/Documentation/powerpc/bootwrapper.txt > @@ -91,6 +91,10 @@ Currently, the following image format targets exist: > a device tree to the kernel at boot. If using an older > version of U-Boot, then you need to use a cuImage > instead. > + uImage.thinx: U-Boot multi component image. Similar to uImage, Change this to "uImage.%:" to match the rest of this document. > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile > index 717a3bc..41ab6aa 100644 > --- a/arch/powerpc/boot/Makefile > +++ b/arch/powerpc/boot/Makefile > @@ -352,7 +359,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y)) > clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \ > zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \ > zImage.iseries zImage.miboot zImage.pmac zImage.pseries \ > - otheros.bld *.dtb > + otheros.bld uImage.* *.dtb Actually, you can probably make this "uImage*" instead because plain 'uImage' targets are missing from this list. > > # clean up files cached by wrapper > clean-kernel := vmlinux.strip vmlinux.bin > diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper > index 965c237..b7c0b23 100755 > --- a/arch/powerpc/boot/wrapper > +++ b/arch/powerpc/boot/wrapper > @@ -153,7 +153,7 @@ coff) > lds=$object/zImage.coff.lds > link_address='0x50' > ;; > -miboot|uboot) > +miboot|uboot|uboot-*) Similarly, uboot and uboot-* can probably be collapsed to 'uboot*' g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
