Re: [PATCH] powerpc/pseries: Make request_ras_irqs() available to other pseries code
On Wednesday 19 May 2010 16:35:54 Michael Ellerman wrote: > On Wed, 2010-05-19 at 16:35 +1000, Mark Nelson wrote: > > Hi Michael, > > > > Thanks for looking over these patches! > .. > > > > > > Existing code I know, but the error handling in here is a little lax, > > > what's not going to work if we miss some or all of the interrupts? > > > > That's a good point. For the existing code, if we miss an EPOW event > > it just means that the event won't be logged (as that's all we do with > > those events at the moment, although there is a comment saying > > that it should be fixed to take appropriate action depending upon the > > type of power failure); but it's a bigger problem if we miss one of the > > RAS errors because then we could miss a fatal event that we should halt > > the machine on. And for the upcoming IO events it's even worse as we'd > > miss an interrupt from the device... > > Yeah that's what I was thinking. > > > I would do it in a follow-on patch rather than this one, but what would > > be a good course of action if we can't request the interrupt? > > Yes a follow on patch is the way to do it. > > There shouldn't be that many reasons the request fails, other than > ENOMEM, or broken device tree perhaps. It's definitely worth a > WARN_ON(), people notice those at least. That sounds good. I'll do a simple follow-on patch that adds the WARN_ON(). Thanks! Mark ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pseries: Make request_ras_irqs() available to other pseries code
On Wed, 2010-05-19 at 16:35 +1000, Mark Nelson wrote: > Hi Michael, > > Thanks for looking over these patches! .. > > > > Existing code I know, but the error handling in here is a little lax, > > what's not going to work if we miss some or all of the interrupts? > > That's a good point. For the existing code, if we miss an EPOW event > it just means that the event won't be logged (as that's all we do with > those events at the moment, although there is a comment saying > that it should be fixed to take appropriate action depending upon the > type of power failure); but it's a bigger problem if we miss one of the > RAS errors because then we could miss a fatal event that we should halt > the machine on. And for the upcoming IO events it's even worse as we'd > miss an interrupt from the device... Yeah that's what I was thinking. > I would do it in a follow-on patch rather than this one, but what would > be a good course of action if we can't request the interrupt? Yes a follow on patch is the way to do it. There shouldn't be that many reasons the request fails, other than ENOMEM, or broken device tree perhaps. It's definitely worth a WARN_ON(), people notice those at least. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pseries: Make request_ras_irqs() available to other pseries code
Hi Michael,
Thanks for looking over these patches!
On Tuesday 18 May 2010 22:40:51 Michael Ellerman wrote:
> On Mon, 2010-05-17 at 22:33 +1000, Mark Nelson wrote:
> > At the moment only the RAS code uses event-sources interrupts (for EPOW
> > events and internal errors) so request_ras_irqs() (which actually requests
> > the event-sources interrupts) is found in ras.c and is static.
>
> Hi Mark,
>
> Just a few niggles,
>
> ...
>
> > +
> > +void request_event_sources_irqs(struct device_node *np,
> > + irq_handler_t handler,
> > + const char *name)
> > +{
> > + int i, index, count = 0;
> > + struct of_irq oirq;
> > + const u32 *opicprop;
> > + unsigned int opicplen;
> > + unsigned int virqs[16];
> > +
> > + /* Check for obsolete "open-pic-interrupt" property. If present, then
> > +* map those interrupts using the default interrupt host and default
> > +* trigger
> > +*/
> > + opicprop = of_get_property(np, "open-pic-interrupt", &opicplen);
> > + if (opicprop) {
> > + opicplen /= sizeof(u32);
> > + for (i = 0; i < opicplen; i++) {
> > + if (count > 15)
> > + break;
> > + virqs[count] = irq_create_mapping(NULL, *(opicprop++));
> > + if (virqs[count] == NO_IRQ)
> > + printk(KERN_ERR "Unable to allocate interrupt "
> > + "number for %s\n", np->full_name);
> > + else
> > + count++;
> > +
> > + }
> > + }
> > + /* Else use normal interrupt tree parsing */
> > + else {
> > + /* First try to do a proper OF tree parsing */
> > + for (index = 0; of_irq_map_one(np, index, &oirq) == 0;
> > +index++) {
> > + if (count > 15)
> > + break;
> > + virqs[count] = irq_create_of_mapping(oirq.controller,
> > + oirq.specifier,
> > + oirq.size);
> > + if (virqs[count] == NO_IRQ)
> > + printk(KERN_ERR "Unable to allocate interrupt "
> > + "number for %s\n", np->full_name);
> > + else
> > + count++;
> > + }
> > + }
> > +
> > + /* Now request them */
> > + for (i = 0; i < count; i++) {
> > + if (request_irq(virqs[i], handler, 0, name, NULL)) {
> > + printk(KERN_ERR "Unable to request interrupt %d for "
> > + "%s\n", virqs[i], np->full_name);
> > + return;
> > + }
> > + }
>
> Existing code I know, but the error handling in here is a little lax,
> what's not going to work if we miss some or all of the interrupts?
That's a good point. For the existing code, if we miss an EPOW event
it just means that the event won't be logged (as that's all we do with
those events at the moment, although there is a comment saying
that it should be fixed to take appropriate action depending upon the
type of power failure); but it's a bigger problem if we miss one of the
RAS errors because then we could miss a fatal event that we should halt
the machine on. And for the upcoming IO events it's even worse as we'd
miss an interrupt from the device...
I would do it in a follow-on patch rather than this one, but what would
be a good course of action if we can't request the interrupt?
>
> > Index: upstream/arch/powerpc/platforms/pseries/event_sources.h
> > ===
> > --- /dev/null
> > +++ upstream/arch/powerpc/platforms/pseries/event_sources.h
> > @@ -0,0 +1,29 @@
> > +/*
> > + * Copyright (C) 2001 Dave Engebretsen IBM Corporation
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> > + */
> > +
> > +#ifndef _POWERPC_EVENT_SOURCES_H
> > +#define _POWERPC_EVENT_SOURCES_H
> > +
> > +#include
> > +
> > +struct device_node;
> > +
> > +extern void request_event_sources_irqs(struct device_node *np,
> > + irq_handler_t handler, const ch
[PATCH] powerpc/pseries: Add support for IO Event interrupt drivers
On Tue, 18 May 2010 23:37:31 +1000, Michael Ellerman wrote:
>
> On Mon, 2010-05-17 at 22:53 +1000, Mark Nelson wrote:
> > This patch adds support for handling IO Event interrupts which come
> > through at the /event-sources/ibm,io-events device tree node.
>
> Hi Mark,
>
> You'll have to explain to me offline sometime how it is we ran out of
> interrupts and started needing to multiplex them ..
Firmware has decided to multiplex all i/o error reporting through a single
interrupt for reasons unknown, that is the primary reason for this patch.
One question is, we already register a few RAS interrupts which call
RTAS using check-exception for getting error information. Those live
in platforms/pseries/ras.c -- should we combine the two into a common
implementation somehow?
> > There is one ibm,io-events interrupt, but this interrupt might be used
> > for multiple I/O devices, each with their own separate driver. So, we
> > create a platform interrupt handler that will do the RTAS check-exception
> > call and then call the appropriate driver's interrupt handler (the one(s)
> > that registered with a scope that matches the scope of the incoming
> > interrupt).
> >
> > So, a driver for a device that uses IO Event interrupts will register
> > it's interrupt service routine (or interrupt handler) with the platform
> > code using ioei_register_isr(). This register function takes a function
> > pointer to the driver's handler and the scope that the driver is
> > interested in (scopes defined in arch/powerpc/include/asm/io_events.h).
> > The driver's handler must take a pointer to a struct io_events_section
> > and must not return anything.
> >
> > The platform code registers io_event_interrupt() as the interrupt handler
> > for the ibm,io-events interrupt. Upon receiving an IO Event interrupt, it
> > checks the scope of the incoming interrupt and only calls those drivers'
> > handlers that have registered as being interested in that scope.
>
> The "checks the scope" requires an RTAS call, which takes a global lock
> (and you add another) - these aren't going to be used for anything
> performance critical I hope?
Nope it shouldn't be performance critical, but it does raise the point
that the current RTAS implementation in Linux *always* uses the global
lock. There is a set of calls which are not required to be serialized
against each other. This would be a totally different patchset to fix that
problem. The "check-exception" call is one that doesn't require the global
RTAS lock. I might work on that someday :-)
> > + /* check to see if we've already registered this function with
> > +* this scope. If we have, don't register it again
> > +*/
> > + iter = ioei_isr_list;
> > + while (iter) {
> > + if (iter->ioei_isr == isr && iter->scope == scope)
> > + break;
> > + iter = iter->next;
> > + }
> > +
> > + if (iter) {
> > + ret = -EEXIST;
> > + goto out;
> > + }
> > +
> > + cons = kmalloc(sizeof(struct ioei_consumer), GFP_KERNEL);
>
> But you don't want to kmalloc while holding the lock and with interrupts
> off.
Well, he could use GFP_ATOMIC but that's the wrong approach. You should
allocate the buffer (using GFP_KERNEL) before taking the spin lock.
> > +#define EXT_INT_VECTOR_OFFSET 0x500
> > +#define RTAS_TYPE_IO_EVENT 0xE1
These defines should probably go in
I noticed the code in ras.c has it's own define too RAS_VECTOR_OFFSET
for 0x500 and asm/rtas.h actually has RTAS_TYPE_IO for 0xE1
> > +
> > +static irqreturn_t io_event_interrupt(int irq, void *dev_id)
> > +{
> > + struct rtas_error_log *rtas_elog;
> > + struct io_events_section *ioei_sec;
> > + char *ch_ptr;
> > + int status;
> > + u16 *sec_len;
> > +
> > + spin_lock(&ioei_log_buf_lock);
> > +
> > + status = rtas_call(ioei_check_exception_token, 6, 1, NULL,
> > + EXT_INT_VECTOR_OFFSET,
> > + irq_map[irq].hwirq,
>
> This is going to be slow anyway, you may as well use virq_to_hw().
>
> > + RTAS_IO_EVENTS, 1 /*Time Critical */,
>
> Missing space before the T ^
>
> > + __pa(&ioei_log_buf),
>
> Does the buffer need to be aligned, and/or inside the RMO? I'd guess
> yes.
The docs for check-exception don't particularly specify alignment
requirements, but RTAS in generally going to want it in the RMO
Also, if we're going to go ahead and use rtas_call() which locks
it's own buffer which meets the requirements, why do we even need
a separate buffer? Really, we should make this call, then copy
the content of the buffer before handing it over to the drivers.
> > + rtas_get_error_log_max());
Here, we're passing back what RTAS told us what it's max is
which doesn't necessarily equal the static buffer size we
allocated which can cause a buffer overflow. So this
argument should be the static size of the buffer.
> >
Re: [PATCH]460EX on-chip SATA driver < resubmission >
On Thu, May 6, 2010 at 2:57 AM, Rupjyoti Sarmah wrote: > This patch enables the on-chip DWC SATA controller of the AppliedMicro > processor 460EX. The controller seems to be a thrid party IP (from Synopsys) in your SoC and there are many chances the IP will appear in some other SOCs too. This implementation doesn't seem to take care of that scenario. So, please either call the driver something like sata_460ex.c or, better still, segregate the driver in two parts - SoC specific stuff and DWC IP core driver that can be reused by other SoCs having the same IP in future. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "event-scan failed" logflood
On Tue, 2010-05-18 at 16:30 +, nello martuscielli wrote:
> Michael Ellerman ellerman.id.au> writes:
>
> _omissis__
> > >
> > > hi, is there available that patch?
> > > With the fresh new 2.6.34 the logflood problem is still present.
> >
> > You could try this, completely untested:
> >
> > diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
> > index 4190eae..fd68bed 100644
> > --- a/arch/powerpc/kernel/rtasd.c
> > +++ b/arch/powerpc/kernel/rtasd.c
> > @@ -490,6 +490,12 @@ static int __init rtas_init(void)
> > return -ENODEV;
> > }
> >
> > + if (!rtas_event_scan_rate) {
> > + /* Broken firmware: take a rate of zero to mean don't scan
> > */
> > + printk(KERN_DEBUG "rtasd: scan rate is 0, not scanning\n");
> > + return 0;
> > + }
> > +
> > /* Make room for the sequence number */
> > rtas_error_log_max = rtas_get_error_log_max();
> > rtas_error_log_buffer_max = rtas_error_log_max + sizeof(int);
> >
>
>
> hi Michael, thanks for pointing me to that patch, now my Pegasos2 G4 seems to
> work fine.
Great. Can I add Tested-by you?
> Anyway i got these dumps caused by mv643xx_eth:
>
>
> [...]
> sysfs: cannot create duplicate filename '/class/mdio_bus/0'
> [ cut here ]
> Badness at fs/sysfs/dir.c:451
> NIP: c00efc70 LR: c00efc70 CTR:
> REGS: ef117c70 TRAP: 0700 Not tainted (2.6.34)
> MSR: 00029032 CR: 22002488 XER:
> TASK = ef110630[80] 'modprobe' THREAD: ef116000
> GPR00: c00efc70 ef117d20 ef110630 0042 c0009480 00134ac8
> GPR08: 22002482 1002 10023ab8
> GPR16: 107db0b0 107db088 10005558 0003 107db324 107db008
> GPR24: 10005558 a9ce fffe ef117d48 ef0a4300 efb87000 ffef
> NIP [c00efc70] sysfs_add_one+0x88/0xb8
> LR [c00efc70] sysfs_add_one+0x88/0xb8
> Call Trace:
> [ef117d20] [c00efc70] sysfs_add_one+0x88/0xb8 (unreliable)
> [ef117d40] [c00f0d9c] sysfs_do_create_link+0x104/0x1ac
> [ef117d70] [c026b238] device_add+0x1c8/0x534
> [ef117db0] [c02b2e40] mdiobus_register+0xb4/0x1d8
> [ef117de0] [f222c510] mv643xx_eth_shared_probe+0x14c/0x420 [mv643xx_eth]
Can't really help with that, looks like it's trying to register the same
mdio bus twice?
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)
On Tue, 2010-05-18 at 15:22 -0700, Darren Hart wrote: > On 05/18/2010 02:52 PM, Brian King wrote: > > Is IRQF_NODELAY something specific to the RT kernel? I don't see it in > > mainline... > > Yes, it basically says "don't make this handler threaded". That is a good fix for EHEA, but the threaded handling is still broken for anything else that is edge triggered isn't it? The result of the discussion about two years ago on this was that we needed a custom flow handler for XICS on RT. Apart from the issue of loosing interrupts there is also the fact that masking on the XICS requires an RTAS call which takes a global lock. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)
On 05/18/2010 02:52 PM, Brian King wrote:
Is IRQF_NODELAY something specific to the RT kernel? I don't see it in
mainline...
Yes, it basically says "don't make this handler threaded".
--
Darren
-Brian
On 05/18/2010 04:33 PM, dvh...@linux.vnet.ibm.com wrote:
> From ad81664794e33d785f533c5edee37aaba20dd92d Mon Sep 17 00:00:00 2001
From: Darren Hart
Date: Tue, 18 May 2010 11:07:13 -0700
Subject: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)
The underlying hardware is edge triggered but presented by XICS as level
triggered. The edge triggered interrupts are not reissued after masking. This
is not a problem in mainline which does not mask the interrupt (relying on the
EOI mechanism instead). The threaded interrupts in PREEMPT_RT do mask the
interrupt, and can lose interrupts that occurred while masked, resulting in a
hung ethernet interface.
The receive handler simply calls napi_schedule(), as such, there is no
significant additional overhead in making this non-threaded, since we either
wakeup the threaded irq handler to call napi_schedule(), or just call
napi_schedule() directly to wakeup the softirqs. As the receive handler is
lockless, there is no need to convert any of the ehea spinlock_t's to
atomic_spinlock_t's.
Without this patch, a simple scp file copy loop would fail quickly (usually
seconds). We have over two hours of sustained scp activity with the patch
applied.
Credit goes to Will Schmidt for lots of instrumentation and tracing which
clarified the scenario and to Thomas Gleixner for the incredibly simple
solution.
Signed-off-by: Darren Hart
Acked-by: Will Schmidt
Cc: Thomas Gleixner
Cc: Jan-Bernd Themann
Cc: Nivedita Singhvi
Cc: Brian King
Cc: Michael Ellerman
Cc: Doug Maxey
---
drivers/net/ehea/ehea_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 977c3d3..2c53df2 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1263,7 +1263,7 @@ static int ehea_reg_interrupts(struct net_device *dev)
"%s-queue%d", dev->name, i);
ret = ibmebus_request_irq(pr->eq->attr.ist1,
ehea_recv_irq_handler,
- IRQF_DISABLED, pr->int_send_name,
+ IRQF_DISABLED | IRQF_NODELAY,
pr->int_send_name,
pr);
if (ret) {
ehea_error("failed registering irq for ehea_queue "
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)
Brian King wrote: Is IRQF_NODELAY something specific to the RT kernel? I don't see it in mainline... Yep, this is RT only. thanks, Nivedita ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch] ppc: Fix gamecube build
On Fri, May 14, 2010 at 12:25:19AM +0900, Simon Horman wrote: > This fixes the kexec-build on ppc32 when > the --game-cube option is supplied to ./configure. > It seems to have bit-rotted a little. > > Cc: Sebastian Andrzej Siewior > Cc: Maxim Uvarov > Signed-off-by: Simon Horman I have gone ahead and applied this change. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] kexec-tools, ppc64: Fix segfault parsing DR memory property
On Tue, May 18, 2010 at 09:30:32AM +1000, Michael Neuling wrote: > > > In message <4becbe89.3020...@ozlabs.org> you wrote: > > add_dyn_reconf_usable_mem_property() iterates over memory spans > > in /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory and intersects > > these with usablemem_rgns ranges. In doing so it used an unchecked > > fixed-size array which will overrun on machines with lots of LMBs. > > > > This patch removes the fixed-sized arrays from > > add_dyn_reconf_usable_mem_property() and add_usable_mem_property(), in lieu > > o > f > > malloc/realloc/free. > > > > Signed-off-by: Matt Evans > > So this works our large P7 machine unlike the last one. > > Acked-by: Michael Neuling Thanks, applied ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)
Is IRQF_NODELAY something specific to the RT kernel? I don't see it in
mainline...
-Brian
On 05/18/2010 04:33 PM, dvh...@linux.vnet.ibm.com wrote:
>>From ad81664794e33d785f533c5edee37aaba20dd92d Mon Sep 17 00:00:00 2001
> From: Darren Hart
> Date: Tue, 18 May 2010 11:07:13 -0700
> Subject: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)
>
> The underlying hardware is edge triggered but presented by XICS as level
> triggered. The edge triggered interrupts are not reissued after masking. This
> is not a problem in mainline which does not mask the interrupt (relying on the
> EOI mechanism instead). The threaded interrupts in PREEMPT_RT do mask the
> interrupt, and can lose interrupts that occurred while masked, resulting in a
> hung ethernet interface.
>
> The receive handler simply calls napi_schedule(), as such, there is no
> significant additional overhead in making this non-threaded, since we either
> wakeup the threaded irq handler to call napi_schedule(), or just call
> napi_schedule() directly to wakeup the softirqs. As the receive handler is
> lockless, there is no need to convert any of the ehea spinlock_t's to
> atomic_spinlock_t's.
>
> Without this patch, a simple scp file copy loop would fail quickly (usually
> seconds). We have over two hours of sustained scp activity with the patch
> applied.
>
> Credit goes to Will Schmidt for lots of instrumentation and tracing which
> clarified the scenario and to Thomas Gleixner for the incredibly simple
> solution.
>
> Signed-off-by: Darren Hart
> Acked-by: Will Schmidt
> Cc: Thomas Gleixner
> Cc: Jan-Bernd Themann
> Cc: Nivedita Singhvi
> Cc: Brian King
> Cc: Michael Ellerman
> Cc: Doug Maxey
> ---
> drivers/net/ehea/ehea_main.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index 977c3d3..2c53df2 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -1263,7 +1263,7 @@ static int ehea_reg_interrupts(struct net_device *dev)
>"%s-queue%d", dev->name, i);
> ret = ibmebus_request_irq(pr->eq->attr.ist1,
> ehea_recv_irq_handler,
> - IRQF_DISABLED, pr->int_send_name,
> + IRQF_DISABLED | IRQF_NODELAY,
> pr->int_send_name,
> pr);
> if (ret) {
> ehea_error("failed registering irq for ehea_queue "
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PATA/legacy IDE subsystem on PowerMac
On Tue, 2010-05-18 at 21:16 +0200, JJDaNiMoTh wrote:
> Hello,
>
> I hope I've posted to the right list.
> I'm the maintainer of the linux kernel in ArchlinuxPPC [1].
>
> We actually set statically the support for the PowerMac on-board IDE support
> (under ATA/ATAPI/MFM/RLL support (DEPRECATED) ), and the disk is recognized
> correctly (hda*).
> If we try to remove this legacy support, enabling Serial ATA and Parallel ATA
> drivers --> Apple PowerMac/PowerBook internal 'MacIO' IDE (NEW) statically,
> the kernel doesn't recognize the partition on the HD. We tried different
> powerbook, and the result is the same.
>
> Because we haven't log, I take two photos [2] [3].
>
> With legacy stuff, I used hda6 as root device: with PATA, neither hda{5,6,7}
> or
> sda{5,6,7} work.
> As you can see from the photos, seems that the hd isn't attached to any
> device
> under /dev.
> With request I could upload somewhere the configs (working and not working)
> used, but they differ only for the things above.
Nothing obvious... the disk seem to be detected properly. Do you have
the support for mac partitions and the SCSI disk driver (BLK_DEV_SD)
enabled ?
Cheers,
Ben.
> Please let me in the right direction.
> Many thanks to all.
>
>
> [1] http://www.archlinuxppc.org
> [2] http://img268.imageshack.us/img268/5787/dsc04701x.jpg
> [3] http://img204.imageshack.us/img204/6476/dsc04701v.jpg
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PATA/legacy IDE subsystem on PowerMac
Hello,
I hope I've posted to the right list.
I'm the maintainer of the linux kernel in ArchlinuxPPC [1].
We actually set statically the support for the PowerMac on-board IDE support
(under ATA/ATAPI/MFM/RLL support (DEPRECATED) ), and the disk is recognized
correctly (hda*).
If we try to remove this legacy support, enabling Serial ATA and Parallel ATA
drivers --> Apple PowerMac/PowerBook internal 'MacIO' IDE (NEW) statically,
the kernel doesn't recognize the partition on the HD. We tried different
powerbook, and the result is the same.
Because we haven't log, I take two photos [2] [3].
With legacy stuff, I used hda6 as root device: with PATA, neither hda{5,6,7} or
sda{5,6,7} work.
As you can see from the photos, seems that the hd isn't attached to any device
under /dev.
With request I could upload somewhere the configs (working and not working)
used, but they differ only for the things above.
Please let me in the right direction.
Many thanks to all.
[1] http://www.archlinuxppc.org
[2] http://img268.imageshack.us/img268/5787/dsc04701x.jpg
[3] http://img204.imageshack.us/img204/6476/dsc04701v.jpg
signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix string library functions
The powerpc strncmp implementation does not correctly handle a zero length, despite the claim in 0119536cd314ef95553604208c25bc35581f7f0a (Add hand-coded assembly strcmp). Additionally, all the length arguments are size_t, not int, so use PPC_LCMPI and eq instead of cmpwi and le throughout. Signed-off-by: Andreas Schwab --- arch/powerpc/lib/string.S | 18 ++ 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/lib/string.S b/arch/powerpc/lib/string.S index 64e2e49..455881a 100644 --- a/arch/powerpc/lib/string.S +++ b/arch/powerpc/lib/string.S @@ -28,7 +28,7 @@ _GLOBAL(strcpy) /* This clears out any unused part of the destination buffer, just as the libc version does. -- paulus */ _GLOBAL(strncpy) - cmpwi 0,r5,0 + PPC_LCMPI 0,r5,0 beqlr mtctr r5 addir6,r3,-1 @@ -39,7 +39,7 @@ _GLOBAL(strncpy) bdnzf 2,1b/* dec ctr, branch if ctr != 0 && !cr0.eq */ bnelr /* if we didn't hit a null char, we're done */ mfctr r5 - cmpwi 0,r5,0 /* any space left in destination buffer? */ + PPC_LCMPI 0,r5,0/* any space left in destination buffer? */ beqlr /* we know r0 == 0 here */ 2: stbur0,1(r6)/* clear it out if so */ bdnz2b @@ -70,8 +70,8 @@ _GLOBAL(strcmp) blr _GLOBAL(strncmp) - PPC_LCMPI r5,0 - beqlr + PPC_LCMPI 0,r5,0 + beq-2f mtctr r5 addir5,r3,-1 addir4,r4,-1 @@ -82,6 +82,8 @@ _GLOBAL(strncmp) beqlr 1 bdnzt eq,1b blr +2: li r3,0 + blr _GLOBAL(strlen) addir4,r3,-1 @@ -92,8 +94,8 @@ _GLOBAL(strlen) blr _GLOBAL(memcmp) - cmpwi 0,r5,0 - ble-2f + PPC_LCMPI 0,r5,0 + beq-2f mtctr r5 addir6,r3,-1 addir4,r4,-1 @@ -106,8 +108,8 @@ _GLOBAL(memcmp) blr _GLOBAL(memchr) - cmpwi 0,r5,0 - ble-2f + PPC_LCMPI 0,r5,0 + beq-2f mtctr r5 addir3,r3,-1 1: lbzur0,1(r3) -- 1.7.1 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: remove all rcu head initializations
Hello!
Would you guys like to carry this patch, or should I push it up
-tip? If I don't hear otherwise from you, I will push it up -tip.
The INIT_RCU_HEAD() primitive is going away in favor of debugobjects.
Thanx, Paul
powerpc: remove all rcu head initializations
Remove all rcu head inits. We don't care about the RCU head state before
passing it to call_rcu() anyway. Only leave the "on_stack" variants so
debugobjects can keep track of objects on stack.
Signed-off-by: Mathieu Desnoyers
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Paul E. McKenney
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index ebc2f38..2c7e801 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -92,7 +92,6 @@ static void pte_free_rcu_callback(struct rcu_head *head)
static void pte_free_submit(struct pte_freelist_batch *batch)
{
- INIT_RCU_HEAD(&batch->rcu);
call_rcu(&batch->rcu, pte_free_rcu_callback);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "event-scan failed" logflood
Michael Ellerman ellerman.id.au> writes:
_omissis__
> >
> > hi, is there available that patch?
> > With the fresh new 2.6.34 the logflood problem is still present.
>
> You could try this, completely untested:
>
> diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
> index 4190eae..fd68bed 100644
> --- a/arch/powerpc/kernel/rtasd.c
> +++ b/arch/powerpc/kernel/rtasd.c
> @@ -490,6 +490,12 @@ static int __init rtas_init(void)
> return -ENODEV;
> }
>
> + if (!rtas_event_scan_rate) {
> + /* Broken firmware: take a rate of zero to mean don't scan */
> + printk(KERN_DEBUG "rtasd: scan rate is 0, not scanning\n");
> + return 0;
> + }
> +
> /* Make room for the sequence number */
> rtas_error_log_max = rtas_get_error_log_max();
> rtas_error_log_buffer_max = rtas_error_log_max + sizeof(int);
>
hi Michael, thanks for pointing me to that patch, now my Pegasos2 G4 seems to
work fine.
Anyway i got these dumps caused by mv643xx_eth:
[...]
sysfs: cannot create duplicate filename '/class/mdio_bus/0'
[ cut here ]
Badness at fs/sysfs/dir.c:451
NIP: c00efc70 LR: c00efc70 CTR:
REGS: ef117c70 TRAP: 0700 Not tainted (2.6.34)
MSR: 00029032 CR: 22002488 XER:
TASK = ef110630[80] 'modprobe' THREAD: ef116000
GPR00: c00efc70 ef117d20 ef110630 0042 c0009480 00134ac8
GPR08: 22002482 1002 10023ab8
GPR16: 107db0b0 107db088 10005558 0003 107db324 107db008
GPR24: 10005558 a9ce fffe ef117d48 ef0a4300 efb87000 ffef
NIP [c00efc70] sysfs_add_one+0x88/0xb8
LR [c00efc70] sysfs_add_one+0x88/0xb8
Call Trace:
[ef117d20] [c00efc70] sysfs_add_one+0x88/0xb8 (unreliable)
[ef117d40] [c00f0d9c] sysfs_do_create_link+0x104/0x1ac
[ef117d70] [c026b238] device_add+0x1c8/0x534
[ef117db0] [c02b2e40] mdiobus_register+0xb4/0x1d8
[ef117de0] [f222c510] mv643xx_eth_shared_probe+0x14c/0x420 [mv643xx_eth]
[ef117e00] [c026f4b4] platform_drv_probe+0x20/0x30
[ef117e10] [c026e044] driver_probe_device+0xdc/0x194
[ef117e30] [c026e174] __driver_attach+0x78/0xb4
[ef117e50] [c026d610] bus_for_each_dev+0x68/0xc0
[ef117e80] [c026de3c] driver_attach+0x24/0x34
[ef117e90] [c026cdbc] bus_add_driver+0xc8/0x278
[ef117eb0] [c026e59c] driver_register+0xd0/0x188
[ef117ed0] [c026f82c] platform_driver_register+0x6c/0x7c
[ef117ee0] [f223602c] mv643xx_eth_init_module+0x2c/0x90 [mv643xx_eth]
[ef117f00] [c0003eec] do_one_initcall+0x70/0x20c
[ef117f20] [c005ccb4] sys_init_module+0xf4/0x248
[ef117f40] [c0015b20] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff654b8
LR = 0x10002e7c
Instruction dump:
807c 7fc4f378 4b3d 3c80c043 38843afa 4bf2bb8d 809d0010 4bf2bb85
7c641b78 3c60c043 38633ac7 482c7d91 <0fe0> 7fc3f378 4bfa4f75 80010024
mii_bus 0 failed to register
mv643xx_eth: probe of mv643xx_eth.0 failed with error -12
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xf222f26c
usbcore: registered new interface driver hiddev
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT CHRP
last sysfs file: /sys/devices/virtual/tty/ptyv3/uevent
Modules linked in: snd_mpu401_uart usbhid(+) snd_rawmidi mv643xx_eth(+) firewire
_core via_rhine i2c_viapro
NIP: f222f26c LR: f222f264 CTR: c026daf0
REGS: ef117d10 TRAP: 0300 Tainted: GW (2.6.34)
MSR: 9032 CR: 84002488 XER: 2000
DAR: , DSISR: 4000
TASK = ef110630[80] 'modprobe' THREAD: ef116000
GPR00: f222f258 ef117dc0 ef110630 efa9e320 efa9e005 efa9e155
GPR08: 0400 ef856cc0 efa9e314 0001 10023ab8
GPR16: 107db0b0 107db088 10005558 0003 107db324 107db008
GPR24: 10005558 c04ca290 a9ce c04ca288 c04ca138 fff4 efa9e000 efa9e320
NIP [f222f26c] mv643xx_eth_probe+0xd8/0x690 [mv643xx_eth]
LR [f222f264] mv643xx_eth_probe+0xd0/0x690 [mv643xx_eth]
Call Trace:
[ef117dc0] [f222f258] mv643xx_eth_probe+0xc4/0x690 [mv643xx_eth] (unreliable)
[ef117e00] [c026f4b4] platform_drv_probe+0x20/0x30
[ef117e10] [c026e044] driver_probe_device+0xdc/0x194
[ef117e30] [c026e174] __driver_attach+0x78/0xb4
[ef117e50] [c026d610] bus_for_each_dev+0x68/0xc0
[ef117e80] [c026de3c] driver_attach+0x24/0x34
[ef117e90] [c026cdbc] bus_add_driver+0xc8/0x278
[ef117eb0] [c026e59c] driver_register+0xd0/0x188
[ef117ed0] [c026f82c] platform_driver_register+0x6c/0x7c
[ef117ee0] [f223603c] mv643xx_eth_init_module+0x3c/0x90 [mv643xx_eth]
[ef117f00] [c0003eec] do_one_initcall+0x70/0x20c
[ef117f20] [c005ccb4] sys_init_module+0xf4/0x248
[ef117f40] [c0015b20] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff654b8
LR = 0x10002e7c
Instruction dump:
7c7e1b79 41820544 3bfe0320 3b3b0008 7f23cb78 7fe4fb78 480019e5 807c
38630008 48001dc9 907e0320 817c0004 <8003> 556b502a 396b0400 7d605a14
[...]
cheers,
nello
___
Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
On 05/18/2010 01:36 AM, Richard Cochran wrote: On Mon, May 17, 2010 at 01:05:54PM -0500, Scott Wood wrote: + - tmr_fiper1 Fixed interval period pulse generator. + - tmr_fiper2 Fixed interval period pulse generator. MPC8572 and P2020 have fiper3 as well. I doubt they really have a third fiper. First of all, this signal is not routed anywhere on the boards. OK, but that's a separate issue from whether it exists on the chip and could be used on a different board. Also, according to the documentation, it has no bit in the TMR_CTRL or the TMR_TEMASK registers. It does seem inconsistent -- but could just be bad docs. Unless there is a bit in TMR_TEMASK, you cannot get an interrupt from it. If you cannot use the signal externally (in the "real" world) and you cannot get an interrupt, what good is it to have such a periodic signal? Polling the bit in the TMR_TEVENT to see when a pulse occurs seems pointless. Scott, you have connections, right? Can you clarify this for me? I'll ask around. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux for MVME1604
Hi I need help with instalaton linux on MVME1604 with 16 MB RAM, do You know any linux version for that and does anybody have try to install this on that? Thansk for any help. Raul ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [lm-sensors] [PATCH] hwmon: (tmp421) Add nfactor support (2nd attempt)
On 05/18/2010 07:38 AM, Andre Prendel wrote:
> I'd prefer starting i with 0 and as condition i < data->channels - 1.
>
> for (i = 0; i < data->channels -1; i++) {
> data->nfactor[i] = i2c_smbus_read_byte_data(client,
> TMP421_NFACTOR[i]);
> }
>
> What do you think?
The first channel is the local channel which does not support nfactor,
so we skip it. Having the for loop start at 1 illustrates this concept.
> Indentation of the arguments is wrong (see other functions).
Should be fixed in the patch below.
I am not sure why the patch file itself still shows the function arguments
off by one. When I apply it to a raw tmp421.c all of the arguments
line up correctly.
After rebasing the changes, I am creating the patch as:
$ git format-patch -1 HEAD
Pretty simple stuff...
>From 467c74e1d8118e34e84a150f18b5e55c6593c777 Mon Sep 17 00:00:00 2001
From: Jeff Angielski
Date: Mon, 10 May 2010 10:26:34 -0400
Subject: [PATCH] hwmon: (tmp421) Add nfactor support
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor hanging off of the remote channels.
Signed-off-by: Jeff Angielski
---
drivers/hwmon/tmp421.c | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 738c472..7944627 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -49,6 +49,7 @@ enum chips { tmp421, tmp422, tmp423 };
static const u8 TMP421_TEMP_MSB[4] = { 0x00, 0x01, 0x02, 0x03 };
static const u8 TMP421_TEMP_LSB[4] = { 0x10, 0x11, 0x12, 0x13 };
+static const u8 TMP421_NFACTOR[3] = { 0x21, 0x22, 0x23 };
/* Flags */
#define TMP421_CONFIG_SHUTDOWN 0x40
@@ -76,6 +77,7 @@ struct tmp421_data {
int channels;
u8 config;
s16 temp[4];
+ s8 nfactor[3];
};
static int temp_from_s16(s16 reg)
@@ -115,6 +117,10 @@ static struct tmp421_data *tmp421_update_device(struct
device *dev)
data->temp[i] |= i2c_smbus_read_byte_data(client,
TMP421_TEMP_LSB[i]);
}
+ for (i = 1; i < data->channels; i++) {
+ data->nfactor[i - 1] = i2c_smbus_read_byte_data(client,
+ TMP421_NFACTOR[i - 1]);
+ }
data->last_updated = jiffies;
data->valid = 1;
}
@@ -157,6 +163,32 @@ static ssize_t show_fault(struct device *dev,
return sprintf(buf, "0\n");
}
+static ssize_t show_nfactor(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ int index = to_sensor_dev_attr(devattr)->index;
+ struct tmp421_data *data = tmp421_update_device(dev);
+
+ return sprintf(buf, "%d\n", data->nfactor[index - 1]);
+}
+
+static ssize_t set_nfactor(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)->index;
+ int nfactor = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(&data->update_lock);
+ i2c_smbus_write_byte_data(client, TMP421_NFACTOR[index - 1],
+ SENSORS_LIMIT(nfactor, -128, 127));
+ mutex_unlock(&data->update_lock);
+
+ return count;
+}
+
static mode_t tmp421_is_visible(struct kobject *kobj, struct attribute *a,
int n)
{
@@ -177,19 +209,28 @@ static mode_t tmp421_is_visible(struct kobject *kobj,
struct attribute *a,
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp_value, NULL, 0);
static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp_value, NULL, 1);
static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_fault, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp2_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 1);
static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, show_temp_value, NULL, 2);
static SENSOR_DEVICE_ATTR(temp3_fault, S_IRUGO, show_fault, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp3_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 2);
static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, show_temp_value, NULL, 3);
static SENSOR_DEVICE_ATTR(temp4_fault, S_IRUGO, show_fault, NULL, 3);
+static SENSOR_DEVICE_ATTR(temp4_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
+ show_nfactor, set_nfactor, 3);
static struct attribute *tmp421_attr[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp2_input.dev_attr.attr,
&sensor_dev_attr_temp2_fault.dev_attr.attr,
+ &sensor_dev_attr_temp2_nfactor.dev_attr.attr,
Re: [PATCH] powerpc/pseries: Add support for IO Event interrupt drivers
On Mon, 2010-05-17 at 22:53 +1000, Mark Nelson wrote:
> This patch adds support for handling IO Event interrupts which come
> through at the /event-sources/ibm,io-events device tree node.
Hi Mark,
You'll have to explain to me offline sometime how it is we ran out of
interrupts and started needing to multiplex them ..
> There is one ibm,io-events interrupt, but this interrupt might be used
> for multiple I/O devices, each with their own separate driver. So, we
> create a platform interrupt handler that will do the RTAS check-exception
> call and then call the appropriate driver's interrupt handler (the one(s)
> that registered with a scope that matches the scope of the incoming
> interrupt).
>
> So, a driver for a device that uses IO Event interrupts will register
> it's interrupt service routine (or interrupt handler) with the platform
> code using ioei_register_isr(). This register function takes a function
> pointer to the driver's handler and the scope that the driver is
> interested in (scopes defined in arch/powerpc/include/asm/io_events.h).
> The driver's handler must take a pointer to a struct io_events_section
> and must not return anything.
>
> The platform code registers io_event_interrupt() as the interrupt handler
> for the ibm,io-events interrupt. Upon receiving an IO Event interrupt, it
> checks the scope of the incoming interrupt and only calls those drivers'
> handlers that have registered as being interested in that scope.
The "checks the scope" requires an RTAS call, which takes a global lock
(and you add another) - these aren't going to be used for anything
performance critical I hope?
> It is possible for a single driver to register the same function pointer
> more than once with different scopes if it is interested in more than one
> type of IO Event interrupt. If a handler wants to be notified of all
> incoming IO Event interrupts it can register with IOEI_SCOPE_ANY.
>
> A driver can unregister to stop receiving the IO Event interrupts using
> ioei_unregister_isr(), passing it the same function pointer to the
> driver's handler and the scope the driver was registered with.
>
> Signed-off-by: Mark Nelson
> ---
> arch/powerpc/include/asm/io_events.h | 40 +
> arch/powerpc/platforms/pseries/Makefile|2
> arch/powerpc/platforms/pseries/io_events.c | 205
> +
> 3 files changed, 246 insertions(+), 1 deletion(-)
>
> Index: upstream/arch/powerpc/include/asm/io_events.h
> ===
> --- /dev/null
> +++ upstream/arch/powerpc/include/asm/io_events.h
> @@ -0,0 +1,40 @@
> +/*
> + * Copyright 2010 IBM Corporation, Mark Nelson
I usually have name, corp, but I'm not sure if it matters.
> + * 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.
> + */
> +
> +#ifndef _ASM_POWERPC_IOEVENTS_H
> +#define _ASM_POWERPC_IOEVENTS_H
> +
> +struct io_events_section {
> + u16 id; // Unique section identifierx00-x01
> + u16 length; // Section length (bytes) x02-x03
> + u8 version;// Section Version x04-x04
> + u8 sec_subtype;// Section subtype x05-x05
> + u16 creator_id; // Creator Component ID x06-x07
> + u8 event_type; // IO-Event Typex08-x08
> + u8 rpc_field_len; // PRC Field Length x09-x09
> + u8 scope; // Error/Event Scopex0A-x0A
> + u8 event_subtype; // I/O-Event Sub-Type x0B-x0B
> + u32 drc_index; // DRC Indexx0C-x0F
> + u32 rpc_data[]; // RPC Data (optional) x10-...
> +};
I know it's idiomatic in that sort of code, but C++ comments?
> +#define IOEI_SCOPE_NOT_APP 0x00
> +#define IOEI_SCOPE_RIO_HUB 0x36
> +#define IOEI_SCOPE_RIO_BRIDGE0x37
> +#define IOEI_SCOPE_PHB 0x38
> +#define IOEI_SCOPE_EADS_GLOBAL 0x39
> +#define IOEI_SCOPE_EADS_SLOT 0x3A
> +#define IOEI_SCOPE_TORRENT_HUB 0x3B
> +#define IOEI_SCOPE_SERVICE_PROC 0x51
> +#define IOEI_SCOPE_ANY -1
> +
> +int ioei_register_isr(void (*isr)(struct io_events_section *), int scope);
> +int ioei_unregister_isr(void (*isr)(struct io_events_section *), int scope);
Given these are exported to the whole kernel I'd vote for
pseries_ioei_register_isr(), if I get to vote that is.
> Index: upstream/arch/powerpc/platforms/pseries/io_events.c
> ===
> --- /dev/null
> +++ upstream/arch/powerpc/platforms/pseries/io_events.c
> @@ -0,0 +1,205 @@
> +/*
> + * Copyright
Re: [PATCH] powerpc/pseries: Make request_ras_irqs() available to other pseries code
On Mon, 2010-05-17 at 22:33 +1000, Mark Nelson wrote:
> At the moment only the RAS code uses event-sources interrupts (for EPOW
> events and internal errors) so request_ras_irqs() (which actually requests
> the event-sources interrupts) is found in ras.c and is static.
Hi Mark,
Just a few niggles,
...
> +
> +void request_event_sources_irqs(struct device_node *np,
> + irq_handler_t handler,
> + const char *name)
> +{
> + int i, index, count = 0;
> + struct of_irq oirq;
> + const u32 *opicprop;
> + unsigned int opicplen;
> + unsigned int virqs[16];
> +
> + /* Check for obsolete "open-pic-interrupt" property. If present, then
> + * map those interrupts using the default interrupt host and default
> + * trigger
> + */
> + opicprop = of_get_property(np, "open-pic-interrupt", &opicplen);
> + if (opicprop) {
> + opicplen /= sizeof(u32);
> + for (i = 0; i < opicplen; i++) {
> + if (count > 15)
> + break;
> + virqs[count] = irq_create_mapping(NULL, *(opicprop++));
> + if (virqs[count] == NO_IRQ)
> + printk(KERN_ERR "Unable to allocate interrupt "
> +"number for %s\n", np->full_name);
> + else
> + count++;
> +
> + }
> + }
> + /* Else use normal interrupt tree parsing */
> + else {
> + /* First try to do a proper OF tree parsing */
> + for (index = 0; of_irq_map_one(np, index, &oirq) == 0;
> + index++) {
> + if (count > 15)
> + break;
> + virqs[count] = irq_create_of_mapping(oirq.controller,
> + oirq.specifier,
> + oirq.size);
> + if (virqs[count] == NO_IRQ)
> + printk(KERN_ERR "Unable to allocate interrupt "
> +"number for %s\n", np->full_name);
> + else
> + count++;
> + }
> + }
> +
> + /* Now request them */
> + for (i = 0; i < count; i++) {
> + if (request_irq(virqs[i], handler, 0, name, NULL)) {
> + printk(KERN_ERR "Unable to request interrupt %d for "
> +"%s\n", virqs[i], np->full_name);
> + return;
> + }
> + }
Existing code I know, but the error handling in here is a little lax,
what's not going to work if we miss some or all of the interrupts?
> Index: upstream/arch/powerpc/platforms/pseries/event_sources.h
> ===
> --- /dev/null
> +++ upstream/arch/powerpc/platforms/pseries/event_sources.h
> @@ -0,0 +1,29 @@
> +/*
> + * Copyright (C) 2001 Dave Engebretsen IBM Corporation
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#ifndef _POWERPC_EVENT_SOURCES_H
> +#define _POWERPC_EVENT_SOURCES_H
> +
> +#include
> +
> +struct device_node;
> +
> +extern void request_event_sources_irqs(struct device_node *np,
> +irq_handler_t handler, const char *name);
This could just go in platforms/pseries/pseries.h
> Index: upstream/arch/powerpc/platforms/pseries/ras.c
> ===
> --- upstream.orig/arch/powerpc/platforms/pseries/ras.c
> +++ upstream/arch/powerpc/platforms/pseries/ras.c
> @@ -50,6 +50,7 @@
> #include
>
> #include "pseries.h"
> +#include "event_sources.h"
:)
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "event-scan failed" logflood
On Mon, 2010-05-17 at 12:58 +, nello martuscielli wrote:
> Benjamin Herrenschmidt kernel.crashing.org> writes:
>
> _omissis__
> >
> > Ok, that gives us a good thing to use to not do the scanning then. If
> > that's 0 then we assume it's a bogus OF and we disable the scan
> > completely. I'll do a patch later today, though feel free to beat me to
> > it.
> >
> > Cheers,
> > Ben.
> >
>
> hi, is there available that patch?
> With the fresh new 2.6.34 the logflood problem is still present.
You could try this, completely untested:
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index 4190eae..fd68bed 100644
--- a/arch/powerpc/kernel/rtasd.c
+++ b/arch/powerpc/kernel/rtasd.c
@@ -490,6 +490,12 @@ static int __init rtas_init(void)
return -ENODEV;
}
+ if (!rtas_event_scan_rate) {
+ /* Broken firmware: take a rate of zero to mean don't scan */
+ printk(KERN_DEBUG "rtasd: scan rate is 0, not scanning\n");
+ return 0;
+ }
+
/* Make room for the sequence number */
rtas_error_log_max = rtas_get_error_log_max();
rtas_error_log_buffer_max = rtas_error_log_max + sizeof(int);
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [lm-sensors] [PATCH] hwmon: (tmp421) Add nfactor support (2nd attempt)
On Mon, May 17, 2010 at 04:30:24PM -0400, Jeff Angielski wrote:
>
> Here is a second attempt at a patch to add nfactor support to the tmp421
> driver.
Hi Jeff,
only a few minor issues, see below.
> This includes the changes as suggested by Andre Prendel, the original driver
> author.
>
>
> >From 8ebe84174ff6bd294656d77183758044f19d8900 Mon Sep 17 00:00:00 2001
> From: Jeff Angielski
> Date: Mon, 10 May 2010 10:26:34 -0400
> Subject: [PATCH] hwmon: (tmp421) Add nfactor support
>
> Add support for reading and writing the n-factor correction
> registers. This is needed to compensate for the characteristics
> of a particular sensor hanging off of the remote channels.
>
> Signed-off-by: Jeff Angielski
> ---
> drivers/hwmon/tmp421.c | 41 +
> 1 files changed, 41 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
> index 738c472..ce1f6d1 100644
> --- a/drivers/hwmon/tmp421.c
> +++ b/drivers/hwmon/tmp421.c
> @@ -49,6 +49,7 @@ enum chips { tmp421, tmp422, tmp423 };
>
> static const u8 TMP421_TEMP_MSB[4] = { 0x00, 0x01, 0x02, 0x03 };
> static const u8 TMP421_TEMP_LSB[4] = { 0x10, 0x11, 0x12, 0x13 };
> +static const u8 TMP421_NFACTOR[3]= { 0x21, 0x22, 0x23 };
>
> /* Flags */
> #define TMP421_CONFIG_SHUTDOWN 0x40
> @@ -76,6 +77,7 @@ struct tmp421_data {
> int channels;
> u8 config;
> s16 temp[4];
> + s8 nfactor[3];
> };
>
> static int temp_from_s16(s16 reg)
> @@ -115,6 +117,10 @@ static struct tmp421_data *tmp421_update_device(struct
> device *dev)
> data->temp[i] |= i2c_smbus_read_byte_data(client,
> TMP421_TEMP_LSB[i]);
> }
> + for (i = 1; i < data->channels; i++) {
> + data->nfactor[i - 1] = i2c_smbus_read_byte_data(client,
> + TMP421_NFACTOR[i - 1]);
> + }
I'd prefer starting i with 0 and as condition i < data->channels - 1.
for (i = 0; i < data->channels -1; i++) {
data->nfactor[i] = i2c_smbus_read_byte_data(client,
TMP421_NFACTOR[i]);
}
What do you think?
> data->last_updated = jiffies;
> data->valid = 1;
> }
> @@ -157,6 +163,32 @@ static ssize_t show_fault(struct device *dev,
> return sprintf(buf, "0\n");
> }
>
> +static ssize_t show_nfactor(struct device *dev,
> + struct device_attribute *devattr, char *buf)
Indentation of the arguments is wrong (see other functions).
> +{
> + int index = to_sensor_dev_attr(devattr)->index;
> + struct tmp421_data *data = tmp421_update_device(dev);
> +
> + return sprintf(buf, "%d\n", data->nfactor[index - 1]);
> +}
> +
> +static ssize_t set_nfactor(struct device *dev,
> + struct device_attribute *devattr,
> + const char *buf, size_t count)
ditto
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct tmp421_data *data = i2c_get_clientdata(client);
> + int index = to_sensor_dev_attr(devattr)->index;
> + int nfactor = simple_strtol(buf, NULL, 10);
> +
> + mutex_lock(&data->update_lock);
> + i2c_smbus_write_byte_data(client, TMP421_NFACTOR[index - 1],
> + SENSORS_LIMIT(nfactor, -128, 127));
ditto
> + mutex_unlock(&data->update_lock);
> +
> + return count;
> +}
> +
> static mode_t tmp421_is_visible(struct kobject *kobj, struct attribute *a,
> int n)
> {
> @@ -177,19 +209,28 @@ static mode_t tmp421_is_visible(struct kobject *kobj,
> struct attribute *a,
> static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp_value, NULL, 0);
> static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp_value, NULL, 1);
> static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_fault, NULL, 1);
> +static SENSOR_DEVICE_ATTR(temp2_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
> + show_nfactor, set_nfactor, 1);
> static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, show_temp_value, NULL, 2);
> static SENSOR_DEVICE_ATTR(temp3_fault, S_IRUGO, show_fault, NULL, 2);
> +static SENSOR_DEVICE_ATTR(temp3_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
> + show_nfactor, set_nfactor, 2);
> static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, show_temp_value, NULL, 3);
> static SENSOR_DEVICE_ATTR(temp4_fault, S_IRUGO, show_fault, NULL, 3);
> +static SENSOR_DEVICE_ATTR(temp4_nfactor, S_IRUSR | S_IWUSR | S_IRGRP,
> + show_nfactor, set_nfactor, 3);
And again three times.
>
> static struct attribute *tmp421_attr[] = {
> &sensor_dev_attr_temp1_input.dev_attr.attr,
> &sensor_dev_attr_temp2_input.dev_attr.attr,
> &sensor_dev_attr_temp2_fault.dev_attr.attr,
> + &sensor_dev_attr_temp2_nfactor.dev_attr.attr,
> &sensor_dev_attr_temp3_input.dev_attr.attr,
> &sensor_dev_attr_temp3_fault.dev_attr.attr,
> + &sensor_
[PATCH 0/1] RapidIO: Fix maintenance access to higher memory areas
The following RapidIO patch is applicable to the latest kernel tree with applied RapidIO patches from Alexandre Bounine. The modification is required for IDT CPS switch devices which will access these memory areas, to setup 16bit routing. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] RapidIO: Fix maintenance access to higher memory areas
Fix the maintenance access functions to farend RapidIO devices.
1. Fixed shift of the given offset, to open the maintenance window
2. Mask offset to limit access to the opened maintenance window
3. Added extended destid part to rowtear register, required for 16bit mode
This method is matching maintenance transactions generation described
by Freescale in the appnote AN2932. With this modification full access
to a 16MB maintenance window is possible, this patch is required for
IDT cps switches. For easier handling of the access routines, the
access was limited to aligned memory regions. This should be no problem
because all registers are 32bit wide.
The patch was generated against 2.6.34 kernel + patches from
Alexandre Bounine
Signed-off-by: Thomas Moll
Tested-by: Alexandre Bounine
---
fsl_rio.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff -purN linux-base/arch/powerpc/sysdev/fsl_rio.c
linux-new/arch/powerpc/sysdev/fsl_rio.c
--- linux-base/arch/powerpc/sysdev/fsl_rio.c2010-05-17 08:56:43.0
+0200
+++ linux-new/arch/powerpc/sysdev/fsl_rio.c 2010-05-17 09:40:41.0
+0200
@@ -1,6 +1,10 @@
/*
* Freescale MPC85xx/MPC86xx RapidIO support
*
+ * Copyright 2009 Sysgo AG
+ * Thomas Moll
+ * - fixed maintenance access routines, check for aligned access
+ *
* Copyright 2009 Integrated Device Technology, Inc.
* Alex Bounine
* - Added Port-Write message handling
@@ -371,10 +375,17 @@ fsl_rio_config_read(struct rio_mport *mp
pr_debug
("fsl_rio_config_read: index %d destid %d hopcount %d offset %8.8x
len %d\n",
index, destid, hopcount, offset, len);
+
+ /* 16MB maintenance window possible */
+ /* allow only aligned access to maintenance registers */
+ if (offset > (0x100 - len) || !IS_ALIGNED(offset, len))
+ return -EINVAL;
+
out_be32(&priv->maint_atmu_regs->rowtar,
-(destid << 22) | (hopcount << 12) | ((offset & ~0x3) >> 9));
+(destid << 22) | (hopcount << 12) | (offset >> 12));
+ out_be32(&priv->maint_atmu_regs->rowtear, (destid >> 10));
- data = (u8 *) priv->maint_win + offset;
+ data = (u8 *) priv->maint_win + (offset & (RIO_MAINT_WIN_SIZE - 1));
switch (len) {
case 1:
__fsl_read_rio_config(rval, data, err, "lbz");
@@ -382,9 +393,11 @@ fsl_rio_config_read(struct rio_mport *mp
case 2:
__fsl_read_rio_config(rval, data, err, "lhz");
break;
- default:
+ case 4:
__fsl_read_rio_config(rval, data, err, "lwz");
break;
+ default:
+ return -EINVAL;
}
if (err) {
@@ -419,10 +432,17 @@ fsl_rio_config_write(struct rio_mport *m
pr_debug
("fsl_rio_config_write: index %d destid %d hopcount %d offset %8.8x
len %d val %8.8x\n",
index, destid, hopcount, offset, len, val);
+
+ /* 16MB maintenance windows possible */
+ /* allow only aligned access to maintenance registers */
+ if (offset > (0x100 - len) || !IS_ALIGNED(offset, len))
+ return -EINVAL;
+
out_be32(&priv->maint_atmu_regs->rowtar,
-(destid << 22) | (hopcount << 12) | ((offset & ~0x3) >> 9));
+(destid << 22) | (hopcount << 12) | (offset >> 12));
+ out_be32(&priv->maint_atmu_regs->rowtear, (destid >> 10));
- data = (u8 *) priv->maint_win + offset;
+ data = (u8 *) priv->maint_win + (offset & (RIO_MAINT_WIN_SIZE - 1));
switch (len) {
case 1:
out_8((u8 *) data, val);
@@ -430,9 +450,11 @@ fsl_rio_config_write(struct rio_mport *m
case 2:
out_be16((u16 *) data, val);
break;
- default:
+ case 4:
out_be32((u32 *) data, val);
break;
+ default:
+ return -EINVAL;
}
return 0;
@@ -1483,7 +1505,8 @@ int fsl_rio_setup(struct of_device *dev)
/* Configure maintenance transaction window */
out_be32(&priv->maint_atmu_regs->rowbar, law_start >> 12);
- out_be32(&priv->maint_atmu_regs->rowar, 0x80077015);/* 4M */
+ out_be32(&priv->maint_atmu_regs->rowar,
+0x80077000 | (ilog2(RIO_MAINT_WIN_SIZE) - 1));
priv->maint_win = ioremap(law_start, RIO_MAINT_WIN_SIZE);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
