* nest branch update
From: Benjamin Herrenschmidt @ 2009-03-11 6:25 UTC (permalink / raw)
To: linuxppc-dev list
The following commits have been added to powerpc next:
Anton Vorontsov (1):
powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
Arnd Bergmann (1):
powerpc/spufs: Initialize ctx->stats.tstamp correctly
Benjamin Herrenschmidt (1):
powerpc: Wire up /proc/vmallocinfo to our ioremap()
Geoff Levand (2):
powerpc: Add missing DABR flags
powerpc/ps3: Print memory hotplug errors
Grant Likely (2):
powerpc/5200: Add 'simple-bus' to the of_platform probe list.
powerpc/4xx: update ml507 .dts file to release reference design
Grzegorz Bernacki (2):
powerpc/5200: Add digsy-mtc support to mpc5200_defconfig
powerpc/5200: On the digsy-mtc, configure PSC4 and PSC5 as UARTs
Kumar Gala (1):
powerpc/fsl-booke: Add support for tlbilx instructions
Martyn Welch (1):
powerpc/86xx: Correct local bus registers in GE Fanuc SBC610 dts file
Michael Ellerman (3):
powerpc: Deindentify identify_cpu()
powerpc: Make sure we copy all cpu_spec features except PMC related ones
powerpc: Remove unused asm-offsets entries for cpu_spec
Nick Piggin (1):
powerpc: Estimate G5 cpufreq transition latency
Octavian Purdila (1):
powerpc/oprofile: G4 oprofile has variable number of counters
Timur Tabi (3):
i2c-mpc: do not allow interruptions when waiting for I2C to complete
powerpc: add fsl,fifo-depth property to Freescale SSI device nodes
powerpc: Add defintion for MSR[GS] to list of MSR bits
Xiaotian Feng (1):
cpm_uart: fix non-console port startup bug
dayu@datangmobile.cn (1):
powerpc/83xx: Fix the interrupt loss problem on ipic
roel kluin (1):
powerpc/ps3: Make ps3av_set_video_mode mode ID signed
^ permalink raw reply
* test branch update
From: Benjamin Herrenschmidt @ 2009-03-11 6:25 UTC (permalink / raw)
To: linuxppc-dev list
The following commits have been added to powerpc test:
Andrew Klossner (1):
powerpc/udbg: Fix lost byte during console handover; change LFCR
to CRLF
Benjamin Herrenschmidt (10):
powerpc/mm: Properly wire up get_user_pages_fast() on 32-bit
powerpc/kconfig: Kill PPC_MULTIPLATFORM
powerpc/mm: Split the various pgtable-* headers based on MMU type
powerpc/mm: Unify PTE_RPN_SHIFT and _PAGE_CHG_MASK definitions
powerpc/mm: Tweak PTE bit combination definitions
powerpc/mm: Merge various PTE bits and accessors definitions
powerpc/mm: Rename arch/powerpc/kernel/mmap.c to mmap_64.c
powerpc/mm: Fix printk type warning in mmu_context_nohash
powerpc/mm: Add option for non-atomic PTE updates to ppc64
powerpc/mm: Introduce early_init_mmu() on 64-bit
Jeremy Kerr (2):
powerpc/spufs: Check file offset before calculating write size in
fixed-sized files
powerpc/spufs: Fix incorrect buffer offset in regs write
Michael Ellerman (5):
powerpc: Print linux_banner in prom_init
powerpc/pseries: Reject discontiguous/non-zero based MSI-X
requests
powerpc/pseries: The pseries MSI code depends on EEH
powerpc/cell: Fix Axon MSI driver dependencies
powerpc/pseries: The RPA PCI hotplug driver depends on EEH
Octavian Purdila (1):
powerpc/oprofile: Enable support for ppc750 processors
Thomas Gleixner (2):
powerpc/irq: Convert obsolete irq_desc_t to struct irq_desc
powerpc/irq: Convert obsolete hw_interrupt_type to struct irq_chip
Wolfram Sang (1):
powerpc/pci: Fix typo: s/resouces/resources/ in a pr_debug
^ permalink raw reply
* Re: [RESEND GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator
From: Sachin P. Sant @ 2009-03-11 6:48 UTC (permalink / raw)
To: Tejun Heo; +Cc: linuxppc-dev, Ingo Molnar, linux-next, LKML
In-Reply-To: <49B75215.5010707@kernel.org>
Tejun Heo wrote:
> Impact: remove spurious WARN on legacy SMP percpu allocator
>
> Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
> tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
> allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
> for UP but legacy SMP allocator was forgotten. Fix it.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Sachin P. Sant <sachinp@in.ibm.com>
> ---
Thanks. The patch fixes the warning.
Tested-by : Sachin Sant <sachinp@in.ibm.com>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [patch 08/18] powerpc: convert obsolete irq_desc_t to struct irq_desc
From: Thomas Gleixner @ 2009-03-11 7:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Andrew Morton, Ingo Molnar, LKML
In-Reply-To: <1236737962.7086.35.camel@pasglop>
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-03-11 at 00:45 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (powerpc-convert-obsolete-irq-desc-t-typedef.patch)
> > Impact: cleanup
> >
> > Convert the last remaining users.
>
> Ack. This would be more easily carried in my -next tree if that's ok
> with you.
Sure. Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Mikhail Zolotaryov @ 2009-03-11 8:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1236738411.7086.38.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> The problem is that the controller is hardwired to use only one
>> chipselect, even if both are enabled in the DDR0_10 on PPC440EPx/GRx
>> processors
>
> Mikhail, can you verify that Valentine's patch works for you ?
Ben, unfortunately on my board(s) I don't have both bits enabled in
DDR0_10 i.e. I'll have cs=1 calculated even by original Linux code.
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Mikhail Zolotaryov @ 2009-03-11 8:29 UTC (permalink / raw)
To: Valentine; +Cc: linuxppc-dev
In-Reply-To: <49B7167C.9000004@ru.mvista.com>
Valentine wrote:
> The problem is that the controller is hardwired to use only one
> chipselect, even if both are enabled in the DDR0_10 on PPC440EPx/GRx
> processors.
>
It's new information for me. Is this problem described by some ERRATA or
manual, could you please point me to the document (and page) ?
^ permalink raw reply
* Re: test branch update
From: Michael Neuling @ 2009-03-11 8:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1236752755.7086.45.camel@pasglop>
FYI pseries_defconfig and ppc64_defconfig boot fine with this on BML
systemsim.
Mikey "manual kisskb" Neuling
> The following commits have been added to powerpc test:
>
> Andrew Klossner (1):
> powerpc/udbg: Fix lost byte during console handover; change LFCR
> to CRLF
>
> Benjamin Herrenschmidt (10):
> powerpc/mm: Properly wire up get_user_pages_fast() on 32-bit
> powerpc/kconfig: Kill PPC_MULTIPLATFORM
> powerpc/mm: Split the various pgtable-* headers based on MMU type
> powerpc/mm: Unify PTE_RPN_SHIFT and _PAGE_CHG_MASK definitions
> powerpc/mm: Tweak PTE bit combination definitions
> powerpc/mm: Merge various PTE bits and accessors definitions
> powerpc/mm: Rename arch/powerpc/kernel/mmap.c to mmap_64.c
> powerpc/mm: Fix printk type warning in mmu_context_nohash
> powerpc/mm: Add option for non-atomic PTE updates to ppc64
> powerpc/mm: Introduce early_init_mmu() on 64-bit
>
> Jeremy Kerr (2):
> powerpc/spufs: Check file offset before calculating write size in
> fixed-sized files
> powerpc/spufs: Fix incorrect buffer offset in regs write
>
> Michael Ellerman (5):
> powerpc: Print linux_banner in prom_init
> powerpc/pseries: Reject discontiguous/non-zero based MSI-X
> requests
> powerpc/pseries: The pseries MSI code depends on EEH
> powerpc/cell: Fix Axon MSI driver dependencies
> powerpc/pseries: The RPA PCI hotplug driver depends on EEH
>
> Octavian Purdila (1):
> powerpc/oprofile: Enable support for ppc750 processors
>
> Thomas Gleixner (2):
> powerpc/irq: Convert obsolete irq_desc_t to struct irq_desc
> powerpc/irq: Convert obsolete hw_interrupt_type to struct irq_chip
>
> Wolfram Sang (1):
> powerpc/pci: Fix typo: s/resouces/resources/ in a pr_debug
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH] eHEA: Don't do memory allocation under lock if not necessary
From: David Howells @ 2009-03-11 8:44 UTC (permalink / raw)
To: raisch, themann, tklein; +Cc: linuxppc-dev, netdev
In ehea_probe_adapter() the initial memory allocation and initialisation does
not need to be done with the ehea_fw_handles.lock semaphore held. Doing so
extends the amount of time the lock is held unnecessarily.
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/net/ehea/ehea_main.c | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index dfe9226..34480ae 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -3370,18 +3370,19 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
ehea_error("Invalid ibmebus device probed");
return -EINVAL;
}
- mutex_lock(&ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
- ret = -ENOMEM;
dev_err(&dev->dev, "no mem for ehea_adapter\n");
- goto out;
+ return -ENOMEM;
}
- list_add(&adapter->list, &adapter_list);
-
adapter->ofdev = dev;
+ adapter->pd = EHEA_PD_ID;
+
+ mutex_lock(&ehea_fw_handles.lock);
+
+ list_add(&adapter->list, &adapter_list);
adapter_handle = of_get_property(dev->node, "ibm,hea-handle",
NULL);
@@ -3395,8 +3396,6 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
goto out_free_ad;
}
- adapter->pd = EHEA_PD_ID;
-
dev->dev.driver_data = adapter;
^ permalink raw reply related
* RE: Next 10: Badness at mm/allocpercpu.c:123
From: AA @ 2009-03-11 8:50 UTC (permalink / raw)
To: sachinp, sfr, linux-kernel; +Cc: linuxppc-dev, linux-next, linux-kernel
In-Reply-To: <49B67552.5070307@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
Hi all
I am newer to linux.
My board is MPC750+MPC106, and I use MAPB for MPC106.
Due to 106 datasheet,
0x8000,0000 -- 0xFC00,0000 for PCI memory space.
As you know, user space is 0~0xbfff,ffff (3G).
0xc000,0000 ~ 0xffff,ffff(1G) is for kernel.
And my question is:
1) where should I map this address space to ?
2) user application can access this address space directly?
_________________________________________________________________
梦幻K图，百变造型，让你的照片与众不同，快来MClub试试吧！
http://club.msn.cn/?form=3
[-- Attachment #2: Type: text/html, Size: 807 bytes --]
^ permalink raw reply
* where should I map 0x8000,0000 ~ 0xfc00,0000 to ?
From: AA @ 2009-03-11 8:53 UTC (permalink / raw)
To: sachinp, sfr, linux-kernel; +Cc: linuxppc-dev, linux-next, linux-kernel
In-Reply-To: <COL104-W4161BE11903ACD5CE8A80EB9E0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
Hi all
I am newer to linux.
My board is MPC750+MPC106, and I use MAPB for MPC106.
Due to 106 datasheet,
0x8000,0000 -- 0xFC00,0000 for PCI memory space.
As you know, user space is 0~0xbfff,ffff (3G).
0xc000,0000 ~ 0xffff,ffff(1G) is for kernel.
And my question is:
1) where should I map this address space to ?
2) user application can access this address space directly?
_________________________________________________________________
梦幻K图，百变造型，让你的照片与众不同，快来MClub试试吧！
http://club.msn.cn/?form=3
[-- Attachment #2: Type: text/html, Size: 772 bytes --]
^ permalink raw reply
* Re: [RESEND GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator
From: Ingo Molnar @ 2009-03-11 9:31 UTC (permalink / raw)
To: Tejun Heo; +Cc: Stephen Rothwell, linux-next, LKML, linuxppc-dev
In-Reply-To: <49B75215.5010707@kernel.org>
* Tejun Heo <tj@kernel.org> wrote:
> Impact: remove spurious WARN on legacy SMP percpu allocator
>
> Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
> tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
> allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
> for UP but legacy SMP allocator was forgotten. Fix it.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Sachin P. Sant <sachinp@in.ibm.com>
> ---
> (RESEND: cc'ing Ingo. :-)
>
> Oops, that was a stupid omission. This patch should fix it. Ingo,
> please pull from the following git vector to receive the first first
> four patches from the use-dynamic-percpu-allocator-by-default patchset
> (without the actual conversion which can disrupt archs) + this patch.
> I moved the actual conversion patch into #tj-percpu-exp branch, so the
> pull should be safe.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git tj-percpu
>
> Thanks.
Pulled into tip:core/percpu, thanks a lot Tejun!
Ingo
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Geert Uytterhoeven @ 2009-03-11 9:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <1236729444.7086.24.camel@pasglop>
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
> Here are some late fixes for 2.6.29. I've included a radeonfb/aty128fb commit
Will you also take care of the new ps3vram driver, which has been ack'ed by
Jens for 2.6.29?
Or do you prefer it to go in by email through Geoff (as PS3 maintainer), or
from me directly?
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH] eHEA: Don't do memory allocation under lock if not necessary
From: Jan-Bernd Themann @ 2009-03-11 9:37 UTC (permalink / raw)
To: David Howells; +Cc: tklein, linuxppc-dev, raisch, netdev, themann
In-Reply-To: <20090311084456.9190.52805.stgit@warthog.procyon.org.uk>
Hi David,
thanks for your patch. Coincidentally we have been working on a patch that
does some locking rework and also touches this particular lock.
So your patch finnally won't be required anymore. Thanks anyway for trying
to improve the eHEA driver!
I'm going to post our patch later today.
Regards,
Jan-Bernd
On Wednesday 11 March 2009 09:44:57 David Howells wrote:
> In ehea_probe_adapter() the initial memory allocation and initialisation does
> not need to be done with the ehea_fw_handles.lock semaphore held. Doing so
> extends the amount of time the lock is held unnecessarily.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> drivers/net/ehea/ehea_main.c | 13 ++++++-------
> 1 files changed, 6 insertions(+), 7 deletions(-)
>
>
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index dfe9226..34480ae 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -3370,18 +3370,19 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
> ehea_error("Invalid ibmebus device probed");
> return -EINVAL;
> }
> - mutex_lock(&ehea_fw_handles.lock);
>
> adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
> if (!adapter) {
> - ret = -ENOMEM;
> dev_err(&dev->dev, "no mem for ehea_adapter\n");
> - goto out;
> + return -ENOMEM;
> }
>
> - list_add(&adapter->list, &adapter_list);
> -
> adapter->ofdev = dev;
> + adapter->pd = EHEA_PD_ID;
> +
> + mutex_lock(&ehea_fw_handles.lock);
> +
> + list_add(&adapter->list, &adapter_list);
>
> adapter_handle = of_get_property(dev->node, "ibm,hea-handle",
> NULL);
> @@ -3395,8 +3396,6 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
> goto out_free_ad;
> }
>
> - adapter->pd = EHEA_PD_ID;
> -
> dev->dev.driver_data = adapter;
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: RX problem in ibm_newemac driver
From: Felix Radensky @ 2009-03-11 8:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, linuxppc-dev list
In-Reply-To: <1236730894.7086.29.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2009-03-11 at 01:39 +0200, Felix Radensky wrote:
>
>> Benjamin Herrenschmidt wrote:
>>
>>> On Wed, 2009-03-11 at 00:14 +0200, Felix Radensky wrote:
>>>
>>>
>>>> Yes, seems logical. U-boot has code to enable and disable loopback clock
>>>> for 440SPE, 440EPX,440GRX,405EX, 460EX and 460GT.
>>>>
>>>> I can test patches on my board. Alternatively, I can try something myself
>>>> if you can provide some guidance. I guess you are referring to the code
>>>> using
>>>> EMAC_FTR_440GX_PHY_CLK_FIX and EMAC_FTR_440EP_PHY_CLK_FIX.
>>>>
>>>>
>>> It would be nice if you could try something as I don't have anything to
>>> test here.
>>>
>>> And yes, it's probably one of those 2 fixes that need to be extended.
>>>
>>> I'll have a look later today if I can find the 405EXr user manual and
>>> give you more precise guidance.
>>>
>
> >From the doc, it looks like it needs the 440 type workaround (and the
> 405EX as well). Can you try this patch:
>
> emac: Fix clock control for 405EX and 405EXr chips
>
> The EMAC variant in the 405EX and 405EXr chips needs the "440EP" type clock
> control workaround to avoid lockups of the Rx side during reset.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Index: linux-work/drivers/net/ibm_newemac/core.c
> ===================================================================
> --- linux-work.orig/drivers/net/ibm_newemac/core.c 2009-03-11 11:13:37.000000000 +1100
> +++ linux-work/drivers/net/ibm_newemac/core.c 2009-03-11 11:14:00.000000000 +1100
> @@ -2594,6 +2594,9 @@ static int __devinit emac_init_config(st
> if (of_device_is_compatible(np, "ibm,emac-460ex") ||
> of_device_is_compatible(np, "ibm,emac-460gt"))
> dev->features |= EMAC_FTR_460EX_PHY_CLK_FIX;
> + if (of_device_is_compatible(np, "ibm,emac-405ex") ||
> + of_device_is_compatible(np, "ibm,emac-405exr"))
> + dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
> } else if (of_device_is_compatible(np, "ibm,emac4")) {
> dev->features |= EMAC_FTR_EMAC4;
> if (of_device_is_compatible(np, "ibm,emac-440gx"))
>
>
>
Hi, Ben
This patch fixes a problem for me. Thank you very much for a quick fix.
Felix.
^ permalink raw reply
* Re: [PATCH 0/7] Generic RTC class driver
From: Geert Uytterhoeven @ 2009-03-11 10:36 UTC (permalink / raw)
To: Kyle McMartin
Cc: linux-m68k, Alessandro Zummo, rtc-linux, linux-parisc,
Linux Kernel Development, Linux/PPC Development, Paul Mundt,
Dann Frazier
In-Reply-To: <1236605183-22718-1-git-send-email-Geert.Uytterhoeven@sonycom.com>
Hi Kyle,
On Mon, 9 Mar 2009, Geert Uytterhoeven wrote:
> These patches are relative to the "rtc-parisc" branch of Kyle's PA-RISC git
> repository, which already contains some cleanups for the rtc-parisc driver by
> Dann, which already have been ack'ed by Alessandro:
>
> http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=shortlog;h=rtc-parisc
>
> Paul: Feel free to add your SuperH support.
>
> I suppose the easiest way for this to go in is through Kyle's PA-RISC tree, as
> he already has the preceding patches? Can I have your acks, please?
Is it OK for you to take it through your PA-RISC tree?
If yes, I can resend the patch series with the collected acks.
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Josh Boyer @ 2009-03-11 10:37 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, lebon
In-Reply-To: <20090310195013.GA27835@ru.mvista.com>
On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
>I was just going to submit a patch for that too.
>Indeed, the denali_fixup_memsize() miscalculated a couple of address
>field widths. We were lucky to eventually get the right result,
>because the effect of the first error was killed by the other one.
>According to the AMCC 440EPX/GRX user manual,
>the Chip Select width is always fixed at 1 bit no matter
>what is actually read from register DDR_10.
>The workaround is to use a predefined chipselect value for 440EPx/GRx.
>Also, setting the REDUC bit (REDUC = 1) enables 32-bit data path.
>If REDUC = 0, full data path of 64 bits is used.
>
>Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>
I've been looking over this one a bit more. At the moment, I'm inclined
to queue this up in my -next branch. I would like to see if Mikhail
could test it though, and have Valentine answer the question in the hard
wired part.
josh
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-03-11 10:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <alpine.LRH.2.00.0903111028480.1040@vixen.sonytel.be>
On Wed, 2009-03-11 at 10:37 +0100, Geert Uytterhoeven wrote:
> On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
> > Here are some late fixes for 2.6.29. I've included a radeonfb/aty128fb commit
>
> Will you also take care of the new ps3vram driver, which has been ack'ed by
> Jens for 2.6.29?
> Or do you prefer it to go in by email through Geoff (as PS3 maintainer), or
> from me directly?
I'd like to have Andrew or Linus opinion on doing this driver swap that
late in the process.
Ben.
> Thanks!
>
> With kind regards,
>
> Geert Uytterhoeven
> Software Architect
>
> Sony Techsoft Centre Europe
> The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
>
> Phone: +32 (0)2 700 8453
> Fax: +32 (0)2 700 8622
> E-mail: Geert.Uytterhoeven@sonycom.com
> Internet: http://www.sony-europe.com/
>
> A division of Sony Europe (Belgium) N.V.
> VAT BE 0413.825.160 · RPR Brussels
> Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Please pull from 'next' branch (missed a few patches)
From: Kumar Gala @ 2009-03-11 11:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
In the last pull I think you might have had a tree of mine before these
few minor commits.
arch/powerpc/Makefile | 4 ++--
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 2 +-
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 2 +-
arch/powerpc/math-emu/Makefile | 5 ++---
arch/powerpc/platforms/85xx/ksi8560.c | 2 --
5 files changed, 6 insertions(+), 9 deletions(-)
Liu Yu (1):
powerpc/math-emu: Fix efp dependence
Ted Peters (1):
powerpc/85xx: Fix MPC8572DS PCI protected interrupt sources
Thomas Gleixner (1):
powerpc/85xx: remove setup_irq(NULL action) in ksi8560
^ permalink raw reply
* [PATCH] powerpc/85xx: Update smp support to handle doorbells and non-mpic init
From: Kumar Gala @ 2009-03-11 11:46 UTC (permalink / raw)
To: linuxppc-dev
Use device tree to determine if we actually have an MPIC and use
CPU feature to decide if we should use doorbells for IPIs.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/smp.c | 43 ++++++++++++++++++++++++++++++-------
1 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 79a0df1..cc0b0db 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -21,6 +21,7 @@
#include <asm/page.h>
#include <asm/mpic.h>
#include <asm/cacheflush.h>
+#include <asm/dbell.h>
#include <sysdev/fsl_soc.h>
@@ -80,10 +81,8 @@ smp_85xx_kick_cpu(int nr)
}
static void __init
-smp_85xx_setup_cpu(int cpu_nr)
+smp_85xx_basic_setup(int cpu_nr)
{
- mpic_setup_this_cpu();
-
/* Clear any pending timer interrupts */
mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
@@ -91,15 +90,43 @@ smp_85xx_setup_cpu(int cpu_nr)
mtspr(SPRN_TCR, TCR_DIE);
}
+static void __init
+smp_85xx_setup_cpu(int cpu_nr)
+{
+ mpic_setup_this_cpu();
+
+ smp_85xx_basic_setup(cpu_nr);
+}
+
struct smp_ops_t smp_85xx_ops = {
- .message_pass = smp_mpic_message_pass,
- .probe = smp_mpic_probe,
.kick_cpu = smp_85xx_kick_cpu,
- .setup_cpu = smp_85xx_setup_cpu,
};
-void __init
-mpc85xx_smp_init(void)
+static int __init smp_dummy_probe(void)
{
+ return NR_CPUS;
+}
+
+void __init mpc85xx_smp_init(void)
+{
+ struct device_node *np;
+
+ smp_85xx_ops.message_pass = NULL;
+
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (np) {
+ smp_85xx_ops.probe = smp_mpic_probe;
+ smp_85xx_ops.setup_cpu = smp_85xx_setup_cpu;
+ smp_85xx_ops.message_pass = smp_mpic_message_pass;
+ } else {
+ smp_85xx_ops.probe = smp_dummy_probe;
+ smp_85xx_ops.setup_cpu = smp_85xx_basic_setup;
+ }
+
+ if (cpu_has_feature(CPU_FTR_DBELL))
+ smp_85xx_ops.message_pass = smp_dbell_message_pass;
+
+ BUG_ON(!smp_85xx_ops.message_pass);
+
smp_ops = &smp_85xx_ops;
}
--
1.5.6.6
^ permalink raw reply related
* [PATCH] powerpc: Add support for CoreInt delivery of interrupts on MPIC
From: Kumar Gala @ 2009-03-11 11:48 UTC (permalink / raw)
Cc: linuxppc-dev
CoreInt provides a mechansim to deliver the IRQ vector directly
into the core on an interrupt (via the SPR EPR) rather than having
to go IACK on the PIC. This is suppose to provide an improvment
in interrupt latency by reducing the time to get the IRQ vector.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/mpic.h | 5 +++++
arch/powerpc/sysdev/mpic.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index c2ccca5..41f8fce 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -22,6 +22,7 @@
#define MPIC_GREG_FEATURE_1 0x00010
#define MPIC_GREG_GLOBAL_CONF_0 0x00020
#define MPIC_GREG_GCONF_RESET 0x80000000
+#define MPIC_GREG_GCONF_COREINT 0x40000000
#define MPIC_GREG_GCONF_8259_PTHROU_DIS 0x20000000
#define MPIC_GREG_GCONF_NO_BIAS 0x10000000
#define MPIC_GREG_GCONF_BASE_MASK 0x000fffff
@@ -357,6 +358,8 @@ struct mpic
#define MPIC_BROKEN_FRR_NIRQS 0x00000800
/* Destination only supports a single CPU at a time */
#define MPIC_SINGLE_DEST_CPU 0x00001000
+/* Enable CoreInt delivery of interrupts */
+#define MPIC_ENABLE_COREINT 0x00002000
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf0000000
@@ -470,6 +473,8 @@ extern void mpic_end_irq(unsigned int irq);
extern unsigned int mpic_get_one_irq(struct mpic *mpic);
/* This one gets from the primary mpic */
extern unsigned int mpic_get_irq(void);
+/* This one gets from the primary mpic via CoreInt*/
+extern unsigned int mpic_get_coreint_irq(void);
/* Fetch Machine Check interrupt from primary mpic */
extern unsigned int mpic_get_mcirq(void);
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index a35297d..6fca4f1 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1169,6 +1169,12 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mb();
}
+ /* CoreInt */
+ if (flags & MPIC_ENABLE_COREINT)
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
+ | MPIC_GREG_GCONF_COREINT);
+
if (flags & MPIC_ENABLE_MCK)
mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
@@ -1524,6 +1530,30 @@ unsigned int mpic_get_irq(void)
return mpic_get_one_irq(mpic);
}
+unsigned int mpic_get_coreint_irq(void)
+{
+ struct mpic *mpic = mpic_primary;
+ u32 src;
+
+ BUG_ON(mpic == NULL);
+
+ src = mfspr(SPRN_EPR);
+
+ if (unlikely(src == mpic->spurious_vec)) {
+ if (mpic->flags & MPIC_SPV_EOI)
+ mpic_eoi(mpic);
+ return NO_IRQ;
+ }
+ if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
+ if (printk_ratelimit())
+ printk(KERN_WARNING "%s: Got protected source %d !\n",
+ mpic->name, (int)src);
+ return NO_IRQ;
+ }
+
+ return irq_linear_revmap(mpic->irqhost, src);
+}
+
unsigned int mpic_get_mcirq(void)
{
struct mpic *mpic = mpic_primary;
--
1.5.6.6
^ permalink raw reply related
* Re: [PATCH 1/9] powerpc/kconfig: Kill PPC_MULTIPLATFORM
From: Kumar Gala @ 2009-03-11 12:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20090311035330.DDF1FDE153@ozlabs.org>
On Mar 10, 2009, at 10:53 PM, Benjamin Herrenschmidt wrote:
>
> config PPC_NATIVE
> bool
> - depends on PPC_MULTIPLATFORM
> + depends on 6xx || PPC64
> help
> Support for running natively on the hardware, i.e. without
> a hypervisor. This option is not user-selectable but should
> be selected by all platforms that need it.
Should this really just be PPC64 && BOOK3S ? It doesnt look to be
used for anything beyond using hash_native_64.S
- k
^ permalink raw reply
* MPC512x DMA to PCI dev
From: Matteo Fortini @ 2009-03-11 12:11 UTC (permalink / raw)
To: linux-ppc list
Hi all,
I'm trying to send some data through DMA from a memory buffer to a PCI
video card VRAM.
While I got that I need to alloc the src buffer through
dma_alloc_coherent, I don't understand which address I should give as
the dst address.
I tried both the mapped hw address and an address received from
pci_map_single, but even if the DMA transfer completes "correctly", I
have the wrong data in the VRAM in the end.
I read about all the PCI DMA manuals, but it seems they are for letting
some external DMA device on the PCI bus read/write from/to the main memory.
How do you do that?
Thanks,
Matteo
^ permalink raw reply
* Re: C67x00 reset problems
From: A. Nolson @ 2009-03-11 13:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40903101642l20d4d3e1qab1eac14493690f1@mail.gmail.com>
I have upgraded to the latest John Linn's stable PPC kernel (2.6.25rc9)
and I have applied the patch v11(latest) from Peter Korsgaard for the
c67x00. I get the same problem with that, plus an added "feature" of my
Xilinx Temac driver not working anymore :/
loaded at: 00400000
0056B19C
board data at: 00569120
0056919C
relocated to: 00404064
004040E0
zimage at: 00404E50
00568B99
avail ram: 0056C000
04000000
Linux/PPC load: console=ttyUL0,57600 root=/dev/xsa2 rw
init=/sbin/init
Uncompressing
Linux...done.
Now booting the
kernel
[ 0.000000] Linux version 2.6.25-rc9-dirty (xxx@xxx) (gcc versio
n 4.2.2) #3 PREEMPT Wed Mar 11 14:04:07 CET
2009
[ 0.000000] Xilinx Generic PowerPC board support package (Xilinx
ML403) (Virt
ex-4
FX)
[ 0.000000] Zone PFN
ranges:
[ 0.000000] DMA 0 ->
16384
[ 0.000000] Normal 16384 ->
16384
[ 0.000000] HighMem 16384 ->
16384
[ 0.000000] Movable zone start PFN for each
node
[ 0.000000] early_node_map[1] active PFN
ranges
[ 0.000000] 0: 0 ->
16384
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pag
es:
16256
[ 0.000000] Kernel command line: console=ttyUL0,57600 root=/dev/xsa2
rw init=
/sbin/init
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to
0xFDFFF000
[ 0.000000] PID hash table entries: 256 (order: 8, 1024
bytes)
[ 0.000164] Console: colour dummy device
80x25
[ 0.000578] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
[ 0.001311] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
[ 0.013500] Memory: 61580k available (2392k kernel code, 796k data,
116k init
, 0k
highmem)
[ 0.013765] SLUB: Genslabs=12, HWalign=32, Order=0-1, MinObjects=4,
CPUs=1, N
odes=1
[ 0.035217] Mount-cache hash table entries:
512
[ 0.040125] net_namespace: 152
bytes
[ 0.042375] NET: Registered protocol family
16
[ 0.045220] Registering device
uartlite:0
[ 0.045919] Registering device
xsysace:0
[ 0.046686] Registering device
xilinx_temac:0
[ 0.047481] Registering device
xilinx_gpio_iic:0
[ 0.048251] Registering device
xilinx_gpio_iic:1
[ 0.048960] Registering device
c67x00:0
[ 0.049773] Registering device
xilinx_spi:0
[ 0.073716] usbcore: registered new interface driver
usbfs
[ 0.074525] usbcore: registered new interface driver
hub
[ 0.075645] usbcore: registered new device driver
usb
[ 0.090615] NET: Registered protocol family
2
[ 0.100483] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.102400] TCP established hash table entries: 2048 (order: 2, 16384
bytes)
[ 0.102680] TCP bind hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.102837] TCP: Hash tables configured (established 2048 bind
2048)
[ 0.102866] TCP reno
registered
[ 0.162283] Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
[ 0.165259] io scheduler noop
registered
[ 0.165302] io scheduler anticipatory
registered
[ 0.165328] io scheduler deadline
registered
[ 0.165676] io scheduler cfq registered
(default)
[ 0.764717] Generic RTC Driver
v1.07
[ 0.765484] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharing
disabled
[ 0.773231] uartlite.0: ttyUL0 at MMIO 0x40600003 (irq = 5) is a
uartlite
[ 0.773293] console [ttyUL0]
enabled
[ 1.281526] brd: module
loaded
[ 1.292177] loop: module
loaded
[ 1.297447] xsysace xsa: Xilinx SystemACE revision
1.0.12
[ 1.307231] xsysace xsa: capacity: 4001760
sectors
[ 1.316387] xsa: xsa1 xsa2
xsa3
[ 1.326864] Xilinx SystemACE device driver,
major=254
[ 1.335692] nbd: registered device at major
43
[ 1.359637] XTemac: using sgDMA
mode.
[ 1.364027] XTemac: using TxDRE
mode
[ 1.371101] XTemac: using RxDRE
mode
[ 1.378028] XTemac: buffer descriptor size: 32768
(0x8000)
[ 1.390044] XTemac: (buffer_descriptor_init) phy: 0x3d30000, virt:
0xff100000
, size:
0x8000
[ 1.411208] eth%d: XTemac: PHY detected at address
0.
[ 1.418020] 00: 1140 7949 0141 0cc2 01e1 0000 0004
2001
[ 1.429021] 08: 0000 0300 0000 0000 0000 0000 0000
3000
[ 1.439344] 10: 0078 8100 0000 0000 0c60 0000 0000
0000
[ 1.450021] 18: 4100 0000 000a 848f 0000 0000 0000
0000
[ 1.460429] eth0: Dropping NETIF_F_SG since no checksum
feature.
[ 1.475459] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC5020000,
irq=2
[ 1.486078] eth0: XTemac id 1.0f, block id 5, type
8
[ 1.498804] xilinx_spi xilinx_spi.0: at 0x40618000 mapped to
0xC5004000, irq=
4
[ 6.515214] ------------[ cut here
]------------
[ 6.516000] Badness at
drivers/usb/c67x00/c67x00-ll-hpi.c:241
[ 6.516000] NIP: c01aa530 LR: c01aa524 CTR:
c0018a14
[ 6.516000] REGS: c3c1bd70 TRAP: 0700 Not tainted
(2.6.25-rc9-dirty)
[ 6.516000] MSR: 00029030 <EE,ME,IR,DR> CR: 24000082 XER:
2000005d
[ 6.516000] TASK = c3c18000[1] 'swapper' THREAD:
c3c1a000
[ 6.516000] GPR00: 00000001 c3c1be20 c3c18000 00000000 c02d7518
c0314730 8453
2ba7
00000001
[ 6.516000] GPR08: 00000000 00000000 c3d15e04 c3c1a000 24000082
ffffffff c029
2be0
c0292bf0
[ 6.516000] GPR16: c0292c14 c0292c1c c0292c2c c0292c58 c0292c6c
00000000 ffff
ffff
ffffffff
[ 6.516000] GPR24: c0310000 c0292bd8 c02d8a88 00000000 c3d15de8
00000000 c3d1
5de0
c02d8a6c
[ 6.516000] NIP [c01aa530]
c67x00_ll_reset+0x48/0x88
[ 6.516000] LR [c01aa524]
c67x00_ll_reset+0x3c/0x88
[ 6.516000] Call
Trace:
[ 6.516000] [c3c1be20] [c01aa524] c67x00_ll_reset+0x3c/0x88
(unreliable)
[ 6.516000] [c3c1be40] [c02505a4]
c67x00_drv_probe+0x16c/0x2e0
[ 6.516000] [c3c1be70] [c0180e4c]
platform_drv_probe+0x20/0x30
[ 6.516000] [c3c1be80] [c017ee44]
driver_probe_device+0xec/0x194
[ 6.516000] [c3c1bea0] [c017f09c]
__driver_attach+0x88/0xf4
[ 6.516000] [c3c1bec0] [c017df94]
bus_for_each_dev+0x58/0x98
[ 6.516000] [c3c1bef0] [c017ec40]
driver_attach+0x24/0x34
[ 6.516000] [c3c1bf00] [c017e9b8]
bus_add_driver+0xb4/0x218
[ 6.516000] [c3c1bf20] [c017f400]
driver_register+0x78/0x10c
[ 6.516000] [c3c1bf40] [c01811c8]
platform_driver_register+0x9c/0xac
[ 6.516000] [c3c1bf50] [c030641c]
c67x00_init+0x18/0x28
[ 6.516000] [c3c1bf60] [c02f4204]
kernel_init+0x100/0x298
[ 6.516000] [c3c1bff0] [c0004918]
kernel_thread+0x44/0x60
[ 6.516000] Instruction
dump:
[ 6.516000] 90010024 480a89e5 38800000 7fa3eb78 6084fa50 4bffefbd
387d0020 38
801388
[ 6.516000] 480a7fd1 707dffff 7c000026 54001ffe <0f000000> 3c00ffff
7fbd00d0
60000005
[ 6.860078] c67x00 c67x00.0: Device reset
failed
[ 6.866113] c67x00: probe of c67x00.0 failed with error
65531
[ 6.879751] usbcore: registered new interface driver
libusual
[ 6.890566] usbcore: registered new interface driver
cypress_cy7c63
[ 6.903058] i8042.c: No controller
found.
[ 6.912220] mice: PS/2 mouse device common for all
mice
[ 6.923303] i2c /dev entries
driver
[ 6.930558] i2c-parport-light: adapter type
unspecified
[ 6.941806] xilinx_gpio_iic.0 #0 at 0x400C0000 mapped to
0xC5040000
[ 6.953631] xilinx_gpio_iic.1 #1 at 0x400A0000 mapped to
0xC5060000
[ 7.041126] usbcore: registered new interface driver
usbhid
[ 7.049104] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core
driver
[ 7.065981] TCP cubic
registered
[ 7.070135] NET: Registered protocol family
1
[ 7.078177] NET: Registered protocol family
17
[ 7.090737] RPC: Registered udp transport
module.
[ 7.097122] RPC: Registered tcp transport
module.
[ 7.123804] kjournald starting. Commit interval 5
seconds
[ 7.132117] EXT3-fs warning: maximal mount count reached, running
e2fsck is r
ecommended
[ 7.150770] EXT3 FS on xsa2, internal
journal
[ 7.156016] EXT3-fs: recovery
complete.
[ 7.164048] EXT3-fs: mounted filesystem with ordered data
mode.
[ 7.176115] VFS: Mounted root (ext3
filesystem).
[ 7.185289] Freeing unused kernel memory: 116k
init
Grant Likely wrote:
> Unfortunately, the 2.6.24-rc3 stuff in my git tree is really old.
> I've been getting all of my recent work into mainline. The CF driver
> is in much better shape there. The c67x00 driver is merged into
> mainline, but I haven't tested it at all in the last year so I don't
> know how well it will work.
>
> Cheers,
> g.
>
> On Tue, Mar 10, 2009 at 5:17 PM, A. Nolson <alohanono@gmail.com> wrote:
>
>> Hi,
>>
>> I am using 2.6.24-rc3 ( secretlabs git) in an ML403 where I want to
>> use the USB c67x00 based host with Peter Kosgaard driver. I am using it
>> together with the sysace device for CF access ( in the ML403 those two
>> share lines, but I managed to insert some logic to multiplex both
>> devices). I have been able to use the c67300 without OS, but when I try
>> to boot the kernel I am getting driver reset problems (the whole log is
>> at the end)
>>
>> [ 6.882540] c67x00 c67x00.0: Device reset
>> failed
>> [ 6.889278] c67x00: probe of c67x00.0 failed with error 65531
>>
>> And of course the device cannot get probed. I think this has happened to
>> other people before but I can't find the solution in the archive. My
>> virtex_devices.c initialization looks like this:
>>
>> #define XPAR_C67x00_USB(num) { \
>> .name = "c67x00", \
>> .id = num, \
>> .num_resources = 2, \
>> .resource = (struct resource[]) { \
>> { \
>> .start = XPAR_C67X00_USB_PRH##num##_BASEADDR, \
>> .end = XPAR_C67X00_USB_PRH##num##_BASEADDR + 0xf, \
>> .flags = IORESOURCE_MEM, \
>> }, \
>> { \
>> .start = XPAR_OPB_INTC_0_SYSTEM_USB_HPI_INT_INTR, \
>> .end = XPAR_OPB_INTC_0_SYSTEM_USB_HPI_INT_INTR, \
>> .flags = IORESOURCE_IRQ, \
>> }, \
>> }, \
>> .dev.platform_data = &(struct c67x00_platform_data) { \
>> .sie_config = C67X00_SIE1_HOST | C67X00_SIE2_PERIPHERAL_A, \
>> .hpi_regstep = 0x02, /* A0 not connected on 16bit bus */ \
>> }, \
>> }
>>
>> /* Cypress USB C67x00 instances */
>> #if defined(XPAR_C67X00_USB_PRH0_BASEADDR)
>> XPAR_C67x00_USB(0),
>> #endif
>>
>>
>> and my xparameters_ml403.h like this:
>>
>> /* Definitions for peripheral C67X00_USB */
>> #define XPAR_C67X00_USB_PRH0_BASEADDR 0xA5000000
>> #define XPAR_C67X00_USB_PRH0_HIGHADDR 0xA500FFFF
>> #define XPAR_C67X00_USB_PRH1_BASEADDR 0xA5010000
>> #define XPAR_C67X00_USB_PRH1_HIGHADDR 0xA501FFFF
>> #define XPAR_C67X00_USB_PRH2_BASEADDR 0xA5020000
>> #define XPAR_C67X00_USB_PRH2_HIGHADDR 0xA502FFFF
>> #define XPAR_C67X00_USB_PRH3_BASEADDR 0xA5030000
>> #define XPAR_C67X00_USB_PRH3_HIGHADDR 0xA503FFFF
>>
>> #define XPAR_OPB_INTC_0_SYSTEM_USB_HPI_INT_INTR 0
>> #define XPAR_SYSTEM_USB_HPI_INT_MASK 0X000001
>>
>> I don't know what could be wrong here. Any clues?
>>
>> /Albert
>>
>>
>>
>> loaded at: 00400000
>> 0056419C
>> board data at: 00562120
>> 0056219C
>> relocated to: 0040406C
>> 004040E8
>> zimage at: 00404E58
>> 00561F12
>> avail ram: 00565000
>> 04000000
>>
>>
>> Linux/PPC load: console=ttyUL0,57600 root=/dev/xsa2 rw
>> init=/sbin/init
>> Uncompressing
>> Linux...done.
>> Now booting the
>> kernel
>> [ 0.000000] Linux version 2.6.24-rc3-dirty (xxx@xxx) (gcc vers
>> n 4.2.2) #77 PREEMPT Mon Mar 9 18:31:59 CET
>> 2009
>> [ 0.000000] Xilinx ML403 Reference System (Virtex-4
>> FX)
>> [ 0.000000] Zone PFN
>> ranges:
>> [ 0.000000] DMA 0 ->
>> 16384
>> [ 0.000000] Normal 16384 ->
>> 16384
>> [ 0.000000] HighMem 16384 ->
>> 16384
>> [ 0.000000] Movable zone start PFN for each
>> node
>> [ 0.000000] early_node_map[1] active PFN
>> ranges
>> [ 0.000000] 0: 0 ->
>> 16384
>> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
>> Total p
>> es:
>> 16256
>> [ 0.000000] Kernel command line: console=ttyUL0,57600 root=/dev/xsa2
>> rw ini
>> /sbin/init
>>
>> [ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to
>> 0xFDFFF000
>> [ 0.000000] PID hash table entries: 256 (order: 8, 1024
>> bytes)
>> [ 0.000160] Console: colour dummy device
>> 80x25
>> [ 0.000569] Dentry cache hash table entries: 8192 (order: 3, 32768
>> bytes)
>> [ 0.001326] Inode-cache hash table entries: 4096 (order: 2, 16384
>> bytes)
>> [ 0.013549] Memory: 61628k available (2352k kernel code, 796k data,
>> 112k in
>> , 0k
>> highmem)
>> [ 0.013800] SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4,
>> CPUs=1,
>> odes=1
>>
>> [ 0.035282] Mount-cache hash table entries:
>> 512
>> [ 0.039567] net_namespace: 64
>> bytes
>> [ 0.044545] NET: Registered protocol family
>> 16
>> [ 0.051781] Registering
>> spi1_board_info
>> [ 0.074960] usbcore: registered new interface driver
>> usbfs
>> [ 0.075863] usbcore: registered new interface driver
>> hub
>> [ 0.076911] usbcore: registered new device driver
>> usb
>> [ 0.090812] NET: Registered protocol family
>> 2
>> [ 0.100648] IP route cache hash table entries: 1024 (order: 0, 4096
>> bytes)
>> [ 0.103337] TCP established hash table entries: 2048 (order: 2, 16384
>> bytes
>> [ 0.103614] TCP bind hash table entries: 2048 (order: 1, 8192
>> bytes)
>> [ 0.103770] TCP: Hash tables configured (established 2048 bind
>> 2048)
>> [ 0.103798] TCP reno
>> registered
>> [ 0.107443] sysctl table check failed: /kernel/l2cr .1.31 Missing
>> strategy
>> [ 0.107511] Call
>> Trace:
>> [ 0.107530] [c3c11de0] [c0008338] show_stack+0x50/0x188
>> (unreliable)
>> [ 0.107606] [c3c11e30] [c003cf88]
>> set_fail+0x50/0x68
>> [ 0.107675] [c3c11e50] [c003d5f8]
>> sysctl_check_table+0x658/0x6ac
>> [ 0.107730] [c3c11ec0] [c003d60c]
>> sysctl_check_table+0x66c/0x6ac
>> [ 0.107785] [c3c11f30] [c002907c]
>> register_sysctl_table+0x64/0xe0
>> [ 0.107851] [c3c11f50] [c02ee750]
>> register_ppc_htab_sysctl+0x18/0x2c
>> [ 0.107919] [c3c11f60] [c02e8230]
>> kernel_init+0x10c/0x2a4
>> [ 0.107962] [c3c11ff0] [c0004c38]
>> kernel_thread+0x44/0x60
>> [ 0.165612] Installing knfsd (copyright (C) 1996
>> okir@monad.swb.de).
>> [ 0.168476] io scheduler noop
>> registered
>> [ 0.168515] io scheduler anticipatory
>> registered
>> [ 0.168538] io scheduler deadline
>> registered
>> [ 0.168885] io scheduler cfq registered
>> (default)
>> [ 0.763801] Generic RTC Driver
>> v1.07
>> [ 0.764606] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
>> sharin
>> disabled
>>
>> [ 0.773092] uartlite.0: ttyUL0 at MMIO 0x40600003 (irq = 5) is a
>> uartlite
>> [ 0.773152] console [ttyUL0]
>> enabled
>> [ 1.334309] RAMDISK driver initialized: 16 RAM disks of 4096K size
>> 1024 blo
>> size
>>
>> [ 1.353807] loop: module
>> loaded
>> [ 1.358480] xsysace xsysace.0: Xilinx SystemACE revision
>> 1.0.12
>> [ 1.370084] xsysace xsysace.0: capacity: 7831152
>> sectors
>> [ 1.380238] xsa: xsa1 xsa2
>> xsa3
>> [ 1.389686] Xilinx SystemACE device driver,
>> major=254
>> [ 1.398224] nbd: registered device at major
>> 43
>> [ 1.424199] XTemac: using sgDMA
>> mode.
>> [ 1.429022] XTemac: using TxDRE
>> mode
>> [ 1.436090] XTemac: using RxDRE
>> mode
>> [ 1.443173] XTemac: buffer descriptor size: 32768
>> (0x8000)
>> [ 1.454594] XTemac: (buffer_descriptor_init) phy: 0x3d20000, virt:
>> 0xff1000
>> , size:
>> 0x8000
>> [ 1.475707] eth%d: XTemac: PHY detected at address
>> 0.
>> [ 1.483329] eth0: Dropping NETIF_F_SG since no checksum
>> feature.
>> [ 1.498175] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC5020000,
>> irq=2
>> [ 1.509565] eth0: XTemac id 1.0f, block id 5, type
>> 8
>> [ 1.522258] xilinx_spi xilinx_spi.0: at 0x40618000 mapped to
>> 0xC5004000, ir
>> 4
>>
>> [ 6.538578] ------------[ cut here
>> ]------------
>> [ 6.545188] Badness at
>> drivers/usb/c67x00/c67x00-ll-hpi.c:241
>> [ 6.556588] NIP: c01a4ec0 LR: c01a4eb4 CTR:
>> c00186a4
>> [ 6.566441] REGS: c3c11d80 TRAP: 0700 Not tainted
>> (2.6.24-rc3-dirty)
>>
>> [ 6.580945] MSR: 00029030 <EE,ME,IR,DR> CR: 35000093 XER:
>> e0000065
>> [ 6.593565] TASK = c3c0d000[1] 'swapper' THREAD:
>> c3c10000
>> [ 6.603925] GPR00: 00000001 c3c11e30 c3c0d000 00000000 c02c8528
>> 00000001 85
>> 5751
>> 00000000
>> [ 6.620512] GPR08: 00000000 00000000 c3d12384 c3c10000 35000093
>> ffffffff c0
>> 4040
>> c0284050
>> [ 6.637100] GPR16: c0284074 c028407c c028408c c02840b8 c02840cc
>> 00000000 ff
>> ffff
>> ffffffff
>> [ 6.653687] GPR24: c0300000 c0284038 c02c9a20 00000000 c3d12368
>> 00000000 c3
>> 2360
>> c02c9a04
>> [ 6.670620] NIP [c01a4ec0]
>> c67x00_ll_reset+0x48/0x88
>> [ 6.680468] LR [c01a4eb4]
>> c67x00_ll_reset+0x3c/0x88
>> [ 6.690143] Call
>> Trace:
>> [ 6.694986] [c3c11e30] [c01a4eb4] c67x00_ll_reset+0x3c/0x88
>> (unreliable)
>> [ 6.708290] [c3c11e50] [c01a3b0c]
>> c67x00_drv_probe+0x16c/0x2e0
>> [ 6.719866] [c3c11e80] [c017af4c]
>> platform_drv_probe+0x20/0x30
>> [ 6.731442] [c3c11e90] [c0179328]
>> driver_probe_device+0xec/0x194
>> [ 6.743364] [c3c11eb0] [c0179580]
>> __driver_attach+0x88/0xf4
>> [ 6.754422] [c3c11ed0] [c017855c]
>> bus_for_each_dev+0x54/0x94
>> [ 6.765654] [c3c11f00] [c017912c]
>> driver_attach+0x24/0x34
>> [ 6.776366] [c3c11f10] [c0178998]
>> bus_add_driver+0x78/0x1d4
>> [ 6.787424] [c3c11f30] [c01798b4]
>> driver_register+0x88/0x9c
>> [ 6.798482] [c3c11f40] [c017b2c8]
>> platform_driver_register+0x9c/0xac
>> [ 6.811095] [c3c11f50] [c02fae74]
>> c67x00_init+0x18/0x28
>> [ 6.821462] [c3c11f60] [c02e8230]
>> kernel_init+0x10c/0x2a4
>> [ 6.832175] [c3c11ff0] [c0004c38]
>> kernel_thread+0x44/0x60
>> [ 6.842886] Instruction
>> dump:
>> [ 6.848760] 90010024 480a4969 38800000 7fa3eb78 6084fa50 4bffefbd
>> 387d0020
>> 801388
>>
>> [ 6.864136] 480a3edd 707dffff 7c000026 54001ffe <0f000000> 3c00ffff
>> 7fbd00d
>> 60000005
>>
>> [ 6.882540] c67x00 c67x00.0: Device reset
>> failed
>> [ 6.889278] c67x00: probe of c67x00.0 failed with error
>> 65531
>> [ 6.901621] usbcore: registered new interface driver
>> libusual
>> [ 6.912837] usbcore: registered new interface driver
>> cypress_cy7c63
>> [ 6.925443] i8042.c: No controller
>> found.
>> [ 6.934533] mice: PS/2 mouse device common for all
>> mice
>> [ 6.945746] i2c /dev entries
>> driver
>> [ 6.953016] i2c-parport-light: adapter type
>> unspecified
>> [ 6.964041] usbcore: registered new interface driver
>> usbhid
>> [ 6.972725] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core
>> driver
>> [ 6.985267] TCP cubic
>> registered
>> [ 6.991691] NET: Registered protocol family
>> 1
>> [ 7.000260] NET: Registered protocol family
>> 17
>> [ 7.011149] RPC: Registered udp transport
>> module.
>> [ 7.018303] RPC: Registered tcp transport
>> module.
>> [ 20.920617] kjournald starting. Commit interval 5
>> seconds
>> [ 20.975785] EXT3 FS on xsa2, internal
>> journal
>> [ 20.981905] EXT3-fs: recovery
>> complete.
>> [ 21.287791] EXT3-fs: mounted filesystem with ordered data
>> mode.
>> [ 21.297194] VFS: Mounted root (ext3
>> filesystem).
>>
>>
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
>
>
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: Add support for CoreInt delivery of interrupts onMPIC
From: Liu Dave-R63238 @ 2009-03-11 14:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1236772127-28543-1-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -22,6 +22,7 @@
#define MPIC_GREG_FEATURE_1 0x00010
#define MPIC_GREG_GLOBAL_CONF_0 0x00020
#define MPIC_GREG_GCONF_RESET 0x80000000
+#define MPIC_GREG_GCONF_COREINT 0x40000000
#define MPIC_GREG_GCONF_8259_PTHROU_DIS 0x20000000
#define MPIC_GREG_GCONF_NO_BIAS 0x10000000
#define MPIC_GREG_GCONF_BASE_MASK 0x000fffff
according to the latest UM, the MPIC_GREG_GCONF_COREINT should be
0x60000000.
[-- Attachment #2: Type: text/html, Size: 1956 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/pseries failed reconfig notifier chain call cleanup
From: Nathan Fontenot @ 2009-03-11 15:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1236750467.7086.42.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2009-03-05 at 13:53 -0600, Nathan Fontenot wrote:
>> The return code from invoking the notifier chain when updating the
>> ibm,dynamic-memory property is not handled properly. In failure
>> cases (rc == NOTIFY_BAD) we should be restoring the original value
>> of the property. In success (rc == NOTIFY_OK) we should be returning
>> zero from the calling routine.
>
> This is actually not clear to me ... if the memory has been added or
> removed, we must make sure the device-tree is up to date... ie, we can't
> tell the firmware that we failed can we ?
>
Once the memory is added or removed the device tree is updated to reflect
the change. The case for systems where the memory in the device tree is
specified in the ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory
property is slightly different. Because it is a property that is being
updated (as opposed to addition or removal of a device tree node for
memory specified as memory@XXXX nodes) The kernel updates the property
in the device tree then invokes the notifier chain. If anyone on the
notifier chain returns a failure we should restore the property to its
previous value. I think that part is understood.
The main user (and probably only user) of this interface is the drmgr
tool that handles DLPAR of memory and other conmponents. The drmgr
tool tries to update the property after acquiring it from firmware. If
the property update fails, drmgr cleans up and returns the memory to
firmware. This update ensures that the device tree property is not left
in a state that implies that the system owns the memory.
Hope that helps.
-Nathan
> Ben.
>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>> arch/powerpc/platforms/pseries/reconfig.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> Index: linux-2.6/arch/powerpc/platforms/pseries/reconfig.c
>> ===================================================================
>> --- linux-2.6.orig/arch/powerpc/platforms/pseries/reconfig.c 2008-10-23 22:29:24.000000000 -0500
>> +++ linux-2.6/arch/powerpc/platforms/pseries/reconfig.c 2009-03-05 13:20:00.000000000 -0600
>> @@ -468,9 +468,13 @@
>>
>> rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
>> action, value);
>> + if (rc == NOTIFY_BAD) {
>> + rc = prom_update_property(np, oldprop, newprop);
>> + return -ENOMEM;
>> + }
>> }
>>
>> - return rc;
>> + return 0;
>> }
>>
>> /**
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ 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