Re: Powerbook shuts down hard when hot, patch found
On Mon, 2007-10-01 at 22:58 +0200, Michael Buesch wrote: > On Monday 01 October 2007 10:00:02 Michel Dänzer wrote: > > > > On Sun, 2007-09-30 at 12:16 +0200, Michael Buesch wrote: > > > > > > Ah, forgot to say. > > > It does not crash immediately when the register is written. It takes > > > about two seconds > > > to crash. And when the machine is colder to begin with, it takes slightly > > > longer to trigger. That _might_ support your overheating theory. > > > > > > Though, it does not trigger when it's up and running, no matter how hot > > > you drive it. > > > > Maybe the thermal control module prevents it from overheating. Have you > > tried unloading it or loading it ASAP on bootup to see if that makes any > > difference either way? > > I'm not sure how that works. Can I unload the framebuffer module? I'm talking about the thermal control module (therm_adt746x in my case), not radeonfb. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/6] Sysace: Use the established platform bus api
On Tue, Oct 02 2007, Benjamin Herrenschmidt wrote: > > On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote: > > On Sun, Sep 30 2007, Grant Likely wrote: > > > On 9/30/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote: > > > > > + if ((rc = platform_driver_register(&ace_platform_driver)) != 0) > > > > > + goto err_plat; > > > > > > > > rc = platform_driver_register(&ace_platform_driver); > > > > if (rc) > > > > goto err_plat; > > > > > > > > please. > > > > > > Okay, will do. > > > > > > > > > > > > + err_plat: > > > > > + unregister_blkdev(ace_major, "xsysace"); > > > > > + err_blk: > > > > > > > > labels should be indented zero or one space, but not more. > > > > > > scripts/Lindent does this. Originally, I *didn't* have my labels > > > indented. :-) Does Lindent need to be fixed? > > > > Seems so, if it idents labels. > > > > Just send a fixup patch for that, I'll add your series to the block tree > > for 2.6.24. > > It's actually better off living in the powerpc tree I think as it's > really about adding support for a new powerpc platform and somewhat > needs to sync with other things in there. Unless you really want the > whole thing in your tree :-) I already included it yesterday, it'll go up once 2.6.24 opens. Let me know if you want me to rip it out, though. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] Simplify rtas_change_msi() error semantics
On Tue, 2007-10-02 at 15:58 +1000, Michael Ellerman wrote: > > Looks allright, just a question tho... what do we do if it fails ? > Do we > > try to fallback to a lower number of MSIs ? Or what ? Dead device ? > > That's all up to the device driver. In theory the driver could try again > with a lower count - but that might require extra logic in the driver to > handle shared irq handlers etc. In practice I think the current drivers > will just fail. Question is badly phrased.. I meant something more like... what do we do if RTAS returns a lower count ? That is, we end up with that device with that lower count of MSIs enabled, we fail at the driver level, do we still somewhat keep track ? Drivers might assume that means it can use LSIs no ? which may not be the case... Shouldn't we try to switch back to LSI mode (or does the RTAS interface doesnt allow it ?) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/7] Add dcr_map_reg() helper
On Tue, 2007-10-02 at 15:51 +1000, Michael Ellerman wrote: > On Tue, 2007-10-02 at 15:19 +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote: > > > Add a helper routine to map dcr's based on the "dcr-reg" property of > > > a device node. > > > > > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> > > > > Wouldn't it be more consistent to call it of_map_dcr ? Or maybe find an > > even better name, but dcr_map_reg really sucks :-) > > That would give us dcr_map(), dcr_unmap() and of_map_dcr() - which > doesn't strike me as more consistent. > > I don't particularly like dcr_map_reg(), but I think it's at least > obvious that it's a variant of dcr_map() and that it has something to do > with a "reg" .. maybe even a "dcr-reg" :) dcr_map_node maybe ? dcr_map_device ? dcr_map_property ? hrm... allright, keep it that way if you want but heh, at least see if you can come up with something better before it gets merged :-) Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/7] Use dcr_host_t.base in ibm_emac_mal
On Tue, 2007-10-02 at 15:13 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote: > > This requires us to do a sort-of fake dcr_map(), so that base is set > > properly. This will be fixed/removed when the device-tree-aware emac driver > > is merged. > > > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> > > Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > (Have you actually tested btw ? :-) Hmm, I wrote these in mid June, so to be honest I don't remember. I don't think I boot tested it on anything, but I think I would have built it. I see now that the newemac driver is in Jeff's 24 tree, so it's probably best to wait for Linus to merge that and then we can fix up it as well in the one series. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nap/dfs on 7448
On Mon, 2007-10-01 at 17:32 -0400, Leisner, Martin wrote: > I asked this on linuxppc-embedded a week ago (I didn't even know this > list existed until last week -- another reason to get rid of > linuxpcc-embedded). > > Has anyone gotten NAP/DFS to reliably work on a 7448? > > I'm seeing strange problems with peripherals...(using a ram disk > works fine). Could it be that your host bridge isn't properly waking up the CPU to DOZE state for snooping DMA ? (It might require some delays on QACK in some cases, I know Apple had workarounds in those areas, maybe something along those lines need to be configured in the chipset). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/6] Sysace: Use the established platform bus api
On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote: > On Sun, Sep 30 2007, Grant Likely wrote: > > On 9/30/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote: > > > > + if ((rc = platform_driver_register(&ace_platform_driver)) != 0) > > > > + goto err_plat; > > > > > > rc = platform_driver_register(&ace_platform_driver); > > > if (rc) > > > goto err_plat; > > > > > > please. > > > > Okay, will do. > > > > > > > > > + err_plat: > > > > + unregister_blkdev(ace_major, "xsysace"); > > > > + err_blk: > > > > > > labels should be indented zero or one space, but not more. > > > > scripts/Lindent does this. Originally, I *didn't* have my labels > > indented. :-) Does Lindent need to be fixed? > > Seems so, if it idents labels. > > Just send a fixup patch for that, I'll add your series to the block tree > for 2.6.24. It's actually better off living in the powerpc tree I think as it's really about adding support for a new powerpc platform and somewhat needs to sync with other things in there. Unless you really want the whole thing in your tree :-) Cheers Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] Simplify rtas_change_msi() error semantics
On Tue, 2007-10-02 at 15:23 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2007-09-20 at 16:36 +1000, Michael Ellerman wrote: > > Currently rtas_change_msi() returns either the error code from RTAS, or if > > the RTAS call succeeded the number of irqs that were configured by RTAS. > > This makes checking the return value more complicated than it needs to be. > > > > Instead, have rtas_change_msi() check that the number of irqs configured by > > RTAS is equal to what we requested - and return an error otherwise. This > > makes > > the return semantics match the usual 0 for success, something else for > > error. > > > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> > > Looks allright, just a question tho... what do we do if it fails ? Do we > try to fallback to a lower number of MSIs ? Or what ? Dead device ? That's all up to the device driver. In theory the driver could try again with a lower count - but that might require extra logic in the driver to handle shared irq handlers etc. In practice I think the current drivers will just fail. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 5/6] Sysace: Move IRQ handler registration to occur after FSM is initialized
On Sun, 2007-09-30 at 16:57 -0600, Grant Likely wrote:
> val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
> ace_out(ace, ACE_CTRL, val);
>
> + /* Now we can hook up the irq handler */
> + if (ace->irq != NO_IRQ) {
> + rc = request_irq(ace->irq, ace_interrupt, 0,
> "systemace", ace);
> + if (rc) {
> + /* Failure - fall back to polled mode */
> + dev_err(ace->dev, "request_irq failed\n");
> + ace->irq = NO_IRQ;
> + }
> + }
> +
I don't know the HW but from the above, it looks like you enable
interrupt emission on the HW before you register the handler, which is
wrong. You should make sure on the contrary that IRQs on the HW are
disabled until after you have registered a handler.
Only really a problem if you have shared interrupts but still...
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
On Sun, 2007-09-30 at 16:42 -0600, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> Add of_platform bus binding so this driver can be used with arch/powerpc
Another option is to have a "constructor" in the platform code that
generates the platform device from the DT. It might even become the
preferred way one of these days, I'm not too sure at this stage. Anyway,
do what you prefer.
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> ---
>
> drivers/serial/uartlite.c | 101
> +
> 1 files changed, 93 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
> index ed13b9f..8752fac 100644
> --- a/drivers/serial/uartlite.c
> +++ b/drivers/serial/uartlite.c
> @@ -1,7 +1,8 @@
> /*
> * uartlite.c: Serial driver for Xilinx uartlite serial controller
> *
> - * Peter Korsgaard <[EMAIL PROTECTED]>
> + * Copyright (C) 2006 Peter Korsgaard <[EMAIL PROTECTED]>
> + * Copyright (C) 2007 Secret Lab Technologies Ltd.
> *
> * This file is licensed under the terms of the GNU General Public License
> * version 2. This program is licensed "as is" without any warranty of any
> @@ -17,6 +18,10 @@
> #include
> #include
> #include
> +#if defined(CONFIG_OF)
> +#include
> +#include
> +#endif
>
> #define ULITE_NAME "ttyUL"
> #define ULITE_MAJOR 204
> @@ -382,8 +387,10 @@ static int __init ulite_console_setup(struct console
> *co, char *options)
> port = &ulite_ports[co->index];
>
> /* not initialized yet? */
> - if (!port->membase)
> + if (!port->membase) {
> + pr_debug("console on ttyUL%i not initialized\n", co->index);
> return -ENODEV;
> + }
>
> if (options)
> uart_parse_options(options, &baud, &parity, &bits, &flow);
> @@ -542,6 +549,72 @@ static struct platform_driver ulite_platform_driver = {
> };
>
> /* -
> + * OF bus bindings
> + */
> +#if defined(CONFIG_OF)
> +static int __devinit
> +ulite_of_probe(struct of_device *op, const struct of_device_id *match)
> +{
> + struct resource res;
> + const unsigned int *id;
> + int irq, rc;
> +
> + dev_dbg(&op->dev, "%s(%p, %p)\n", __FUNCTION__, op, match);
> +
> + rc = of_address_to_resource(op->node, 0, &res);
> + if (rc) {
> + dev_err(&op->dev, "invalide address\n");
> + return rc;
> + }
> +
> + irq = irq_of_parse_and_map(op->node, 0);
> +
> + id = of_get_property(op->node, "port-number", NULL);
> +
> + return ulite_assign(&op->dev, id ? *id : -1, res.start, irq);
> +}
> +
> +static int __devexit ulite_of_remove(struct of_device *op)
> +{
> + return ulite_release(&op->dev);
> +}
> +
> +/* Match table for of_platform binding */
> +static struct of_device_id __devinit ulite_of_match[] = {
> + { .type = "serial", .compatible = "xilinx,uartlite", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ulite_of_match);
> +
> +static struct of_platform_driver ulite_of_driver = {
> + .owner = THIS_MODULE,
> + .name = "uartlite",
> + .match_table = ulite_of_match,
> + .probe = ulite_of_probe,
> + .remove = __devexit_p(ulite_of_remove),
> + .driver = {
> + .name = "uartlite",
> + },
> +};
> +
> +/* Registration helpers to keep the number of #ifdefs to a minimum */
> +static inline int __init ulite_of_register(void)
> +{
> + pr_debug("uartlite: calling of_register_platform_driver()\n");
> + return of_register_platform_driver(&ulite_of_driver);
> +}
> +
> +static inline void __exit ulite_of_unregister(void)
> +{
> + of_unregister_platform_driver(&ulite_of_driver);
> +}
> +#else /* CONFIG_OF */
> +/* CONFIG_OF not enabled; do nothing helpers */
> +static inline int __init ulite_of_register(void) { return 0; }
> +static inline void __exit ulite_of_unregister(void) { }
> +#endif /* CONFIG_OF */
> +
> +/* -
> * Module setup/teardown
> */
>
> @@ -549,20 +622,32 @@ int __init ulite_init(void)
> {
> int ret;
>
> - ret = uart_register_driver(&ulite_uart_driver);
> - if (ret)
> - return ret;
> + pr_debug("uartlite: calling uart_register_driver()\n");
> + if ((ret = uart_register_driver(&ulite_uart_driver)) != 0)
> + goto err_uart;
>
> - ret = platform_driver_register(&ulite_platform_driver);
> - if (ret)
> - uart_unregister_driver(&ulite_uart_driver);
> + if ((ret = ulite_of_register()) != 0)
> + goto err_of;
>
> + pr_debug("uartlite: calling platform_driver_register()\n");
> + if ((ret = platform_driver_register(&ulite_platform_driver)) != 0)
> + goto err_plat;
> +
> + return 0;
> +
> +err_plat:
> + ulite_of_unregister();
> +err_of:
> + uart_unregister_driver(&ulite_uart_driver);
> +err_uart:
> + p
Re: [PATCH 6/7] Add dcr_map_reg() helper
On Tue, 2007-10-02 at 15:19 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote: > > Add a helper routine to map dcr's based on the "dcr-reg" property of > > a device node. > > > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> > > Wouldn't it be more consistent to call it of_map_dcr ? Or maybe find an > even better name, but dcr_map_reg really sucks :-) That would give us dcr_map(), dcr_unmap() and of_map_dcr() - which doesn't strike me as more consistent. I don't particularly like dcr_map_reg(), but I think it's at least obvious that it's a variant of dcr_map() and that it has something to do with a "reg" .. maybe even a "dcr-reg" :) 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Implement logging of unhandled signals
Implement show_unhandled_signals sysctl + support to print when a process
is killed due to unhandled signals just as i386 and x86_64 does.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
Fixed the const char definitions, plus the two warnings that the change
brought (printing a ptr as %lx without cast).
Index: 2.6.23/arch/powerpc/kernel/traps.c
===
--- 2.6.23.orig/arch/powerpc/kernel/traps.c
+++ 2.6.23/arch/powerpc/kernel/traps.c
@@ -172,11 +172,21 @@ int die(const char *str, struct pt_regs
void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr)
{
siginfo_t info;
+ const char fmt32[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %08lx nip %08lx lr %08lx code %x\n";
+ const char fmt64[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %016lx nip %016lx lr %016lx code %x\n";
if (!user_mode(regs)) {
if (die("Exception in kernel mode", regs, signr))
return;
- }
+ } else if (show_unhandled_signals &&
+ unhandled_signal(current, signr) &&
+ printk_ratelimit()) {
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, signr,
+ addr, regs->nip, regs->link, code);
+ }
memset(&info, 0, sizeof(info));
info.si_signo = signr;
Index: 2.6.23/arch/powerpc/kernel/signal_64.c
===
--- 2.6.23.orig/arch/powerpc/kernel/signal_64.c
+++ 2.6.23/arch/powerpc/kernel/signal_64.c
@@ -64,6 +64,11 @@ struct rt_sigframe {
char abigap[288];
} __attribute__ ((aligned (16)));
+static const char fmt32[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %08lx nip %08lx lr %08lx\n";
+static const char fmt64[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %016lx nip %016lx lr %016lx\n";
+
/*
* Set up the sigcontext for the signal frame.
*/
@@ -315,6 +320,11 @@ badframe:
printk("badframe in sys_rt_sigreturn, regs=%p uc=%p
&uc->uc_mcontext=%p\n",
regs, uc, &uc->uc_mcontext);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "rt_sigreturn",
+ (long)uc, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
@@ -398,6 +408,11 @@ badframe:
printk("badframe in setup_rt_frame, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "setup_rt_frame",
+ (long)frame, regs->nip, regs->link);
+
force_sigsegv(signr, current);
return 0;
}
Index: 2.6.23/kernel/sysctl.c
===
--- 2.6.23.orig/kernel/sysctl.c
+++ 2.6.23/kernel/sysctl.c
@@ -1221,7 +1221,7 @@ static ctl_table fs_table[] = {
};
static ctl_table debug_table[] = {
-#ifdef CONFIG_X86
+#if defined(CONFIG_X86) || defined(CONFIG_PPC)
{
.ctl_name = CTL_UNNUMBERED,
.procname = "exception-trace",
Index: 2.6.23/arch/powerpc/kernel/signal_32.c
===
--- 2.6.23.orig/arch/powerpc/kernel/signal_32.c
+++ 2.6.23/arch/powerpc/kernel/signal_32.c
@@ -705,11 +705,13 @@ int handle_rt_signal32(unsigned long sig
{
struct rt_sigframe __user *rt_sf;
struct mcontext __user *frame;
+ void __user *addr;
unsigned long newsp = 0;
/* Set up Signal Frame */
/* Put a Real Time Context onto stack */
rt_sf = get_sigframe(ka, regs, sizeof(*rt_sf));
+ addr = rt_sf;
if (unlikely(rt_sf == NULL))
goto badframe;
@@ -728,6 +730,7 @@ int handle_rt_signal32(unsigned long sig
/* Save user registers on the stack */
frame = &rt_sf->uc.uc_mcontext;
+ addr = frame;
if (vdso32_rt_sigtramp && current->mm->context.vdso_base) {
if (save_user_regs(regs, frame, 0))
goto badframe;
@@ -742,6 +745,7 @@ int handle_rt_signal32(unsigned long sig
/* create a stack frame for the caller of the handler */
newsp = ((unsigned long)rt_sf) - (__SIGNAL_FRAMESIZE + 16);
+ addr = (void __user *)regs->gpr[1];
if (put_user(regs->gpr[1], (u32 __user *)newsp))
goto badframe;
@@ -762,6 +766,12 @@ badframe:
printk("badframe in handle_rt_signal, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+
Re: [PATCH 4/4] Inline u3msi_compose_msi_msg()
On Thu, 2007-09-20 at 16:36 +1000, Michael Ellerman wrote:
> In the MPIC U3 MSI code, we call u3msi_compose_msi_msg() once for each MSI.
> This is overkill, as the address is per pci device, not per MSI. So setup
> the address once, and just set the data per MSI.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/sysdev/mpic_u3msi.c | 24 +---
> 1 files changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/mpic_u3msi.c
> b/arch/powerpc/sysdev/mpic_u3msi.c
> index 4e50d1c..027fe01 100644
> --- a/arch/powerpc/sysdev/mpic_u3msi.c
> +++ b/arch/powerpc/sysdev/mpic_u3msi.c
> @@ -107,26 +107,17 @@ static void u3msi_teardown_msi_irqs(struct pci_dev
> *pdev)
> return;
> }
>
> -static void u3msi_compose_msi_msg(struct pci_dev *pdev, int virq,
> - struct msi_msg *msg)
> -{
> - u64 addr;
> -
> - addr = find_ht_magic_addr(pdev);
> - msg->address_lo = addr & 0x;
> - msg->address_hi = addr >> 32;
> - msg->data = virq_to_hw(virq);
> -
> - pr_debug("u3msi: allocated virq 0x%x (hw 0x%lx) at address 0x%lx\n",
> - virq, virq_to_hw(virq), addr);
> -}
> -
> static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
> {
> irq_hw_number_t hwirq;
> unsigned int virq;
> struct msi_desc *entry;
> struct msi_msg msg;
> + u64 addr;
> +
> + addr = find_ht_magic_addr(pdev);
> + msg.address_lo = addr & 0x;
> + msg.address_hi = addr >> 32;
>
> list_for_each_entry(entry, &pdev->msi_list, list) {
> hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
> @@ -146,7 +137,10 @@ static int u3msi_setup_msi_irqs(struct pci_dev *pdev,
> int nvec, int type)
> set_irq_chip(virq, &mpic_u3msi_chip);
> set_irq_type(virq, IRQ_TYPE_EDGE_RISING);
>
> - u3msi_compose_msi_msg(pdev, virq, &msg);
> + pr_debug("u3msi: allocated virq 0x%x (hw 0x%lx) addr 0x%lx\n",
> + virq, hwirq, addr);
> +
> + msg.data = hwirq;
> write_msi_msg(virq, &msg);
>
> hwirq++;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] Simplify rtas_change_msi() error semantics
On Thu, 2007-09-20 at 16:36 +1000, Michael Ellerman wrote:
> Currently rtas_change_msi() returns either the error code from RTAS, or if
> the RTAS call succeeded the number of irqs that were configured by RTAS.
> This makes checking the return value more complicated than it needs to be.
>
> Instead, have rtas_change_msi() check that the number of irqs configured by
> RTAS is equal to what we requested - and return an error otherwise. This makes
> the return semantics match the usual 0 for success, something else for error.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Looks allright, just a question tho... what do we do if it fails ? Do we
try to fallback to a lower number of MSIs ? Or what ? Dead device ?
Ben.
> ---
> arch/powerpc/platforms/pseries/msi.c | 18 +++---
> 1 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/msi.c
> b/arch/powerpc/platforms/pseries/msi.c
> index 9c3bcfe..2793a1b 100644
> --- a/arch/powerpc/platforms/pseries/msi.c
> +++ b/arch/powerpc/platforms/pseries/msi.c
> @@ -70,11 +70,15 @@ static int rtas_change_msi(struct pci_dn *pdn, u32 func,
> u32 num_irqs)
> seq_num = rtas_ret[1];
> } while (rtas_busy_delay(rc));
>
> - if (rc == 0) /* Success */
> - rc = rtas_ret[0];
> + /*
> + * If the RTAS call succeeded, check the number of irqs is actually
> + * what we asked for. If not, return an error.
> + */
> + if (rc == 0 && rtas_ret[0] != num_irqs)
> + rc = -ENOSPC;
>
> - pr_debug("rtas_msi: ibm,change_msi(func=%d,num=%d) = (%d)\n",
> - func, num_irqs, rc);
> + pr_debug("rtas_msi: ibm,change_msi(func=%d,num=%d), got %d rc = %d\n",
> + func, num_irqs, rtas_ret[0], rc);
>
> return rc;
> }
> @@ -87,7 +91,7 @@ static void rtas_disable_msi(struct pci_dev *pdev)
> if (!pdn)
> return;
>
> - if (rtas_change_msi(pdn, RTAS_CHANGE_FN, 0) != 0)
> + if (rtas_change_msi(pdn, RTAS_CHANGE_FN, 0))
> pr_debug("rtas_msi: Setting MSIs to 0 failed!\n");
> }
>
> @@ -180,14 +184,14 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev,
> int nvec, int type)
> if (type == PCI_CAP_ID_MSI) {
> rc = rtas_change_msi(pdn, RTAS_CHANGE_MSI_FN, nvec);
>
> - if (rc != nvec) {
> + if (rc) {
> pr_debug("rtas_msi: trying the old firmware call.\n");
> rc = rtas_change_msi(pdn, RTAS_CHANGE_FN, nvec);
> }
> } else
> rc = rtas_change_msi(pdn, RTAS_CHANGE_MSIX_FN, nvec);
>
> - if (rc != nvec) {
> + if (rc) {
> pr_debug("rtas_msi: rtas_change_msi() failed\n");
> return rc;
> }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Simplify error logic in rtas_setup_msi_irqs()
On Thu, 2007-09-20 at 16:36 +1000, Michael Ellerman wrote:
> rtas_setup_msi_irqs() doesn't need to call teardown() itself,
> the generic code will do this for us as long as we return a non
> zero value.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/pseries/msi.c | 17 +++--
> 1 files changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/msi.c
> b/arch/powerpc/platforms/pseries/msi.c
> index 6063ea2..9c3bcfe 100644
> --- a/arch/powerpc/platforms/pseries/msi.c
> +++ b/arch/powerpc/platforms/pseries/msi.c
> @@ -189,29 +189,22 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev,
> int nvec, int type)
>
> if (rc != nvec) {
> pr_debug("rtas_msi: rtas_change_msi() failed\n");
> -
> - /*
> - * In case of an error it's not clear whether the device is
> - * left with MSI enabled or not, so we explicitly disable.
> - */
> - goto out_free;
> + return rc;
> }
>
> i = 0;
> list_for_each_entry(entry, &pdev->msi_list, list) {
> hwirq = rtas_query_irq_number(pdn, i);
> if (hwirq < 0) {
> - rc = hwirq;
> pr_debug("rtas_msi: error (%d) getting hwirq\n", rc);
> - goto out_free;
> + return hwirq;
> }
>
> virq = irq_create_mapping(NULL, hwirq);
>
> if (virq == NO_IRQ) {
> pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);
> - rc = -ENOSPC;
> - goto out_free;
> + return -ENOSPC;
> }
>
> dev_dbg(&pdev->dev, "rtas_msi: allocated virq %d\n", virq);
> @@ -220,10 +213,6 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int
> nvec, int type)
> }
>
> return 0;
> -
> - out_free:
> - rtas_teardown_msi_irqs(pdev);
> - return rc;
> }
>
> static void rtas_msi_pci_irq_fixup(struct pci_dev *pdev)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Simplify error logic in u3msi_setup_msi_irqs()
On Thu, 2007-09-20 at 16:36 +1000, Michael Ellerman wrote:
> u3msi_setup_msi_irqs() doesn't need to call teardown() itself,
> the generic code will do this for us as long as we return a non
> zero value.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/sysdev/mpic_u3msi.c | 11 ++-
> 1 files changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/mpic_u3msi.c
> b/arch/powerpc/sysdev/mpic_u3msi.c
> index 305b864..4e50d1c 100644
> --- a/arch/powerpc/sysdev/mpic_u3msi.c
> +++ b/arch/powerpc/sysdev/mpic_u3msi.c
> @@ -124,7 +124,6 @@ static void u3msi_compose_msi_msg(struct pci_dev *pdev,
> int virq,
> static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
> {
> irq_hw_number_t hwirq;
> - int rc;
> unsigned int virq;
> struct msi_desc *entry;
> struct msi_msg msg;
> @@ -132,17 +131,15 @@ static int u3msi_setup_msi_irqs(struct pci_dev *pdev,
> int nvec, int type)
> list_for_each_entry(entry, &pdev->msi_list, list) {
> hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
> if (hwirq < 0) {
> - rc = hwirq;
> pr_debug("u3msi: failed allocating hwirq\n");
> - goto out_free;
> + return hwirq;
> }
>
> virq = irq_create_mapping(msi_mpic->irqhost, hwirq);
> if (virq == NO_IRQ) {
> pr_debug("u3msi: failed mapping hwirq 0x%lx\n", hwirq);
> mpic_msi_free_hwirqs(msi_mpic, hwirq, 1);
> - rc = -ENOSPC;
> - goto out_free;
> + return -ENOSPC;
> }
>
> set_irq_msi(virq, entry);
> @@ -156,10 +153,6 @@ static int u3msi_setup_msi_irqs(struct pci_dev *pdev,
> int nvec, int type)
> }
>
> return 0;
> -
> - out_free:
> - u3msi_teardown_msi_irqs(pdev);
> - return rc;
> }
>
> int mpic_u3msi_init(struct mpic *mpic)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/7] Remove msic_dcr_read() and use dcr_map_reg() in axon_msi.c
On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote:
> msic_dcr_read() doesn't really do anything useful, just replace it with
> direct calls to dcr_read().
>
> Use dcr_map_reg() in the axon_msi setup code, rather than essentially doing
> it by hand.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/axon_msi.c | 22 +++---
> 1 files changed, 3 insertions(+), 19 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c
> b/arch/powerpc/platforms/cell/axon_msi.c
> index 26a5e88..57a6149 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -80,18 +80,13 @@ static void msic_dcr_write(struct axon_msic *msic,
> unsigned int dcr_n, u32 val)
> dcr_write(msic->dcr_host, dcr_n, val);
> }
>
> -static u32 msic_dcr_read(struct axon_msic *msic, unsigned int dcr_n)
> -{
> - return dcr_read(msic->dcr_host, dcr_n);
> -}
> -
> static void axon_msi_cascade(unsigned int irq, struct irq_desc *desc)
> {
> struct axon_msic *msic = get_irq_data(irq);
> u32 write_offset, msi;
> int idx;
>
> - write_offset = msic_dcr_read(msic, MSIC_WRITE_OFFSET_REG);
> + write_offset = dcr_read(msic->dcr_host, MSIC_WRITE_OFFSET_REG);
> pr_debug("axon_msi: original write_offset 0x%x\n", write_offset);
>
> /* write_offset doesn't wrap properly, so we have to mask it */
> @@ -306,7 +301,7 @@ static int axon_msi_notify_reboot(struct notifier_block
> *nb,
> list_for_each_entry(msic, &axon_msic_list, list) {
> pr_debug("axon_msi: disabling %s\n",
> msic->irq_host->of_node->full_name);
> - tmp = msic_dcr_read(msic, MSIC_CTRL_REG);
> + tmp = dcr_read(msic->dcr_host, MSIC_CTRL_REG);
> tmp &= ~MSIC_CTRL_ENABLE & ~MSIC_CTRL_IRQ_ENABLE;
> msic_dcr_write(msic, MSIC_CTRL_REG, tmp);
> }
> @@ -323,7 +318,6 @@ static int axon_msi_setup_one(struct device_node *dn)
> struct page *page;
> struct axon_msic *msic;
> unsigned int virq;
> - int dcr_base, dcr_len;
>
> pr_debug("axon_msi: setting up dn %s\n", dn->full_name);
>
> @@ -334,17 +328,7 @@ static int axon_msi_setup_one(struct device_node *dn)
> goto out;
> }
>
> - dcr_base = dcr_resource_start(dn, 0);
> - dcr_len = dcr_resource_len(dn, 0);
> -
> - if (dcr_base == 0 || dcr_len == 0) {
> - printk(KERN_ERR
> -"axon_msi: couldn't parse dcr properties on %s\n",
> - dn->full_name);
> - goto out;
> - }
> -
> - msic->dcr_host = dcr_map(dn, dcr_base, dcr_len);
> + msic->dcr_host = dcr_map_reg(dn, 0);
> if (!DCR_MAP_OK(msic->dcr_host)) {
> printk(KERN_ERR "axon_msi: dcr_map failed for %s\n",
> dn->full_name);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/7] Add dcr_map_reg() helper
On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote:
> Add a helper routine to map dcr's based on the "dcr-reg" property of
> a device node.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Wouldn't it be more consistent to call it of_map_dcr ? Or maybe find an
even better name, but dcr_map_reg really sucks :-)
Ben.
> ---
> arch/powerpc/sysdev/dcr.c | 17 +
> include/asm-powerpc/dcr.h |1 +
> 2 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> index ab11c0b..da4f9c6 100644
> --- a/arch/powerpc/sysdev/dcr.c
> +++ b/arch/powerpc/sysdev/dcr.c
> @@ -126,6 +126,23 @@ dcr_host_t dcr_map(struct device_node *dev, unsigned int
> dcr_n,
> }
> EXPORT_SYMBOL_GPL(dcr_map);
>
> +dcr_host_t dcr_map_reg(struct device_node *dev, unsigned int index)
> +{
> + dcr_host_t ret = { .token = NULL };
> +
> + unsigned int dcr_n, dcr_c;
> +
> + dcr_n = dcr_resource_start(dev, index);
> + if (!dcr_n)
> + return ret;
> +
> + dcr_c = dcr_resource_len(dev, index);
> + if (!dcr_c)
> + return ret;
> +
> + return dcr_map(dev, dcr_n, dcr_c);
> +}
> +
> void dcr_unmap(dcr_host_t host, unsigned int dcr_n, unsigned int dcr_c)
> {
> dcr_host_t h = host;
> diff --git a/include/asm-powerpc/dcr.h b/include/asm-powerpc/dcr.h
> index 9338d50..4d42f01 100644
> --- a/include/asm-powerpc/dcr.h
> +++ b/include/asm-powerpc/dcr.h
> @@ -38,6 +38,7 @@ extern unsigned int dcr_resource_start(struct device_node
> *np,
> unsigned int index);
> extern unsigned int dcr_resource_len(struct device_node *np,
>unsigned int index);
> +extern dcr_host_t dcr_map_reg(struct device_node *np, unsigned int index);
> #endif /* CONFIG_PPC_MERGE */
>
> #endif /* CONFIG_PPC_DCR */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] Add dcr_host_t.base in dcr_read()/dcr_write()
On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote:
> Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we can
> save them the trouble and do it in dcr_read()/dcr_write().
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Please, fixup the changeset comment to be more exlicit or provide some
Documentation/powerpc/dcr.txt explaning some of the discussions we had
about why this is actually a good idea :-)
Among others:
- Initially, the goal was to operate like mfdcr/mtdcr who take absolute
DCR numbers. The reason is that on 4xx hardware, indirect DCR access is
a pain (goes through a table of instructions) and it's useful to have
the compiler resolve an absolute DCR inline.
- We decided that wasn't worth the API bastardisation since most cases
where absolute DCR values are used are low level 4xx-only code which may
as well continue using mfdcr/mtdcr, while the new API is designed for
device "instances" that can exist on 4xx and Axon type platforms and may
be located at variable DCR offsets.
Something around those lines...
Appart from that, patch is fine, I'll ack with the new comment :-)
Ben.
> ---
> arch/powerpc/platforms/cell/axon_msi.c |4 ++--
> arch/powerpc/sysdev/mpic.c |4 ++--
> drivers/net/ibm_emac/ibm_emac_mal.h|4 ++--
> include/asm-powerpc/dcr-mmio.h |4 ++--
> include/asm-powerpc/dcr-native.h |4 ++--
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c
> b/arch/powerpc/platforms/cell/axon_msi.c
> index 23e039a..26a5e88 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -77,12 +77,12 @@ static void msic_dcr_write(struct axon_msic *msic,
> unsigned int dcr_n, u32 val)
> {
> pr_debug("axon_msi: dcr_write(0x%x, 0x%x)\n", val, dcr_n);
>
> - dcr_write(msic->dcr_host, msic->dcr_host.base + dcr_n, val);
> + dcr_write(msic->dcr_host, dcr_n, val);
> }
>
> static u32 msic_dcr_read(struct axon_msic *msic, unsigned int dcr_n)
> {
> - return dcr_read(msic->dcr_host, msic->dcr_host.base + dcr_n);
> + return dcr_read(msic->dcr_host, dcr_n);
> }
>
> static void axon_msi_cascade(unsigned int irq, struct irq_desc *desc)
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 16b1f4b..61f5730 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -156,7 +156,7 @@ static inline u32 _mpic_read(enum mpic_reg_type type,
> switch(type) {
> #ifdef CONFIG_PPC_DCR
> case mpic_access_dcr:
> - return dcr_read(rb->dhost, rb->dhost.base + reg);
> + return dcr_read(rb->dhost, reg);
> #endif
> case mpic_access_mmio_be:
> return in_be32(rb->base + (reg >> 2));
> @@ -173,7 +173,7 @@ static inline void _mpic_write(enum mpic_reg_type type,
> switch(type) {
> #ifdef CONFIG_PPC_DCR
> case mpic_access_dcr:
> - return dcr_write(rb->dhost, rb->dhost.base + reg, value);
> + return dcr_write(rb->dhost, reg, value);
> #endif
> case mpic_access_mmio_be:
> return out_be32(rb->base + (reg >> 2), value);
> diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h
> b/drivers/net/ibm_emac/ibm_emac_mal.h
> index 6b1fbeb..10dc978 100644
> --- a/drivers/net/ibm_emac/ibm_emac_mal.h
> +++ b/drivers/net/ibm_emac/ibm_emac_mal.h
> @@ -208,12 +208,12 @@ struct ibm_ocp_mal {
>
> static inline u32 get_mal_dcrn(struct ibm_ocp_mal *mal, int reg)
> {
> - return dcr_read(mal->dcrhost, mal->dcrhost.base + reg);
> + return dcr_read(mal->dcrhost, reg);
> }
>
> static inline void set_mal_dcrn(struct ibm_ocp_mal *mal, int reg, u32 val)
> {
> - dcr_write(mal->dcrhost, mal->dcrhost.base + reg, val);
> + dcr_write(mal->dcrhost, reg, val);
> }
>
> /* Register MAL devices */
> diff --git a/include/asm-powerpc/dcr-mmio.h b/include/asm-powerpc/dcr-mmio.h
> index 6b82c3b..a7d9eaf 100644
> --- a/include/asm-powerpc/dcr-mmio.h
> +++ b/include/asm-powerpc/dcr-mmio.h
> @@ -37,12 +37,12 @@ extern void dcr_unmap(dcr_host_t host, unsigned int
> dcr_n, unsigned int dcr_c);
>
> static inline u32 dcr_read(dcr_host_t host, unsigned int dcr_n)
> {
> - return in_be32(host.token + dcr_n * host.stride);
> + return in_be32(host.token + ((host.base + dcr_n) * host.stride));
> }
>
> static inline void dcr_write(dcr_host_t host, unsigned int dcr_n, u32 value)
> {
> - out_be32(host.token + dcr_n * host.stride, value);
> + out_be32(host.token + ((host.base + dcr_n) * host.stride), value);
> }
>
> extern u64 of_translate_dcr_address(struct device_node *dev,
> diff --git a/include/asm-powerpc/dcr-native.h
> b/include/asm-powerpc/dcr-native.h
> index f41058c..3bc780f 100644
> --- a/include/asm-powerpc/dcr-native.h
> +++ b/include/asm-powerpc/dcr-native.h
> @@ -30,8 +30,8 @@ typedef struct {
>
> #define dcr_map(dev, dcr_n, dcr_c) ((dcr_hos
Re: [PATCH 4/7] Update axon_msi to use dcr_host_t.base
On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote:
> Now that dcr_host_t contains the base address, we can use that in the
> axon_msi code, rather than storing it separately.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/axon_msi.c | 13 ++---
> 1 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c
> b/arch/powerpc/platforms/cell/axon_msi.c
> index 74407af..23e039a 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -69,7 +69,6 @@ struct axon_msic {
> dcr_host_t dcr_host;
> struct list_head list;
> u32 read_offset;
> - u32 dcr_base;
> };
>
> static LIST_HEAD(axon_msic_list);
> @@ -78,12 +77,12 @@ static void msic_dcr_write(struct axon_msic *msic,
> unsigned int dcr_n, u32 val)
> {
> pr_debug("axon_msi: dcr_write(0x%x, 0x%x)\n", val, dcr_n);
>
> - dcr_write(msic->dcr_host, msic->dcr_base + dcr_n, val);
> + dcr_write(msic->dcr_host, msic->dcr_host.base + dcr_n, val);
> }
>
> static u32 msic_dcr_read(struct axon_msic *msic, unsigned int dcr_n)
> {
> - return dcr_read(msic->dcr_host, msic->dcr_base + dcr_n);
> + return dcr_read(msic->dcr_host, msic->dcr_host.base + dcr_n);
> }
>
> static void axon_msi_cascade(unsigned int irq, struct irq_desc *desc)
> @@ -324,7 +323,7 @@ static int axon_msi_setup_one(struct device_node *dn)
> struct page *page;
> struct axon_msic *msic;
> unsigned int virq;
> - int dcr_len;
> + int dcr_base, dcr_len;
>
> pr_debug("axon_msi: setting up dn %s\n", dn->full_name);
>
> @@ -335,17 +334,17 @@ static int axon_msi_setup_one(struct device_node *dn)
> goto out;
> }
>
> - msic->dcr_base = dcr_resource_start(dn, 0);
> + dcr_base = dcr_resource_start(dn, 0);
> dcr_len = dcr_resource_len(dn, 0);
>
> - if (msic->dcr_base == 0 || dcr_len == 0) {
> + if (dcr_base == 0 || dcr_len == 0) {
> printk(KERN_ERR
> "axon_msi: couldn't parse dcr properties on %s\n",
> dn->full_name);
> goto out;
> }
>
> - msic->dcr_host = dcr_map(dn, msic->dcr_base, dcr_len);
> + msic->dcr_host = dcr_map(dn, dcr_base, dcr_len);
> if (!DCR_MAP_OK(msic->dcr_host)) {
> printk(KERN_ERR "axon_msi: dcr_map failed for %s\n",
> dn->full_name);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/7] Use dcr_host_t.base in ibm_emac_mal
On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote:
> This requires us to do a sort-of fake dcr_map(), so that base is set
> properly. This will be fixed/removed when the device-tree-aware emac driver
> is merged.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
(Have you actually tested btw ? :-)
> ---
> drivers/net/ibm_emac/ibm_emac_mal.c |5 -
> drivers/net/ibm_emac/ibm_emac_mal.h |5 ++---
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c
> b/drivers/net/ibm_emac/ibm_emac_mal.c
> index cabd984..b08da96 100644
> --- a/drivers/net/ibm_emac/ibm_emac_mal.c
> +++ b/drivers/net/ibm_emac/ibm_emac_mal.c
> @@ -421,7 +421,10 @@ static int __init mal_probe(struct ocp_device *ocpdev)
> ocpdev->def->index);
> return -ENOMEM;
> }
> - mal->dcrbase = maldata->dcr_base;
> +
> + /* XXX This only works for native dcr for now */
> + mal->dcrhost = dcr_map(NULL, maldata->dcr_base, 0);
> +
> mal->def = ocpdev->def;
>
> INIT_LIST_HEAD(&mal->poll_list);
> diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h
> b/drivers/net/ibm_emac/ibm_emac_mal.h
> index 64bc338..6b1fbeb 100644
> --- a/drivers/net/ibm_emac/ibm_emac_mal.h
> +++ b/drivers/net/ibm_emac/ibm_emac_mal.h
> @@ -191,7 +191,6 @@ struct mal_commac {
> };
>
> struct ibm_ocp_mal {
> - int dcrbase;
> dcr_host_t dcrhost;
>
> struct list_headpoll_list;
> @@ -209,12 +208,12 @@ struct ibm_ocp_mal {
>
> static inline u32 get_mal_dcrn(struct ibm_ocp_mal *mal, int reg)
> {
> - return dcr_read(mal->dcrhost, mal->dcrbase + reg);
> + return dcr_read(mal->dcrhost, mal->dcrhost.base + reg);
> }
>
> static inline void set_mal_dcrn(struct ibm_ocp_mal *mal, int reg, u32 val)
> {
> - dcr_write(mal->dcrhost, mal->dcrbase + reg, val);
> + dcr_write(mal->dcrhost, mal->dcrhost.base + reg, val);
> }
>
> /* Register MAL devices */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7] Update mpic to use dcr_host_t.base
On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote:
> Now that dcr_host_t contains the base address, we can use that in the mpic
> code, rather than storing it separately.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/sysdev/mpic.c | 28 +++-
> include/asm-powerpc/mpic.h |6 --
> 2 files changed, 11 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 8de29f2..16b1f4b 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -156,8 +156,7 @@ static inline u32 _mpic_read(enum mpic_reg_type type,
> switch(type) {
> #ifdef CONFIG_PPC_DCR
> case mpic_access_dcr:
> - return dcr_read(rb->dhost,
> - rb->dbase + reg + rb->doff);
> + return dcr_read(rb->dhost, rb->dhost.base + reg);
> #endif
> case mpic_access_mmio_be:
> return in_be32(rb->base + (reg >> 2));
> @@ -174,8 +173,7 @@ static inline void _mpic_write(enum mpic_reg_type type,
> switch(type) {
> #ifdef CONFIG_PPC_DCR
> case mpic_access_dcr:
> - return dcr_write(rb->dhost,
> - rb->dbase + reg + rb->doff, value);
> + return dcr_write(rb->dhost, rb->dhost.base + reg, value);
> #endif
> case mpic_access_mmio_be:
> return out_be32(rb->base + (reg >> 2), value);
> @@ -279,9 +277,11 @@ static void _mpic_map_mmio(struct mpic *mpic, unsigned
> long phys_addr,
> static void _mpic_map_dcr(struct mpic *mpic, struct mpic_reg_bank *rb,
> unsigned int offset, unsigned int size)
> {
> - rb->dbase = mpic->dcr_base;
> - rb->doff = offset;
> - rb->dhost = dcr_map(mpic->irqhost->of_node, rb->dbase + rb->doff, size);
> + const u32 *dbasep;
> +
> + dbasep = of_get_property(mpic->irqhost->of_node, "dcr-reg", NULL);
> +
> + rb->dhost = dcr_map(mpic->irqhost->of_node, *dbasep + offset, size);
> BUG_ON(!DCR_MAP_OK(rb->dhost));
> }
>
> @@ -1075,20 +1075,14 @@ struct mpic * __init mpic_alloc(struct device_node
> *node,
> BUG_ON(paddr == 0 && node == NULL);
>
> /* If no physical address passed in, check if it's dcr based */
> - if (paddr == 0 && of_get_property(node, "dcr-reg", NULL) != NULL)
> - mpic->flags |= MPIC_USES_DCR;
> -
> + if (paddr == 0 && of_get_property(node, "dcr-reg", NULL) != NULL) {
> #ifdef CONFIG_PPC_DCR
> - if (mpic->flags & MPIC_USES_DCR) {
> - const u32 *dbasep;
> - dbasep = of_get_property(node, "dcr-reg", NULL);
> - BUG_ON(dbasep == NULL);
> - mpic->dcr_base = *dbasep;
> + mpic->flags |= MPIC_USES_DCR;
> mpic->reg_type = mpic_access_dcr;
> - }
> #else
> - BUG_ON (mpic->flags & MPIC_USES_DCR);
> + BUG();
> #endif /* CONFIG_PPC_DCR */
> + }
>
> /* If the MPIC is not DCR based, and no physical address was passed
>* in, try to obtain one
> diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
> index edb4a7c..ae84dde 100644
> --- a/include/asm-powerpc/mpic.h
> +++ b/include/asm-powerpc/mpic.h
> @@ -224,8 +224,6 @@ struct mpic_reg_bank {
> u32 __iomem *base;
> #ifdef CONFIG_PPC_DCR
> dcr_host_t dhost;
> - unsigned intdbase;
> - unsigned intdoff;
> #endif /* CONFIG_PPC_DCR */
> };
>
> @@ -289,10 +287,6 @@ struct mpic
> struct mpic_reg_bankcpuregs[MPIC_MAX_CPUS];
> struct mpic_reg_bankisus[MPIC_MAX_ISU];
>
> -#ifdef CONFIG_PPC_DCR
> - unsigned intdcr_base;
> -#endif
> -
> /* Protected sources */
> unsigned long *protected;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] Store the base address in dcr_host_t
On Mon, 2007-09-17 at 16:05 +1000, Michael Ellerman wrote:
> In its current form, dcr_map() doesn't remember the base address you passed
> it, which means you need to store it somewhere else. Rather than adding the
> base to another struct it seems simpler to store it in the dcr_host_t.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/sysdev/dcr.c|2 +-
> include/asm-powerpc/dcr-mmio.h |6 +-
> include/asm-powerpc/dcr-native.h |6 --
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> index e82d54d..ab11c0b 100644
> --- a/arch/powerpc/sysdev/dcr.c
> +++ b/arch/powerpc/sysdev/dcr.c
> @@ -104,7 +104,7 @@ u64 of_translate_dcr_address(struct device_node *dev,
> dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
> unsigned int dcr_c)
> {
> - dcr_host_t ret = { .token = NULL, .stride = 0 };
> + dcr_host_t ret = { .token = NULL, .stride = 0, .base = dcr_n };
> u64 addr;
>
> pr_debug("dcr_map(%s, 0x%x, 0x%x)\n",
> diff --git a/include/asm-powerpc/dcr-mmio.h b/include/asm-powerpc/dcr-mmio.h
> index 5dbfca8..6b82c3b 100644
> --- a/include/asm-powerpc/dcr-mmio.h
> +++ b/include/asm-powerpc/dcr-mmio.h
> @@ -23,7 +23,11 @@
>
> #include
>
> -typedef struct { void __iomem *token; unsigned int stride; } dcr_host_t;
> +typedef struct {
> + void __iomem *token;
> + unsigned int stride;
> + unsigned int base;
> +} dcr_host_t;
>
> #define DCR_MAP_OK(host) ((host).token != NULL)
>
> diff --git a/include/asm-powerpc/dcr-native.h
> b/include/asm-powerpc/dcr-native.h
> index 05af081..f41058c 100644
> --- a/include/asm-powerpc/dcr-native.h
> +++ b/include/asm-powerpc/dcr-native.h
> @@ -22,11 +22,13 @@
> #ifdef __KERNEL__
> #ifndef __ASSEMBLY__
>
> -typedef struct {} dcr_host_t;
> +typedef struct {
> + unsigned int base;
> +} dcr_host_t;
>
> #define DCR_MAP_OK(host) (1)
>
> -#define dcr_map(dev, dcr_n, dcr_c) ((dcr_host_t){})
> +#define dcr_map(dev, dcr_n, dcr_c) ((dcr_host_t){ .base = (dcr_n) })
> #define dcr_unmap(host, dcr_n, dcr_c)do {} while (0)
> #define dcr_read(host, dcr_n)mfdcr(dcr_n)
> #define dcr_write(host, dcr_n, value)mtdcr(dcr_n, value)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Make sure to of_node_get() the result of pci_device_to_OF_node()
On Mon, 2007-09-17 at 16:03 +1000, Michael Ellerman wrote:
> pci_device_to_OF_node() returns the device node attached to a PCI device,
> but doesn't actually grab a reference - we need to do it ourselves.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/axon_msi.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c
> b/arch/powerpc/platforms/cell/axon_msi.c
> index 57a6149..2b2dfcc 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -119,7 +119,7 @@ static struct axon_msic *find_msi_translator(struct
> pci_dev *dev)
> const phandle *ph;
> struct axon_msic *msic = NULL;
>
> - dn = pci_device_to_OF_node(dev);
> + dn = of_node_get(pci_device_to_OF_node(dev));
> if (!dn) {
> dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
> return NULL;
> @@ -176,7 +176,7 @@ static int setup_msi_msg_address(struct pci_dev *dev,
> struct msi_msg *msg)
> int len;
> const u32 *prop;
>
> - dn = pci_device_to_OF_node(dev);
> + dn = of_node_get(pci_device_to_OF_node(dev));
> if (!dn) {
> dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
> return -ENODEV;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Limit range of __init_ref_ok somewhat
This patch introduces zalloc_maybe_bootmem and uses it so that we don;t
have to mark a whole (largish) routine as __init_ref_ok.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/irq.c| 10 ++
arch/powerpc/lib/alloc.c | 15 +++
include/asm-powerpc/system.h |1 +
3 files changed, 18 insertions(+), 8 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 0e47c8c..151b131 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -424,7 +424,7 @@ static int default_irq_host_match(struct irq_host *h,
struct device_node *np)
return h->of_node != NULL && h->of_node == np;
}
-__init_refok struct irq_host *irq_alloc_host(struct device_node *of_node,
+struct irq_host *irq_alloc_host(struct device_node *of_node,
unsigned int revmap_type,
unsigned int revmap_arg,
struct irq_host_ops *ops,
@@ -439,13 +439,7 @@ __init_refok struct irq_host *irq_alloc_host(struct
device_node *of_node,
/* Allocate structure and revmap table if using linear mapping */
if (revmap_type == IRQ_HOST_MAP_LINEAR)
size += revmap_arg * sizeof(unsigned int);
- if (mem_init_done)
- host = kzalloc(size, GFP_KERNEL);
- else {
- host = alloc_bootmem(size);
- if (host)
- memset(host, 0, size);
- }
+ host = zalloc_maybe_bootmem(size, GFP_KERNEL);
if (host == NULL)
return NULL;
diff --git a/arch/powerpc/lib/alloc.c b/arch/powerpc/lib/alloc.c
index e58c805..f53e09c 100644
--- a/arch/powerpc/lib/alloc.c
+++ b/arch/powerpc/lib/alloc.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include
#include
@@ -12,3 +13,17 @@ void * __init_refok alloc_maybe_bootmem(size_t size, gfp_t
mask)
else
return alloc_bootmem(size);
}
+
+void * __init_refok zalloc_maybe_bootmem(size_t size, gfp_t mask)
+{
+ void *p;
+
+ if (mem_init_done)
+ p = kzalloc(size, mask);
+ else {
+ p = alloc_bootmem(size);
+ if (p)
+ memset(p, 0, size);
+ }
+ return p;
+}
diff --git a/include/asm-powerpc/system.h b/include/asm-powerpc/system.h
index f7879fc..d10e99b 100644
--- a/include/asm-powerpc/system.h
+++ b/include/asm-powerpc/system.h
@@ -190,6 +190,7 @@ extern unsigned long memory_limit;
extern unsigned long klimit;
extern void *alloc_maybe_bootmem(size_t size, gfp_t mask);
+extern void *zalloc_maybe_bootmem(size_t size, gfp_t mask);
extern int powersave_nap; /* set if nap mode can be used in idle loop */
--
1.5.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get a bug-fix from Anton Blanchard for 2.6.23. Thanks, Paul. arch/powerpc/platforms/pseries/xics.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) commit e48395f1753cab0fde6c03f1db833cece9ef2ba0 Author: Anton Blanchard <[EMAIL PROTECTED]> Date: Mon Oct 1 07:45:55 2007 +1000 [POWERPC] Fix xics set_affinity code On a POWER6 machine running 2.6.23-rc8 I sometimes see the following error: xics_set_affinity: No online cpus in the mask ,,,0001 for irq 20 In a desperate attempt to get a changelog entry in 2.6.23, I took a look into it. It turns out we are passing a real and not a virtual irq into get_irq_server. This works for the case where hwirq < NR_IRQS and we set virq = hwirq. In my case however hwirq = 590082 and we try and access irq_desc[590082], slightly past the end at 512 entries. Lucky we ship lots of memory with our machines. Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix pci domain detection
On Wed, 2007-09-26 at 16:02 +0200, Arnd Bergmann wrote:
> The /proc/bus/pci/* files list PCI domain numbers only for
> devices that claim to be on a multi-domain system. The check
> for this is broken on powerpc, because the buid value is
> truncated to 32 bits.
>
> There is at least one machine (IBM QS21) that only uses
> the high-order bits of the buid, so the return value
> of pci_proc_domain() ends up being always zero, which
> makes /proc/bus/pci useless.
>
> Change the logic to always return '1' for a nonzero
> buid value.
>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Good catch !
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
>
> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> index 291ffbc..9f63bdc 100644
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
> @@ -588,7 +588,7 @@ int pci_proc_domain(struct pci_bus *bus)
> return 0;
> else {
> struct pci_controller *hose = pci_bus_to_host(bus);
> - return hose->buid;
> + return hose->buid != 0;
> }
> }
>
> ___
> 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 v3 10/12] Uartlite: Comment block tidy
From: Grant Likely <[EMAIL PROTECTED]>
Tidy the comments to split the driver into logical section; the main driver,
the console driver, the platform bus binding, and module initialization
and teardown.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/uartlite.c | 43 ---
1 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index c00a627..ed13b9f 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -23,9 +23,13 @@
#define ULITE_MINOR187
#define ULITE_NR_UARTS 4
-/* For register details see datasheet:
- http://www.xilinx.com/bvdocs/ipcenter/data_sheet/opb_uartlite.pdf
-*/
+/* -
+ * Register definitions
+ *
+ * For register details see datasheet:
+ * http://www.xilinx.com/bvdocs/ipcenter/data_sheet/opb_uartlite.pdf
+ */
+
#define ULITE_RX 0x00
#define ULITE_TX 0x04
#define ULITE_STATUS 0x08
@@ -49,6 +53,10 @@
static struct uart_port ulite_ports[ULITE_NR_UARTS];
+/* -
+ * Core UART driver operations
+ */
+
static int ulite_receive(struct uart_port *port, int stat)
{
struct tty_struct *tty = port->info->tty;
@@ -308,6 +316,10 @@ static struct uart_ops ulite_ops = {
.verify_port= ulite_verify_port
};
+/* -
+ * Console driver operations
+ */
+
#ifdef CONFIG_SERIAL_UARTLITE_CONSOLE
static void ulite_console_wait_tx(struct uart_port *port)
{
@@ -413,6 +425,19 @@ static struct uart_driver ulite_uart_driver = {
#endif
};
+/* -
+ * Port assignment functions (mapping devices to uart_port structures)
+ */
+
+/** ulite_assign: register a uartlite device with the driver
+ *
+ * @dev: pointer to device structure
+ * @id: requested id number. Pass -1 for automatic port assignment
+ * @base: base address of uartlite registers
+ * @irq: irq number for uartlite
+ *
+ * Returns: 0 on success, <0 otherwise
+ */
static int __devinit ulite_assign(struct device *dev, int id, u32 base, int
irq)
{
struct uart_port *port;
@@ -465,6 +490,10 @@ static int __devinit ulite_assign(struct device *dev, int
id, u32 base, int irq)
return 0;
}
+/** ulite_release: register a uartlite device with the driver
+ *
+ * @dev: pointer to device structure
+ */
static int __devinit ulite_release(struct device *dev)
{
struct uart_port *port = dev_get_drvdata(dev);
@@ -479,6 +508,10 @@ static int __devinit ulite_release(struct device *dev)
return rc;
}
+/* -
+ * Platform bus binding
+ */
+
static int __devinit ulite_probe(struct platform_device *pdev)
{
struct resource *res, *res2;
@@ -508,6 +541,10 @@ static struct platform_driver ulite_platform_driver = {
},
};
+/* -
+ * Module setup/teardown
+ */
+
int __init ulite_init(void)
{
int ret;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 08/12] Uartlite: Add macro for uartlite device name
From: Grant Likely <[EMAIL PROTECTED]>
Changed to make the following OF_platform bus binding patch a wee bit cleaner
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/uartlite.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index ae05a67..10e0da9 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -18,6 +18,7 @@
#include
#include
+#define ULITE_NAME "ttyUL"
#define ULITE_MAJOR204
#define ULITE_MINOR187
#define ULITE_NR_UARTS 4
@@ -381,7 +382,7 @@ static int __init ulite_console_setup(struct console *co,
char *options)
static struct uart_driver ulite_uart_driver;
static struct console ulite_console = {
- .name = "ttyUL",
+ .name = ULITE_NAME,
.write = ulite_console_write,
.device = uart_console_device,
.setup = ulite_console_setup,
@@ -403,7 +404,7 @@ console_initcall(ulite_console_init);
static struct uart_driver ulite_uart_driver = {
.owner = THIS_MODULE,
.driver_name= "uartlite",
- .dev_name = "ttyUL",
+ .dev_name = ULITE_NAME,
.major = ULITE_MAJOR,
.minor = ULITE_MINOR,
.nr = ULITE_NR_UARTS,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 09/12] Uartlite: Separate the bus binding from the driver proper
From: Grant Likely <[EMAIL PROTECTED]>
Separate the bus binding code from the driver structure allocation code in
preparation for adding the of_platform_bus bindings needed by arch/powerpc
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/uartlite.c | 99 ++---
1 files changed, 65 insertions(+), 34 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 10e0da9..c00a627 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -413,59 +413,90 @@ static struct uart_driver ulite_uart_driver = {
#endif
};
-static int __devinit ulite_probe(struct platform_device *pdev)
+static int __devinit ulite_assign(struct device *dev, int id, u32 base, int
irq)
{
- struct resource *res, *res2;
struct uart_port *port;
+ int rc;
- if (pdev->id < 0 || pdev->id >= ULITE_NR_UARTS)
+ /* if id = -1; then scan for a free id and use that */
+ if (id < 0) {
+ for (id = 0; id < ULITE_NR_UARTS; id++)
+ if (ulite_ports[id].mapbase == 0)
+ break;
+ }
+ if (id < 0 || id >= ULITE_NR_UARTS) {
+ dev_err(dev, "%s%i too large\n", ULITE_NAME, id);
return -EINVAL;
+ }
- if (ulite_ports[pdev->id].membase)
+ if (ulite_ports[id].mapbase) {
+ dev_err(dev, "cannot assign to %s%i; it is already in use\n",
+ ULITE_NAME, id);
return -EBUSY;
+ }
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
+ port = &ulite_ports[id];
- res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res2)
- return -ENODEV;
+ spin_lock_init(&port->lock);
+ port->fifosize = 16;
+ port->regshift = 2;
+ port->iotype = UPIO_MEM;
+ port->iobase = 1; /* mark port in use */
+ port->mapbase = base;
+ port->membase = NULL;
+ port->ops = &ulite_ops;
+ port->irq = irq;
+ port->flags = UPF_BOOT_AUTOCONF;
+ port->dev = dev;
+ port->type = PORT_UNKNOWN;
+ port->line = id;
+
+ dev_set_drvdata(dev, port);
+
+ /* Register the port */
+ rc = uart_add_one_port(&ulite_uart_driver, port);
+ if (rc) {
+ dev_err(dev, "uart_add_one_port() failed; err=%i\n", rc);
+ port->mapbase = 0;
+ dev_set_drvdata(dev, NULL);
+ return rc;
+ }
- port = &ulite_ports[pdev->id];
+ return 0;
+}
- port->fifosize = 16;
- port->regshift = 2;
- port->iotype= UPIO_MEM;
- port->iobase= 1; /* mark port in use */
- port->mapbase = res->start;
- port->membase = NULL;
- port->ops = &ulite_ops;
- port->irq = res2->start;
- port->flags = UPF_BOOT_AUTOCONF;
- port->dev = &pdev->dev;
- port->type = PORT_UNKNOWN;
- port->line = pdev->id;
+static int __devinit ulite_release(struct device *dev)
+{
+ struct uart_port *port = dev_get_drvdata(dev);
+ int rc = 0;
- uart_add_one_port(&ulite_uart_driver, port);
- platform_set_drvdata(pdev, port);
+ if (port) {
+ rc = uart_remove_one_port(&ulite_uart_driver, port);
+ dev_set_drvdata(dev, NULL);
+ port->mapbase = 0;
+ }
- return 0;
+ return rc;
}
-static int ulite_remove(struct platform_device *pdev)
+static int __devinit ulite_probe(struct platform_device *pdev)
{
- struct uart_port *port = platform_get_drvdata(pdev);
+ struct resource *res, *res2;
- platform_set_drvdata(pdev, NULL);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
- if (port)
- uart_remove_one_port(&ulite_uart_driver, port);
+ res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res2)
+ return -ENODEV;
- /* mark port as free */
- port->membase = NULL;
+ return ulite_assign(&pdev->dev, pdev->id, res->start, res2->start);
+}
- return 0;
+static int ulite_remove(struct platform_device *pdev)
+{
+ return ulite_release(&pdev->dev);
}
static struct platform_driver ulite_platform_driver = {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 02/12] Virtex: Add Kconfig macros for Xilinx Virtex board support
From: Grant Likely <[EMAIL PROTECTED]> Add the needed kconfig macros to enable Xilinx Virtex board support Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- arch/powerpc/platforms/40x/Kconfig | 38 1 files changed, 25 insertions(+), 13 deletions(-) diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig index c3dce3b..a0a50b1 100644 --- a/arch/powerpc/platforms/40x/Kconfig +++ b/arch/powerpc/platforms/40x/Kconfig @@ -61,13 +61,22 @@ config WALNUT help This option enables support for the IBM PPC405GP evaluation board. -#config XILINX_ML300 -# bool "Xilinx-ML300" -# depends on 40x -# default y -# select VIRTEX_II_PRO -# help -#This option enables support for the Xilinx ML300 evaluation board. +config XILINX_VIRTEX_GENERIC_BOARD + bool "Generic Xilinx Virtex board" + depends on 40x + default n + select XILINX_VIRTEX_II_PRO + select XILINX_VIRTEX_4_FX + help + This option enables generic support for Xilinx Virtex based boards. + + The generic virtex board support matches any device tree which + specifies 'xilinx,virtex' in its compatible field. This includes + the Xilinx ML3xx and ML4xx reference designs using the powerpc + core. + + Most Virtex designs should use this unless it needs to do some + special configuration at board probe time. # 40x specific CPU modules, selected based on the board above. config NP405H @@ -91,11 +100,19 @@ config 405EP config 405GPR bool -config VIRTEX_II_PRO +config XILINX_VIRTEX bool + +config XILINX_VIRTEX_II_PRO + bool + select XILINX_VIRTEX select IBM405_ERR77 select IBM405_ERR51 +config XILINX_VIRTEX_4_FX + bool + select XILINX_VIRTEX + config STB03xxx bool select IBM405_ERR77 @@ -111,11 +128,6 @@ config IBM405_ERR77 config IBM405_ERR51 bool -#config XILINX_OCP -# bool -# depends on XILINX_ML300 -# default y - #config BIOS_FIXUP # bool # depends on BUBINGA || EP405 || SYCAMORE || WALNUT ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 06/12] Uartlite: Fix reg io to access documented register size
From: Grant Likely <[EMAIL PROTECTED]>
The Uartlite data sheet defines the registers as 32 bit wide. This
patch changes the register access to use 32 bit transfers and eliminates
the magic +3 offset which is currently required to make the device
work.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Acked-by: John Williams <[EMAIL PROTECTED]>
---
arch/ppc/syslib/virtex_devices.c |2 +-
drivers/serial/uartlite.c| 32
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
index ace4ec0..270ad3a 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -28,7 +28,7 @@
.num_resources = 2, \
.resource = (struct resource[]) { \
{ \
- .start = XPAR_UARTLITE_##num##_BASEADDR + 3, \
+ .start = XPAR_UARTLITE_##num##_BASEADDR, \
.end = XPAR_UARTLITE_##num##_HIGHADDR, \
.flags = IORESOURCE_MEM, \
}, \
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index f5051cf..59b674a 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -61,7 +61,7 @@ static int ulite_receive(struct uart_port *port, int stat)
/* stats */
if (stat & ULITE_STATUS_RXVALID) {
port->icount.rx++;
- ch = readb(port->membase + ULITE_RX);
+ ch = in_be32((void*)port->membase + ULITE_RX);
if (stat & ULITE_STATUS_PARITY)
port->icount.parity++;
@@ -106,7 +106,7 @@ static int ulite_transmit(struct uart_port *port, int stat)
return 0;
if (port->x_char) {
- writeb(port->x_char, port->membase + ULITE_TX);
+ out_be32((void*)port->membase + ULITE_TX, port->x_char);
port->x_char = 0;
port->icount.tx++;
return 1;
@@ -115,7 +115,7 @@ static int ulite_transmit(struct uart_port *port, int stat)
if (uart_circ_empty(xmit) || uart_tx_stopped(port))
return 0;
- writeb(xmit->buf[xmit->tail], port->membase + ULITE_TX);
+ out_be32((void*)port->membase + ULITE_TX, xmit->buf[xmit->tail]);
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE-1);
port->icount.tx++;
@@ -132,7 +132,7 @@ static irqreturn_t ulite_isr(int irq, void *dev_id)
int busy;
do {
- int stat = readb(port->membase + ULITE_STATUS);
+ int stat = in_be32((void*)port->membase + ULITE_STATUS);
busy = ulite_receive(port, stat);
busy |= ulite_transmit(port, stat);
} while (busy);
@@ -148,7 +148,7 @@ static unsigned int ulite_tx_empty(struct uart_port *port)
unsigned int ret;
spin_lock_irqsave(&port->lock, flags);
- ret = readb(port->membase + ULITE_STATUS);
+ ret = in_be32((void*)port->membase + ULITE_STATUS);
spin_unlock_irqrestore(&port->lock, flags);
return ret & ULITE_STATUS_TXEMPTY ? TIOCSER_TEMT : 0;
@@ -171,7 +171,7 @@ static void ulite_stop_tx(struct uart_port *port)
static void ulite_start_tx(struct uart_port *port)
{
- ulite_transmit(port, readb(port->membase + ULITE_STATUS));
+ ulite_transmit(port, in_be32((void*)port->membase + ULITE_STATUS));
}
static void ulite_stop_rx(struct uart_port *port)
@@ -200,17 +200,17 @@ static int ulite_startup(struct uart_port *port)
if (ret)
return ret;
- writeb(ULITE_CONTROL_RST_RX | ULITE_CONTROL_RST_TX,
- port->membase + ULITE_CONTROL);
- writeb(ULITE_CONTROL_IE, port->membase + ULITE_CONTROL);
+ out_be32((void*)port->membase + ULITE_CONTROL,
+ULITE_CONTROL_RST_RX | ULITE_CONTROL_RST_TX);
+ out_be32((void*)port->membase + ULITE_CONTROL, ULITE_CONTROL_IE);
return 0;
}
static void ulite_shutdown(struct uart_port *port)
{
- writeb(0, port->membase + ULITE_CONTROL);
- readb(port->membase + ULITE_CONTROL); /* dummy */
+ out_be32((void*)port->membase + ULITE_CONTROL, 0);
+ in_be32((void*)port->membase + ULITE_CONTROL); /* dummy */
free_irq(port->irq, port);
}
@@ -314,7 +314,7 @@ static void ulite_console_wait_tx(struct uart_port *port)
/* wait up to 10ms for the character(s) to be sent */
for (i = 0; i < 1; i++) {
- if (readb(port->membase + ULITE_STATUS) & ULITE_STATUS_TXEMPTY)
+ if (in_be32((void*)port->membase + ULITE_STATUS) &
ULITE_STATUS_TXEMPTY)
break;
udelay(1);
}
@@ -323,7 +323,7 @@ static void ulite_console_wait_tx(struct uart_port *port)
static void ulite_console_putchar(struct uart_port *port, int ch)
{
ulite_console_wait_tx(port);
- writeb(ch, port->membase + ULITE_TX);
+ out_be32((void*)p
[PATCH v3 04/12] Virtex: Add generic Xilinx Virtex board support
From: Grant Likely <[EMAIL PROTECTED]>
Adds support for generic Xilinx Virtex boards. Any board which specifies
"xilinx,virtex" in the compatible property will make use of this board
support.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/Makefile |1 +
arch/powerpc/platforms/40x/virtex.c | 50 +++
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Makefile
b/arch/powerpc/platforms/40x/Makefile
index e6c0bbd..0a3cfe9 100644
--- a/arch/powerpc/platforms/40x/Makefile
+++ b/arch/powerpc/platforms/40x/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_WALNUT) += walnut.o
+obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) += virtex.o
diff --git a/arch/powerpc/platforms/40x/virtex.c
b/arch/powerpc/platforms/40x/virtex.c
new file mode 100644
index 000..b52aa94
--- /dev/null
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -0,0 +1,50 @@
+/*
+ * Xilinx Virtex (IIpro & 4FX) based board support
+ *
+ * Copyright 2007 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int __init virtex_device_probe(void)
+{
+ if (!machine_is(virtex))
+ return 0;
+
+ of_platform_bus_probe(NULL, NULL, NULL);
+
+ return 0;
+}
+device_initcall(virtex_device_probe);
+
+static int __init virtex_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "xilinx,virtex"))
+ return 0;
+
+ return 1;
+}
+
+static void __init virtex_setup_arch(void)
+{
+}
+
+define_machine(virtex) {
+ .name = "Xilinx Virtex",
+ .probe = virtex_probe,
+ .setup_arch = virtex_setup_arch,
+ .init_IRQ = xilinx_intc_init_tree,
+ .get_irq= xilinx_intc_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 12/12] Uartlite: Let the console be initialized earlier
From: Grant Likely <[EMAIL PROTECTED]>
By configuring it earlier we get console output sooner which is helpful
for debugging when the kernel crashes before the serial drivers are
initialized.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/uartlite.c | 41 ++---
1 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 0904c2a..2b8404c 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -373,6 +373,31 @@ static void ulite_console_write(struct console *co, const
char *s,
spin_unlock_irqrestore(&port->lock, flags);
}
+#if defined(CONFIG_OF)
+static inline void __init ulite_console_of_find_device(int id)
+{
+ struct device_node *np;
+ struct resource res;
+ const unsigned int *of_id;
+ int rc;
+
+ for_each_compatible_node(np, NULL, "xilinx,uartlite") {
+ of_id = of_get_property(np, "port-number", NULL);
+ if ((!of_id) || (*of_id != id))
+ continue;
+
+ rc = of_address_to_resource(np, 0, &res);
+ if (rc)
+ continue;
+
+ ulite_ports[id].mapbase = res.start;
+ return;
+ }
+}
+#else /* CONFIG_OF */
+static inline void __init ulite_console_of_find_device(int id) { /* do nothing
*/ }
+#endif /* CONFIG_OF */
+
static int __init ulite_console_setup(struct console *co, char *options)
{
struct uart_port *port;
@@ -386,10 +411,20 @@ static int __init ulite_console_setup(struct console *co,
char *options)
port = &ulite_ports[co->index];
+ /* Check if it is an OF device */
+ if (!port->mapbase)
+ ulite_console_of_find_device(co->index);
+
+ /* Do we have a device now? */
+ if (!port->mapbase) {
+ pr_debug("console on ttyUL%i not present\n", co->index);
+ return -ENODEV;
+ }
+
/* not initialized yet? */
if (!port->membase) {
- pr_debug("console on ttyUL%i not initialized\n", co->index);
- return -ENODEV;
+ if (ulite_request_port(port))
+ return -ENODEV;
}
if (options)
@@ -461,7 +496,7 @@ static int __devinit ulite_assign(struct device *dev, int
id, u32 base, int irq)
return -EINVAL;
}
- if (ulite_ports[id].mapbase) {
+ if ((ulite_ports[id].mapbase) && (ulite_ports[id].mapbase != base)) {
dev_err(dev, "cannot assign to %s%i; it is already in use\n",
ULITE_NAME, id);
return -EBUSY;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 11/12] Uartlite: Add of-platform-bus binding
From: Grant Likely <[EMAIL PROTECTED]>
Add of_platform bus binding so this driver can be used with arch/powerpc
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/uartlite.c | 96 +++--
1 files changed, 92 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index ed13b9f..0904c2a 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -1,7 +1,8 @@
/*
* uartlite.c: Serial driver for Xilinx uartlite serial controller
*
- * Peter Korsgaard <[EMAIL PROTECTED]>
+ * Copyright (C) 2006 Peter Korsgaard <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Secret Lab Technologies Ltd.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -17,6 +18,10 @@
#include
#include
#include
+#if defined(CONFIG_OF)
+#include
+#include
+#endif
#define ULITE_NAME "ttyUL"
#define ULITE_MAJOR204
@@ -382,8 +387,10 @@ static int __init ulite_console_setup(struct console *co,
char *options)
port = &ulite_ports[co->index];
/* not initialized yet? */
- if (!port->membase)
+ if (!port->membase) {
+ pr_debug("console on ttyUL%i not initialized\n", co->index);
return -ENODEV;
+ }
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
@@ -542,6 +549,72 @@ static struct platform_driver ulite_platform_driver = {
};
/* -
+ * OF bus bindings
+ */
+#if defined(CONFIG_OF)
+static int __devinit
+ulite_of_probe(struct of_device *op, const struct of_device_id *match)
+{
+ struct resource res;
+ const unsigned int *id;
+ int irq, rc;
+
+ dev_dbg(&op->dev, "%s(%p, %p)\n", __FUNCTION__, op, match);
+
+ rc = of_address_to_resource(op->node, 0, &res);
+ if (rc) {
+ dev_err(&op->dev, "invalide address\n");
+ return rc;
+ }
+
+ irq = irq_of_parse_and_map(op->node, 0);
+
+ id = of_get_property(op->node, "port-number", NULL);
+
+ return ulite_assign(&op->dev, id ? *id : -1, res.start, irq);
+}
+
+static int __devexit ulite_of_remove(struct of_device *op)
+{
+ return ulite_release(&op->dev);
+}
+
+/* Match table for of_platform binding */
+static struct of_device_id __devinit ulite_of_match[] = {
+ { .type = "serial", .compatible = "xilinx,uartlite", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ulite_of_match);
+
+static struct of_platform_driver ulite_of_driver = {
+ .owner = THIS_MODULE,
+ .name = "uartlite",
+ .match_table = ulite_of_match,
+ .probe = ulite_of_probe,
+ .remove = __devexit_p(ulite_of_remove),
+ .driver = {
+ .name = "uartlite",
+ },
+};
+
+/* Registration helpers to keep the number of #ifdefs to a minimum */
+static inline int __init ulite_of_register(void)
+{
+ pr_debug("uartlite: calling of_register_platform_driver()\n");
+ return of_register_platform_driver(&ulite_of_driver);
+}
+
+static inline void __exit ulite_of_unregister(void)
+{
+ of_unregister_platform_driver(&ulite_of_driver);
+}
+#else /* CONFIG_OF */
+/* CONFIG_OF not enabled; do nothing helpers */
+static inline int __init ulite_of_register(void) { return 0; }
+static inline void __exit ulite_of_unregister(void) { }
+#endif /* CONFIG_OF */
+
+/* -
* Module setup/teardown
*/
@@ -549,20 +622,35 @@ int __init ulite_init(void)
{
int ret;
+ pr_debug("uartlite: calling uart_register_driver()\n");
ret = uart_register_driver(&ulite_uart_driver);
if (ret)
- return ret;
+ goto err_uart;
+
+ ret = ulite_of_register();
+ if (ret)
+ goto err_of;
+ pr_debug("uartlite: calling platform_driver_register()\n");
ret = platform_driver_register(&ulite_platform_driver);
if (ret)
- uart_unregister_driver(&ulite_uart_driver);
+ goto err_plat;
+
+ return 0;
+err_plat:
+ ulite_of_unregister();
+err_of:
+ uart_unregister_driver(&ulite_uart_driver);
+err_uart:
+ printk(KERN_ERR "registering uartlite driver failed: err=%i", ret);
return ret;
}
void __exit ulite_exit(void)
{
platform_driver_unregister(&ulite_platform_driver);
+ ulite_of_unregister();
uart_unregister_driver(&ulite_uart_driver);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 07/12] Uartlite: change name of ports to ulite_ports
From: Grant Likely <[EMAIL PROTECTED]>
Changed to match naming convention used in the rest of the module
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/uartlite.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 59b674a..ae05a67 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -46,7 +46,7 @@
#define ULITE_CONTROL_IE 0x10
-static struct uart_port ports[ULITE_NR_UARTS];
+static struct uart_port ulite_ports[ULITE_NR_UARTS];
static int ulite_receive(struct uart_port *port, int stat)
{
@@ -329,7 +329,7 @@ static void ulite_console_putchar(struct uart_port *port,
int ch)
static void ulite_console_write(struct console *co, const char *s,
unsigned int count)
{
- struct uart_port *port = &ports[co->index];
+ struct uart_port *port = &ulite_ports[co->index];
unsigned long flags;
unsigned int ier;
int locked = 1;
@@ -366,7 +366,7 @@ static int __init ulite_console_setup(struct console *co,
char *options)
if (co->index < 0 || co->index >= ULITE_NR_UARTS)
return -EINVAL;
- port = &ports[co->index];
+ port = &ulite_ports[co->index];
/* not initialized yet? */
if (!port->membase)
@@ -420,7 +420,7 @@ static int __devinit ulite_probe(struct platform_device
*pdev)
if (pdev->id < 0 || pdev->id >= ULITE_NR_UARTS)
return -EINVAL;
- if (ports[pdev->id].membase)
+ if (ulite_ports[pdev->id].membase)
return -EBUSY;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -431,7 +431,7 @@ static int __devinit ulite_probe(struct platform_device
*pdev)
if (!res2)
return -ENODEV;
- port = &ports[pdev->id];
+ port = &ulite_ports[pdev->id];
port->fifosize = 16;
port->regshift = 2;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 05/12] Add PowerPC Xilinx Virtex entry to maintainers
From: Grant Likely <[EMAIL PROTECTED]> Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8f80068..bca4ca5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2304,6 +2304,13 @@ L: [EMAIL PROTECTED] T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git S: Maintained +LINUX FOR POWERPC EMBEDDED XILINX VIRTEX +P: Grant Likely +M: [EMAIL PROTECTED] +W: http://www.secretlab.ca/ +L: linuxppc-dev@ozlabs.org +S: Maintained + LINUX FOR POWERPC BOOT CODE P: Tom Rini M: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 03/12] Virtex: add xilinx interrupt controller driver
From: Grant Likely <[EMAIL PROTECTED]>
Adds support for the Xilinx opb-intc interrupt controller
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/Makefile |1
arch/powerpc/sysdev/xilinx_intc.c | 151 +
include/asm-powerpc/xilinx_intc.h | 20 +
3 files changed, 172 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 08ce31e..0457117 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_PPC_INDIRECT_PCI)+= indirect_pci.o
obj-$(CONFIG_PPC_I8259)+= i8259.o
obj-$(CONFIG_PPC_83xx) += ipic.o
obj-$(CONFIG_4xx) += uic.o
+obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
endif
# Temporary hack until we have migrated to asm-powerpc
diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
new file mode 100644
index 000..c2f17cc
--- /dev/null
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -0,0 +1,151 @@
+/*
+ * Interrupt controller driver for Xilinx Virtex FPGAs
+ *
+ * Copyright (C) 2007 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+/*
+ * This is a driver for the interrupt controller typically found in
+ * Xilinx Virtex FPGA designs.
+ *
+ * The interrupt sense levels are hard coded into the FPGA design with
+ * typically a 1:1 relationship between irq lines and devices (no shared
+ * irq lines). Therefore, this driver does not attempt to handle edge
+ * and level interrupts differently.
+ */
+#undef DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * INTC Registers
+ */
+#define XINTC_ISR 0 /* Interrupt Status */
+#define XINTC_IPR 4 /* Interrupt Pending */
+#define XINTC_IER 8 /* Interrupt Enable */
+#define XINTC_IAR 12 /* Interrupt Acknowledge */
+#define XINTC_SIE 16 /* Set Interrupt Enable bits */
+#define XINTC_CIE 20 /* Clear Interrupt Enable bits */
+#define XINTC_IVR 24 /* Interrupt Vector */
+#define XINTC_MER 28 /* Master Enable */
+
+static struct irq_host *master_irqhost;
+
+/*
+ * IRQ Chip operations
+ */
+static void xilinx_intc_mask(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void * regs = get_irq_chip_data(virq);
+ pr_debug("mask: %d\n", irq);
+ out_be32(regs + XINTC_CIE, 1 << irq);
+}
+
+static void xilinx_intc_unmask(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void * regs = get_irq_chip_data(virq);
+ pr_debug("unmask: %d\n", irq);
+ out_be32(regs + XINTC_SIE, 1 << irq);
+}
+
+static void xilinx_intc_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void * regs = get_irq_chip_data(virq);
+ pr_debug("ack: %d\n", irq);
+ out_be32(regs + XINTC_IAR, 1 << irq);
+}
+
+static struct irq_chip xilinx_intc_irqchip = {
+ .typename = "Xilinx INTC",
+ .mask = xilinx_intc_mask,
+ .unmask = xilinx_intc_unmask,
+ .ack = xilinx_intc_ack,
+};
+
+/*
+ * IRQ Host operations
+ */
+static int xilinx_intc_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t irq)
+{
+ set_irq_chip_data(virq, h->host_data);
+ set_irq_chip_and_handler(virq, &xilinx_intc_irqchip, handle_level_irq);
+ set_irq_type(virq, IRQ_TYPE_NONE);
+ return 0;
+}
+
+static struct irq_host_ops xilinx_intc_ops = {
+ .map = xilinx_intc_map,
+};
+
+struct irq_host * __init
+xilinx_intc_init(struct device_node *np)
+{
+ struct irq_host * irq;
+ struct resource res;
+ void * regs;
+ int rc;
+
+ /* Find and map the intc registers */
+ rc = of_address_to_resource(np, 0, &res);
+ if (rc) {
+ printk(KERN_ERR __FILE__ ": of_address_to_resource() failed\n");
+ return NULL;
+ }
+ regs = ioremap(res.start, 32);
+
+ printk(KERN_INFO "Xilinx intc at 0x%08X mapped to 0x%p\n",
+ res.start, regs);
+
+ /* Setup interrupt controller */
+ out_be32(regs + XINTC_IER, 0); /* disable all irqs */
+ out_be32(regs + XINTC_IAR, ~(u32) 0); /* Acknowledge pending irqs */
+ out_be32(regs + XINTC_MER, 0x3UL); /* Turn on the Master Enable. */
+
+ /* Allocate and initialize an irq_host structure. */
+ irq = irq_alloc_host(np, IRQ_HOST_MAP_LINEAR, 32, &xilinx_intc_ops, -1);
+ if (!irq)
+ panic(__FILE__ ": Cannot allocate IRQ host\n");
+ irq->host_data = regs;
+ return irq;
+}
+
+int xilinx_intc_get_irq(void)
+{
+ void * regs = master_irqhost->host_data;
+ pr_debug("get_irq:\n");
+ return irq_linear_revmap(master_irqhost, in_be32(regs + XINTC_IVR));
+}
+
[PATCH v3 00/12] Xilinx Virtex and Uartlite arch/powerpc patches ready for merge
Josh, Here is the Xilinx Virtex and Uartlite series of patches to add support to arch/powerpc. Please merge. Device tree source files (.dts) and defconfigs to follow in a subsuquent patch series. Thanks, 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
[PATCH v3 01/12] Virtex: Add uartlite bootwrapper driver
From: Grant Likely <[EMAIL PROTECTED]>
Allows the bootwrapper to use the uartlite device for console output.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile |2 +
arch/powerpc/boot/ops.h |1 +
arch/powerpc/boot/serial.c |2 +
arch/powerpc/boot/uartlite.c | 64 ++
4 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c1582b6..371fbc6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -45,7 +45,7 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c
flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
- cpm-serial.c stdlib.c
+ cpm-serial.c stdlib.c uartlite.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index 703255b..4ef30e4 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -84,6 +84,7 @@ int serial_console_init(void);
int ns16550_console_init(void *devp, struct serial_console_data *scdp);
int mpsc_console_init(void *devp, struct serial_console_data *scdp);
int cpm_console_init(void *devp, struct serial_console_data *scdp);
+int uartlite_console_init(void *devp, struct serial_console_data *scdp);
void *simple_alloc_init(char *base, unsigned long heap_size,
unsigned long granularity, unsigned long max_allocs);
extern void flush_cache(void *, unsigned long);
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index d47f8e0..70f36bf 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -126,6 +126,8 @@ int serial_console_init(void)
dt_is_compatible(devp, "fsl,cpm2-scc-uart") ||
dt_is_compatible(devp, "fsl,cpm2-smc-uart"))
rc = cpm_console_init(devp, &serial_cd);
+ else if (dt_is_compatible(devp, "xilinx,uartlite"))
+ rc = uartlite_console_init(devp, &serial_cd);
/* Add other serial console driver calls here */
diff --git a/arch/powerpc/boot/uartlite.c b/arch/powerpc/boot/uartlite.c
new file mode 100644
index 000..f4249a7
--- /dev/null
+++ b/arch/powerpc/boot/uartlite.c
@@ -0,0 +1,64 @@
+/*
+ * Xilinx UARTLITE bootloader driver
+ *
+ * Copyright (C) 2007 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "io.h"
+#include "ops.h"
+
+static void * reg_base;
+
+static int uartlite_open(void)
+{
+ /* Clear the RX FIFO */
+ out_be32(reg_base + 0x0C, 0x2);
+ return 0;
+}
+
+static void uartlite_putc(unsigned char c)
+{
+ while ((in_be32(reg_base + 0x8) & 0x08) != 0); /* spin */
+ out_be32(reg_base + 0x4, c);
+}
+
+static unsigned char uartlite_getc(void)
+{
+ while ((in_be32(reg_base + 0x8) & 0x01) == 0); /* spin */
+ return in_be32(reg_base);
+}
+
+static u8 uartlite_tstc(void)
+{
+ return ((in_be32(reg_base + 0x8) & 0x01) != 0);
+}
+
+int uartlite_console_init(void *devp, struct serial_console_data *scdp)
+{
+ int n;
+ unsigned long reg_phys;
+
+ n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
+ if (n != sizeof(reg_base)) {
+ if (!dt_xlate_reg(devp, 0, ®_phys, NULL))
+ return -1;
+
+ reg_base = (void *)reg_phys;
+ }
+
+ scdp->open = uartlite_open;
+ scdp->putc = uartlite_putc;
+ scdp->getc = uartlite_getc;
+ scdp->tstc = uartlite_tstc;
+ scdp->close = NULL;
+ return 0;
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
On Mon, Oct 01, 2007 at 05:41:32PM -0500, Linas Vepstas wrote: > On Mon, Oct 01, 2007 at 02:12:47PM -0600, Matthew Wilcox wrote: > > I think the fundamental problem is that completions aren't really > > supposed to be used like this. Here's one attempt at using completions > > perhaps a little more the way they're supposed to be used, > > Yes, that looks very good to me. I see it solves a bug that > I hadn't been quite aware of. I don't understand why > struct host_data is preferable to struct sym_shcb (is it because > this is the structure that is "naturally protectected" by the > spinlock?) The thing to remember is that sym2 is in transition from being a dual BSD/Linux driver to being a purely Linux driver. I know, it's been more than two years, and I'm still not done. My latest thing I'm looking at fixing is to make Scsi_Host very much the primary entity in the sym2 driver, and leave just the device/scripts-accessible stuff in the hcb. > My gut instinct is to say "ack", although prudence dictates that > I should test first. Which might take a few days... Fine by me. Do you have the ability to produce failures on a whim on your platforms? I've been vaguely musing a PCI device failure patch for x86, just so people can test driver failure paths. > I thought that earlier versions of the driver used waitqueues (I vaguely > remember "eh_wait" in the code), which were later converted to > completions (I also vaguely recall thinking that the new code was > more elegant/simpler). I converted my patch to use the completions > likewise, and, as you've clearly shown, did a rather sloppy job in > the conversion. eh_wait (when I removed it) contained a completion ... I think it used to be a semaphore, some time before 2.6.12 > I'm tempted to go with this patch; but if you prod, I could attempt > a wait-queue based patch. Let's leave it with a completion for now. I think it works out more efficiently in the end. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/18] Add PowerPC Xilinx Virtex entry to maintainers
Grant Likely writes: > On 9/28/07, Grant Likely <[EMAIL PROTECTED]> wrote: > > From: Grant Likely <[EMAIL PROTECTED]> > > > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > --- > > > > Paul, is this okay by you? Josh has already okayed it. > > Specifically, I'll collect the virtex changes and ask Josh to pull > them from me before requesting a pull from you. Sounds fine to me. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: MAINTAINERS shouldn't reference linuxppc-embedded
Powerpc patches should be posted to linuxppc-dev@ozlabs.org so modify MAINTAINERS to no longer reference [EMAIL PROTECTED] Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- MAINTAINERS | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) --- diff --git a/MAINTAINERS b/MAINTAINERS index 8f80068..06259b4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1543,7 +1543,7 @@ P:Pantelis Antoniou M: [EMAIL PROTECTED] P: Vitaly Bordug M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained @@ -1551,14 +1551,14 @@ FREESCALE HIGHSPEED USB DEVICE DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FREESCALE QUICC ENGINE UCC ETHERNET DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FILE LOCKING (flock() and fcntl()/lockf()) @@ -2291,7 +2291,6 @@ M:[EMAIL PROTECTED] W: http://www.246tNt.com/mpc52xx/ W: http://www.penguinppc.org/ L: linuxppc-dev@ozlabs.org -L: [EMAIL PROTECTED] S: Maintained LINUX FOR POWERPC EMBEDDED PPC4XX @@ -2300,7 +2299,7 @@ M:[EMAIL PROTECTED] P: Matt Porter M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git S: Maintained @@ -2308,21 +2307,21 @@ LINUX FOR POWERPC BOOT CODE P: Tom Rini M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC8XX P: Marcelo Tosatti M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX P: Kumar Gala M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC PA SEMI PWRFICIENT @@ -2978,7 +2977,7 @@ POWERPC 4xx EMAC DRIVER P: Eugene Surovegin M: [EMAIL PROTECTED] W: http://kernel.ebshome.net/emac/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Implement logging of unhandled signals
On Tue, Oct 02, 2007 at 09:41:30AM +1000, Stephen Rothwell wrote: > Hi Olof, > > On Mon, 1 Oct 2007 15:32:42 -0500 Olof Johansson <[EMAIL PROTECTED]> wrote: > > > > + char fmt32[] = KERN_INFO "%s[%d]: unhandled signal %d " \ > > + "at %08lx nip %08lx lr %08lx code %x\n"; > > + char fmt64[] = KERN_INFO "%s[%d]: unhandled signal %d " \ > > + "at %016lx nip %016lx lr %016lx code %x\n"; > > const char ... ? > > > +static char fmt32[] = KERN_INFO \ > > + "%s[%d]: bad frame in %s: %08lx nip %08lx lr %08lx\n"; > > +static char fmt64[] = KERN_INFO \ > > + "%s[%d]: bad frame in %s: %016lx nip %016lx lr %016lx\n"; > > again? Yeah, sure. Thanks, -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Change MAINTAINER references linuxppc-embedded
On Mon, Oct 01, 2007 at 05:20:53PM -0700, Mark A. Greer wrote: > Powerpc patches should be posted to linuxppc-dev@ozlabs.org so modify > MAINTAINERS to no longer reference [EMAIL PROTECTED] > > Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> /me sighs. Disregard this. I send before I had the proper subject Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Change MAINTAINER references linuxppc-embedded
Powerpc patches should be posted to linuxppc-dev@ozlabs.org so modify MAINTAINERS to no longer reference [EMAIL PROTECTED] Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- MAINTAINERS | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) --- diff --git a/MAINTAINERS b/MAINTAINERS index 8f80068..06259b4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1543,7 +1543,7 @@ P:Pantelis Antoniou M: [EMAIL PROTECTED] P: Vitaly Bordug M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained @@ -1551,14 +1551,14 @@ FREESCALE HIGHSPEED USB DEVICE DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FREESCALE QUICC ENGINE UCC ETHERNET DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FILE LOCKING (flock() and fcntl()/lockf()) @@ -2291,7 +2291,6 @@ M:[EMAIL PROTECTED] W: http://www.246tNt.com/mpc52xx/ W: http://www.penguinppc.org/ L: linuxppc-dev@ozlabs.org -L: [EMAIL PROTECTED] S: Maintained LINUX FOR POWERPC EMBEDDED PPC4XX @@ -2300,7 +2299,7 @@ M:[EMAIL PROTECTED] P: Matt Porter M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git S: Maintained @@ -2308,21 +2307,21 @@ LINUX FOR POWERPC BOOT CODE P: Tom Rini M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC8XX P: Marcelo Tosatti M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX P: Kumar Gala M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC PA SEMI PWRFICIENT @@ -2978,7 +2977,7 @@ POWERPC 4xx EMAC DRIVER P: Eugene Surovegin M: [EMAIL PROTECTED] W: http://kernel.ebshome.net/emac/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Get rid of linuxppc-embedded?
On Mon, Oct 01, 2007 at 02:59:14PM -0600, Grant Likely wrote: > On 10/1/07, Mark A. Greer <[EMAIL PROTECTED]> wrote: > > With the merging of the powerpc trees I'm not sure there is a clear > > reason why we have 2 separate powerpc lists anymore (linuxppc-dev and > > linuxppc-embedded). > > > > linuxppc-embedded is fairly low volume/noise but there is still the > > occasional > > patch posted there that should really be posted to linuxppc-dev. I think > > it would be nice to have just one list where all eyes are focused. > > > > Is it time to get rid of linuxppc-embedded? > > Ack Ack Ack! > > I agree 100% Okay. Even if we keep the list around, we should update MAINTAINERS to only refer to -dev. I'll post a patch in a second. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PowerPC: new EMAC driver typo fix
On Mon, 2007-10-01 at 18:57 -0500, Josh Boyer wrote:
> On Mon, 2007-10-01 at 18:23 +0400, Valentine Barshak wrote:
> > This looks like typo. Please, apply this patch to fix.
> >
> > diff -ruNp linux-2.6.orig/drivers/net/ibm_newemac/core.c
> > linux-2.6/drivers/net/ibm_newemac/core.c
> > --- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2007-10-01
> > 17:23:35.0 +0400
> > +++ linux-2.6/drivers/net/ibm_newemac/core.c2007-10-01
> > 17:44:57.0 +0400
> > @@ -1232,9 +1232,9 @@ static inline int emac_xmit_finish(struc
> > * instead
> > */
> > if (emac_has_feature(dev, EMAC_FTR_EMAC4))
> > - out_be32(&p->tmr0, EMAC_TMR0_XMIT);
> > - else
> > out_be32(&p->tmr0, EMAC4_TMR0_XMIT);
> > + else
> > + out_be32(&p->tmr0, EMAC_TMR0_XMIT);
> >
> > if (unlikely(++dev->tx_cnt == NUM_TX_BUFF)) {
> > netif_stop_queue(ndev);
>
> No Signed-off-by: line.
>
> The patch looks sane otherwise. David, Ben, comments?
It does definitely look like a genuine typo so Acked by me.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PowerPC: new EMAC driver typo fix
On Mon, 2007-10-01 at 18:23 +0400, Valentine Barshak wrote:
> This looks like typo. Please, apply this patch to fix.
>
> diff -ruNp linux-2.6.orig/drivers/net/ibm_newemac/core.c
> linux-2.6/drivers/net/ibm_newemac/core.c
> --- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2007-10-01
> 17:23:35.0 +0400
> +++ linux-2.6/drivers/net/ibm_newemac/core.c 2007-10-01 17:44:57.0
> +0400
> @@ -1232,9 +1232,9 @@ static inline int emac_xmit_finish(struc
>* instead
>*/
> if (emac_has_feature(dev, EMAC_FTR_EMAC4))
> - out_be32(&p->tmr0, EMAC_TMR0_XMIT);
> - else
> out_be32(&p->tmr0, EMAC4_TMR0_XMIT);
> + else
> + out_be32(&p->tmr0, EMAC_TMR0_XMIT);
>
> if (unlikely(++dev->tx_cnt == NUM_TX_BUFF)) {
> netif_stop_queue(ndev);
No Signed-off-by: line.
The patch looks sane otherwise. David, Ben, comments?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: Add RGMII support for Sequoia 440EPx
On Mon, 2007-10-01 at 18:12 +0400, Valentine Barshak wrote: > This adds RGMII support to Sequoia DTS and sets correct phy-mode > for EMACs. According to Sequoia datasheet, both ethernet ports > are connected to RGMII interface, while ZMII is used only for MDIO. I'm going to hold off on this one until the new EMAC driver is in Paul's tree. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Implement logging of unhandled signals
Hi Olof, On Mon, 1 Oct 2007 15:32:42 -0500 Olof Johansson <[EMAIL PROTECTED]> wrote: > > + char fmt32[] = KERN_INFO "%s[%d]: unhandled signal %d " \ > + "at %08lx nip %08lx lr %08lx code %x\n"; > + char fmt64[] = KERN_INFO "%s[%d]: unhandled signal %d " \ > + "at %016lx nip %016lx lr %016lx code %x\n"; const char ... ? > +static char fmt32[] = KERN_INFO \ > + "%s[%d]: bad frame in %s: %08lx nip %08lx lr %08lx\n"; > +static char fmt64[] = KERN_INFO \ > + "%s[%d]: bad frame in %s: %016lx nip %016lx lr %016lx\n"; again? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpQU2y6ggjnu.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
>> This is an interrupt controller (it has an "interrupt-controller" >> property, and it has no interrupt parent (there is no >> "interrupt-parent" >> property, for interrupt controllers you do not follow the "normal" >> tree >> parent), so it is the root interrupt controller and there is no loop. >> >> It seems from your description that the Linux code is using the tree >> parent as interrupt parent even for interrupt controller nodes. This >> is wrong behaviour. > > It shoudn't normally happen. The reason it -does- happen in fact is > that > the above node is also missing the #interrupt-cells property, which > cause the parent-lookup routine to skip it before it gets a chance to > see that there's an "interrupt-controller" property in there. > > I'm not sure whether linux behaviour is a bug or not since I believe we > are clearly in undefined-land as an interrupt controller should always > have a #interrupt-cells property. That isn't required for legacy (pieces of) trees that don't go through an interrupt-map, actually (but strongly recommended of course) -- and I'm not sure how valid a tree that uses the imap recommended practice for only part of the tree is really ;-) Either way, the Linux code should use the explicit information (the lack of "interrupt-parent" in a node with "interrupt-controller") to determine whether a node is the root interrupt controller, instead of some implicit information. You can then more clearly do sanity checking on "#interrupt-cells" etc. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7] [POWERPC] Fix QEIC->MPIC cascading
On Tue, 2007-09-25 at 18:34 +0400, Anton Vorontsov wrote: > set_irq_chained_handler overwrites MPIC's handle_irq function > (handle_fasteoi_irq) thus MPIC never gets eoi event from the > cascaded IRQ. This situation hangs MPIC on MPC8568E. > > Patch adds flow level "end" handler to the MPIC, and QEIC calls > it when QEIC's interrupt processing finished. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Not sure if I already NAKed it on the list, so if I didn't here's it :-) The proper way of doing that is to have the cascade handler perform the EOI call to mpic. Look at how it's done for i8259 mpic cascade handlers. Basically, when doing a cascade nowadays, you can either just do a normal request_irq() of the cascade, in which case your handler don't have to care about the parent controller at all, but you get various limitations and/or overhead from being a full blown interrupt handler, or you can use the chained handler mechanism which is a "shortcut" but implies that your cascade handler "knows" what needs to be done to the parent (and thus is specific to the combination parent/child). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
On Tue, 2007-10-02 at 08:54 +1000, Benjamin Herrenschmidt wrote: > It shoudn't normally happen. The reason it -does- happen in fact is > that > the above node is also missing the #interrupt-cells property, which > cause the parent-lookup routine to skip it before it gets a chance to > see that there's an "interrupt-controller" property in there. > > I'm not sure whether linux behaviour is a bug or not since I believe > we > are clearly in undefined-land as an interrupt controller should always > have a #interrupt-cells property. That's btw something we could add as a warning to dtc... A node with "interrupt-controller" or "interrupt-map" in it should always have a #interrupt-cells property. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
On Tue, 2007-10-02 at 00:33 +0200, Segher Boessenkool wrote:
> > i8259: [EMAIL PROTECTED] {
> > device_type = "interrupt-controller";
> > compatible = "pnpPNP,000";
> > interrupt-controller;
> > reg = <0001 0020 0002
> >0001 00a0 0002
> >0001 04d0 0002>;
> > reserved-interrupts = <2>;
> > };
>
> This is an interrupt controller (it has an "interrupt-controller"
> property, and it has no interrupt parent (there is no "interrupt-parent"
> property, for interrupt controllers you do not follow the "normal" tree
> parent), so it is the root interrupt controller and there is no loop.
>
> It seems from your description that the Linux code is using the tree
> parent as interrupt parent even for interrupt controller nodes. This
> is wrong behaviour.
It shoudn't normally happen. The reason it -does- happen in fact is that
the above node is also missing the #interrupt-cells property, which
cause the parent-lookup routine to skip it before it gets a chance to
see that there's an "interrupt-controller" property in there.
I'm not sure whether linux behaviour is a bug or not since I believe we
are clearly in undefined-land as an interrupt controller should always
have a #interrupt-cells property.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
On Mon, Oct 01, 2007 at 02:12:47PM -0600, Matthew Wilcox wrote: > > I think the fundamental problem is that completions aren't really > supposed to be used like this. Here's one attempt at using completions > perhaps a little more the way they're supposed to be used, Yes, that looks very good to me. I see it solves a bug that I hadn't been quite aware of. I don't understand why struct host_data is preferable to struct sym_shcb (is it because this is the structure that is "naturally protectected" by the spinlock?) My gut instinct is to say "ack", although prudence dictates that I should test first. Which might take a few days... > although now > I've written it, I wonder if we shouldn't just use a waitqueue instead. I thought that earlier versions of the driver used waitqueues (I vaguely remember "eh_wait" in the code), which were later converted to completions (I also vaguely recall thinking that the new code was more elegant/simpler). I converted my patch to use the completions likewise, and, as you've clearly shown, did a rather sloppy job in the conversion. I'm tempted to go with this patch; but if you prod, I could attempt a wait-queue based patch. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
> i8259: [EMAIL PROTECTED] {
> device_type = "interrupt-controller";
> compatible = "pnpPNP,000";
> interrupt-controller;
> reg = <0001 0020 0002
> 0001 00a0 0002
> 0001 04d0 0002>;
> reserved-interrupts = <2>;
> };
This is an interrupt controller (it has an "interrupt-controller"
property, and it has no interrupt parent (there is no "interrupt-parent"
property, for interrupt controllers you do not follow the "normal" tree
parent), so it is the root interrupt controller and there is no loop.
It seems from your description that the Linux code is using the tree
parent as interrupt parent even for interrupt controller nodes. This
is wrong behaviour.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
On Mon, 2007-10-01 at 16:48 -0500, Scott Wood wrote: > Benjamin Herrenschmidt wrote: > > On Mon, 2007-10-01 at 16:37 -0500, Scott Wood wrote: > >> Scott Wood wrote: > >> Actually, it doesn't -- it should stop when it sees the > >> interrupt-controller property in the i8259 node, at which point it'll be > >> trying to use the raw PCI IRQ pin number as an i8259 IRQ. This is > >> Unlikely To Work(tm). > > > > It will work in the specific 8259 case I suppose since it gets the > > legacy 1:1 mapping... but it sucks :-) > > The mapping between INTA-D and i8259 numbers isn't generally 1:1, and it > looked as if it'd try using the former... though the code is > sufficiently complicated that I could easily be missing something. If the whole of_* thing totally fails, pci_read_irq_line should pickup the value in the config space PCI_INTERRUPT_LINE. That will work on things like Pegasos and possibly on this AmigaOne but it sucks. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
Benjamin Herrenschmidt wrote: > On Mon, 2007-10-01 at 16:37 -0500, Scott Wood wrote: >> Scott Wood wrote: >> Actually, it doesn't -- it should stop when it sees the >> interrupt-controller property in the i8259 node, at which point it'll be >> trying to use the raw PCI IRQ pin number as an i8259 IRQ. This is >> Unlikely To Work(tm). > > It will work in the specific 8259 case I suppose since it gets the > legacy 1:1 mapping... but it sucks :-) The mapping between INTA-D and i8259 numbers isn't generally 1:1, and it looked as if it'd try using the former... though the code is sufficiently complicated that I could easily be missing something. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
nap/dfs on 7448
I asked this on linuxppc-embedded a week ago (I didn't even know this list existed until last week -- another reason to get rid of linuxpcc-embedded). Has anyone gotten NAP/DFS to reliably work on a 7448? I'm seeing strange problems with peripherals...(using a ram disk works fine). marty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
On Mon, 2007-10-01 at 16:37 -0500, Scott Wood wrote: > Scott Wood wrote: > >> The problem occurs now, if there is no device node defined for another > >> PCI device. In this case, of_irq_map_pci() checks for an interrupt pin, > >> searches again for the host bridge node and calls of_irq_map_raw() with > >> the device node of the host bridge. The function finds the > >> #interrupt-cells, #address-cells, interrupt-controller properties, but > >> fails to find the interrupt-map property (because it's missing in the > >> device tree). Therefore the function then tries to find a new parent, > >> which leads to an endless loop (it always selects the PCI2ISA southbridge > >> in the device tree). > > > > That seems likely... there should probably be some loop detection. > > Actually, it doesn't -- it should stop when it sees the > interrupt-controller property in the i8259 node, at which point it'll be > trying to use the raw PCI IRQ pin number as an i8259 IRQ. This is > Unlikely To Work(tm). It will work in the specific 8259 case I suppose since it gets the legacy 1:1 mapping... but it sucks :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
On Mon, 2007-10-01 at 23:11 +0200, Gerhard Pircher wrote:
> [EMAIL PROTECTED] {
> device_type = "pci";
> compatible = "mai-logic,articia-s";
> bus-frequency = <01fca055>; // 33.3MHz
> bus-range = <0 ff>;
> ranges = <0100 0 fe00 0
> 00c0 // PCI I/O
> 0200 0 8000 8000 0
> 7d00 // PCI memory
> 0200 0 fd00 fd00 0
> 0100>; // PCI alias memory
> 8259-interrupt-acknowledge = ;
> interrupt-parent = <&i8259>;
> #interrupt-cells = <1>;
> #address-cells = <3>;
> #size-cells = <2>;
>
Part of your problem is that interrupt-parent property. You shouldn't
have such a property in a PCI host bridge. It's not technically illegal,
but it's triggering the "loop" you've been experiencing.
If you want the parsing to fail for PCI devices (to get the fallback to
config space values), you need to make sure it does fail.
Another option is to put an empty interrupt-map in there. That will
guarantee failure.
But that's all very ugly. I don't understand why you don't setup a
proper map either from your bootloader, zImage wrapper or even prom_init
or platform code.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
Scott Wood wrote: >> The problem occurs now, if there is no device node defined for another >> PCI device. In this case, of_irq_map_pci() checks for an interrupt pin, >> searches again for the host bridge node and calls of_irq_map_raw() with >> the device node of the host bridge. The function finds the >> #interrupt-cells, #address-cells, interrupt-controller properties, but >> fails to find the interrupt-map property (because it's missing in the >> device tree). Therefore the function then tries to find a new parent, >> which leads to an endless loop (it always selects the PCI2ISA southbridge >> in the device tree). > > That seems likely... there should probably be some loop detection. Actually, it doesn't -- it should stop when it sees the interrupt-controller property in the i8259 node, at which point it'll be trying to use the raw PCI IRQ pin number as an i8259 IRQ. This is Unlikely To Work(tm). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
On Mon, 2007-10-01 at 23:00 +0200, Gerhard Pircher wrote: > Hi, > > I think I found an issue in the OF interrupt parsing code, although I > have to admit that my device tree source doesn't really follow the > specification. > > First some information about my target setup. I didn't specify an > interrupt-map and interrupt-map-mask property in the pci node, because > AFAIK there are three different AmigaOne models with different IRQ > routing. Secondly the AmigaOne is a desktop system with 4 PCI/AGP slots, > thus I can't specify device nodes for all possible devices. By looking at > pci_read_irq_line() in pci_common.c it should be possible for the kernel > to fall back to the interrupt settings in the PCI config space of every > device. That's deprecated and only support for legacy stuff that predates the current device-tree support & old/crappy firmware. You should be able to generate the appropriate interrupt-map from your loader or wrapper to provide the routing for your slots. It should be easy enough to have 3 static arrays in your wrapper and use the right one to "set" the property value. > Unfortunately I couldn't capture the kernel log, because the serial > console is not yet working, so here comes a description of what I think > is going on. > Well, pci_read_irq_line() starts with PCI device 00:00.0 (PCI host bridge) > and invokes of_irq_map_pci() in prom_parse.c. It find the predefined > device node in the device tree. Since of_irq_map_one() can't find an > interrupt property in the device node, it returns to pci_read_irq_line() > and setups the interrupt mapping based on the settings in the PCI config > space. So far so good. > The problem occurs now, if there is no device node defined for another > PCI device. In this case, of_irq_map_pci() checks for an interrupt pin, > searches again for the host bridge node and calls of_irq_map_raw() with > the device node of the host bridge. The function finds the > #interrupt-cells, #address-cells, interrupt-controller properties, but > fails to find the interrupt-map property (because it's missing in the > device tree). Therefore the function then tries to find a new parent, > which leads to an endless loop (it always selects the PCI2ISA southbridge > in the device tree). > > Can somebody confirm my explanation? It would help, if the kernel could > fall back to the PCI settings in this case, too. I'm not sure what you are trying to explain above... It looks like your tree layout is somewhat broken though I think I see how... One option would be to make the PCI specific IRQ parsing stop & fail if the host bridge doesn't provide a map instead of following up an interrupt-parent link (which is I think what you have in there). But I don't like that. Just fixup your maps properly and everything should work just fine. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
Gerhard Pircher wrote: > First some information about my target setup. I didn't specify an > interrupt-map and interrupt-map-mask property in the pci node, because > AFAIK there are three different AmigaOne models with different IRQ > routing. So detect which one you're running on in the bootwrapper, and fix up (or select) the device tree appropriately. > Secondly the AmigaOne is a desktop system with 4 PCI/AGP slots, > thus I can't specify device nodes for all possible devices. By looking at > pci_read_irq_line() in pci_common.c it should be possible for the kernel > to fall back to the interrupt settings in the PCI config space of every > device. Those interrupt settings are purely a communication vector from firmware to OS. Is your firmware putting i8259 interrupt numbers in there, and did you set the default interrupt controller? > The problem occurs now, if there is no device node defined for another > PCI device. In this case, of_irq_map_pci() checks for an interrupt pin, > searches again for the host bridge node and calls of_irq_map_raw() with > the device node of the host bridge. The function finds the > #interrupt-cells, #address-cells, interrupt-controller properties, but > fails to find the interrupt-map property (because it's missing in the > device tree). Therefore the function then tries to find a new parent, > which leads to an endless loop (it always selects the PCI2ISA southbridge > in the device tree). That seems likely... there should probably be some loop detection. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with OF interrupt parsing code
And here comes the device tree source:
/*
* AmigaOne Device Tree Source
*
* Copyright 2007 Gerhard Pircher ([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.
*/
/ {
model = "AmigaOne";
compatible = "eyetech,amigaone","mai-logic,teron";
coherency-off;
#address-cells = <1>;
#size-cells = <1>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
[EMAIL PROTECTED] {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // 33.3 MHz, from U-boot
clock-frequency = <0>; // From U-boot
bus-frequency = <0>;// From U-boot
32-bit;
};
};
memory {
device_type = "memory";
reg = <0 0>;// From U-boot
};
[EMAIL PROTECTED] {
device_type = "pci";
compatible = "mai-logic,articia-s";
bus-frequency = <01fca055>; // 33.3MHz
bus-range = <0 ff>;
ranges = <0100 0 fe00 0 00c0 // PCI
I/O
0200 0 8000 8000 0 7d00 // PCI
memory
0200 0 fd00 fd00 0 0100>; // PCI
alias memory
8259-interrupt-acknowledge = ;
interrupt-parent = <&i8259>;
#interrupt-cells = <1>;
#address-cells = <3>;
#size-cells = <2>;
[EMAIL PROTECTED] {
compatible = "pciclass,0600";
vendor-id = <10cc>;
device-id = <0660>;
revision-id = <0001>;
class-code = <0006>;
subsystem-id = <0>;
subsystem-vendor-id = <0>;
devsel-speed = <0001>;
66mhz-capable;
min-grant = <0>;
max-latency = <0>;
// AGP aperture is unset.
reg = <4210 0 0 0040>;
assigned-addresses = <4210 0 0 0040>;
};
[EMAIL PROTECTED] {
device_type = "isa";
compatible = "pciclass,0601";
vendor-id = <1106>;
device-id = <0686>;
revision-id = <0010>;
class-code = <00060100>;
subsystem-id = <0>;
subsystem-vendor-id = <0>;
devsel-speed = <0001>;
min-grant = <0>;
max-latency = <0>;
/* First 64k for I/O at 0x0 on PCI mapped to 0x0 on
ISA. */
ranges = <0001 0 0100 0 0001>;
interrupt-parent = <&i8259>;
#interrupt-cells = <2>;
#address-cells = <2>;
#size-cells = <1>;
[EMAIL PROTECTED] {
device_type = "dma-controller";
compatible = "pnpPNP,200";
reg = <0001 0020
0001 0080 0010
0001 00c0 0020>;
/* Channel 4 reserverd, cascade mode, 2x32k
transfer/counter
* widths and bus master capability. Is this
really necessary?
*/
/* dma = <4 4 20 20 1>; */
};
i8259: [EMAIL PROTECTED] {
device_type = "interrupt-controller";
compatible = "pnpPNP,000";
interrupt-controller;
reg = <0001 0020 0002
0001 00a0 0002
0001 04d0 0002>;
Re: Powerbook shuts down hard when hot, patch found
On Monday 01 October 2007 10:00:02 Michel Dänzer wrote: > > On Sun, 2007-09-30 at 12:16 +0200, Michael Buesch wrote: > > > > Ah, forgot to say. > > It does not crash immediately when the register is written. It takes about > > two seconds > > to crash. And when the machine is colder to begin with, it takes slightly > > longer to trigger. That _might_ support your overheating theory. > > > > Though, it does not trigger when it's up and running, no matter how hot you > > drive it. > > Maybe the thermal control module prevents it from overheating. Have you > tried unloading it or loading it ASAP on bootup to see if that makes any > difference either way? I'm not sure how that works. Can I unload the framebuffer module? I mean, when I unloaded it, how does the console access the display? Your suggestion might be less trivial to do than it sounds like. :) I currently have compiled the stuff into the kernel image. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problem with OF interrupt parsing code
Hi, I think I found an issue in the OF interrupt parsing code, although I have to admit that my device tree source doesn't really follow the specification. First some information about my target setup. I didn't specify an interrupt-map and interrupt-map-mask property in the pci node, because AFAIK there are three different AmigaOne models with different IRQ routing. Secondly the AmigaOne is a desktop system with 4 PCI/AGP slots, thus I can't specify device nodes for all possible devices. By looking at pci_read_irq_line() in pci_common.c it should be possible for the kernel to fall back to the interrupt settings in the PCI config space of every device. Unfortunately I couldn't capture the kernel log, because the serial console is not yet working, so here comes a description of what I think is going on. Well, pci_read_irq_line() starts with PCI device 00:00.0 (PCI host bridge) and invokes of_irq_map_pci() in prom_parse.c. It find the predefined device node in the device tree. Since of_irq_map_one() can't find an interrupt property in the device node, it returns to pci_read_irq_line() and setups the interrupt mapping based on the settings in the PCI config space. So far so good. The problem occurs now, if there is no device node defined for another PCI device. In this case, of_irq_map_pci() checks for an interrupt pin, searches again for the host bridge node and calls of_irq_map_raw() with the device node of the host bridge. The function finds the #interrupt-cells, #address-cells, interrupt-controller properties, but fails to find the interrupt-map property (because it's missing in the device tree). Therefore the function then tries to find a new parent, which leads to an endless loop (it always selects the PCI2ISA southbridge in the device tree). Can somebody confirm my explanation? It would help, if the kernel could fall back to the PCI settings in this case, too. Thanks! regards, Gerhard -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Get rid of linuxppc-embedded?
On 10/1/07, Mark A. Greer <[EMAIL PROTECTED]> wrote: > With the merging of the powerpc trees I'm not sure there is a clear > reason why we have 2 separate powerpc lists anymore (linuxppc-dev and > linuxppc-embedded). > > linuxppc-embedded is fairly low volume/noise but there is still the occasional > patch posted there that should really be posted to linuxppc-dev. I think > it would be nice to have just one list where all eyes are focused. > > Is it time to get rid of linuxppc-embedded? Ack Ack Ack! I agree 100% g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Implement logging of unhandled signals
Implement exception-trace sysctl + support to print when a process is
killed due to unhandled signals just as i386 and x86_64 does.
Just like on x86, it can be disabled by setting the sysctl variable
debug.exception-trace, and the messages are rate limited to not create
a DoS exposure.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: 2.6.23/arch/powerpc/kernel/traps.c
===
--- 2.6.23.orig/arch/powerpc/kernel/traps.c
+++ 2.6.23/arch/powerpc/kernel/traps.c
@@ -172,11 +172,21 @@ int die(const char *str, struct pt_regs
void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr)
{
siginfo_t info;
+ char fmt32[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %08lx nip %08lx lr %08lx code %x\n";
+ char fmt64[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %016lx nip %016lx lr %016lx code %x\n";
if (!user_mode(regs)) {
if (die("Exception in kernel mode", regs, signr))
return;
- }
+ } else if (show_unhandled_signals &&
+ unhandled_signal(current, signr) &&
+ printk_ratelimit()) {
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, signr,
+ addr, regs->nip, regs->link, code);
+ }
memset(&info, 0, sizeof(info));
info.si_signo = signr;
Index: 2.6.23/arch/powerpc/kernel/signal_64.c
===
--- 2.6.23.orig/arch/powerpc/kernel/signal_64.c
+++ 2.6.23/arch/powerpc/kernel/signal_64.c
@@ -64,6 +64,11 @@ struct rt_sigframe {
char abigap[288];
} __attribute__ ((aligned (16)));
+static char fmt32[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %08lx nip %08lx lr %08lx\n";
+static char fmt64[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %016lx nip %016lx lr %016lx\n";
+
/*
* Set up the sigcontext for the signal frame.
*/
@@ -315,6 +320,11 @@ badframe:
printk("badframe in sys_rt_sigreturn, regs=%p uc=%p
&uc->uc_mcontext=%p\n",
regs, uc, &uc->uc_mcontext);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "rt_sigreturn",
+ uc, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
@@ -398,6 +408,11 @@ badframe:
printk("badframe in setup_rt_frame, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "setup_rt_frame",
+ frame, regs->nip, regs->link);
+
force_sigsegv(signr, current);
return 0;
}
Index: 2.6.23/kernel/sysctl.c
===
--- 2.6.23.orig/kernel/sysctl.c
+++ 2.6.23/kernel/sysctl.c
@@ -1221,7 +1221,7 @@ static ctl_table fs_table[] = {
};
static ctl_table debug_table[] = {
-#ifdef CONFIG_X86
+#if defined(CONFIG_X86) || defined(CONFIG_PPC)
{
.ctl_name = CTL_UNNUMBERED,
.procname = "exception-trace",
Index: 2.6.23/arch/powerpc/kernel/signal_32.c
===
--- 2.6.23.orig/arch/powerpc/kernel/signal_32.c
+++ 2.6.23/arch/powerpc/kernel/signal_32.c
@@ -705,11 +705,13 @@ int handle_rt_signal32(unsigned long sig
{
struct rt_sigframe __user *rt_sf;
struct mcontext __user *frame;
+ void __user *addr;
unsigned long newsp = 0;
/* Set up Signal Frame */
/* Put a Real Time Context onto stack */
rt_sf = get_sigframe(ka, regs, sizeof(*rt_sf));
+ addr = rt_sf;
if (unlikely(rt_sf == NULL))
goto badframe;
@@ -728,6 +730,7 @@ int handle_rt_signal32(unsigned long sig
/* Save user registers on the stack */
frame = &rt_sf->uc.uc_mcontext;
+ addr = frame;
if (vdso32_rt_sigtramp && current->mm->context.vdso_base) {
if (save_user_regs(regs, frame, 0))
goto badframe;
@@ -742,6 +745,7 @@ int handle_rt_signal32(unsigned long sig
/* create a stack frame for the caller of the handler */
newsp = ((unsigned long)rt_sf) - (__SIGNAL_FRAMESIZE + 16);
+ addr = (void __user *)regs->gpr[1];
if (put_user(regs->gpr[1], (u32 __user *)newsp))
goto badframe;
@@ -762,6 +766,12 @@ badframe:
printk("badframe in handle_rt_signal, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+
Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
On Thu, Sep 27, 2007 at 06:34:37PM -0500, Linas Vepstas wrote:
> Good catch. But no ... and I had to study this a bit. Bear with me:
I agree with the analysis which I've now snipped.
> I think the race you describe above is harmless. The first time
> that sym_eh_handler() will run, it will be with SYM_EH_ABORT,
> in it doesn't matter if we lose that, since the device is hosed
> anyway. At some later time, it will run with SYM_EH_DEVICE_RESET
> and then SYM_EH_BUS_RESET and then SYM_EH_HOST_RESET, and we won't
> miss those, since, by now, sym2_io_error_detected() will have run.
>
> So, by my reading, I'd say that init_completion() in
> sym2_io_error_detected() has to stay (although perhaps
> it should be replaced by the INIT_COMPLETION() macro.)
> Removing it will prevent correct operation on the second
> and subsequent errors.
I think the fundamental problem is that completions aren't really
supposed to be used like this. Here's one attempt at using completions
perhaps a little more the way they're supposed to be used, although now
I've written it, I wonder if we shouldn't just use a waitqueue instead.
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c
b/drivers/scsi/sym53c8xx_2/sym_glue.c
index e8a4361..b425b89 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.c
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -602,6 +602,7 @@ static int sym_eh_handler(int op, char *opname, struct
scsi_cmnd *cmd)
struct sym_hcb *np = SYM_SOFTC_PTR(cmd);
struct sym_ucmd *ucmd = SYM_UCMD_PTR(cmd);
struct Scsi_Host *host = cmd->device->host;
+ struct pci_dev *pdev = np->s.device;
SYM_QUEHEAD *qp;
int cmd_queued = 0;
int sts = -1;
@@ -616,9 +617,19 @@ static int sym_eh_handler(int op, char *opname, struct
scsi_cmnd *cmd)
* point in hurrying; take a leisurely wait.
*/
#define WAIT_FOR_PCI_RECOVERY 35
- if (pci_channel_offline(np->s.device)) {
- int finished_reset = wait_for_completion_timeout(
- &np->s.io_reset_wait, WAIT_FOR_PCI_RECOVERY*HZ);
+ if (pci_channel_offline(pdev)) {
+ struct host_data *hostdata = shost_priv(host);
+ int finished_reset = 0;
+ init_completion(&eh_done);
+ spin_lock_irq(host->host_lock);
+ if (!hostdata->io_reset)
+ hostdata->io_reset = &eh_done;
+ if (!pci_channel_offline(pdev))
+ finished_reset = 1;
+ spin_unlock_irq(host->host_lock);
+ if (!finished_reset)
+ finished_reset = wait_for_completion_timeout(
+ hostdata->io_reset, WAIT_FOR_PCI_RECOVERY*HZ);
if (!finished_reset)
return SCSI_FAILED;
}
@@ -1396,7 +1407,6 @@ static struct Scsi_Host * __devinit sym_attach(struct
scsi_host_template *tpnt,
np->maxoffs = dev->chip.offset_max;
np->maxburst= dev->chip.burst_max;
np->myaddr = dev->host_id;
- init_completion(&np->s.io_reset_wait);
/*
* Edit its name.
@@ -1842,15 +1852,12 @@ static void __devexit sym2_remove(struct pci_dev *pdev)
static pci_ers_result_t sym2_io_error_detected(struct pci_dev *pdev,
enum pci_channel_state state)
{
- struct sym_hcb *np = pci_get_drvdata(pdev);
-
/* If slot is permanently frozen, turn everything off */
if (state == pci_channel_io_perm_failure) {
sym2_remove(pdev);
return PCI_ERS_RESULT_DISCONNECT;
}
- init_completion(&np->s.io_reset_wait);
disable_irq(pdev->irq);
pci_disable_device(pdev);
@@ -1912,7 +1919,7 @@ static pci_ers_result_t sym2_io_slot_reset(struct pci_dev
*pdev)
sym_name(np));
if (pci_enable_device(pdev)) {
- printk(KERN_ERR "%s: Unable to enable afer PCI reset\n",
+ printk(KERN_ERR "%s: Unable to enable after PCI reset\n",
sym_name(np));
return PCI_ERS_RESULT_DISCONNECT;
}
@@ -1953,7 +1960,14 @@ static pci_ers_result_t sym2_io_slot_reset(struct
pci_dev *pdev)
static void sym2_io_resume(struct pci_dev *pdev)
{
struct sym_hcb *np = pci_get_drvdata(pdev);
- complete_all(&np->s.io_reset_wait);
+ struct Scsi_Host *shost = np->s.host;
+ struct host_data *hostdata = shost_priv(shost);
+
+ spin_lock_irq(shost->host_lock);
+ if (hostdata->io_reset)
+ complete_all(hostdata->io_reset);
+ hostdata->io_reset = NULL;
+ spin_unlock_irq(shost->host_lock);
}
static void sym2_get_signalling(struct Scsi_Host *shost)
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.h
b/drivers/scsi/sym53c8xx_2/sym_glue.h
index a172cc5..b961f70 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.h
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.h
@@ -180,9 +180,6 @@ stru
[RFC] Get rid of linuxppc-embedded?
With the merging of the powerpc trees I'm not sure there is a clear reason why we have 2 separate powerpc lists anymore (linuxppc-dev and linuxppc-embedded). linuxppc-embedded is fairly low volume/noise but there is still the occasional patch posted there that should really be posted to linuxppc-dev. I think it would be nice to have just one list where all eyes are focused. Is it time to get rid of linuxppc-embedded? Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm: Describe multi-user ram in its own device node.
Kumar Gala wrote: > > On Sep 29, 2007, at 1:49 AM, Vitaly Bordug wrote: >> cpms have dpram, qe has muram. these two are the same stuff in fact. >> Or you are asking about have QE stuff utilize such a binding at the >> same pass? > > I was asking about both these things. As stated in the commit message, QE can use this; it just needs a compatible entry in the data node. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 3/4] Virtex: add xilinx interrupt controller driver
On 10/1/07, Stephen Rothwell <[EMAIL PROTECTED]> wrote: > On Sun, 30 Sep 2007 16:20:43 -0600 Grant Likely <[EMAIL PROTECTED]> wrote: > > > > diff --git a/arch/powerpc/sysdev/xilinx_intc.c > > b/arch/powerpc/sysdev/xilinx_intc.c > > new file mode 100644 > > index 000..69f05cd > > --- /dev/null > > +++ b/arch/powerpc/sysdev/xilinx_intc.c > > @@ -0,0 +1,151 @@ > > +#include > > +#include > > +#include > > +#include > > +#include > > You probably want linux/of_device.h or linux/of.h instead of asm/prom.h Done. Thanks for the comments, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 4/4] Virtex: Add generic Xilinx Virtex board support
On 10/1/07, Stephen Rothwell <[EMAIL PROTECTED]> wrote: > On Sun, 30 Sep 2007 16:20:52 -0600 Grant Likely <[EMAIL PROTECTED]> wrote: > > > > +++ b/arch/powerpc/platforms/40x/virtex.c > > +#include > > /me puts on broken record voice :-) > > linux/of_platform.h, please Done -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 3/4] Virtex: add xilinx interrupt controller driver
On Sun, 30 Sep 2007 16:20:43 -0600 Grant Likely <[EMAIL PROTECTED]> wrote: > > diff --git a/arch/powerpc/sysdev/xilinx_intc.c > b/arch/powerpc/sysdev/xilinx_intc.c > new file mode 100644 > index 000..69f05cd > --- /dev/null > +++ b/arch/powerpc/sysdev/xilinx_intc.c > @@ -0,0 +1,151 @@ > +#include > +#include > +#include > +#include > +#include You probably want linux/of_device.h or linux/of.h instead of asm/prom.h -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpt466ck3tjL.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 4/4] Virtex: Add generic Xilinx Virtex board support
On Sun, 30 Sep 2007 16:20:52 -0600 Grant Likely <[EMAIL PROTECTED]> wrote: > > +++ b/arch/powerpc/platforms/40x/virtex.c > +#include /me puts on broken record voice :-) linux/of_platform.h, please -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpSvAzwzgrdT.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: DLPAR memory add fix
Jan-Bernd Themann wrote: > Hi, > > On Monday 01 October 2007 16:44, Jeff Garzik wrote: >> Jan-Bernd Themann wrote: >>> Due to stability issues in high load situations the HW queue handling >>> has to be changed. The HW queues are now stopped and restarted again instead >>> of destroying and allocating new HW queues. >>> >>> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> >> May I presume this is for 2.6.23? >> >> Jeff > > no, the patch is build against 2.6.24 upstream (new NAPI interface). OK, thanks. Since we typically have two streams, the current bug-fix stream and the for-next-kernel stream, please indicate to which kernel/git tree your patch applies, in the future. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: DLPAR memory add fix
Hi, On Monday 01 October 2007 16:44, Jeff Garzik wrote: > Jan-Bernd Themann wrote: > > Due to stability issues in high load situations the HW queue handling > > has to be changed. The HW queues are now stopped and restarted again instead > > of destroying and allocating new HW queues. > > > > Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> > > May I presume this is for 2.6.23? > > Jeff no, the patch is build against 2.6.24 upstream (new NAPI interface). Regards, Jan-Bernd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: DLPAR memory add fix
Jan-Bernd Themann wrote: > Due to stability issues in high load situations the HW queue handling > has to be changed. The HW queues are now stopped and restarted again instead > of destroying and allocating new HW queues. > > Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> May I presume this is for 2.6.23? Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ehea: DLPAR memory add fix
Due to stability issues in high load situations the HW queue handling
has to be changed. The HW queues are now stopped and restarted again instead
of destroying and allocating new HW queues.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |4 +-
drivers/net/ehea/ehea_main.c | 276 +-
drivers/net/ehea/ehea_phyp.h |1 +
drivers/net/ehea/ehea_qmr.c | 20 ++--
drivers/net/ehea/ehea_qmr.h |4 +-
5 files changed, 259 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index c0cbd94..3022089 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,13 +40,13 @@
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0074"
+#define DRV_VERSION"EHEA_0077"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
#define DLPAR_MEM_ADD 2
#define DLPAR_MEM_REM 4
-#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM)
+#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM | DLPAR_MEM_ADD)
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 62d6c1e..5bc0a15 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -97,6 +97,7 @@ u64 ehea_driver_flags = 0;
struct workqueue_struct *ehea_driver_wq;
struct work_struct ehea_rereg_mr_task;
+struct semaphore dlpar_mem_lock;
static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
const struct of_device_id *id);
@@ -177,16 +178,24 @@ static void ehea_refill_rq1(struct ehea_port_res *pr, int
index, int nr_of_wqes)
struct sk_buff **skb_arr_rq1 = pr->rq1_skba.arr;
struct net_device *dev = pr->port->netdev;
int max_index_mask = pr->rq1_skba.len - 1;
+ int fill_wqes = pr->rq1_skba.os_skbs + nr_of_wqes;
+ int adder = 0;
int i;
- if (!nr_of_wqes)
+ pr->rq1_skba.os_skbs = 0;
+
+ if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))) {
+ pr->rq1_skba.index = index;
+ pr->rq1_skba.os_skbs = fill_wqes;
return;
+ }
- for (i = 0; i < nr_of_wqes; i++) {
+ for (i = 0; i < fill_wqes; i++) {
if (!skb_arr_rq1[index]) {
skb_arr_rq1[index] = netdev_alloc_skb(dev,
EHEA_L_PKT_SIZE);
if (!skb_arr_rq1[index]) {
+ pr->rq1_skba.os_skbs = fill_wqes - i;
ehea_error("%s: no mem for skb/%d wqes filled",
dev->name, i);
break;
@@ -194,9 +203,14 @@ static void ehea_refill_rq1(struct ehea_port_res *pr, int
index, int nr_of_wqes)
}
index--;
index &= max_index_mask;
+ adder++;
}
+
+ if (adder == 0)
+ return;
+
/* Ring doorbell */
- ehea_update_rq1a(pr->qp, i);
+ ehea_update_rq1a(pr->qp, adder);
}
static int ehea_init_fill_rq1(struct ehea_port_res *pr, int nr_rq1a)
@@ -230,16 +244,21 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
struct sk_buff **skb_arr = q_skba->arr;
struct ehea_rwqe *rwqe;
int i, index, max_index_mask, fill_wqes;
+ int adder = 0;
int ret = 0;
fill_wqes = q_skba->os_skbs + num_wqes;
+ q_skba->os_skbs = 0;
- if (!fill_wqes)
+ if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))) {
+ q_skba->os_skbs = fill_wqes;
return ret;
+ }
index = q_skba->index;
max_index_mask = q_skba->len - 1;
for (i = 0; i < fill_wqes; i++) {
+ u64 tmp_addr;
struct sk_buff *skb = netdev_alloc_skb(dev, packet_size);
if (!skb) {
ehea_error("%s: no mem for skb/%d wqes filled",
@@ -251,30 +270,37 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
skb_reserve(skb, NET_IP_ALIGN);
skb_arr[index] = skb;
+ tmp_addr = ehea_map_vaddr(skb->data);
+ if (tmp_addr == -1) {
+ dev_kfree_skb(skb);
+ q_skba->os_skbs = fill_wqes - i;
+ ret = 0;
+ break;
+ }
rwqe = ehea_get_next_rwqe(qp, rq_nr);
rwqe->wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE, wqe_type)
| EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
rwqe->sg_list[0].l_key = pr->recv_mr.lkey;
- rwqe->sg_list[0].vaddr = ehea_map_vaddr(skb->data);
+ rwqe->sg_list[0].vaddr = tmp_addr;
rwqe->sg_list[0].len =
PowerPC: new EMAC driver typo fix
This looks like typo. Please, apply this patch to fix.
diff -ruNp linux-2.6.orig/drivers/net/ibm_newemac/core.c
linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2007-10-01
17:23:35.0 +0400
+++ linux-2.6/drivers/net/ibm_newemac/core.c2007-10-01 17:44:57.0
+0400
@@ -1232,9 +1232,9 @@ static inline int emac_xmit_finish(struc
* instead
*/
if (emac_has_feature(dev, EMAC_FTR_EMAC4))
- out_be32(&p->tmr0, EMAC_TMR0_XMIT);
- else
out_be32(&p->tmr0, EMAC4_TMR0_XMIT);
+ else
+ out_be32(&p->tmr0, EMAC_TMR0_XMIT);
if (unlikely(++dev->tx_cnt == NUM_TX_BUFF)) {
netif_stop_queue(ndev);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PowerPC: Add RGMII support for Sequoia 440EPx
This adds RGMII support to Sequoia DTS and sets correct phy-mode
for EMACs. According to Sequoia datasheet, both ethernet ports
are connected to RGMII interface, while ZMII is used only for MDIO.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts | 14 --
arch/powerpc/platforms/44x/Kconfig |1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff -ruNp linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts
linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts2007-09-29
16:59:29.0 +0400
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-09-29 17:35:55.0
+0400
@@ -241,6 +241,12 @@
reg = ;
};
+ RGMII0: [EMAIL PROTECTED] {
+ device_type = "rgmii-interface";
+ compatible = "ibm,rgmii-440epx", "ibm,rgmii";
+ reg = ;
+ };
+
EMAC0: [EMAIL PROTECTED] {
linux,network-index = <0>;
device_type = "network";
@@ -261,10 +267,12 @@
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
- phy-mode = "rmii";
+ phy-mode = "rgmii";
phy-map = <>;
zmii-device = <&ZMII0>;
zmii-channel = <0>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
};
EMAC1: [EMAIL PROTECTED] {
@@ -287,10 +295,12 @@
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
- phy-mode = "rmii";
+ phy-mode = "rgmii";
phy-map = <>;
zmii-device = <&ZMII0>;
zmii-channel = <1>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
};
};
};
diff -ruNp linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig
linux-2.6/arch/powerpc/platforms/44x/Kconfig
--- linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig 2007-09-29
16:59:31.0 +0400
+++ linux-2.6/arch/powerpc/platforms/44x/Kconfig2007-09-29
17:59:51.0 +0400
@@ -50,6 +50,7 @@ config 440EPX
select PPC_FPU
# Disabled until the new EMAC Driver is merged.
# select IBM_NEW_EMAC_EMAC4
+# select IBM_NEW_EMAC_RGMII
# select IBM_NEW_EMAC_ZMII
config 440GP
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/6] Sysace: Use the established platform bus api
On 10/1/07, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Sun, Sep 30 2007, Grant Likely wrote: > > On 9/30/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote: > > > > + if ((rc = platform_driver_register(&ace_platform_driver)) != 0) > > > > + goto err_plat; > > > > > > rc = platform_driver_register(&ace_platform_driver); > > > if (rc) > > > goto err_plat; > > > > > > please. > > > > Okay, will do. > > > > > > > > > + err_plat: > > > > + unregister_blkdev(ace_major, "xsysace"); > > > > + err_blk: > > > > > > labels should be indented zero or one space, but not more. > > > > scripts/Lindent does this. Originally, I *didn't* have my labels > > indented. :-) Does Lindent need to be fixed? > > Seems so, if it idents labels. > > Just send a fixup patch for that, I'll add your series to the block tree > for 2.6.24. Cool, thanks Jens. I'll generate a patch to unindent the labels this afternoon. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/6] Sysace: Use the established platform bus api
On Sun, Sep 30 2007, Grant Likely wrote: > On 9/30/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote: > > > + if ((rc = platform_driver_register(&ace_platform_driver)) != 0) > > > + goto err_plat; > > > > rc = platform_driver_register(&ace_platform_driver); > > if (rc) > > goto err_plat; > > > > please. > > Okay, will do. > > > > > > + err_plat: > > > + unregister_blkdev(ace_major, "xsysace"); > > > + err_blk: > > > > labels should be indented zero or one space, but not more. > > scripts/Lindent does this. Originally, I *didn't* have my labels > indented. :-) Does Lindent need to be fixed? Seems so, if it idents labels. Just send a fixup patch for that, I'll add your series to the block tree for 2.6.24. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerbook shuts down hard when hot, patch found
On Sun, 2007-09-30 at 12:16 +0200, Michael Buesch wrote: > > Ah, forgot to say. > It does not crash immediately when the register is written. It takes about > two seconds > to crash. And when the machine is colder to begin with, it takes slightly > longer to trigger. That _might_ support your overheating theory. > > Though, it does not trigger when it's up and running, no matter how hot you > drive it. Maybe the thermal control module prevents it from overheating. Have you tried unloading it or loading it ASAP on bootup to see if that makes any difference either way? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
