* Re: [PATCH] powerpc: print cores passed to firmware in decimal
From: Michael Neuling @ 2010-07-23 1:44 UTC (permalink / raw)
To: Jesse Larrew, benh; +Cc: linuxppc-dev
In-Reply-To: <4C48B36E.6040505@linux.vnet.ibm.com>
Currently we look pretty stupid when printing out the number of cores
passed to FW
Max number of cores passed to firmware: 0x0000000000000080
So I've change this to print in decimal:
Max number of cores passed to firmware: 128 (NR_CPUS = 256)
This required adding a prom_print_dec() function.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
> > cores = (u32 *)PTRRELOC(&ibm_architecture_vec[IBM_ARCH_VEC_NRCO
RES_OFFSET]);
> > if (*cores != NR_CPUS) {
> > prom_printf("WARNING ! "
> > - "ibm_architecture_vec structure inconsisten
t: 0x%x !\n",
> > + "ibm_architecture_vec structure inconsisten
t: 0x%i !\n",
> > *cores);
> >
>
> Since we're changing from hex to decimal, we shouldn't print the "0x".
Oops yes. Thanks!
BTW please CC me directly rather than sending only to the list.
arch/powerpc/kernel/prom_init.c | 35 ++++++++++++++++++++++++++++++++---
1 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 3b6f8ae..28b9116 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -311,6 +311,27 @@ static void __init prom_print_hex(unsigned long val)
call_prom("write", 3, 1, _prom->stdout, buf, nibbles);
}
+/* max number of decimal digits in an unsigned long */
+#define UL_DIGITS 21
+static void __init prom_print_dec(unsigned long val)
+{
+ int i, size;
+ char buf[UL_DIGITS+1];
+ struct prom_t *_prom = &RELOC(prom);
+
+ for (i = UL_DIGITS-1; i >= 0; i--) {
+ buf[i] = (val % 10) + '0';
+ val = val/10;
+ if (val == 0)
+ break;
+ }
+ /* shift stuff down */
+ size = UL_DIGITS - i;
+ for (i = 0 ; i < size ; i++)
+ buf[i] = buf[i + UL_DIGITS - size];
+ buf[size+1] = '\0';
+ call_prom("write", 3, 1, _prom->stdout, buf, size);
+}
static void __init prom_printf(const char *format, ...)
{
@@ -350,6 +371,14 @@ static void __init prom_printf(const char *format, ...)
v = va_arg(args, unsigned long);
prom_print_hex(v);
break;
+ case 'l':
+ ++q;
+ if (*q == 'u') { /* '%lu' */
+ ++q;
+ v = va_arg(args, unsigned long);
+ prom_print_dec(v);
+ }
+ break;
}
}
}
@@ -869,12 +898,12 @@ static void __init prom_send_capabilities(void)
cores = (u32 *)PTRRELOC(&ibm_architecture_vec[IBM_ARCH_VEC_NRCORES_OFFSET]);
if (*cores != NR_CPUS) {
prom_printf("WARNING ! "
- "ibm_architecture_vec structure inconsistent: 0x%x !\n",
+ "ibm_architecture_vec structure inconsistent: %lu !\n",
*cores);
} else {
*cores = DIV_ROUND_UP(NR_CPUS, prom_count_smt_threads());
- prom_printf("Max number of cores passed to firmware: 0x%x\n",
- (unsigned long)*cores);
+ prom_printf("Max number of cores passed to firmware: %lu (NR_CPUS = %lu)\n",
+ *cores, NR_CPUS);
}
/* try calling the ibm,client-architecture-support method */
^ permalink raw reply related
* Re: linux-next: OOPS at bot time
From: Michael Ellerman @ 2010-07-23 2:05 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Stephen Rothwell, ppc-dev, LKML, Jesse Barnes
In-Reply-To: <1279847985.4883.391.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]
On Fri, 2010-07-23 at 02:19 +0100, Ben Hutchings wrote:
> On Fri, 2010-07-23 at 10:22 +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > My Power7 boot test paniced like this: (next-20100722)
> >
> > %GQLogic Fibre Channel HBA Driver: 8.03.03-k0
> > qla2xxx 0002:01:00.2: enabling device (0144 -> 0146)
> > qla2xxx 0002:01:00.2: Found an ISP8001, irq 35, iobase 0xd000080080014000
> > ------------[ cut here ]------------
> > kernel BUG at drivers/pci/msi.c:205!
> [...]
> > Call Trace:
> > [c00000000278b270] [c000000000048d9c] .rtas_setup_msi_irqs+0x1d8/0x254 (unreliable)
> > [c00000000278b360] [c00000000002a9cc] .arch_setup_msi_irqs+0x34/0x4c
> > [c00000000278b3e0] [c0000000002fd3fc] .pci_enable_msix+0x49c/0x4ac
> [...]
> > That line number is this:
> >
> > BUG_ON(!(entry->msg.address_hi | entry->msg.address_lo |
> > entry->msg.data));
> >
> > in read_msi_msg_desc(). That BUG_ON was added by commit
> > 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 ("PCI: MSI: Remove unsafe and
> > unnecessary hardware access") from the pci tree.
>
> I wanted to assert that read_msi_msg_desc() is only used to update
> MSI/MSI-X descriptors that have already been generated by Linux. It
> looks like you found an exception.
>
> We could make read_msi_msg() fall back to reading from the hardware, but
> I think that what the pSeries code is trying to do - save an MSI message
> generated by firmware - is different from what the other callers want.
> Instead we could add:
>
> void save_msi_msg(unsigned int irq)
> {
> struct irq_desc *desc = irq_to_desc(irq);
> struct msi_desc *entry = get_irq_desc_msi(desc);
> struct msi_msg *msg = &entry->msg;
>
> /* ...followed by the old implementation of read_msi_msg_desc() */
> }
>
> Possibly conditional on something like CONFIG_ARCH_NEEDS_SAVE_MSI_MSG.
Maybe.
But then you end up with read_msi_msg(), which doesn't actually read
anything, which I think is confusing. I'd rather read_msi_msg() read the
message, from the device, and we have another routine which returns the
previously saved msg from the msi_desc.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 1/1] Added PowerMac10,2 device descriptor
From: Mark Crichton @ 2010-07-23 2:40 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Small patch to recognize the Mac Mini's that were quietly rolled out
~2005. Work needs to
be done on the WOL (Radeon and network card).
Signed-off-by: Mark Crichton <crichton@gmail.com>
---
arch/powerpc/platforms/powermac/feature.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/feature.c
b/arch/powerpc/platforms/powermac/feature.c
index 9e1b9fd..fa90384 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2191,6 +2191,10 @@ static struct pmac_mb_def pmac_mb_defs[] = {
PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
PMAC_MB_MAY_SLEEP,
},
+ { "PowerMac10,2", "Mac mini (Late 2005)",
+ PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
+ PMAC_MB_MAY_SLEEP,
+ },
{ "iMac,1", "iMac (first generation)",
PMAC_TYPE_ORIG_IMAC, paddington_features,
0
--
1.7.1
^ permalink raw reply related
* [PATCH] powerpc: ONLINE to OFFLINE CPU state transition during removal
From: Robert Jennings @ 2010-07-23 2:43 UTC (permalink / raw)
To: Nathan Fontenot, Benjamin Herrenschmidt, Paul Mackerras,
Gautham R Shenoy, Julia Lawall, Vaidyanathan Srinivasan,
linuxppc-dev
If a CPU remove is attempted using the 'release' interface on hardware
which supports extended cede, the CPU will be put in the INACTIVE state
rather than the OFFLINE state due to the default preferred_offline_state
in that situation. In the INACTIVE state it will fail to be removed.
This patch changes the preferred offline state to OFFLINE when an CPU is
in the ONLINE state. After cpu_down() is called in dlpar_offline_cpu()
the CPU will be OFFLINE and CPU removal can continue.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index d71e585..227c1c3 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -463,6 +463,7 @@ static int dlpar_offline_cpu(struct device_node *dn)
break;
if (get_cpu_current_state(cpu) == CPU_STATE_ONLINE) {
+ set_preferred_offline_state(cpu, CPU_STATE_OFFLINE);
cpu_maps_update_done();
rc = cpu_down(cpu);
if (rc)
^ permalink raw reply related
* Re: [PATCH] fix of_flat_dt_is_compatible to match the full compatible string
From: Benjamin Herrenschmidt @ 2010-07-23 2:45 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev
In-Reply-To: <1279841330-28695-1-git-send-email-stuart.yoder@freescale.com>
On Thu, 2010-07-22 at 18:28 -0500, Stuart Yoder wrote:
> From: Stuart Yoder <stuart.yoder@freescale.com>
>
> With the previous string comparison, a device tree
> compatible of "foo-bar" would match as compatible
> with a driver looking for "foo".
>
> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
Beware you are doing two changes in one here and only documenting one...
You also removed the case insenstivity.
Now, those things are supposed to be case sensitive afaik, but we have
enough legacy HW with more/less crap DTs and I'd be careful with
changing that without a good reason (ie, it breaks not to do it ?).
No objection with fixing the partial match tho.
Cheers,
Ben.
> ---
> drivers/of/fdt.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index dee4fb5..f5239c0 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -169,7 +169,7 @@ int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
> if (cp == NULL)
> return 0;
> while (cplen > 0) {
> - if (strncasecmp(cp, compat, strlen(compat)) == 0)
> + if (!strcmp(cp, compat))
> return 1;
> l = strlen(cp) + 1;
> cp += l;
^ permalink raw reply
* Re: [PATCH 3/5] powerpc/mm: Fix bugs in huge page hashing
From: Benjamin Herrenschmidt @ 2010-07-23 3:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1279845704-14848-3-git-send-email-benh@kernel.crashing.org>
On Fri, 2010-07-23 at 10:41 +1000, Benjamin Herrenschmidt wrote:
> There's a couple of nasty bugs lurking in our huge page hashing code.
>
> First, we don't check the access permission atomically with setting
> the _PAGE_BUSY bit, which means that the PTE value we end up using
> for the hashing might be different than the one we have checked
> the access permissions for.
>
> We've seen cases where that leads us to try to use an invalidated
> PTE for hashing, causing all sort of "interesting" issues.
>
> Then, we also failed to set _PAGE_DIRTY on a write access.
>
> This fixes both, while also simplifying the code a bit.
The changeset lacks a comment about a change to the return value
when hitting _PAGE_BUSY and ...
> do {
> old_pte = pte_val(*ptep);
> - if (old_pte & _PAGE_BUSY)
> - goto out;
> + /* If PTE busy, retry the access */
> + if (unlikely(old_pte & _PAGE_BUSY))
> + return 0;
> + /* If PTE permissions don't match, take page fault */
> + if (unlikely(access & ~pte_val(*ptep)))
> + return 1;
old_pte will do just fine instead of reloading it
Thanks Michael !
I'll respin that one.
Cheers,
Ben.
> + /* Try to lock the PTE, add ACCESSED and DIRTY if it was
> + * a write access */
> new_pte = old_pte | _PAGE_BUSY | _PAGE_ACCESSED;
> + if (access & _PAGE_RW)
> + new_pte |= _PAGE_DIRTY;
> } while(old_pte != __cmpxchg_u64((unsigned long *)ptep,
> old_pte, new_pte));
>
> @@ -127,8 +127,7 @@ repeat:
> */
> if (unlikely(slot == -2)) {
> *ptep = __pte(old_pte);
> - err = -1;
> - goto out;
> + return -1;
> }
>
> new_pte |= (slot << 12) & (_PAGE_F_SECOND | _PAGE_F_GIX);
> @@ -138,9 +137,5 @@ repeat:
> * No need to use ldarx/stdcx here
> */
> *ptep = __pte(new_pte & ~_PAGE_BUSY);
> -
> - err = 0;
> -
> - out:
> - return err;
> + return 0;
> }
^ permalink raw reply
* [PATCH 3/5 v2] powerpc/mm: Fix bugs in huge page hashing
From: Benjamin Herrenschmidt @ 2010-07-23 3:04 UTC (permalink / raw)
To: linuxppc-dev
There's a couple of nasty bugs lurking in our huge page hashing code.
First, we don't check the access permission atomically with setting
the _PAGE_BUSY bit, which means that the PTE value we end up using
for the hashing might be different than the one we have checked
the access permissions for.
We've seen cases where that leads us to try to use an invalidated
PTE for hashing, causing all sort of "interesting" issues.
Then, we also failed to set _PAGE_DIRTY on a write access.
Finally, a minor tweak but we should return 0 when we find the
PTE busy, in order to just re-execute the access, rather than 1
which means going to do_page_fault().
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/mm/hugetlbpage-hash64.c | 31 +++++++++++++------------------
1 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c b/arch/powerpc/mm/hugetlbpage-hash64.c
index c9acd79..faae9ec 100644
--- a/arch/powerpc/mm/hugetlbpage-hash64.c
+++ b/arch/powerpc/mm/hugetlbpage-hash64.c
@@ -21,21 +21,13 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
unsigned long old_pte, new_pte;
unsigned long va, rflags, pa, sz;
long slot;
- int err = 1;
BUG_ON(shift != mmu_psize_defs[mmu_psize].shift);
/* Search the Linux page table for a match with va */
va = hpt_va(ea, vsid, ssize);
- /*
- * Check the user's access rights to the page. If access should be
- * prevented then send the problem up to do_page_fault.
- */
- if (unlikely(access & ~pte_val(*ptep)))
- goto out;
- /*
- * At this point, we have a pte (old_pte) which can be used to build
+ /* At this point, we have a pte (old_pte) which can be used to build
* or update an HPTE. There are 2 cases:
*
* 1. There is a valid (present) pte with no associated HPTE (this is
@@ -49,9 +41,17 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
do {
old_pte = pte_val(*ptep);
- if (old_pte & _PAGE_BUSY)
- goto out;
+ /* If PTE busy, retry the access */
+ if (unlikely(old_pte & _PAGE_BUSY))
+ return 0;
+ /* If PTE permissions don't match, take page fault */
+ if (unlikely(access & ~old_pte))
+ return 1;
+ /* Try to lock the PTE, add ACCESSED and DIRTY if it was
+ * a write access */
new_pte = old_pte | _PAGE_BUSY | _PAGE_ACCESSED;
+ if (access & _PAGE_RW)
+ new_pte |= _PAGE_DIRTY;
} while(old_pte != __cmpxchg_u64((unsigned long *)ptep,
old_pte, new_pte));
@@ -127,8 +127,7 @@ repeat:
*/
if (unlikely(slot == -2)) {
*ptep = __pte(old_pte);
- err = -1;
- goto out;
+ return -1;
}
new_pte |= (slot << 12) & (_PAGE_F_SECOND | _PAGE_F_GIX);
@@ -138,9 +137,5 @@ repeat:
* No need to use ldarx/stdcx here
*/
*ptep = __pte(new_pte & ~_PAGE_BUSY);
-
- err = 0;
-
- out:
- return err;
+ return 0;
}
^ permalink raw reply related
* Re: [PATCH] powerpc: ONLINE to OFFLINE CPU state transition during removal
From: Vaidyanathan Srinivasan @ 2010-07-23 4:13 UTC (permalink / raw)
To: Robert Jennings, Nathan Fontenot, Benjamin Herrenschmidt,
Paul Mackerras, Gautham R Shenoy, Julia Lawall, linuxppc-dev
In-Reply-To: <20100723024343.GC32534@linux.vnet.ibm.com>
* Robert Jennings <rcj@linux.vnet.ibm.com> [2010-07-22 21:43:44]:
> If a CPU remove is attempted using the 'release' interface on hardware
> which supports extended cede, the CPU will be put in the INACTIVE state
> rather than the OFFLINE state due to the default preferred_offline_state
> in that situation. In the INACTIVE state it will fail to be removed.
>
> This patch changes the preferred offline state to OFFLINE when an CPU is
> in the ONLINE state. After cpu_down() is called in dlpar_offline_cpu()
> the CPU will be OFFLINE and CPU removal can continue.
Hi Robert,
Thanks for the patch. In dlpar operation, we would offline the CPU
first using the sysfs online file and then write to the sysfs release
file to complete the sequence right? The current code in
dlpar_offline_cpu() would work as long as the cpu is in either
inactive state or offline state (in case of unsupported platform).
Is the dlpar tools being changed to complete the operation with one
sysfs write to release file?
> Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
>
> ---
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
> index d71e585..227c1c3 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -463,6 +463,7 @@ static int dlpar_offline_cpu(struct device_node *dn)
> break;
>
> if (get_cpu_current_state(cpu) == CPU_STATE_ONLINE) {
> + set_preferred_offline_state(cpu, CPU_STATE_OFFLINE);
> cpu_maps_update_done();
> rc = cpu_down(cpu);
> if (rc)
The patch looks good. Will need to test out the various scenarios so
that the preferred_offline_state do not get flipped before cpu_down()
is called. This is unlikely, but still we need to validate
a concurrent sysfs online file write and sysfs release file write.
--Vaidy
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-07-23 4:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: linuxppc-dev list, Andrew Morton, Russell King, Linux Kernel list
Hi Linus !
Here's a few things for 2.6.35.
One's a fallover from the lmb->memblock rename that I missed, which causes
a bunch of pseries machine to boot with 128M of memory and that's it :-)
There's a few patches fixing a nasty race we found in our hugepage code,
a kexec fix from Kumar, and an .lds fix from Sam for a bug that as far
as we know only affects powerpc.
Cheers,
Ben.
The following changes since commit b37fa16e78d6f9790462b3181602a26b5af36260:
Linus Torvalds (1):
Linux 2.6.35-rc6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Blanchard (1):
powerpc/mm: Handle hypervisor pte insert failure in __hash_page_huge
Benjamin Herrenschmidt (5):
powerpc/mm: Move around testing of _PAGE_PRESENT in hash code
powerpc/mm: Fix bugs in huge page hashing
powerpc/mm: Add some debug output when hash insertion fails
powerpc: Fix erroneous lmb->memblock conversions
Merge commit 'kumar/merge' into merge
Kumar Gala (1):
powerpc/kexec: Fix boundary case for book-e kexec memory limits
Sam Ravnborg (1):
vmlinux.lds: fix .data..init_task output section (fix popwerpc boot)
arch/powerpc/include/asm/kexec.h | 6 +-
arch/powerpc/include/asm/mmu-hash64.h | 4 +-
arch/powerpc/kernel/prom.c | 2 +-
arch/powerpc/mm/hash_low_64.S | 9 ----
arch/powerpc/mm/hash_utils_64.c | 53 +++++++++++++++++------
arch/powerpc/mm/hugetlbpage-hash64.c | 40 +++++++++--------
arch/powerpc/mm/numa.c | 24 +++++-----
arch/powerpc/platforms/pseries/hotplug-memory.c | 22 +++++-----
include/asm-generic/vmlinux.lds.h | 2 +-
9 files changed, 93 insertions(+), 69 deletions(-)
^ permalink raw reply
* RE: [PATCH] RapidIO,powerpc/85xx: remove MCSR_MASK in fsl_rio
From: Li Yang-R58472 @ 2010-07-23 3:59 UTC (permalink / raw)
To: Kumar Gala, Alexandre Bounine, akpm, linux-kernel, linuxppc-dev
In-Reply-To: <1279730810-24926-1-git-send-email-alexandre.bounine@idt.com>
>Subject: [PATCH] RapidIO,powerpc/85xx: remove MCSR_MASK in fsl_rio
>
>Fixes compile problem caused by MCSR_MASK removal from book-E =
definitions.
Hi Alex,
Only with your patch, there will still be problem on SRIO platforms =
other than MPC85xx.
I have posted a patch series to fix this together with several =
compatibility issues a month before.
http://patchwork.ozlabs.org/patch/56135/
http://patchwork.ozlabs.org/patch/56136/
http://patchwork.ozlabs.org/patch/56138/
http://patchwork.ozlabs.org/patch/56137/
Can anyone pick the patch series quickly as currently there is a compile =
error when SRIO is enabled.
- Leo
>
>Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
>Cc: Kumar Gala <galak@kernel.crashing.org>
>Cc: Grant Likely <grant.likely@secretlab.ca>
>Cc: Matt Porter <mporter@kernel.crashing.org>
>---
> arch/powerpc/sysdev/fsl_rio.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/arch/powerpc/sysdev/fsl_rio.c =
b/arch/powerpc/sysdev/fsl_rio.c
>index 30e1626..c58df58 100644
>--- a/arch/powerpc/sysdev/fsl_rio.c
>+++ b/arch/powerpc/sysdev/fsl_rio.c
>@@ -245,7 +245,7 @@ static int (*saved_mcheck_exception)(struct pt_regs
>*regs); static int fsl_rio_mcheck_exception(struct pt_regs *regs) {
> const struct exception_table_entry *entry =3D NULL;
>- unsigned long reason =3D (mfspr(SPRN_MCSR) & MCSR_MASK);
>+ unsigned long reason =3D mfspr(SPRN_MCSR);
>
> if (reason & MCSR_BUS_RBERR) {
> reason =3D in_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR));
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Darren Hart @ 2010-07-23 4:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <4C48DADE.1050409@us.ibm.com>
On 07/22/2010 04:57 PM, Darren Hart wrote:
> On 07/22/2010 03:25 PM, Benjamin Herrenschmidt wrote:
>> On Thu, 2010-07-22 at 11:24 -0700, Darren Hart wrote:
>>>
>>> 1) How can the preempt_count() get mangled across the H_CEDE hcall?
>>> 2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?
>>
>> The preempt count is on the thread info at the bottom of the stack.
>>
>> Can you check the stack pointers ?
>
> Hi Ben, thanks for looking.
>
> I instrumented the area around extended_cede_processor() as follows
> (please confirm I'm getting the stack pointer correctly).
>
> while (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
> asm("mr %0,1" : "=r" (sp));
> printk("before H_CEDE current->stack: %lx, pcnt: %x\n", sp, preempt_count());
> extended_cede_processor(cede_latency_hint);
> asm("mr %0,1" : "=r" (sp));
> printk("after H_CEDE current->stack: %lx, pcnt: %x\n", sp, preempt_count());
> }
>
>
> On Mainline (2.6.33.6, CONFIG_PREEMPT=y) I see this:
> Jul 22 18:37:08 igoort1 kernel: before H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
> Jul 22 18:37:08 igoort1 kernel: after H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
>
> This surprised me as preempt_count is 1 before and after, so no
> corruption appears to occur on mainline. This makes the pcnt of 65 I see
> without the preempt_count()=0 hack very strange. I ran several hundred
> off/on cycles. The issue of preempt_count being 1 is still addressed by
> this patch however.
>
> On PREEMPT_RT (2.6.33.5-rt23 - tglx, sorry, rt/2.6.33 next time, promise):
> Jul 22 18:51:11 igoort1 kernel: before H_CEDE current->stack: c000000089bcfcf0, pcnt: 1
> Jul 22 18:51:11 igoort1 kernel: after H_CEDE current->stack: c000000089bcfcf0, pcnt: ffffffff
>
> In both cases the stack pointer appears unchanged.
>
> Note: there is a BUG triggered in between these statements as the
> preempt_count causes the printk to trigger:
> Badness at kernel/sched.c:5572
At Steven's suggestion I updated the instrumentation to display the
local_save_flags and irqs_disabled_flags:
while (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
local_save_flags(flags);
printk("local flags: %lx, irqs disabled: %d\n", flags, irqs_disabled_flags(flags));
asm("mr %0,1" : "=r" (sp));
printk("before H_CEDE current->stack: %lx, pcnt: %x\n", sp, preempt_count());
extended_cede_processor(cede_latency_hint);
asm("mr %0,1" : "=r" (sp));
printk("after H_CEDE current->stack: %lx, pcnt: %x\n", sp, preempt_count());
}
Jul 22 23:36:58 igoort1 kernel: local flags: 0, irqs disabled: 1
Jul 22 23:36:58 igoort1 kernel: before H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
Jul 22 23:36:58 igoort1 kernel: after H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
I'm not sure if I'm reading that right, but I believe interrupts are
intended to be disabled here. If accomplished via the
spin_lock_irqsave() this would behave differently on RT. However, this
path disables the interrupts handled by xics, all but the IPIs anyway.
On RT I disabled the decrementer as well.
Is it possible for RT to be receiving other interrupts here?
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Vaidyanathan Srinivasan @ 2010-07-23 5:08 UTC (permalink / raw)
To: Darren Hart
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <4C491E14.9010100@us.ibm.com>
* Darren Hart <dvhltc@us.ibm.com> [2010-07-22 21:44:04]:
> On 07/22/2010 04:57 PM, Darren Hart wrote:
> > On 07/22/2010 03:25 PM, Benjamin Herrenschmidt wrote:
> >> On Thu, 2010-07-22 at 11:24 -0700, Darren Hart wrote:
> >>>
> >>> 1) How can the preempt_count() get mangled across the H_CEDE hcall?
> >>> 2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?
> >>
> >> The preempt count is on the thread info at the bottom of the stack.
> >>
> >> Can you check the stack pointers ?
> >
> > Hi Ben, thanks for looking.
> >
> > I instrumented the area around extended_cede_processor() as follows
> > (please confirm I'm getting the stack pointer correctly).
> >
> > while (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
> > asm("mr %0,1" : "=r" (sp));
> > printk("before H_CEDE current->stack: %lx, pcnt: %x\n", sp, preempt_count());
> > extended_cede_processor(cede_latency_hint);
> > asm("mr %0,1" : "=r" (sp));
> > printk("after H_CEDE current->stack: %lx, pcnt: %x\n", sp, preempt_count());
> > }
> >
> >
> > On Mainline (2.6.33.6, CONFIG_PREEMPT=y) I see this:
> > Jul 22 18:37:08 igoort1 kernel: before H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
> > Jul 22 18:37:08 igoort1 kernel: after H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
> >
> > This surprised me as preempt_count is 1 before and after, so no
> > corruption appears to occur on mainline. This makes the pcnt of 65 I see
> > without the preempt_count()=0 hack very strange. I ran several hundred
> > off/on cycles. The issue of preempt_count being 1 is still addressed by
> > this patch however.
> >
> > On PREEMPT_RT (2.6.33.5-rt23 - tglx, sorry, rt/2.6.33 next time, promise):
> > Jul 22 18:51:11 igoort1 kernel: before H_CEDE current->stack: c000000089bcfcf0, pcnt: 1
> > Jul 22 18:51:11 igoort1 kernel: after H_CEDE current->stack: c000000089bcfcf0, pcnt: ffffffff
> >
> > In both cases the stack pointer appears unchanged.
> >
> > Note: there is a BUG triggered in between these statements as the
> > preempt_count causes the printk to trigger:
> > Badness at kernel/sched.c:5572
>
> At Steven's suggestion I updated the instrumentation to display the
> local_save_flags and irqs_disabled_flags:
>
> while (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
> local_save_flags(flags);
> printk("local flags: %lx, irqs disabled: %d\n", flags, irqs_disabled_flags(flags));
> asm("mr %0,1" : "=r" (sp));
> printk("before H_CEDE current->stack: %lx, pcnt: %x\n", sp, preempt_count());
> extended_cede_processor(cede_latency_hint);
> asm("mr %0,1" : "=r" (sp));
> printk("after H_CEDE current->stack: %lx, pcnt: %x\n", sp, preempt_count());
> }
>
>
> Jul 22 23:36:58 igoort1 kernel: local flags: 0, irqs disabled: 1
> Jul 22 23:36:58 igoort1 kernel: before H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
> Jul 22 23:36:58 igoort1 kernel: after H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
>
> I'm not sure if I'm reading that right, but I believe interrupts are
> intended to be disabled here. If accomplished via the
> spin_lock_irqsave() this would behave differently on RT. However, this
> path disables the interrupts handled by xics, all but the IPIs anyway.
> On RT I disabled the decrementer as well.
>
> Is it possible for RT to be receiving other interrupts here?
Yes. extended_cede_processor() will return with interrupts enabled in
the cpu. (This is done by the hypervisor). Under normal cases we
cannot be interrupted because no IO interrupts are routed to us after
xics_teardown_cpu() and since the CPU is out of the map, nobody will
send us IPIs.
Though H_CEDE will return with interrupts enabled, it is unlikely that
an interrupt can be delivered in this context.
--Vaidy
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Benjamin Herrenschmidt @ 2010-07-23 5:09 UTC (permalink / raw)
To: Darren Hart
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <4C491E14.9010100@us.ibm.com>
On Thu, 2010-07-22 at 21:44 -0700, Darren Hart wrote:
> suggestion I updated the instrumentation to display the
> local_save_flags and irqs_disabled_flags:
> Jul 22 23:36:58 igoort1 kernel: local flags: 0, irqs disabled: 1
> Jul 22 23:36:58 igoort1 kernel: before H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
> Jul 22 23:36:58 igoort1 kernel: after H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
>
> I'm not sure if I'm reading that right, but I believe interrupts are
> intended to be disabled here. If accomplished via the
> spin_lock_irqsave() this would behave differently on RT. However, this
> path disables the interrupts handled by xics, all but the IPIs anyway.
> On RT I disabled the decrementer as well.
>
> Is it possible for RT to be receiving other interrupts here?
Also you may want to call hard_irq_disable() to -really- disable
interrupts ... since we do lazy-disable on powerpc
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Benjamin Herrenschmidt @ 2010-07-23 5:11 UTC (permalink / raw)
To: svaidy
Cc: Stephen Rothwell, Darren Hart, Gautham R Shenoy, Steven Rostedt,
linuxppc-dev, Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <20100723050814.GA26162@dirshya.in.ibm.com>
On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote:
> Yes. extended_cede_processor() will return with interrupts enabled in
> the cpu. (This is done by the hypervisor). Under normal cases we
> cannot be interrupted because no IO interrupts are routed to us after
> xics_teardown_cpu() and since the CPU is out of the map, nobody will
> send us IPIs.
What about decrementer ?
> Though H_CEDE will return with interrupts enabled, it is unlikely that
> an interrupt can be delivered in this context.
Well, if interrupts are soft-disabled, even if one occurs, we will just
mask and return, so that at least should be ok.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/4] of/device: Replace of_device with platform_device in includes and core code
From: David Miller @ 2010-07-23 5:50 UTC (permalink / raw)
To: grant.likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux
In-Reply-To: <20100722223006.21557.84275.stgit@angua>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Thu, 22 Jul 2010 16:30:06 -0600
> of_device is currently just an #define alias to platform_device until it
> gets removed entirely. This patch removes references to it from the
> include directories and the core drivers/of code.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 3/4] sparc: remove references to of_device and to_of_device
From: David Miller @ 2010-07-23 5:51 UTC (permalink / raw)
To: grant.likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux
In-Reply-To: <20100722223016.21557.40832.stgit@angua>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Thu, 22 Jul 2010 16:30:16 -0600
> of_device is just a #define alias to platform_device. This patch
> replaces all references to it with platform_device.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] Adding ADMA support for PPC460EX DMA engine.
From: Stefan Roese @ 2010-07-23 6:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-raid, dan.j.williams, linux-crypto, tmarri
In-Reply-To: <1279846638-22323-1-git-send-email-tmarri@amcc.com>
Hi Marri,
On Friday 23 July 2010 02:57:18 tmarri@amcc.com wrote:
> From: Tirumala Marri <tmarri@amcc.com>
>
> This patch will add ADMA support for DMA engine and HW offload for
> XOR/ADG (RAID-5/6) functionalities.
> 1. It supports memcpy, xor, GF(2) based RAID-6.
> 2. It supports interrupt based DMA completions.
> 3. Also supports memcpy in RAID-1 case.
>
> Kernel version: 2.6.35-rc5
>
> Testing:
> Created RAID-5/6 arrays usign mdadm.
> And ran raw IO and filesystem IO to the RAID array.
> Chunk size 4k,64k was tested.
> RAID rebuild , disk fail, resync tested.
>
> File names:
> This code is similar to ppc440spe . So I named the files as
> drivers/dma/ppc4xx/adma1.c and drivers/dma/ppc4xx/adma1.h
As you describe above, a lot of the code seems to be copied from
drivers/dma/ppc4xx/adma.c/h. Wouldn't it make more sense to factor out the
common code instead of duplicating it?
Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Where can I get help about crosstool commands on powerpc?
From: Judy @ 2010-07-23 7:05 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
I've just installed crosstool 0.43 for powerpc 405, and got the following
commands:
powerpc-405-linux-gnu-ar
powerpc-405-linux-gnu-as
powerpc-405-linux-gnu-c++
powerpc-405-linux-gnu-c++filt
powerpc-405-linux-gnu-cpp
powerpc-405-linux-gnu-g++
powerpc-405-linux-gnu-gcc
powerpc-405-linux-gnu-gcc-4.1.0
powerpc-405-linux-gnu-gccbug
powerpc-405-linux-gnu-gcov
powerpc-405-linux-gnu-gprof
powerpc-405-linux-gnu-ld
powerpc-405-linux-gnu-nm
powerpc-405-linux-gnu-objcopy
powerpc-405-linux-gnu-objdump
powerpc-405-linux-gnu-ranlib
powerpc-405-linux-gnu-readelf
powerpc-405-linux-gnu-size
powerpc-405-linux-gnu-strings
powerpc-405-linux-gnu-strip
I'm quite confused by the usage of these commands. I wanna know how to use
them. I've searched the man directories and help doc, but found little
information. Where can I get some help in detail?
Thanks
[-- Attachment #2: Type: text/html, Size: 5766 bytes --]
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Vaidyanathan Srinivasan @ 2010-07-23 7:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Darren Hart, Gautham R Shenoy, Steven Rostedt,
linuxppc-dev, Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <1279861860.1970.74.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> [2010-07-23 15:11:00]:
> On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote:
> > Yes. extended_cede_processor() will return with interrupts enabled in
> > the cpu. (This is done by the hypervisor). Under normal cases we
> > cannot be interrupted because no IO interrupts are routed to us after
> > xics_teardown_cpu() and since the CPU is out of the map, nobody will
> > send us IPIs.
>
> What about decrementer ?
Decrementer expiry event handling is bit complex. The event as such
may not bring back the extended_cede_processor() cpu, but may be
marked pending when we get out of this state eventually. I will find
more information on this event and update.
> > Though H_CEDE will return with interrupts enabled, it is unlikely that
> > an interrupt can be delivered in this context.
>
> Well, if interrupts are soft-disabled, even if one occurs, we will just
> mask and return, so that at least should be ok.
Yes. We will immediately return to the extended_cede_processor() in
the while loop until the preferred_offline_state is changed.
--Vaidy
^ permalink raw reply
* [next-20100722] drivers/input/serio/i8042.ko undefined error & Bad Relocations warning
From: Subrata Modak @ 2010-07-23 10:15 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: sachinp, Stephen Rothwell, linux-kernel, Kamalesh Babulal,
Linuxppc-dev, linux-next, Paul Mackerras, divya.vikas
With linux-next-20100722 on Power7 and allmodconfig, i get the following
undefined error and Bad relocation warning:
ERROR: "of_i8042_kbd_irq" [drivers/input/serio/i8042.ko] undefined!
ERROR: "of_i8042_aux_irq" [drivers/input/serio/i8042.ko] undefined!
...
and
...
WARNING: 3 bad relocations
c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460
c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598
c000000000add890 R_PPC64_ADDR64 __crc_softirq_work_list
I reported the above on 2.6.35-rc5 alone few days back:
http://marc.info/?t=127919383300002&r=1&w=2,
However,
c000000000add890 R_PPC64_ADDR64 __crc_softirq_work_list
is newly seen apart from:
c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460
c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598
Regards--
Subrata
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Switch to a static PACA on the way out
From: Michael Ellerman @ 2010-07-23 13:12 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <4C358479.1090502@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
On Thu, 2010-07-08 at 17:55 +1000, Matt Evans wrote:
> With dynamic PACAs, the kexecing CPU's PACA won't lie within the kernel
> static data and there is a chance that something may stomp it when preparing
> to kexec. This patch switches this final CPU to a static PACA just before
> we pull the switch.
>
> Signed-off-by: Matt Evans <matt@ozlabs.org>
> ---
> v2: Changes from Milton's review:
> - Use setup_paca() and move from setup_64.c,
> - SLB cache inval. not required,
> - Adjust 'paca' (oops..), and
> - Poison data_offset/per_cpu_offset
>
> arch/powerpc/include/asm/paca.h | 2 +-
> arch/powerpc/kernel/machine_kexec_64.c | 20 ++++++++++++++++++++
> arch/powerpc/kernel/paca.c | 10 ++++++++++
> arch/powerpc/kernel/setup_64.c | 10 ----------
> 4 files changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index 8ce7963..1ff6662 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -146,7 +146,7 @@ struct paca_struct {
> extern struct paca_struct *paca;
> extern __initdata struct paca_struct boot_paca;
> extern void initialise_paca(struct paca_struct *new_paca, int cpu);
> -
> +extern void setup_paca(struct paca_struct *new_paca);
> extern void allocate_pacas(void);
> extern void free_unused_pacas(void);
>
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
> index 26f9900..c4d0123 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> @@ -273,6 +273,12 @@ static void kexec_prepare_cpus(void)
> static union thread_union kexec_stack __init_task_data =
> { };
>
> +/*
> + * For similar reasons to the stack above, the kexecing CPU needs to be on a
> + * static PACA; we switch to kexec_paca.
> + */
> +struct paca_struct kexec_paca;
> +
Hopelessly late probably but .. we could use boot_paca which already
exists and is static.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v3 2/2] powerpc/mpc5121: add initial support for PDM360NG board
From: Anatolij Gustschin @ 2010-07-23 13:49 UTC (permalink / raw)
To: linuxppc-dev
Cc: Detlev Zundel, Markus Fischer, devicetree-discuss, Michael Weiss,
Anatolij Gustschin, Wolfgang Grandegger
In-Reply-To: <1272882222-12253-1-git-send-email-agust@denx.de>
Adds IFM PDM360NG device tree, and platform code.
Currently following is supported:
- Spansion S29GL512P 256 MB NOR flash
- ST Micro NAND 1 GiB flash
- DIU, please use "fbcon=map:5 video=fslfb:800x480-32@60"
at the kernel command line to enable PrimeView PM070WL3
Display support.
- FEC
- I2C
- RTC, EEPROM
- MSCAN
- PSC UART, please pass "console=tty0 console=ttyPSC5,115200"
on the kernel command line.
- SPI, ADS7845 Touchscreen
- USB0/1 Host
- USB0 OTG Host/Device
- VIU, Overlay/Capture support
Signed-off-by: Markus Fischer <markus.fischer.ec@ifm.com>
Signed-off-by: Wolfgang Grandegger <wg@denx.de>
Signed-off-by: Michael Weiss <michael.weiss@ifm.com>
Signed-off-by: Detlev Zundel <dzu@denx.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Grant Likely <grant.likely@secretlab.ca>
---
v3:
- uncomment and correct .irq_flags field of touchscreen
platform data struct as proposed extension to this
data struct has been accepted and merged via input tree
a short while ago
v1 -> v2:
- fix interrupt-parent property in nfc node
- drop #address-cells in ipic node
- remove device_type from ethernet-phy sub-node
- remove device_type from ethernet node
- add aliases node for eth0, needed for MAC address
update by U-Boot
- removed spaces around &ipic
arch/powerpc/boot/dts/pdm360ng.dts | 432 ++++++++++++++++++++++++++++++++
arch/powerpc/platforms/512x/Kconfig | 7 +
arch/powerpc/platforms/512x/Makefile | 1 +
arch/powerpc/platforms/512x/pdm360ng.c | 158 ++++++++++++
4 files changed, 598 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/pdm360ng.dts
create mode 100644 arch/powerpc/platforms/512x/pdm360ng.c
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts b/arch/powerpc/boot/dts/pdm360ng.dts
new file mode 100644
index 0000000..7dc42e9
--- /dev/null
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -0,0 +1,432 @@
+/*
+ * Device Tree Source for IFM PDM360NG.
+ *
+ * Copyright 2009 - 2010 DENX Software Engineering.
+ * Anatolij Gustschin <agust@denx.de>
+ *
+ * Based on MPC5121E ADS dts.
+ * Copyright 2008 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "pdm360ng";
+ compatible = "ifm,pdm360ng";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,5121@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>; // L1, 32K
+ i-cache-size = <0x8000>; // L1, 32K
+ timebase-frequency = <49500000>;// 49.5 MHz (csb/4)
+ bus-frequency = <198000000>; // 198 MHz csb bus
+ clock-frequency = <396000000>; // 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>; // 512MB at 0
+ };
+
+ nfc@40000000 {
+ compatible = "fsl,mpc5121-nfc";
+ reg = <0x40000000 0x100000>;
+ interrupts = <0x6 0x8>;
+ interrupt-parent = <&ipic>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ bank-width = <0x1>;
+ chips = <0x1>;
+
+ partition@0 {
+ label = "nand0";
+ reg = <0x0 0x40000000>;
+ };
+ };
+
+ sram@50000000 {
+ compatible = "fsl,mpc5121-sram";
+ reg = <0x50000000 0x20000>; // 128K at 0x50000000
+ };
+
+ localbus@80000020 {
+ compatible = "fsl,mpc5121-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x80000020 0x40>;
+
+ ranges = <0x0 0x0 0xf0000000 0x10000000 /* Flash */
+ 0x2 0x0 0x50040000 0x00020000>; /* CS2: MRAM */
+
+ flash@0,0 {
+ compatible = "amd,s29gl01gp", "cfi-flash";
+ reg = <0 0x00000000 0x08000000
+ 0 0x08000000 0x08000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <4>;
+ device-width = <2>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x00000000 0x00080000>;
+ read-only;
+ };
+ partition@80000 {
+ label = "environment";
+ reg = <0x00080000 0x00080000>;
+ read-only;
+ };
+ partition@100000 {
+ label = "splash-image";
+ reg = <0x00100000 0x00080000>;
+ read-only;
+ };
+ partition@180000 {
+ label = "device-tree";
+ reg = <0x00180000 0x00040000>;
+ };
+ partition@1c0000 {
+ label = "kernel";
+ reg = <0x001c0000 0x00500000>;
+ };
+ partition@6c0000 {
+ label = "filesystem";
+ reg = <0x006c0000 0x07940000>;
+ };
+ };
+
+ mram0@2,0 {
+ compatible = "mtd-ram";
+ reg = <2 0x00000 0x10000>;
+ bank-width = <2>;
+ };
+
+ mram1@2,10000 {
+ compatible = "mtd-ram";
+ reg = <2 0x010000 0x10000>;
+ bank-width = <2>;
+ };
+ };
+
+ soc@80000000 {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x80000000 0x400000>;
+ reg = <0x80000000 0x400000>;
+ bus-frequency = <66000000>; // 66 MHz ips bus
+
+ // IPIC
+ // interrupts cell = <intr #, sense>
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: interrupt-controller@c00 {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ rtc@a00 { // Real time clock
+ compatible = "fsl,mpc5121-rtc";
+ reg = <0xa00 0x100>;
+ interrupts = <79 0x8 80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ reset@e00 { // Reset module
+ compatible = "fsl,mpc5121-reset";
+ reg = <0xe00 0x100>;
+ };
+
+ clock@f00 { // Clock control
+ compatible = "fsl,mpc5121-clock";
+ reg = <0xf00 0x100>;
+ };
+
+ pmc@1000{ //Power Management Controller
+ compatible = "fsl,mpc5121-pmc";
+ reg = <0x1000 0x100>;
+ interrupts = <83 0x2>;
+ interrupt-parent = <&ipic>;
+ };
+
+ gpio@1100 {
+ compatible = "fsl,mpc5121-gpio";
+ reg = <0x1100 0x100>;
+ interrupts = <78 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ can@1300 {
+ compatible = "fsl,mpc5121-mscan";
+ interrupts = <12 0x8>;
+ interrupt-parent = <&ipic>;
+ reg = <0x1300 0x80>;
+ };
+
+ can@1380 {
+ compatible = "fsl,mpc5121-mscan";
+ interrupts = <13 0x8>;
+ interrupt-parent = <&ipic>;
+ reg = <0x1380 0x80>;
+ };
+
+ i2c@1700 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c";
+ reg = <0x1700 0x20>;
+ interrupts = <0x9 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,preserve-clocking;
+
+ eeprom@50 {
+ compatible = "at,24c01";
+ reg = <0x50>;
+ };
+
+ rtc@68 {
+ compatible = "stm,m41t00";
+ reg = <0x68>;
+ };
+ };
+
+ i2c@1740 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c";
+ reg = <0x1740 0x20>;
+ interrupts = <0xb 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,preserve-clocking;
+ };
+
+ i2ccontrol@1760 {
+ compatible = "fsl,mpc5121-i2c-ctrl";
+ reg = <0x1760 0x8>;
+ };
+
+ axe@2000 {
+ compatible = "fsl,mpc5121-axe";
+ reg = <0x2000 0x100>;
+ interrupts = <42 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ display@2100 {
+ compatible = "fsl,mpc5121-diu";
+ reg = <0x2100 0x100>;
+ interrupts = <64 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ can@2300 {
+ compatible = "fsl,mpc5121-mscan";
+ interrupts = <90 0x8>;
+ interrupt-parent = <&ipic>;
+ reg = <0x2300 0x80>;
+ };
+
+ can@2380 {
+ compatible = "fsl,mpc5121-mscan";
+ interrupts = <91 0x8>;
+ interrupt-parent = <&ipic>;
+ reg = <0x2380 0x80>;
+ };
+
+ viu@2400 {
+ compatible = "fsl,mpc5121-viu";
+ reg = <0x2400 0x400>;
+ interrupts = <67 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ mdio@2800 {
+ compatible = "fsl,mpc5121-fec-mdio";
+ reg = <0x2800 0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy: ethernet-phy@0 {
+ reg = <0x1f>;
+ };
+ };
+
+ eth0: ethernet@2800 {
+ compatible = "fsl,mpc5121-fec";
+ reg = <0x2800 0x200>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <4 0x8>;
+ interrupt-parent = <&ipic>;
+ phy-handle = < &phy >;
+ };
+
+ // USB1 using external ULPI PHY
+ usb@3000 {
+ compatible = "fsl,mpc5121-usb2-dr";
+ reg = <0x3000 0x600>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&ipic>;
+ interrupts = <43 0x8>;
+ dr_mode = "host";
+ phy_type = "ulpi";
+ };
+
+ // USB0 using internal UTMI PHY
+ usb@4000 {
+ compatible = "fsl,mpc5121-usb2-dr";
+ reg = <0x4000 0x600>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&ipic>;
+ interrupts = <44 0x8>;
+ dr_mode = "otg";
+ phy_type = "utmi_wide";
+ fsl,invert-pwr-fault;
+ };
+
+ // IO control
+ ioctl@a000 {
+ compatible = "fsl,mpc5121-ioctl";
+ reg = <0xA000 0x1000>;
+ };
+
+ // 512x PSCs are not 52xx PSCs compatible
+ serial@11000 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <0>;
+ reg = <0x11000 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ serial@11100 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <1>;
+ reg = <0x11100 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ serial@11200 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <2>;
+ reg = <0x11200 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ serial@11300 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <3>;
+ reg = <0x11300 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ serial@11400 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <4>;
+ reg = <0x11400 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ serial@11600 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <6>;
+ reg = <0x11600 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ serial@11800 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <8>;
+ reg = <0x11800 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ serial@11B00 {
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ cell-index = <11>;
+ reg = <0x11B00 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ pscfifo@11f00 {
+ compatible = "fsl,mpc5121-psc-fifo";
+ reg = <0x11f00 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ spi@11900 {
+ compatible = "fsl,mpc5121-psc-spi", "fsl,mpc5121-psc";
+ cell-index = <9>;
+ reg = <0x11900 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = <&ipic>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+
+ // 7845 touch screen controller
+ ts@0 {
+ compatible = "ti,ads7845";
+ interrupt-parent = <&ipic>;
+ // pen irq is GPIO25
+ interrupts = <78 0x8>;
+ };
+ };
+
+ dma@14000 {
+ compatible = "fsl,mpc5121-dma";
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index e9dca28..27b0651 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -25,3 +25,10 @@ config MPC5121_GENERIC
Compatible boards include: Protonic LVT base boards (ZANMCU
and VICVT2).
+
+config PDM360NG
+ bool "ifm PDM360NG board"
+ depends on PPC_MPC512x
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the PDM360NG board.
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 90be2f5..4efc1c4 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -4,3 +4,4 @@
obj-y += clock.o mpc512x_shared.o
obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
obj-$(CONFIG_MPC5121_GENERIC) += mpc5121_generic.o
+obj-$(CONFIG_PDM360NG) += pdm360ng.o
diff --git a/arch/powerpc/platforms/512x/pdm360ng.c b/arch/powerpc/platforms/512x/pdm360ng.c
new file mode 100644
index 0000000..01e6023
--- /dev/null
+++ b/arch/powerpc/platforms/512x/pdm360ng.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (C) 2010 DENX Software Engineering
+ *
+ * Anatolij Gustschin, <agust@denx.de>
+ *
+ * PDM360NG board setup
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/of_platform.h>
+
+#include <asm/machdep.h>
+#include <asm/ipic.h>
+#include <asm/prom.h>
+
+#include "mpc512x.h"
+
+#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
+ defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
+#include <linux/fsl_devices.h>
+#include <linux/interrupt.h>
+#include <linux/spi/ads7846.h>
+#include <linux/spi/spi.h>
+
+static void *pdm360ng_gpio_base;
+
+static int pdm360ng_get_pendown_state(void)
+{
+ u32 reg;
+
+ reg = in_be32((u32 *)(pdm360ng_gpio_base + 0xc));
+ if (reg & 0x40)
+ setbits32((u32 *)(pdm360ng_gpio_base + 0xc), 0x40);
+
+ reg = in_be32((u32 *)(pdm360ng_gpio_base + 0x8));
+
+ /* return 1 if pen is down */
+ return reg & 0x40 ? 0 : 1;
+}
+
+static struct ads7846_platform_data pdm360ng_ads7846_pdata __initdata = {
+ .model = 7845,
+ .get_pendown_state = pdm360ng_get_pendown_state,
+ .irq_flags = IRQF_TRIGGER_LOW,
+};
+
+static int __init pdm360ng_penirq_init(void)
+{
+ struct device_node *np;
+ struct resource r;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-gpio");
+ if (!np) {
+ pr_err("%s: Can't find 'mpc5121-gpio' node\n", __func__);
+ return -1;
+ }
+
+ if (of_address_to_resource(np, 0, &r)) {
+ pr_err("%s: Invalid gpio address.\n", __func__);
+ of_node_put(np);
+ return -1;
+ }
+ of_node_put(np);
+
+ pdm360ng_gpio_base = ioremap(r.start, resource_size(&r));
+ if (!pdm360ng_gpio_base) {
+ pr_err("%s: Can't map gpio regs.\n", __func__);
+ return -1;
+ }
+ out_be32((u32 *)pdm360ng_gpio_base + 0xc, 0xffffffff);
+ setbits32((u32 *)(pdm360ng_gpio_base + 0x18), 0x2000);
+ setbits32((u32 *)(pdm360ng_gpio_base + 0x10), 0x40);
+
+ return 0;
+}
+
+static int __init pdm360ng_touchscreen_init(void)
+{
+ struct device_node *np;
+ struct of_device *of_dev;
+ struct spi_board_info info;
+ const u32 *prop;
+ int bus_num = -1;
+ int len;
+
+ np = of_find_compatible_node(NULL, NULL, "ti,ads7845");
+ if (!np)
+ return -ENODEV;
+
+ memset(&info, 0, sizeof(info));
+ info.irq = irq_of_parse_and_map(np, 0);
+ if (info.irq == NO_IRQ)
+ return -ENODEV;
+
+ info.platform_data = &pdm360ng_ads7846_pdata;
+ if (strlcpy(info.modalias, "ads7846",
+ SPI_NAME_SIZE) >= SPI_NAME_SIZE)
+ return -ENOMEM;
+
+ np = of_get_next_parent(np);
+ if (!np)
+ return -ENODEV;
+
+ prop = of_get_property(np, "cell-index", &len);
+ if (prop && len == 4)
+ bus_num = *prop;
+
+ if (bus_num < 0 || bus_num > 11)
+ return -ENODEV;
+
+ info.bus_num = bus_num;
+
+ of_dev = of_find_device_by_node(np);
+ of_node_put(np);
+ if (of_dev) {
+ struct fsl_spi_platform_data *pdata;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (pdata) {
+ pdata->bus_num = bus_num;
+ pdata->max_chipselect = 1;
+ of_dev->dev.platform_data = pdata;
+ }
+ }
+
+ if (pdm360ng_penirq_init())
+ return -ENODEV;
+
+ return spi_register_board_info(&info, 1);
+}
+machine_device_initcall(pdm360ng, pdm360ng_touchscreen_init);
+#endif
+
+static int __init pdm360ng_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "ifm,pdm360ng");
+}
+
+define_machine(pdm360ng) {
+ .name = "PDM360NG",
+ .probe = pdm360ng_probe,
+ .setup_arch = mpc512x_setup_diu,
+ .init = mpc512x_init,
+ .init_early = mpc512x_init_diu,
+ .init_IRQ = mpc512x_init_IRQ,
+ .get_irq = ipic_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+ .restart = mpc512x_restart,
+};
--
1.7.0.4
^ permalink raw reply related
* [PATCH] powerpc/mpc512x: add clock structure for Video-IN (VIU) unit
From: Anatolij Gustschin @ 2010-07-23 13:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin, Hongjun Chen
Allows using clk_get()/clk_enable()/clk_disable() for VIU
clock in the v4l2 video driver.
Signed-off-by: Hongjun Chen <hong-jun.chen@freescale.com>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/platforms/512x/clock.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c
index 4c42246..e1c5cd6 100644
--- a/arch/powerpc/platforms/512x/clock.c
+++ b/arch/powerpc/platforms/512x/clock.c
@@ -292,6 +292,15 @@ static void diu_clk_calc(struct clk *clk)
clk->rate = rate;
}
+static void viu_clk_calc(struct clk *clk)
+{
+ unsigned long rate;
+
+ rate = sys_clk.rate;
+ rate /= 2;
+ clk->rate = rate;
+}
+
static void half_clk_calc(struct clk *clk)
{
clk->rate = clk->parent->rate / 2;
@@ -412,6 +421,14 @@ static struct clk diu_clk = {
.calc = diu_clk_calc,
};
+static struct clk viu_clk = {
+ .name = "viu_clk",
+ .flags = CLK_HAS_CTRL,
+ .reg = 1,
+ .bit = 18,
+ .calc = viu_clk_calc,
+};
+
static struct clk axe_clk = {
.name = "axe_clk",
.flags = CLK_HAS_CTRL,
@@ -535,6 +552,7 @@ struct clk *rate_clks[] = {
&ref_clk,
&sys_clk,
&diu_clk,
+ &viu_clk,
&csb_clk,
&e300_clk,
&ips_clk,
--
1.7.0.4
^ permalink raw reply related
* [PATCH] PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
From: Ben Hutchings @ 2010-07-23 13:56 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Stephen Rothwell, ppc-dev, LKML, linux-pci
In-Reply-To: <1279850740.6381.19.camel@concordia>
commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove
unsafe and unnecessary hardware access" changed read_msi_msg_desc() to
return the last MSI message written instead of reading it from the
device, since it may be called while the device is in a reduced
power state.
However, the pSeries platform code really does need to read messages
from the device, since they are initially written by firmware.
Therefore:
- Restore the previous behaviour of read_msi_msg_desc()
- Add new functions get_cached_msi_msg{,_desc}() which return the
last MSI message written
- Use the new functions where appropriate
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Compile-tested only.
Ben.
arch/ia64/kernel/msi_ia64.c | 2 +-
arch/ia64/sn/kernel/msi_sn.c | 2 +-
arch/x86/kernel/apic/io_apic.c | 2 +-
drivers/pci/msi.c | 47 +++++++++++++++++++++++++++++++++++----
include/linux/msi.h | 2 +
5 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
index 6c89228..4a746ea 100644
--- a/arch/ia64/kernel/msi_ia64.c
+++ b/arch/ia64/kernel/msi_ia64.c
@@ -25,7 +25,7 @@ static int ia64_set_msi_irq_affinity(unsigned int irq,
if (irq_prepare_move(irq, cpu))
return -1;
- read_msi_msg(irq, &msg);
+ get_cached_msi_msg(irq, &msg);
addr = msg.address_lo;
addr &= MSI_ADDR_DEST_ID_MASK;
diff --git a/arch/ia64/sn/kernel/msi_sn.c b/arch/ia64/sn/kernel/msi_sn.c
index ebfdd6a..0c72dd4 100644
--- a/arch/ia64/sn/kernel/msi_sn.c
+++ b/arch/ia64/sn/kernel/msi_sn.c
@@ -175,7 +175,7 @@ static int sn_set_msi_irq_affinity(unsigned int irq,
* Release XIO resources for the old MSI PCI address
*/
- read_msi_msg(irq, &msg);
+ get_cached_msi_msg(irq, &msg);
sn_pdev = (struct pcidev_info *)sn_irq_info->irq_pciioinfo;
pdev = sn_pdev->pdi_linux_pcidev;
provider = SN_PCIDEV_BUSPROVIDER(pdev);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e41ed24..4dc0084 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3397,7 +3397,7 @@ static int set_msi_irq_affinity(unsigned int irq, const struct cpumask *mask)
cfg = desc->chip_data;
- read_msi_msg_desc(desc, &msg);
+ get_cached_msi_msg_desc(desc, &msg);
msg.data &= ~MSI_DATA_VECTOR_MASK;
msg.data |= MSI_DATA_VECTOR(cfg->vector);
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 4c14f31..69b7be3 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -197,9 +197,46 @@ void read_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
{
struct msi_desc *entry = get_irq_desc_msi(desc);
- /* We do not touch the hardware (which may not even be
- * accessible at the moment) but return the last message
- * written. Assert that this is valid, assuming that
+ BUG_ON(entry->dev->current_state != PCI_D0);
+
+ if (entry->msi_attrib.is_msix) {
+ void __iomem *base = entry->mask_base +
+ entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
+
+ msg->address_lo = readl(base + PCI_MSIX_ENTRY_LOWER_ADDR);
+ msg->address_hi = readl(base + PCI_MSIX_ENTRY_UPPER_ADDR);
+ msg->data = readl(base + PCI_MSIX_ENTRY_DATA);
+ } else {
+ struct pci_dev *dev = entry->dev;
+ int pos = entry->msi_attrib.pos;
+ u16 data;
+
+ pci_read_config_dword(dev, msi_lower_address_reg(pos),
+ &msg->address_lo);
+ if (entry->msi_attrib.is_64) {
+ pci_read_config_dword(dev, msi_upper_address_reg(pos),
+ &msg->address_hi);
+ pci_read_config_word(dev, msi_data_reg(pos, 1), &data);
+ } else {
+ msg->address_hi = 0;
+ pci_read_config_word(dev, msi_data_reg(pos, 0), &data);
+ }
+ msg->data = data;
+ }
+}
+
+void read_msi_msg(unsigned int irq, struct msi_msg *msg)
+{
+ struct irq_desc *desc = irq_to_desc(irq);
+
+ read_msi_msg_desc(desc, msg);
+}
+
+void get_cached_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
+{
+ struct msi_desc *entry = get_irq_desc_msi(desc);
+
+ /* Assert that the cache is valid, assuming that
* valid messages are not all-zeroes. */
BUG_ON(!(entry->msg.address_hi | entry->msg.address_lo |
entry->msg.data));
@@ -207,11 +244,11 @@ void read_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
*msg = entry->msg;
}
-void read_msi_msg(unsigned int irq, struct msi_msg *msg)
+void get_cached_msi_msg(unsigned int irq, struct msi_msg *msg)
{
struct irq_desc *desc = irq_to_desc(irq);
- read_msi_msg_desc(desc, msg);
+ get_cached_msi_msg_desc(desc, msg);
}
void write_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 6991ab5..91b05c1 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -14,8 +14,10 @@ struct irq_desc;
extern void mask_msi_irq(unsigned int irq);
extern void unmask_msi_irq(unsigned int irq);
extern void read_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg);
+extern void get_cached_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg);
extern void write_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg);
extern void read_msi_msg(unsigned int irq, struct msi_msg *msg);
+extern void get_cached_msi_msg(unsigned int irq, struct msi_msg *msg);
extern void write_msi_msg(unsigned int irq, struct msi_msg *msg);
struct msi_desc {
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH] powerpc: fix .data..init_task output section
From: Sam Ravnborg @ 2010-07-23 13:58 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20100722195008.72fe2e71@lappy.seanm.ca>
On Thu, Jul 22, 2010 at 07:50:08PM -0400, Sean MacLennan wrote:
> On Tue, 13 Jul 2010 11:50:24 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
>
> > From 851e645a7eee68380caaf026eb6d3be118876370 Mon Sep 17 00:00:00 2001
> > From: Sam Ravnborg <sam@ravnborg.org>
> > Date: Tue, 13 Jul 2010 11:39:42 +0200
> > Subject: [PATCH] vmlinux.lds: fix .data..init_task output section
> > (fix popwerpc boot)
> >
> > The .data..init_task output section was missing
> > a load offset causing a popwerpc target to fail to boot.
> >
> > Sean MacLennan tracked it down to the definition of
> > INIT_TASK_DATA_SECTION().
> >
> > There are only two users of INIT_TASK_DATA_SECTION()
> > in the kernel today: cris and popwerpc.
> > cris do not support relocatable kernels and is thus not
> > impacted by this change.
> >
> > Fix INIT_TASK_DATA_SECTION() to specify load offset like
> > all other output sections.
> >
> > Reported-by: Sean MacLennan <smaclennan@pikatech.com>
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > ---
> >
> > On the assumption that Sean reports that it fixes
> > the warnings/boot issue here is a real patch.
> >
> > Ben - will you take it via the popwerpc tree
> > or shall I ask Michal to take it via kbuild?
> >
> > Sam
Sorry for the bad initial subject line!
As Sean reported that the patch fixes his isuse it
deserves a:
Tested-by: Sean MacLennan <smaclennan@pikatech.com>
Sam
^ 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