* [PATCH v2.6.33] powerpc: hlwd-pic: convert irq_desc.lock to raw_spinlock
From: Albert Herranz @ 2009-12-18 20:04 UTC (permalink / raw)
To: linuxppc-dev, glikely; +Cc: Albert Herranz
Fix the following build failures:
arch/powerpc/platforms/embedded6xx/hlwd-pic.c: In function 'hlwd_pic_irq_cascade':
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:135: error: passing argument 1 of 'spin_lock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:137: error: passing argument 1 of 'spin_unlock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:145: error: passing argument 1 of 'spin_lock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:149: error: passing argument 1 of 'spin_unlock' from incompatible pointer type
These failures are caused by the changes introduced in commit
"genirq: Convert irq_desc.lock to raw_spinlock". The reason this driver
was not updated is that it wasn't merged yet.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
---
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
index fe0ff06..a771f91 100644
--- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
@@ -132,9 +132,9 @@ static void hlwd_pic_irq_cascade(unsigned int cascade_virq,
struct irq_host *irq_host = get_irq_data(cascade_virq);
unsigned int virq;
- spin_lock(&desc->lock);
+ raw_spin_lock(&desc->lock);
desc->chip->mask(cascade_virq); /* IRQ_LEVEL */
- spin_unlock(&desc->lock);
+ raw_spin_unlock(&desc->lock);
virq = __hlwd_pic_get_irq(irq_host);
if (virq != NO_IRQ)
@@ -142,11 +142,11 @@ static void hlwd_pic_irq_cascade(unsigned int cascade_virq,
else
pr_err("spurious interrupt!\n");
- spin_lock(&desc->lock);
+ raw_spin_lock(&desc->lock);
desc->chip->ack(cascade_virq); /* IRQ_LEVEL */
if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
desc->chip->unmask(cascade_virq);
- spin_unlock(&desc->lock);
+ raw_spin_unlock(&desc->lock);
}
/*
--
1.6.3.3
^ permalink raw reply related
* [PATCH] powerpc: update ibm,client-architecture
From: Joel Schopp @ 2009-12-18 21:07 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In order to boot with more than 64 cores on machines that support the ibm,client-architecture RTAS call a
new field has been added to the structure. This patch updates that field and adds a few others in the
process. It would be good if this could go in as a bugfix.
Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.git/arch/powerpc/kernel/prom_init.c
@@ -654,6 +654,9 @@ static void __init early_cmdline_parse(v
#define OV5_CMO 0x00
#endif
+/* Option Vector 6: IBM PAPR hints */
+#define OV6_LINUX 0x02 /* Linux is our OS */
+
/*
* The architecture vector has an array of PVR mask/value pairs,
* followed by # option vectors - 1, followed by the option vectors.
@@ -665,7 +668,7 @@ static unsigned char ibm_architecture_ve
W(0xffffffff), W(0x0f000003), /* all 2.06-compliant */
W(0xffffffff), W(0x0f000002), /* all 2.05-compliant */
W(0xfffffffe), W(0x0f000001), /* all 2.04-compliant and earlier */
- 5 - 1, /* 5 option vectors */
+ 6 - 1, /* 6 option vectors */
/* option vector 1: processor architectures supported */
3 - 2, /* length */
@@ -697,12 +700,26 @@ static unsigned char ibm_architecture_ve
0, /* don't halt */
/* option vector 5: PAPR/OF options */
- 5 - 2, /* length */
+ 13 - 2, /* length */
0, /* don't ignore, don't halt */
OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
OV5_DONATE_DEDICATE_CPU | OV5_MSI,
0,
OV5_CMO,
+ 0, /* reserved */
+ 0, /* reserved */
+ 0, /* reserved */
+ 0, /* reserved */
+ W(NR_CPUS/4), /* max cores supported */
+
+ /* option vector 6: IBM PAPR hints */
+ 4 - 2,
+ 0, /* reserved */
+ 0, /* 1 == no secondary pteg */
+ OV6_LINUX,
+
+ /* option vector 7: IBM PAPR OS identification */
+ /* a human readable ascii string will go here */
};
/* Old method - ELF header with PT_NOTE sections */
^ permalink raw reply
* Re: [PATCH] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
From: Benjamin Herrenschmidt @ 2009-12-18 22:09 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Geert Uytterhoeven, linuxppc-dev, linux-wireless
In-Reply-To: <20091218085547.fb8bdaf5.randy.dunlap@oracle.com>
On Fri, 2009-12-18 at 08:55 -0800, Randy Dunlap wrote:
>
> Probably also needs
> depends on WLAN
> to prevent build failures.
Yeah, GELIC_WIRELESS should probably. I'll do a separate patch next week
but feel free to beat me to it.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
From: Benjamin Herrenschmidt @ 2009-12-18 22:09 UTC (permalink / raw)
To: Geoff Levand
Cc: Randy Dunlap, linuxppc-dev, Geert Uytterhoeven,
linux-wireless@vger.kernel.org, Hamish Guthrie
In-Reply-To: <4B2BC8E6.9090007@am.sony.com>
On Fri, 2009-12-18 at 10:24 -0800, Geoff Levand wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> The option to support the old style PSK interface in the PS3
> GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> v2: Added 'depends on WLAN'.
>
> Please send to Linus asap (or I can put it in powerpc.git) as it's
> breaking one of my test build configs :-)
>
> Just as a note, I asked Hamish to work to remove this option.
> No distros use it anymore, so we don't need it.
Geoff, the depends on WLAN should be on config GELIC_WIRELESS
Cheers,
Ben.
> -Geoff
> ---
> drivers/net/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2357,7 +2357,9 @@ config GELIC_WIRELESS
>
> config GELIC_WIRELESS_OLD_PSK_INTERFACE
> bool "PS3 Wireless private PSK interface (OBSOLETE)"
> + depends on WLAN
> depends on GELIC_WIRELESS
> + select WEXT_PRIV
> help
> This option retains the obsolete private interface to pass
> the PSK from user space programs to the driver. The PSK
^ permalink raw reply
* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Dan Williams @ 2009-12-18 22:17 UTC (permalink / raw)
To: Li Yang-R58472
Cc: herbert, Ira W. Snyder, Suresh Vishnu-B05022, Tabi Timur-B04825,
linux-kernel, linux-raid, linuxppc-dev, linux-crypto,
Gupta Maneesh-B18878, Dudhat Dipen-B09055
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED01059526@zch01exm26.fsl.freescale.net>
On Fri, Dec 18, 2009 at 8:02 AM, Li Yang-R58472 <r58472@freescale.com> wrot=
e:
>
>>Subject: Re: [PATCH v2 2/2] Crypto: Talitos: Support for
>>Async_tx XOR offload
>>
>>Ira W. Snyder wrote:
>>> Yes, I have used the device_prep_dma_interrupt()
>>functionality quite a
>>> while back. However, I found it to be pretty much useless.
>>
>>The specific case it is needed for Talitos/raid is a channel
>>switch interrupt. =A0The interrupt causes the cleanup operation
>>to be run which will kick off any pending dependent operations
>>on the xor channel. =A0In the raid case we only have callbacks
>>at the end of a chain, so we need the interrupt to kick the
>>engine in an operation chain like
>>xor->copy->xor->callback.
>
> I am wondering if can use more callbacks to kick off pending dependent op=
erations?
> Like xor->callback->copy->callback->xor->callback?
>
No, the callback field is reserved for clients of the api. What you want i=
s:
xor->cleanupT->copy->cleanupF->xor->cleanupT->callback
Where cleanupT is the Talitos descriptor cleanup routine and cleanupF
is from fsldma. The assumption is that the interrupt kicks the
cleanup routine and that calls dma_run_dependencies().
--
Dan
^ permalink raw reply
* [PATCH] powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem
From: Peter Tyser @ 2009-12-18 22:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Peter Tyser, Nate Case
Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
the "cpu-release-addr" device tree property to contain the physical RAM
location that secondary cores were spinning at. Previously, the
"cpu-release-addr" property contained a value referencing the boot page
translation address range of 0xfffffxxx, which then indirectly accessed
RAM.
The "cpu-release-addr" is currently ioremapped and the secondary cores
kicked. However, due to the recent change in "cpu-release-addr", it
sometimes points to a memory location in low memory that cannot be
ioremapped. For example on a P2020-based board with 512MB of RAM the
following error occurs on bootup:
<...>
mpic: requesting IPIs ...
__ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
Unable to handle kernel paging request for data at address 0x00000014
Faulting instruction address: 0xc05df9b0
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2 P2020 RDB
Modules linked in:
<... eventual kernel panic>
Adding logic to conditionally ioremap or access memory directly resolves
the issue.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Nate Case <ncase@xes-inc.com>
Reported-by: Dipen Dudhat <B09055@freescale.com>
Tested-by: Dipen Dudhat <B09055@freescale.com>
---
arch/powerpc/platforms/85xx/smp.c | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 04160a4..a15f582 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -46,6 +46,7 @@ smp_85xx_kick_cpu(int nr)
__iomem u32 *bptr_vaddr;
struct device_node *np;
int n = 0;
+ int ioremappable;
WARN_ON (nr < 0 || nr >= NR_CPUS);
@@ -59,21 +60,37 @@ smp_85xx_kick_cpu(int nr)
return;
}
+ /*
+ * A secondary core could be in a spinloop in the bootpage
+ * (0xfffff000), somewhere in highmem, or somewhere in lowmem.
+ * The bootpage and highmem can be accessed via ioremap(), but
+ * we need to directly access the spinloop if its in lowmem.
+ */
+ ioremappable = *cpu_rel_addr > virt_to_phys(high_memory);
+
/* Map the spin table */
- bptr_vaddr = ioremap(*cpu_rel_addr, SIZE_BOOT_ENTRY);
+ if (ioremappable)
+ bptr_vaddr = ioremap(*cpu_rel_addr, SIZE_BOOT_ENTRY);
+ else
+ bptr_vaddr = phys_to_virt(*cpu_rel_addr);
local_irq_save(flags);
out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
+ if (!ioremappable)
+ flush_dcache_range((ulong)bptr_vaddr,
+ (ulong)(bptr_vaddr + SIZE_BOOT_ENTRY));
+
/* Wait a bit for the CPU to ack. */
while ((__secondary_hold_acknowledge != nr) && (++n < 1000))
mdelay(1);
local_irq_restore(flags);
- iounmap(bptr_vaddr);
+ if (ioremappable)
+ iounmap(bptr_vaddr);
pr_debug("waited %d msecs for CPU #%d.\n", n, nr);
}
--
1.6.2.1
^ permalink raw reply related
* DWC_OTG Issues
From: Hunter Cobbs @ 2009-12-19 2:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1261176637-23912-1-git-send-email-ptyser@xes-inc.com>
Hello list. I've run into a rather odd problem. I seem to have a
problem with full-speed isochronous transfers across a USB2.0 Hub. I
believe this was observed before with the general EHCI drivers in Linux.
In the latest branch of the kernel, the EHCI driver has some "Enhanced
Transaction Translation" scheduling. This would be great for me to use
as it seems to directly address the issues I've seen. However, I'm not
really sure on how to proceed because the DWC_OTG driver is not GPL code
while the EHCI code I'd like to use is. Therefore, I don't believe that
I can port the Enhanced Transaction Translation routine into the DWC_OTG
driver without violating both the GPL and Synopsis's own driver.
Does anyone have a suggestion on how to proceed?
^ permalink raw reply
* Re: [PATCH 5/6 v5] CPU probe/release files
From: Benjamin Herrenschmidt @ 2009-12-19 8:46 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <m2oclw9wt4.fsf@igel.home>
On Fri, 2009-12-18 at 15:33 +0100, Andreas Schwab wrote:
> Nathan Fontenot <nfont@austin.ibm.com> writes:
>
> > Index: powerpc/arch/powerpc/Kconfig
> > ===================================================================
> > --- powerpc.orig/arch/powerpc/Kconfig 2009-10-28 15:21:47.000000000 -0500
> > +++ powerpc/arch/powerpc/Kconfig 2009-10-28 15:21:53.000000000 -0500
> > @@ -320,6 +320,10 @@
> >
> > Say N if you are unsure.
> >
> > +config ARCH_CPU_PROBE_RELEASE
> > + def_bool y
> > + depends on HOTPLUG_CPU
> > +
>
> That does not work.
>
> drivers/built-in.o: In function `.store_online':
> cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
> cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
> make: *** [.tmp_vmlinux1] Error 1
>
> cpu_hotplug_driver_lock is only defined on pseries, but HOTPLUG_CPU is
> also defined on pmac.
Well, the stuff was merged ... so we need to fix it.
Nathan, the problem is that the above wlil define ARCH_CPU_PROBE_RELEASE
for any powerpc platform that has HOTPLUG_CPU. So a kernel that doesn't
have pSeries support but has hotplug CPU will have a problem, though for
some reason none of my test configs triggered it (I'll have to check why
next week).
The right approach here is to have cpu_hotplug_driver_lock go through
ppc_md. I suppose, along with some of the other CPU hotplug platform
specific bits.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 5/6 v5] CPU probe/release files
From: Andreas Schwab @ 2009-12-19 10:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1261212415.2173.94.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Nathan, the problem is that the above wlil define ARCH_CPU_PROBE_RELEASE
> for any powerpc platform that has HOTPLUG_CPU. So a kernel that doesn't
> have pSeries support but has hotplug CPU will have a problem, though for
> some reason none of my test configs triggered it (I'll have to check why
> next week).
Perhaps you didn't enable CONFIG_SUSPEND.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* xilinx xps_spi & ads7846
From: Jothi Adithya @ 2009-12-19 17:47 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 112 bytes --]
Hi
Anybody has experience using xilinx xps_spi driver & ads7846 driver for touchscreen control?
Jothi
[-- Attachment #2: Type: text/html, Size: 485 bytes --]
^ permalink raw reply
* Re: DWC_OTG Issues
From: Wolfgang Denk @ 2009-12-19 18:56 UTC (permalink / raw)
To: Hunter Cobbs; +Cc: linuxppc-dev
In-Reply-To: <1261190115.14590.5.camel@mobiLinux>
Dear Hunter Cobbs,
In message <1261190115.14590.5.camel@mobiLinux> you wrote:
> Hello list. I've run into a rather odd problem. I seem to have a
> problem with full-speed isochronous transfers across a USB2.0 Hub. I
> believe this was observed before with the general EHCI drivers in Linux.
Which exazct kernel / driver cversions are you talking about?
> In the latest branch of the kernel, the EHCI driver has some "Enhanced
> Transaction Translation" scheduling. This would be great for me to use
> as it seems to directly address the issues I've seen. However, I'm not
> really sure on how to proceed because the DWC_OTG driver is not GPL code
Oops? if that wa the case you could not use (and distribute) this code
in a Linux context at all.
> while the EHCI code I'd like to use is. Therefore, I don't believe that
> I can port the Enhanced Transaction Translation routine into the DWC_OTG
> driver without violating both the GPL and Synopsis's own driver.
What makes you think so?
The Synopsis dwc_otg driver license does not seem to be in conflict
to the GPL, if you ask me (but then, I am not a layer). When we
worked on this, we were assured that the use of this driver source in
the context of GPLed software like the Linux kernel (or U-Boot) was
not considered an issue by Synopsis.
> Does anyone have a suggestion on how to proceed?
We have been doing some work on the DWC drivers in the past, fixing a
number of issues. [We never attempted to psuh any of this into
mainline as the Synopsis drivers are - in our opinion - not
avcceptable for mainline but require more or less a rewrite from
scratch. But you can find all this stuff in our linux-2.6-denx repo.]
I recommend you give a try to our latest stable branch.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is research but a blind date with knowledge? -- Will Harvey
^ permalink raw reply
* Re: enabling USB Host controller on ppc405ex based board
From: Weirich, Bernhard @ 2009-12-20 15:13 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
If you enable PCI on 405EX you MUST have valid clock signals on the PCIE po=
rts. If you do not have these on your board your kernel will hang just as y=
ou said.
I do not know why PCI is required for the USB controller, if it is just for=
some software interfaces to be present then you can try to remove the PCIE=
entries from the kilauea.dts device tree.
Then you will be able to boot even without proper clock signals, yet I do n=
ot know whether the USB controller will work.
Best regards,
Bernhard
^ permalink raw reply
* Re: DWC_OTG Issues
From: Hunter Cobbs @ 2009-12-20 20:13 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20091219185657.5FF29E85072@gemini.denx.de>
Well, thank you for the assurance on the Synopsis drivers not being in
conflict. That makes me feel a little better.
We're using Linux 2.6.30(.3)-denx. We've worked on this issue a bit
before, although at the time you were doing some work for AMCC on just
accessing devices across a hub in general. We've been using the driver
for a few months now and it is very stable on first-use of the driver,
but once we close a full-speed port and try to reopen, that's when we
get error concerning not being able to allocate resources and getting
-28 errors. I don't have anything precise in front of me at the moment,
my test equipment is at the office. But this seems to be the issues
that lead to the Enhanced Transaction Translation Scheduling changes in
the main-line kernel.
I'm mainly being, I believe, overly cautious about not including GPL
code in the Synopsis driver simply because I'd rather be overly careful
than be exposed to some liability later down the road if Synopsis
decides they want to make their driver completely proprietary. While
the code is available, I'm not sure if we can include code from GPL
sources in the Synopsis drivers without requiring the Synopsis driver to
become completely GPL. I am also not a lawyer, but I'd rather be
cautious.
I did do a comparison on the previous branch we are (2.6.30.3-denx) and
the current stable. The only differences in the code were minor enough
that I simply merged them into our existing codebase. It didn't really
help our issue, but on block transfers and standard connect/disconnect
the driver seemed more responsive. I believe this was mainly from
Setphan's actions to put some sleeps inside of tight loops that would
chew up major CPU time on a non-preemptable kernel(which we had earlier).
On Sat, 2009-12-19 at 19:56 +0100, Wolfgang Denk wrote:
> Dear Hunter Cobbs,
>
> In message <1261190115.14590.5.camel@mobiLinux> you wrote:
> > Hello list. I've run into a rather odd problem. I seem to have a
> > problem with full-speed isochronous transfers across a USB2.0 Hub. I
> > believe this was observed before with the general EHCI drivers in Linux.
>
> Which exazct kernel / driver cversions are you talking about?
>
> > In the latest branch of the kernel, the EHCI driver has some "Enhanced
> > Transaction Translation" scheduling. This would be great for me to use
> > as it seems to directly address the issues I've seen. However, I'm not
> > really sure on how to proceed because the DWC_OTG driver is not GPL code
>
> Oops? if that wa the case you could not use (and distribute) this code
> in a Linux context at all.
>
> > while the EHCI code I'd like to use is. Therefore, I don't believe that
> > I can port the Enhanced Transaction Translation routine into the DWC_OTG
> > driver without violating both the GPL and Synopsis's own driver.
>
> What makes you think so?
>
> The Synopsis dwc_otg driver license does not seem to be in conflict
> to the GPL, if you ask me (but then, I am not a layer). When we
> worked on this, we were assured that the use of this driver source in
> the context of GPLed software like the Linux kernel (or U-Boot) was
> not considered an issue by Synopsis.
>
> > Does anyone have a suggestion on how to proceed?
>
> We have been doing some work on the DWC drivers in the past, fixing a
> number of issues. [We never attempted to psuh any of this into
> mainline as the Synopsis drivers are - in our opinion - not
> avcceptable for mainline but require more or less a rewrite from
> scratch. But you can find all this stuff in our linux-2.6-denx repo.]
>
> I recommend you give a try to our latest stable branch.
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Michael Neuling @ 2009-12-20 20:54 UTC (permalink / raw)
To: Masami Hiramatsu; +Cc: Mahesh Jagannath Salgaonkar, linuxppc-dev
In-Reply-To: <4B2B934C.1060807@redhat.com>
In message <4B2B934C.1060807@redhat.com> you wrote:
>
>
> Mahesh Jagannath Salgaonkar wrote:
> > Michael Neuling wrote:
> >> In message <4B29EE5F.9020801@linux.vnet.ibm.com> you wrote:
> >>> Hi Michael,
> >>>
> >>> Michael Neuling wrote:
> >>>>> + * regs_get_argument_nth() - get Nth argument at function call
> >>>>> + * @regs: pt_regs which contains registers at function entry.
> >>>>> + * @n: argument number.
> >>>>> + *
> >>>>> + * regs_get_argument_nth() returns @n th argument of a function call.
> >>>>> + * Since usually the kernel stack will be changed right after
> >>>>> function en
> >> try
> >>>> ,
> >>>>> + * you must use this at function entry. If the @n th entry is NOT
> >>>>> in the
> >>>>> + * kernel stack or pt_regs, this returns 0.
> >>>>> + */
> >>>>> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned
> >>>>> int n)
> >>>>> +{
> >>>>> + if (n < ARRAY_SIZE(arg_offs_table))
> >>>>> + return *(unsigned long *)((char *)regs + arg_offs_table[n]);
> >>>>> + else {
> >>>>> + /*
> >>>>> + * If more arguments are passed that can be stored in
> >>>>> + * registers, the remaining arguments are stored in the
> >>>>> + * parameter save area located at fixed offset from stack
> >>>>> + * pointer.
> >>>>> + * Following the PowerPC ABI, the first few arguments are
> >>>>> + * actually passed in registers (r3-r10), with equivalent
> >>>>> space
> >>>>> + * left unused in the parameter save area.
> >>>>> + */
> >>>>> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
> >>>>> + return regs_get_kernel_stack_nth(regs, n);
> >>>> How do we handle FP args?
> >>> Currently this patch does not support FP args.
> >>
> >> This might be OK. I don't think we use floating point parameters in any
> >> function definitions in the kernel.
> >> We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
> >> they are static inline, so they probably don't even end up as
> >> functions.
> >> I guess we need to make sure that we're not limiting the interface in
> >> such a way that we can't support it later if the above changes.
> >> regs_get_argument_nth returns an unsigned long which makes returning a
> >> 128 bit VMX register impossible. This might be a show stopper for me.
> >> How are the x86 guys dealing with this?
> >>
> > Nope, x86 does not deal with bigger registers (Masami, correct me if I
> > am wrong). The return data type is opaque to user. Hence this enables us
> > to handle any such situations in future without effecting user space API.
>
> Right, we don't use those bigger registers in the kernel context.
> (some special functions use it inside, but most of codes
> are just using general regs)
Sure, but kernel interfaces are for now. What happens if this changes in
the future?
> And regs_get_argument_nth is just an accessor of pt_regs field.
> This means that it just provides field in pt_regs.
Sure, that's how it's implemented, but that's not what the name of the
function suggests it does.
Mikey
>
> >>>>> + }
> >>>>> +}
> >>>>> +/*
> >>>>> * does not yet catch signals sent when the child dies.
> >>>>> * in exit.c or in signal.c.
> >>>>> */
> >>>>> Index: linux-2.6-tip/kernel/trace/Kconfig
> >>>>> ===================================================================
> >>>>> --- linux-2.6-tip.orig/kernel/trace/Kconfig
> >>>>> +++ linux-2.6-tip/kernel/trace/Kconfig
> >>>>> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
> >>>>>
> >>>>> config KPROBE_EVENT
> >>>>> depends on KPROBES
> >>>>> - depends on X86
> >>>>> + depends on X86 || PPC
> >>>>> bool "Enable kprobes-based dynamic events"
> >>>>> select TRACING
> >>>>> default y
> >>>>>
> >>>>> _______________________________________________
> >>>>> Linuxppc-dev mailing list
> >>>>> Linuxppc-dev@lists.ozlabs.org
> >>>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>>>>
> >>> Thanks for reviewing.
> >>
> >> We are creating a new user space API here, so I'm keen for others to take
> >> a good look at the interface before we commit to something we are going
> >> to have to keep forever.
> >> Who is the main consumer of this (/me is pretty ignorant of kprobes)?
> >> What do they think of the interface?
> >>
> > The user space API are already present in the upstream kernel and
> > currently only supported architecture is x86. This patch provides ppc
> > architecture specific interfaces that enables powerpc also in par with x86.
>
> Yes, there is a kprobe tracer in ftrace (see Documentation/trace/kprobetrace.
txt).
> and this tracer is only for probing kernel (not userspace).
>
> >
> > The main consumer would be kernel developers who would like to see
> > register values, arguments and stack when the probe hits at given text
> > address.
>
> Right.
>
> BTW, there is a user-space tools we have (tools/perf/builtin-probe.c).
> Currently, it's only for x86. Mahesh, You just need to add a register
> translation table in tools/perf/util/probe-finder.c for ppc support.
>
> Thank you!
>
> --
> Masami Hiramatsu
>
> Software Engineer
> Hitachi Computer Products (America), Inc.
> Software Solutions Division
>
> e-mail: mhiramat@redhat.com
>
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Michael Neuling @ 2009-12-20 20:59 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar; +Cc: linuxppc-dev, Masami Hiramatsu
In-Reply-To: <4B2B0EBF.5040302@linux.vnet.ibm.com>
In message <4B2B0EBF.5040302@linux.vnet.ibm.com> you wrote:
> Michael Neuling wrote:
> > In message <4B29EE5F.9020801@linux.vnet.ibm.com> you wrote:
> >> Hi Michael,
> >>
> >> Michael Neuling wrote:
> >>>> + * regs_get_argument_nth() - get Nth argument at function call
> >>>> + * @regs: pt_regs which contains registers at function entry.
> >>>> + * @n: argument number.
> >>>> + *
> >>>> + * regs_get_argument_nth() returns @n th argument of a function call.
> >>>> + * Since usually the kernel stack will be changed right after function
en
> > try
> >>> ,
> >>>> + * you must use this at function entry. If the @n th entry is NOT in th
e
> >>>> + * kernel stack or pt_regs, this returns 0.
> >>>> + */
> >>>> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned int
n)
> >>>> +{
> >>>> + if (n < ARRAY_SIZE(arg_offs_table))
> >>>> + return *(unsigned long *)((char *)regs + arg_offs_table
[n]);
> >>>> + else {
> >>>> + /*
> >>>> + * If more arguments are passed that can be stored in
> >>>> + * registers, the remaining arguments are stored in the
> >>>> + * parameter save area located at fixed offset from sta
ck
> >>>> + * pointer.
> >>>> + * Following the PowerPC ABI, the first few arguments a
re
> >>>> + * actually passed in registers (r3-r10), with equivale
nt space
> >>>> + * left unused in the parameter save area.
> >>>> + */
> >>>> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long
));
> >>>> + return regs_get_kernel_stack_nth(regs, n);
> >>> How do we handle FP args?
> >> Currently this patch does not support FP args.
> >
> > This might be OK. I don't think we use floating point parameters in any
> > function definitions in the kernel.
> >
> > We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
> > they are static inline, so they probably don't even end up as
> > functions.
> >
> > I guess we need to make sure that we're not limiting the interface in
> > such a way that we can't support it later if the above changes.
> >
> > regs_get_argument_nth returns an unsigned long which makes returning a
> > 128 bit VMX register impossible. This might be a show stopper for me.
> > How are the x86 guys dealing with this?
> >
> Nope, x86 does not deal with bigger registers (Masami, correct me if I
> am wrong). The return data type is opaque to user. Hence this enables us
> to handle any such situations in future without effecting user space API.
How is it opaque? It's an unsigned long? Is this function different to
what is presented to userspace?
Mikey
> >>>> + }
> >>>> +}
> >>>> +/*
> >>>> * does not yet catch signals sent when the child dies.
> >>>> * in exit.c or in signal.c.
> >>>> */
> >>>> Index: linux-2.6-tip/kernel/trace/Kconfig
> >>>> ===================================================================
> >>>> --- linux-2.6-tip.orig/kernel/trace/Kconfig
> >>>> +++ linux-2.6-tip/kernel/trace/Kconfig
> >>>> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
> >>>>
> >>>> config KPROBE_EVENT
> >>>> depends on KPROBES
> >>>> - depends on X86
> >>>> + depends on X86 || PPC
> >>>> bool "Enable kprobes-based dynamic events"
> >>>> select TRACING
> >>>> default y
> >>>>
> >>>> _______________________________________________
> >>>> Linuxppc-dev mailing list
> >>>> Linuxppc-dev@lists.ozlabs.org
> >>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>>>
> >> Thanks for reviewing.
> >
> > We are creating a new user space API here, so I'm keen for others to take
> > a good look at the interface before we commit to something we are going
> > to have to keep forever.
> >
> > Who is the main consumer of this (/me is pretty ignorant of kprobes)?
> > What do they think of the interface?
> >
> The user space API are already present in the upstream kernel and
> currently only supported architecture is x86. This patch provides ppc
> architecture specific interfaces that enables powerpc also in par with x86.
>
> The main consumer would be kernel developers who would like to see
> register values, arguments and stack when the probe hits at given text
> address.
>
> > Mikey
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: DWC_OTG Issues
From: Wolfgang Denk @ 2009-12-20 21:58 UTC (permalink / raw)
To: Hunter Cobbs; +Cc: linuxppc-dev
In-Reply-To: <1261340025.3473.15.camel@mobiLinux>
Dear Hunter Cobbs,
In message <1261340025.3473.15.camel@mobiLinux> you wrote:
>
> We're using Linux 2.6.30(.3)-denx. We've worked on this issue a bit
> before, although at the time you were doing some work for AMCC on just
> accessing devices across a hub in general. We've been using the driver
> for a few months now and it is very stable on first-use of the driver,
> but once we close a full-speed port and try to reopen, that's when we
> get error concerning not being able to allocate resources and getting
> -28 errors. I don't have anything precise in front of me at the moment,
> my test equipment is at the office. But this seems to be the issues
> that lead to the Enhanced Transaction Translation Scheduling changes in
> the main-line kernel.
If you have a detailed bug report, ideally including an easy to
reproduce test case to trigger the problem then please feel free to
send it to our support address.
> I'm mainly being, I believe, overly cautious about not including GPL
> code in the Synopsis driver simply because I'd rather be overly careful
> than be exposed to some liability later down the road if Synopsis
> decides they want to make their driver completely proprietary. While
> the code is available, I'm not sure if we can include code from GPL
> sources in the Synopsis drivers without requiring the Synopsis driver to
> become completely GPL. I am also not a lawyer, but I'd rather be
> cautious.
Well, their license is relatively simple: the driver is unsupported,
it "IS NOT an item of Licensed Software or Licensed Product under any
End User Software License Agreement or Agreement for Licensed
Product", and you "are permitted to use andredistribute this Software
in source and binary forms, with or without modification, provided
that redistributions of source code must retain this notice." And
there is no warranty, of course.
IANAL, but I see no risks here.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If I ever needed a brain transplant, I'd choose a teenager's because
I'd want a brain that had never been used.
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Michael Neuling @ 2009-12-20 23:59 UTC (permalink / raw)
To: Joel Schopp; +Cc: linuxppc-dev
In-Reply-To: <1261170452.8134.13.camel@jschopp-laptop>
> Subject: Re: [PATCH] powerpc: update ibm,client-architecture
Please give this a more appropriate name.
> In order to boot with more than 64 cores on machines that support the
> ibm,client-architecture RTAS call a new field has been added to the
> structure. This patch updates that field and adds a few others in the
> process.
Please detail what these are here.
> It would be good if this could go in as a bugfix.
>
> Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
>
> Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c
> +++ linux-2.6.git/arch/powerpc/kernel/prom_init.c
> @@ -654,6 +654,9 @@ static void __init early_cmdline_parse(v
> #define OV5_CMO 0x00
> #endif
>
> +/* Option Vector 6: IBM PAPR hints */
> +#define OV6_LINUX 0x02 /* Linux is our OS */
> +
> /*
> * The architecture vector has an array of PVR mask/value pairs,
> * followed by # option vectors - 1, followed by the option vectors.
> @@ -665,7 +668,7 @@ static unsigned char ibm_architecture_ve
> W(0xffffffff), W(0x0f000003), /* all 2.06-compliant */
> W(0xffffffff), W(0x0f000002), /* all 2.05-compliant */
> W(0xfffffffe), W(0x0f000001), /* all 2.04-compliant and earlier */
> - 5 - 1, /* 5 option vectors */
> + 6 - 1, /* 6 option vectors */
>
> /* option vector 1: processor architectures supported */
> 3 - 2, /* length */
> @@ -697,12 +700,26 @@ static unsigned char ibm_architecture_ve
> 0, /* don't halt */
>
> /* option vector 5: PAPR/OF options */
> - 5 - 2, /* length */
> + 13 - 2, /* length */
> 0, /* don't ignore, don't halt */
> OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
> OV5_DONATE_DEDICATE_CPU | OV5_MSI,
> 0,
> OV5_CMO,
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> + W(NR_CPUS/4), /* max cores supported */
4?
> +
> + /* option vector 6: IBM PAPR hints */
> + 4 - 2,
Please put a comment next to these to say what it is.
> + 0, /* reserved */
> + 0, /* 1 == no secondary pteg */
> + OV6_LINUX,
> +
> + /* option vector 7: IBM PAPR OS identification */
> + /* a human readable ascii string will go here */
Can we do this now or remove the comment. Maybe UTS_RELEASE or
something like that.
Mikey
> };
>
> /* Old method - ELF header with PT_NOTE sections */
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Tony Breeds @ 2009-12-21 0:44 UTC (permalink / raw)
To: Joel Schopp; +Cc: linuxppc-dev
In-Reply-To: <1261170452.8134.13.camel@jschopp-laptop>
On Fri, Dec 18, 2009 at 03:07:32PM -0600, Joel Schopp wrote:
> In order to boot with more than 64 cores on machines that support the
> ibm,client-architecture RTAS call a new field has been added to the
> structure. This patch updates that field and adds a few others in the
> process. It would be good if this could go in as a bugfix.
But it's not really is it? What does it fix?
> Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
>
> Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c
> +++ linux-2.6.git/arch/powerpc/kernel/prom_init.c
> @@ -654,6 +654,9 @@ static void __init early_cmdline_parse(v
> #define OV5_CMO 0x00
> #endif
>
> +/* Option Vector 6: IBM PAPR hints */
> +#define OV6_LINUX 0x02 /* Linux is our OS */
> +
> /*
> * The architecture vector has an array of PVR mask/value pairs,
> * followed by # option vectors - 1, followed by the option vectors.
> @@ -665,7 +668,7 @@ static unsigned char ibm_architecture_ve
> W(0xffffffff), W(0x0f000003), /* all 2.06-compliant */
> W(0xffffffff), W(0x0f000002), /* all 2.05-compliant */
> W(0xfffffffe), W(0x0f000001), /* all 2.04-compliant and earlier */
> - 5 - 1, /* 5 option vectors */
> + 6 - 1, /* 6 option vectors */
>
> /* option vector 1: processor architectures supported */
> 3 - 2, /* length */
> @@ -697,12 +700,26 @@ static unsigned char ibm_architecture_ve
> 0, /* don't halt */
>
> /* option vector 5: PAPR/OF options */
> - 5 - 2, /* length */
> + 13 - 2, /* length */
> 0, /* don't ignore, don't halt */
> OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
> OV5_DONATE_DEDICATE_CPU | OV5_MSI,
> 0,
> OV5_CMO,
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
Not so much reserved, as unused by us.
> + W(NR_CPUS/4), /* max cores supported */
4? I can see a case for 2 or just plain NR_CPUS, but 4 is wrong.
> + /* option vector 6: IBM PAPR hints */
> + 4 - 2,
We all know this is a length, but please follow the style in this structure.
> + 0, /* reserved */
> + 0, /* 1 == no secondary pteg */
I think the "1 == " confuses things.
> + OV6_LINUX,
Does filling in the vector actually let us boot on systems where we do not already?
> +
> + /* option vector 7: IBM PAPR OS identification */
> + /* a human readable ascii string will go here */
Either fill it in or leave the comments out.
Yours Tony
^ permalink raw reply
* [PATCH-V2] mpc8xxx_gpio: add interrupt support
From: Peter Korsgaard @ 2009-12-21 12:26 UTC (permalink / raw)
To: avorontsov, galak, linuxppc-dev
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
.../powerpc/dts-bindings/fsl/8xxx_gpio.txt | 22 +++-
arch/powerpc/sysdev/mpc8xxx_gpio.c | 147 ++++++++++++++++++++
2 files changed, 168 insertions(+), 1 deletions(-)
Changes since v1:
- Document OF binding for IRQ as requested by Kumar.
diff --git a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
index d015dce..b0019eb 100644
--- a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
@@ -11,7 +11,7 @@ Required properties:
83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- - interrupts : Interrupt mapping for GPIO IRQ (currently unused).
+ - interrupts : Interrupt mapping for GPIO IRQ.
- interrupt-parent : Phandle for the interrupt controller that
services interrupts for this device.
- gpio-controller : Marks the port as GPIO controller.
@@ -38,3 +38,23 @@ Example of gpio-controller nodes for a MPC8347 SoC:
See booting-without-of.txt for details of how to specify GPIO
information for devices.
+
+To use GPIO pins as interrupt sources for peripherals, specify the
+GPIO controller as the interrupt parent and define GPIO number +
+trigger mode using the interrupts property, which is defined like
+this:
+
+interrupts = <number trigger>, where:
+ - number: GPIO pin (0..31)
+ - trigger: trigger mode:
+ 2 = trigger on falling edge
+ 3 = trigger on both edges
+
+Example of device using this is:
+
+ funkyfpga@0 {
+ compatible = "funky-fpga";
+ ...
+ interrupts = <4 3>;
+ interrupt-parent = <&gpio1>;
+ };
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index ee1c0e1..b4f861a 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -15,6 +15,7 @@
#include <linux/of.h>
#include <linux/of_gpio.h>
#include <linux/gpio.h>
+#include <linux/irq.h>
#define MPC8XXX_GPIO_PINS 32
@@ -34,6 +35,7 @@ struct mpc8xxx_gpio_chip {
* open drain mode safely
*/
u32 data;
+ struct irq_host *irq;
};
static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
@@ -127,12 +129,136 @@ static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val
return 0;
}
+static int mpc8xxx_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
+{
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
+
+ if (mpc8xxx_gc->irq && offset < MPC8XXX_GPIO_PINS)
+ return irq_create_mapping(mpc8xxx_gc->irq, offset);
+ else
+ return -ENXIO;
+}
+
+static void mpc8xxx_gpio_irq_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_desc_data(desc);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned int mask;
+
+ mask = in_be32(mm->regs + GPIO_IER) & in_be32(mm->regs + GPIO_IMR);
+ if (mask)
+ generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
+ 32 - ffs(mask)));
+}
+
+static void mpc8xxx_irq_unmask(unsigned int virq)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long flags;
+
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+
+ setbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+}
+
+static void mpc8xxx_irq_mask(unsigned int virq)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long flags;
+
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+
+ clrbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+}
+
+static void mpc8xxx_irq_ack(unsigned int virq)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+
+ out_be32(mm->regs + GPIO_IER, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+}
+
+static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long flags;
+
+ switch (flow_type) {
+ case IRQ_TYPE_EDGE_FALLING:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ setbits32(mm->regs + GPIO_ICR,
+ mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_BOTH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrbits32(mm->regs + GPIO_ICR,
+ mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct irq_chip mpc8xxx_irq_chip = {
+ .name = "mpc8xxx-gpio",
+ .unmask = mpc8xxx_irq_unmask,
+ .mask = mpc8xxx_irq_mask,
+ .ack = mpc8xxx_irq_ack,
+ .set_type = mpc8xxx_irq_set_type,
+};
+
+static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ set_irq_chip_data(virq, h->host_data);
+ set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
+ set_irq_type(virq, IRQ_TYPE_NONE);
+
+ return 0;
+}
+
+static int mpc8xxx_gpio_irq_xlate(struct irq_host *h, struct device_node *ct,
+ u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_flags)
+
+{
+ /* interrupt sense values coming from the device tree equal either
+ * EDGE_FALLING or EDGE_BOTH
+ */
+ *out_hwirq = intspec[0];
+ *out_flags = intspec[1];
+
+ return 0;
+}
+
+static struct irq_host_ops mpc8xxx_gpio_irq_ops = {
+ .map = mpc8xxx_gpio_irq_map,
+ .xlate = mpc8xxx_gpio_irq_xlate,
+};
+
static void __init mpc8xxx_add_controller(struct device_node *np)
{
struct mpc8xxx_gpio_chip *mpc8xxx_gc;
struct of_mm_gpio_chip *mm_gc;
struct of_gpio_chip *of_gc;
struct gpio_chip *gc;
+ unsigned hwirq;
int ret;
mpc8xxx_gc = kzalloc(sizeof(*mpc8xxx_gc), GFP_KERNEL);
@@ -157,11 +283,32 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
else
gc->get = mpc8xxx_gpio_get;
gc->set = mpc8xxx_gpio_set;
+ gc->to_irq = mpc8xxx_gpio_to_irq;
ret = of_mm_gpiochip_add(np, mm_gc);
if (ret)
goto err;
+ hwirq = irq_of_parse_and_map(np, 0);
+ if (hwirq == NO_IRQ)
+ goto skip_irq;
+
+ mpc8xxx_gc->irq =
+ irq_alloc_host(np, IRQ_HOST_MAP_LINEAR, MPC8XXX_GPIO_PINS,
+ &mpc8xxx_gpio_irq_ops, MPC8XXX_GPIO_PINS);
+ if (!mpc8xxx_gc->irq)
+ goto skip_irq;
+
+ mpc8xxx_gc->irq->host_data = mpc8xxx_gc;
+
+ /* ack and mask all irqs */
+ out_be32(mm_gc->regs + GPIO_IER, 0xffffffff);
+ out_be32(mm_gc->regs + GPIO_IMR, 0);
+
+ set_irq_data(hwirq, mpc8xxx_gc);
+ set_irq_chained_handler(hwirq, mpc8xxx_gpio_irq_cascade);
+
+skip_irq:
return;
err:
--
1.6.5
^ permalink raw reply related
* AMCC 405EX Rev D PVR
From: Lee Nipper @ 2009-12-21 15:37 UTC (permalink / raw)
To: linuxppc-dev
I have observed an odd behavior in the latest 405EX revision parts (Rev D).
Upon first power up on our custom board,
the 405EX Rev D shows a value of 0x12911470 in the PVR register.
After a reset, the 405EX Rev D shows the correct value of 0x12911475
in the PVR register.
The 405EX Rev C part had a steady 0x1291147F on first power up on the
same board.
Has anyone seen this ?
Is a wider reset pulse is required for the Rev D 405EX ?
Thanks for any feedback,
Lee
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Joel Schopp @ 2009-12-21 18:15 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <29526.1261353566@neuling.org>
>> Subject: Re: [PATCH] powerpc: update ibm,client-architecture
>>
>
> Please give this a more appropriate name.
>
Any suggestions?
>
>> In order to boot with more than 64 cores on machines that support the
>> ibm,client-architecture RTAS call a new field has been added to the
>> structure. This patch updates that field and adds a few others in the
>> process.
>>
>
> Please detail what these are here.
>
OK.
>> + W(NR_CPUS/4), /* max cores supported */
>>
>
> 4?
>
>
4 is the new 2. Since you don't know the actual threads per core at
this point in boot you have to be conservative and go with the maximum
number of any processor. See page 4 of these charts:
http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf
>
>
> Can we do this now or remove the comment. Maybe UTS_RELEASE or
> something like that.
>
I'll just remove the comment for now.
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Joel Schopp @ 2009-12-21 18:22 UTC (permalink / raw)
To: Joel Schopp, benh, linuxppc-dev
In-Reply-To: <20091221004458.GI30375@ozlabs.org>
Tony Breeds wrote:
> On Fri, Dec 18, 2009 at 03:07:32PM -0600, Joel Schopp wrote:
>
>> In order to boot with more than 64 cores on machines that support the
>> ibm,client-architecture RTAS call a new field has been added to the
>> structure. This patch updates that field and adds a few others in the
>> process. It would be good if this could go in as a bugfix.
>>
>
> But it's not really is it? What does it fix?
>
It fixes kernels compiled with NR_CPUS where NR_CPUS > 256.
>
>> /* option vector 5: PAPR/OF options */
>> - 5 - 2, /* length */
>> + 13 - 2, /* length */
>> 0, /* don't ignore, don't halt */
>> OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
>> OV5_DONATE_DEDICATE_CPU | OV5_MSI,
>> 0,
>> OV5_CMO,
>> + 0, /* reserved */
>> + 0, /* reserved */
>> + 0, /* reserved */
>> + 0, /* reserved */
>>
>
> Not so much reserved, as unused by us.
>
They were all reserved until recently, and the last 2 of the 4 are still
reserved, while we just don't use the first two yet. I'll remove the
comments from the first 2.
>
>> + W(NR_CPUS/4), /* max cores supported */
>>
>
> 4? I can see a case for 2 or just plain NR_CPUS, but 4 is wrong.
>
4 is the new 2. Since the actual threads per core is unknown at this
point in boot you have to be conservative and go with the maximum number
of any processor. See page 4 of these charts:
http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf
>
>> + /* option vector 6: IBM PAPR hints */
>> + 4 - 2,
>>
>
> We all know this is a length, but please follow the style in this structure.
>
OK.
>
>> + 0, /* reserved */
>> + 0, /* 1 == no secondary pteg */
>>
>
> I think the "1 == " confuses things.
>
I'll remove it then.
>
>> + OV6_LINUX,
>>
>
> Does filling in the vector actually let us boot on systems where we do not already?
>
Will add description to the email body on this one.
>
>> +
>> + /* option vector 7: IBM PAPR OS identification */
>> + /* a human readable ascii string will go here */
>>
>
> Either fill it in or leave the comments out.
>
I'll leave the comment out.
^ permalink raw reply
* Trouble specifying dts gpio-leds with GPIO expander chip
From: Bill Gatliff @ 2009-12-21 19:40 UTC (permalink / raw)
To: Linux/PPC Development
Guys:
I'm trying to come up with the right stuff for my dts file to assign a
Linux "heartbeat" trigger to an I2C GPIO expansion device (MAX7314).
I'm running on a platform that is very similar to the lite5200b, with
linux-2.6.32. I'm a bit new to the device tree concept, having come
most recently from an ARM world, so please be gentle... :)
I have this so far:
soc5200@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc5200b-immr","simple-bus";
ranges = <0 0xf0000000 0x0000c000>;
reg = <0xf0000000 0x00000100>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
...
i2c@3d40 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d40 0x40>;
interrupts = <2 16 0>;
lext20: max7314@20 {
#gpio-cells = <2>;
compatible = "maxim,max7314","phillips,pca953x";
reg = <0x20>;
linux,phandle = <0x20>;
gpio-controller;
};
...
};
};
...
system {
compatible = "simple-bus";
gpio-leds {
compatible = "gpio-leds";
heartbeat {
gpios = <&lext20 3 0>;
linux,default-trigger = "heartbeat";
};
};
};
...
The MAX7314 chip is showing up under /debug/gpio:
# cat /debug/gpio
...
GPIOs 198-213, i2c/1-0020, max7314, can sleep:
And, indeed, I can twiddle the LED by hand:
# echo 201 > /sys/class/gpio/export
# while true; do for led in high low; \
do echo $led > /sys/class/gpio/gpio201/direction; \
sleep 1; done; done
(observe blinking)
But I see this at boot:
Skipping unavailable LED gpio -19 (heartbeat)
That error code is -ENODEV. I double-checked that gpio-leds is showing
up on of_platform:
# ls /sys/bus/of_platform/devices/
...
gpio-leds.2
...
I'm stumped. Could it be that the startup code is trying to register
the heartbeat device before it has registered the MAX7314, so it doesn't
know yet that the GPIO line exists?
Anyone have any suggestions?
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Michael Neuling @ 2009-12-21 21:12 UTC (permalink / raw)
To: Joel Schopp; +Cc: linuxppc-dev
In-Reply-To: <4B2FBB3F.8030703@austin.ibm.com>
> >> Subject: Re: [PATCH] powerpc: update ibm,client-architecture
> >>
> >
> > Please give this a more appropriate name.
> >
> Any suggestions?
Something that's more descriptive of what the patch does. Say "Add
max CPU nodes field to ibm,client-architecture call"
> >
> >> In order to boot with more than 64 cores on machines that support the
> >> ibm,client-architecture RTAS call a new field has been added to the
> >> structure. This patch updates that field and adds a few others in the
> >> process.
> >>
> >
> > Please detail what these are here.
> >
> OK.
> >> + W(NR_CPUS/4), /* max cores supported */
FYI reading the PAPR, this comment should technically be "max 'cpu'
nodes presented".
> >>
> >
> > 4?
> >
> >
> 4 is the new 2.
I'd still be asking what 2 is. It's needs a #define to make clearer
what you are doing.
> Since you don't know the actual threads per core at
> this point in boot you have to be conservative and go with the maximum
> number of any processor. See page 4 of these charts:
> http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf
I don't think hard wiring 4 in here is right. If we are booting a
machine with SMT2, we will put only half the number of cores that we can
handle in this field. This is going to break a lot of machines where
people have compiled with NR_CPUS = thread number.
I think you just want to put NR_CPUS here.
Mikey
> >
> >
> > Can we do this now or remove the comment. Maybe UTS_RELEASE or
> > something like that.
> >
> I'll just remove the comment for now.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Trouble specifying dts gpio-leds with GPIO expander chip
From: Anton Vorontsov @ 2009-12-21 21:55 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Linux/PPC Development
In-Reply-To: <4B2FCF40.3050204@billgatliff.com>
On Mon, Dec 21, 2009 at 01:40:48PM -0600, Bill Gatliff wrote:
[...]
> I'm stumped. Could it be that the startup code is trying to register
> the heartbeat device before it has registered the MAX7314, so it doesn't
> know yet that the GPIO line exists?
>
> Anyone have any suggestions?
drivers/gpio/pca953x.c doesn't register itself with the
OF GPIO infrastructure (plus the driver has an absolutely
bogus linux,gpio-base stuff, heh).
As an example of how to do the OF GPIO properly, see
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c:mcu_gpiochip_add().
Though, soon there will be an easier way to register I2C/SPI chips
with the OF GPIO infrastructure.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox