nest branch update
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 d...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
test branch update
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
Re: [RESEND GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator
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 t...@kernel.org Reported-by: Sachin P. Sant sach...@in.ibm.com --- Thanks. The patch fixes the warning. Tested-by : Sachin Sant sach...@in.ibm.com -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 08/18] powerpc: convert obsolete irq_desc_t to struct irq_desc
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote: On Wed, 2009-03-11 at 00:45 +, 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
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) ? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: test branch update
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] eHEA: Don't do memory allocation under lock if not necessary
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 dhowe...@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;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator
* Tejun Heo t...@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 t...@kernel.org Reported-by: Sachin P. Sant sach...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] eHEA: Don't do memory allocation under lock if not necessary
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 dhowe...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RX problem in ibm_newemac driver
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 b...@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.0 +1100
+++ linux-work/drivers/net/ibm_newemac/core.c 2009-03-11 11:14:00.0
+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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Next 10: Badness at mm/allocpercpu.c:123
Hi all I am newer to linux. My board is MPC750+MPC106, and I use MAPB for MPC106. Due to 106 datasheet, 0x8000, -- 0xFC00, for PCI memory space. As you know, user space is 0~0xbfff, (3G). 0xc000, ~ 0x,(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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
where should I map 0x8000,0000 ~ 0xfc00,0000 to ?
Hi all I am newer to linux. My board is MPC750+MPC106, and I use MAPB for MPC106. Due to 106 datasheet, 0x8000, -- 0xFC00, for PCI memory space. As you know, user space is 0~0xbfff, (3G). 0xc000, ~ 0x,(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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Generic RTC class driver
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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
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 vbars...@ru.mvista.com Signed-off-by: Mikhail Zolotaryov le...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'next' branch (missed a few patches)
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Update smp support to handle doorbells and non-mpic init
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 ga...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add support for CoreInt delivery of interrupts on MPIC
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 ga...@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_10x00010
#define MPIC_GREG_GLOBAL_CONF_00x00020
#defineMPIC_GREG_GCONF_RESET 0x8000
+#defineMPIC_GREG_GCONF_COREINT 0x4000
#defineMPIC_GREG_GCONF_8259_PTHROU_DIS 0x2000
#defineMPIC_GREG_GCONF_NO_BIAS 0x1000
#defineMPIC_GREG_GCONF_BASE_MASK 0x000f
@@ -357,6 +358,8 @@ struct mpic
#define MPIC_BROKEN_FRR_NIRQS 0x0800
/* Destination only supports a single CPU at a time */
#define MPIC_SINGLE_DEST_CPU 0x1000
+/* Enable CoreInt delivery of interrupts */
+#define MPIC_ENABLE_COREINT0x2000
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf000
@@ -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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/kconfig: Kill PPC_MULTIPLATFORM
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC512x DMA to PCI dev
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: C67x00 reset problems
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: 0040 0056B19C board data at: 00569120 0056919C relocated to: 00404064 004040E0 zimage at: 00404E50 00568B99 avail ram: 0056C000 0400 Linux/PPC load: console=ttyUL0,57600 root=/dev/xsa2 rw init=/sbin/init Uncompressing Linux...done. Now booting the kernel [0.00] Linux version 2.6.25-rc9-dirty (x...@xxx) (gcc versio n 4.2.2) #3 PREEMPT Wed Mar 11 14:04:07 CET 2009 [0.00] Xilinx Generic PowerPC board support package (Xilinx ML403) (Virt ex-4 FX) [0.00] Zone PFN ranges: [0.00] DMA 0 - 16384 [0.00] Normal 16384 - 16384 [0.00] HighMem 16384 - 16384 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 - 16384 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pag es: 16256 [0.00] Kernel command line: console=ttyUL0,57600 root=/dev/xsa2 rw init= /sbin/init [0.00] Xilinx INTC #0 at 0x4120 mapped to 0xFDFFF000 [0.00] 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 o...@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
Re: [PATCH] powerpc/pseries failed reconfig notifier chain call cleanup
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 mem...@ 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 nf...@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.c2008-10-23
22:29:24.0 -0500
+++ linux-2.6/arch/powerpc/platforms/pseries/reconfig.c 2009-03-05
13:20:00.0 -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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Add support for CoreInt delivery of interrupts on MPIC
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 ga...@kernel.crashing.org
---
* Fixed MPIC_GREG_GCONF_COREINT flag to be 0x6000 as per spec and pointed
about by Dave
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..475b06e 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -22,6 +22,7 @@
#define MPIC_GREG_FEATURE_10x00010
#define MPIC_GREG_GLOBAL_CONF_00x00020
#defineMPIC_GREG_GCONF_RESET 0x8000
+#defineMPIC_GREG_GCONF_COREINT 0x6000
#defineMPIC_GREG_GCONF_8259_PTHROU_DIS 0x2000
#defineMPIC_GREG_GCONF_NO_BIAS 0x1000
#defineMPIC_GREG_GCONF_BASE_MASK 0x000f
@@ -357,6 +358,8 @@ struct mpic
#define MPIC_BROKEN_FRR_NIRQS 0x0800
/* Destination only supports a single CPU at a time */
#define MPIC_SINGLE_DEST_CPU 0x1000
+/* Enable CoreInt delivery of interrupts */
+#define MPIC_ENABLE_COREINT0x2000
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf000
@@ -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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
NFS problems on a MPC5200-based board
Hi, This is a follow-up on NFS problems on an MPC5200-based board reported here a while back: http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612 To recap: while using NFS, especially while mounting the root filesystem over NFS, the system is really slow and displays a bunch of nfs: server 192.168.1.1 not responding, still trying messages. Sometimes it is able to get to the login prompt, sometimes not. In cases where the login is successful, the system is still extremely sluggish (console hangs for tens of seconds and longer). git bisect narrows down the troublesome commit as: commit 4c456a67f501b8b15542c7c21c28812bf88f484b Author: Gerhard Pircher gerhard_pirc...@gmx.net Date: Fri Jan 23 06:51:28 2009 + powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code _PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL. Thus it has to be masked out, if the BAT mapping should be non cacheable or CPU_FTR_NEED_COHERENT is not set. This will work on normal SMP setups because we force-set CPU_FTR_NEED_COHERENT as part of CPU_FTR_COMMON on SMP. Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org We have tested recent mainline kernel (past 2.6.29-rc7) with the 4c456a6... commit reverted and NFS problems went away. Other people have also reported similar problems (original posters on Cc): http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792825.html http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792612.html The commit in question does not look directly related to NFS/ networking; moreover it is a fix for some other problem, so just reverting it is not an option, it seems (?). So how do we go about having NFS operational again? Any comments? Regards, Bartlomiej Sieka ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Freescale MPC8313ERDB-RevA and newer BSP/kernel
Has anyone been able to get a newer Freescale BSP to work with a RevA (processor version 1.0) RDB? The boards we received didn't have SPI compiled into the kernel and when we went to go re-compile the kernel using the 20081222 and 20080711 BSPs. I realize that the interrupts were reversed for eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no longer hang when I ping, etc. But I still can't get the board on the network. I've verified it isn't the network settings. I've pinged Freescale for support (didn't help much) and I am now looking for someone who has actually done it (if ever). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote: I'd like to have Andrew or Linus opinion on doing this driver swap that late in the process. Quite franklly, no. If it was a totally _new_ driver, there's no chance of regression, which is why we allow those drivers. But switching an old one for a new one does not match that pattern. We can clearly get regressions. As such, we don't do it late in the -rc series. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
On Mar 11, 2009, at 10:52 AM, Mark Bishop wrote: Has anyone been able to get a newer Freescale BSP to work with a RevA (processor version 1.0) RDB? The boards we received didn't have SPI compiled into the kernel and when we went to go re-compile the kernel using the 20081222 and 20080711 BSPs. I realize that the interrupts were reversed for eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no longer hang when I ping, etc. But I still can't get the board on the network. I've verified it isn't the network settings. I've pinged Freescale for support (didn't help much) and I am now looking for someone who has actually done it (if ever). Have you tried a kernel.org kernel? The group here would be more than happy to help with any issues you might find with the kernel.org kernel. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Generic RTC class driver
On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote: 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. That's fine with me, just hit me up with a git tree address and I'll suck it all into the rtc-parisc tree? regards, Kyle ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
Yes I have actually. I have booted a 2.6.28.6. Same problem. Also, is it me but at some point from 2.6.23 to 2.6.28 did they started using hex numbers in the .dts file for interrupts = without the 0x preamble? I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this board and .28 looked way different in the interrupt section for the eTSEC. Quoting Kumar Gala ga...@kernel.crashing.org: On Mar 11, 2009, at 10:52 AM, Mark Bishop wrote: Has anyone been able to get a newer Freescale BSP to work with a RevA (processor version 1.0) RDB? The boards we received didn't have SPI compiled into the kernel and when we went to go re-compile the kernel using the 20081222 and 20080711 BSPs. I realize that the interrupts were reversed for eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no longer hang when I ping, etc. But I still can't get the board on the network. I've verified it isn't the network settings. I've pinged Freescale for support (didn't help much) and I am now looking for someone who has actually done it (if ever). Have you tried a kernel.org kernel? The group here would be more than happy to help with any issues you might find with the kernel.org kernel. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Remove extra semicolon in fsl_soc.c
A semicolon at the end of the macro means that the for loop has an empty body, and so TSEC/MDIO will not work with older device trees. This fix only applies to 2.6.28; apparently, this code is gone for 2.6.29, according to Grant Likely! Signed-off-by: Johns Daniel johns.dan...@gmail.com --- --- linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c.orig 2009-02-20 16:41:27.0 -0600 +++ linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c2009-03-10 15:56:47.0 -0500 @@ -257,7 +257,7 @@ gfar_mdio_of_init_one(np); /* try the deprecated version */ - for_each_compatible_node(np, mdio, gianfar); + for_each_compatible_node(np, mdio, gianfar) gfar_mdio_of_init_one(np); return 0; --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Update smp support to handle doorbells and non-mpic init
On Wed, Mar 11, 2009 at 06:46:03AM -0500, Kumar Gala wrote:
+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);
We should probably look by compatible rather than device_type. I see
only one device tree that has the latter but not the former (ksi8560),
and it's not SMP (but should still be fixed, of course).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
Hi Linus, On Wed, 11 Mar 2009, Linus Torvalds wrote: On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote: I'd like to have Andrew or Linus opinion on doing this driver swap that late in the process. Quite franklly, no. If it was a totally _new_ driver, there's no chance of regression, which is why we allow those drivers. But switching an old one for a new one does not match that pattern. We can clearly get regressions. As such, we don't do it late in the -rc series. Are you aware the old one was introduced in 2.6.29-rc1? So there cannot be a regression from 2.6.28 or older. 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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
fsldma driver questions
Hi there, I've been examining the fsl dma driver (drivers/dma/fsldma.c) to work out how a typical dma engine driver works so I can port an Intel dma engine driver to the new dmaengine interface. I have noticed that append_ld_queue() changes the next link descriptor address field in the last link descriptor of the chain. The append_ld_queue function is called from the fsl_dma_tx_submit() which can called at any time by a kernel module using that channel. This could result in the link descriptor being changed whilst the DMA engine is running. Could this issue cause unexpected behavior of the DMA engine or the driver? A second question I have is to do with the dma_halt() routine setting the channel abort flag. The dma_halt() routine is called from fsl_chan_xfer_ld_queue() after the dma engine has been detected as idle. The dma_halt() routine sets the channel stop flag and the channel abort flag. Whilst the dma engine could be idle, it may not have completed a transfer AFAICT. Or if the engine is has no more transactions then a channel abort does not need to be issued anyway? I have access to a GE Fanuc SBC310 which has an 8641D containing a dma engine this driver was written for. So I can test any patches. Thanks for your time. Malcolm -- Malcolm Crossley, Software Engineer, GE Fanuc Intelligent Platforms GE Fanuc Intelligent Platforms Ltd, registered in England and Wales (3828642) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB729849476 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove extra semicolon in fsl_soc.c
On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel johns.dan...@gmail.com wrote: A semicolon at the end of the macro means that the for loop has an empty body, and so TSEC/MDIO will not work with older device trees. This fix only applies to 2.6.28; apparently, this code is gone for 2.6.29, according to Grant Likely! Signed-off-by: Johns Daniel johns.dan...@gmail.com Acked-by: Grant Likely grant.lik...@secretlab.ca Greg: Andy Flemming should probably confirm this, but I think this one should be backported to the stable series. g. --- --- linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c.orig 2009-02-20 16:41:27.0 -0600 +++ linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c 2009-03-10 15:56:47.0 -0500 @@ -257,7 +257,7 @@ gfar_mdio_of_init_one(np); /* try the deprecated version */ - for_each_compatible_node(np, mdio, gianfar); + for_each_compatible_node(np, mdio, gianfar) gfar_mdio_of_init_one(np); return 0; --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [stable] [PATCH] powerpc: Remove extra semicolon in fsl_soc.c
On Wed, Mar 11, 2009 at 10:03:22AM -0600, Grant Likely wrote: On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel johns.dan...@gmail.com wrote: A semicolon at the end of the macro means that the for loop has an empty body, and so TSEC/MDIO will not work with older device trees. This fix only applies to 2.6.28; apparently, this code is gone for 2.6.29, according to Grant Likely! Signed-off-by: Johns Daniel johns.dan...@gmail.com Acked-by: Grant Likely grant.lik...@secretlab.ca Greg: Andy Flemming should probably confirm this, but I think this one should be backported to the stable series. That's what he is asking for as he sent it to sta...@kernel.org and asked that it go into the 2.6.28 tree only :) thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull mpc52xx-next
Hey Ben, here's another -next pull request. I think this exhausts everything in my queue. I'm sure someone will tell me if I've missed anything. I'll update patchwork later today. One commit is outside of arch/powerpc, but it is a xilinx-only change to an SPI driver, and David has acked it. Cheers, g. The following changes since commit e7eec2fc27d7dbefd5852c36b3fe6229e6302c99: roel kluin (1): powerpc/ps3: Make ps3av_set_video_mode mode ID signed are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx next Grant Likely (2): powerpc/5200: remove sysfs debug file from GPT driver powerpc/bootwrapper: add fixed-head.o to simpleimage wrappers John Linn (1): powerpc/virtex/spi: Xilinx SPI driver not releasing memory Wolfgang Grandegger (1): powerpc/5200: add function to return external clock frequency Wolfram Sang (1): powerpc/5200: add Phytec phyCORE-MPC5200B-IO board (pcm032) arch/powerpc/boot/dts/pcm032.dts | 392 ++ arch/powerpc/boot/wrapper|4 +- arch/powerpc/include/asm/mpc52xx.h |1 + arch/powerpc/platforms/52xx/Kconfig |1 + arch/powerpc/platforms/52xx/mpc5200_simple.c |3 +- arch/powerpc/platforms/52xx/mpc52xx_common.c | 37 +++ arch/powerpc/platforms/52xx/mpc52xx_gpt.c| 39 --- drivers/spi/xilinx_spi.c |9 +- 8 files changed, 442 insertions(+), 44 deletions(-) create mode 100644 arch/powerpc/boot/dts/pcm032.dts -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] drivers/base: Add bus_register_notifier_alldev() variant
On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca bus_register_notifier_alldev() is a variation on bus_register_notifier() which also triggers the notifier callback for devices already on the bus and already bound to drivers. This function is useful for the case where a driver needs to get a reference to a struct device other than the one it is bound to and it is not known if the device will be bound before or after this function is called. For example, an Ethernet device connected to a PHY that is probed separately. Can't you just walk the list of all devices already on the bus to get notified of them, and then register your notifier handler as well (or register it first, and then walk the list, which is pretty much what your patch does)? I see this api addition as just confusing people as to which one they should register for :) thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier rdre...@cisco.com wrote: Are there really cases where spinning for 1 jiffy is too long of a timeout? If the result is a timeout, then I say no. A timeout is an error condition, and the code will usually terminate. It might make sense for the parameter passed in to be in terms of microseconds but I have a hard time coming up with a case where having the real timeout be 40 msecs or whatever 1 jiffy ends up being is a real problem -- after all, this helper is intended for the case where we expect the condition to become true much sooner than the worst case. Well, that's the point. What if the condition takes a long time to come true. One argument against this code is that it encourages developers to use busy-waits for long periods of time. The only way to prevent this is to make the timeout really short. But if we're using jiffies, then the minimum amount of time needs to be two. It can't be one, because what if jiffies increments immediately after starting the loop? So you need to use a value of two as a minimum. Two jiffies can be a very long time. Besides, if this function is used when interrupts are disabled, I believe that on some platforms, jiffies never increments. If so, we can't use the actual 'jiffies' variable. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] drivers/base: Add bus_register_notifier_alldev() variant
On Wed, Mar 11, 2009 at 10:26 AM, Greg KH gre...@suse.de wrote: On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca bus_register_notifier_alldev() is a variation on bus_register_notifier() which also triggers the notifier callback for devices already on the bus and already bound to drivers. This function is useful for the case where a driver needs to get a reference to a struct device other than the one it is bound to and it is not known if the device will be bound before or after this function is called. For example, an Ethernet device connected to a PHY that is probed separately. Can't you just walk the list of all devices already on the bus to get notified of them, and then register your notifier handler as well (or register it first, and then walk the list, which is pretty much what your patch does)? Yes, and I originally did, but it looks to me like a useful common pattern that is less error prone than open coding it. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
Timur Tabi wrote: On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier rdre...@cisco.com wrote: Are there really cases where spinning for 1 jiffy is too long of a timeout? If the result is a timeout, then I say no. A timeout is an error condition, and the code will usually terminate. [snip] Two jiffies can be a very long time. One jiffy is fine, but two is just too long? Given that it only happens in cases of malfunctioning hardware (or a buggy driver), it seems reasonable as long as preemption isn't disabled (I'm assuming anyone that cares about a rare latency of a couple jiffies is using a preemptible kernel). Besides, if this function is used when interrupts are disabled, I believe that on some platforms, jiffies never increments. If so, we can't use the actual 'jiffies' variable. Disallow that, enforced with a call to might_sleep(). Alternatively, do something with get_cycles(), and have some sort of #define by which arches can say if get_cycles actually works. In the absence of a working get_cycles() or equivalent, timeouts with interrupts disabled aren't going to happen whether we abstract it with a macro or not. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote: Yes I have actually. I have booted a 2.6.28.6. Same problem. I've booted many recent kernels on revA 8313ERDB; networking works fine. I'll try 2.6.28.6 specifically, though u-boot is acting up at the moment so I have to address that first. :-( Are you using the stock config and device tree from 2.6.28.6, or have you made any changes? Also, is it me but at some point from 2.6.23 to 2.6.28 did they started using hex numbers in the .dts file for interrupts = without the 0x preamble? Yes. dts version 0 had hex by default (with OF-like radix prefixes), and version 1 (indicated by /dts-v1/; at the top of the file) has decimal by default (with C-like radix prefixes). I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this board and .28 looked way different in the interrupt section for the eTSEC. Quoting Kumar Gala ga...@kernel.crashing.org: Please don't top-post. The boards we received didn't have SPI compiled into the kernel and when we went to go re-compile the kernel using the 20081222 and 20080711 BSPs. I realize that the interrupts were reversed for eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no longer hang when I ping, etc. But I still can't get the board on the network. I've verified it isn't the network settings. You're sure you're not trying to talk to the switch (which will claim link-up regardless of what's plugged into it)? The non-switch ethernet port is eTSEC2. What *does* it do when you ping, if neither hang nor work? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] drivers/base: Add bus_register_notifier_alldev() variant
On Wed, Mar 11, 2009 at 10:35:29AM -0600, Grant Likely wrote: On Wed, Mar 11, 2009 at 10:26 AM, Greg KH gre...@suse.de wrote: On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca bus_register_notifier_alldev() is a variation on bus_register_notifier() which also triggers the notifier callback for devices already on the bus and already bound to drivers. This function is useful for the case where a driver needs to get a reference to a struct device other than the one it is bound to and it is not known if the device will be bound before or after this function is called. For example, an Ethernet device connected to a PHY that is probed separately. Can't you just walk the list of all devices already on the bus to get notified of them, and then register your notifier handler as well (or register it first, and then walk the list, which is pretty much what your patch does)? Yes, and I originally did, but it looks to me like a useful common pattern that is less error prone than open coding it. How about we wait, and if someone else does the same thing, we then add it to the core like this? Actually, wouldn't it make more sense to just change the default bus_register_notifier to do this? Is there some reason that the caller would not want this kind of thing to happen? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
On Tue, Mar 10, 2009 at 6:24 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote: Alan did have one valid point though. Determining how long to loop for is architecture-specific. Using jiffies is bad, because even one jiffy is too long. Adding a udelay() inside the loop means that it only checks he condition every microsecond. So the real solution is to use keep looping until a certain amount of time has passed. This means using an architecture-specific timebase register. Now we can create a generic version of the function that uses jiffies, and then arch-specific versions where possible. But Alan still needs to be convinced. I already posted a length rebuttal to his email, but I haven't gotten a reply yet. There are several aspects here: - The amount of time to wait should be specified by the caller since it's generally going to come from HW specs - The amount of time between the polls ... that could also be an argument to the macro, not sure there - The precision of the actual wait calls... I vote for microseconds for everything and udelay. The arch will do its best. No, not udelay. Or any delay for that matter. If spinning on a condition, then there is no advantage to burning cycles with a udelay(). Those cycles may as well be used to keep testing the condition so the loop can be exited faster. a udelay() would only serve to always make the busywait longer. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Generic RTC class driver
Hi Kyle, On Wed, 11 Mar 2009, Kyle McMartin wrote: On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote: 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. That's fine with me, just hit me up with a git tree address and I'll suck it all into the rtc-parisc tree? I put it up at: master.kernel.org:/pub/scm/linux/kernel/git/geert/linux-rtc-generic.git The master branch should be a descendant of your rtc-parisc branch. 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.uytterhoe...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Update smp support to handle doorbells and non-mpic init
On Mar 11, 2009, at 10:52 AM, Scott Wood wrote:
On Wed, Mar 11, 2009 at 06:46:03AM -0500, Kumar Gala wrote:
+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);
We should probably look by compatible rather than device_type. I see
only one device tree that has the latter but not the former (ksi8560),
and it's not SMP (but should still be fixed, of course).
Ever other lookup for the mpic node is done by type. I see no reason
to change this right now.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add support for CoreInt delivery of interrupts onMPIC
--- a/arch/powerpc/include/asm/mpic.h +++ b/arch/powerpc/include/asm/mpic.h @@ -22,6 +22,7 @@ #define MPIC_GREG_FEATURE_10x00010 #define MPIC_GREG_GLOBAL_CONF_00x00020 #defineMPIC_GREG_GCONF_RESET 0x8000 +#defineMPIC_GREG_GCONF_COREINT 0x4000 #defineMPIC_GREG_GCONF_8259_PTHROU_DIS 0x2000 #defineMPIC_GREG_GCONF_NO_BIAS 0x1000 #defineMPIC_GREG_GCONF_BASE_MASK 0x000f according to the latest UM, the MPIC_GREG_GCONF_COREINT should be 0x6000. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
Quoting Scott Wood scottw...@freescale.com: On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote: Yes I have actually. I have booted a 2.6.28.6. Same problem. I've booted many recent kernels on revA 8313ERDB; networking works fine. I'll try 2.6.28.6 specifically, though u-boot is acting up at the moment so I have to address that first. :-( Are you using the stock config and device tree from 2.6.28.6, or have you made any changes? Also, is it me but at some point from 2.6.23 to 2.6.28 did they started using hex numbers in the .dts file for interrupts = without the 0x preamble? Yes. dts version 0 had hex by default (with OF-like radix prefixes), and version 1 (indicated by /dts-v1/; at the top of the file) has decimal by default (with C-like radix prefixes). I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this board and .28 looked way different in the interrupt section for the eTSEC. Quoting Kumar Gala ga...@kernel.crashing.org: Please don't top-post. The boards we received didn't have SPI compiled into the kernel and when we went to go re-compile the kernel using the 20081222 and 20080711 BSPs. I realize that the interrupts were reversed for eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no longer hang when I ping, etc. But I still can't get the board on the network. I've verified it isn't the network settings. You're sure you're not trying to talk to the switch (which will claim link-up regardless of what's plugged into it)? The non-switch ethernet port is eTSEC2. What *does* it do when you ping, if neither hang nor work? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev After remapping the IRQs, it is working now. Any idea on what I need to do to get SPI working? I've compiled it into the kernel but don't see anything in /proc/bus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
Josh Boyer wrote: 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 vbars...@ru.mvista.com Signed-off-by: Mikhail Zolotaryov le...@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. I've been looking at the docs once again and actually I couldn't find an explanation there. And I don't have that e-mail from AMCC support that I got a while back regarding the issue anymore. There might have been some misunderstanding. The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip select field width is always fixed at one bit, but this doesn't actually mean that there's always one chip select used. The patch works fine on Sequoia and another Sequoia-like board with 1GB RAM installed, but it might not work with 2GB RAM. I've tried to play with DDR0_10 settings and Sequoia works fine regardless of what's actually written to DDR0_10. So, probably the best way would be to fix that in u-boot amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x0100); instead of mtsdram(DDR0_10, 0x0300); Sorry, for confusion, but after reviewing the docs, I think that only REDUC interpretation has to be fixed. The chips select part should be fixed in u-boot sdram code for Sequoia as was originally proposed by Mikhail. Stefan, could you please take a look? Thanks, Valentine. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood scottw...@freescale.com wrote: One jiffy is fine, but two is just too long? Any number of jiffies is *not* too long if a timeout occurs. However, I think even one jiffy is too long if that's the normal condition. Unfortunately, the driver may not have any choice in some circumstances. If the hardware is just too slow to respond, and it doesn't provide interrupts, but the code is running in atomic context, and the function what else can it do? Disallow that, enforced with a call to might_sleep(). I think we need to be able to allow this function to work in atomic context. Is jiffies updated in atomic context? Alternatively, do something with get_cycles(), and have some sort of #define by which arches can say if get_cycles actually works. In the absence of a working get_cycles() or equivalent, timeouts with interrupts disabled aren't going to happen whether we abstract it with a macro or not. I think I can live with that. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Wed, 11 Mar 2009, Geert Uytterhoeven wrote: Are you aware the old one was introduced in 2.6.29-rc1? So there cannot be a regression from 2.6.28 or older. Ahh, no, that part hadn't registered. In that case, I guess I don't really care, as long as everybody involved feels it's clearly better than the one merged into -rc1. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
Timur Tabi wrote: On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood scottw...@freescale.com wrote: One jiffy is fine, but two is just too long? Any number of jiffies is *not* too long if a timeout occurs. However, I think even one jiffy is too long if that's the normal condition. I was under the impression that we were only talking about timeouts, and that the common case was significantly shorter than that. Unfortunately, the driver may not have any choice in some circumstances. If the hardware is just too slow to respond, and it doesn't provide interrupts, but the code is running in atomic context, and the function what else can it do? Rework the driver to poll from a periodic timer (like we do with PHYs). However, that's overkill when the hardware is supposed to respond in a handful of clocks, and preemption is enabled in case the timeout path does happen. Disallow that, enforced with a call to might_sleep(). I think we need to be able to allow this function to work in atomic context. Is jiffies updated in atomic context? If it's atomic because preemption was disabled, yes -- but even a rare extended spin in such a context would be bad for hard realtime. If interrupts are disabled, or the code is executing from a timer interrupt (or possibly other interrupts depending on the hardware and its priority scheme), no. Alternatively, do something with get_cycles(), and have some sort of #define by which arches can say if get_cycles actually works. In the absence of a working get_cycles() or equivalent, timeouts with interrupts disabled aren't going to happen whether we abstract it with a macro or not. I think I can live with that. Another option is to use udelay() on platforms without a working get_cycles(). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood scottw...@freescale.com wrote: I was under the impression that we were only talking about timeouts, and that the common case was significantly shorter than that. I think one of the concerns that Alan Cox raised is that the existence of this macro would encourage people to spin for long durations. If it's atomic because preemption was disabled, yes -- but even a rare extended spin in such a context would be bad for hard realtime. If interrupts are disabled, or the code is executing from a timer interrupt (or possibly other interrupts depending on the hardware and its priority scheme), no. So in that case, I can't rely on jiffies. I guess get_cycle() is my only choice. The problem is that there is no num_cycles_per_usec(). -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
Timur Tabi wrote: On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood scottw...@freescale.com wrote: I was under the impression that we were only talking about timeouts, and that the common case was significantly shorter than that. I think one of the concerns that Alan Cox raised is that the existence of this macro would encourage people to spin for long durations. Yes, and I've already stated my response to that line of thinking. I just don't see anyone who would have done something better than a spin loop changing their mind because doing a spin loop becomes a little easier -- the spin loop is *already* easier than the alternatives. What if another variant were added that did msleep between iterations, for longer expected completion times? Or if we want to be really fancy, combine them into one function that starts with small udelays, then switches to msleep of progressively larger intervals up to some maximum? If it's atomic because preemption was disabled, yes -- but even a rare extended spin in such a context would be bad for hard realtime. If interrupts are disabled, or the code is executing from a timer interrupt (or possibly other interrupts depending on the hardware and its priority scheme), no. So in that case, I can't rely on jiffies. Or you can say that atomic context is outside the scope of this macro. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
Scott Wood wrote: Or you can say that atomic context is outside the scope of this macro. No, I don't want to say that. We have wait_event_timeout() for larger-scale operations. I'm just looking for something that can replace while (!condition); -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
Timur Tabi wrote: Scott Wood wrote: Or you can say that atomic context is outside the scope of this macro. No, I don't want to say that. We have wait_event_timeout() for larger-scale operations. I'm just looking for something that can replace while (!condition); wait_event_timeout() requires a wait queue. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: fsldma driver questions
On Wed, Mar 11, 2009 at 10:52 AM, Crossley, Malcolm (GE EntSol, Intelligent Platforms) malcolm.crossl...@gefanuc.com wrote: I have noticed that append_ld_queue() changes the next link descriptor address field in the last link descriptor of the chain. The append_ld_queue function is called from the fsl_dma_tx_submit() which can called at any time by a kernel module using that channel. This could result in the link descriptor being changed whilst the DMA engine is running. Could this issue cause unexpected behavior of the DMA engine or the driver? I would need to study the code more thoroughly, but keep in mind that a DMA descriptor is read by the DMA controller only when it is about to be processed. It's okay to change the descriptor contents while the DMA buffer it references is being transferred. The new values in the descriptor won't be used until the DMA engine tries to use it the next time. A second question I have is to do with the dma_halt() routine setting the channel abort flag. The dma_halt() routine is called from fsl_chan_xfer_ld_queue() after the dma engine has been detected as idle. The dma_halt() routine sets the channel stop flag and the channel abort flag. Whilst the dma engine could be idle, it may not have completed a transfer AFAICT. Or if the engine is has no more transactions then a channel abort does not need to be issued anyway? I would need to study the code to answer this question. I wrote a different driver that uses this DMA controller, so I'm familiar with the controller but not the code. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/kconfig: Kill PPC_MULTIPLATFORM
On Wed, 2009-03-11 at 07:04 -0500, Kumar Gala wrote: 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 Maybe... In this case I didn't want to change it from what it was but you're right, it probably is hash64 only. Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: NFS problems on a MPC5200-based board
On Wed, 2009-03-11 at 16:08 +0100, Bartłomiej Sięka wrote: Hi, This is a follow-up on NFS problems on an MPC5200-based board reported here a while back: http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612 To recap: while using NFS, especially while mounting the root filesystem over NFS, the system is really slow and displays a bunch of nfs: server 192.168.1.1 not responding, still trying messages. Sometimes it is able to get to the login prompt, sometimes not. In cases where the login is successful, the system is still extremely sluggish (console hangs for tens of seconds and longer). git bisect narrows down the troublesome commit as: Maybe you need to set CPU_FTR_NEED_COHERENT for the 5200 ? Cheers, Ben. commit 4c456a67f501b8b15542c7c21c28812bf88f484b Author: Gerhard Pircher gerhard_pirc...@gmx.net Date: Fri Jan 23 06:51:28 2009 + powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code _PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL. Thus it has to be masked out, if the BAT mapping should be non cacheable or CPU_FTR_NEED_COHERENT is not set. This will work on normal SMP setups because we force-set CPU_FTR_NEED_COHERENT as part of CPU_FTR_COMMON on SMP. Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org We have tested recent mainline kernel (past 2.6.29-rc7) with the 4c456a6... commit reverted and NFS problems went away. Other people have also reported similar problems (original posters on Cc): http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792825.html http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792612.html The commit in question does not look directly related to NFS/ networking; moreover it is a fix for some other problem, so just reverting it is not an option, it seems (?). So how do we go about having NFS operational again? Any comments? Regards, Bartlomiej Sieka ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
No, not udelay. Or any delay for that matter. If spinning on a condition, then there is no advantage to burning cycles with a udelay(). Those cycles may as well be used to keep testing the condition so the loop can be exited faster. a udelay() would only serve to always make the busywait longer. Well, there's a non-empty set of HW where polling as fast as you can will effectively prevent it to make fwd progress... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
Benjamin Herrenschmidt wrote:
Well, there's a non-empty set of HW where polling as fast as you can
will effectively prevent it to make fwd progress...
Alan Cox mentioned this. He gave PCI and 10us as an example. I suggested
adding a third parameter that would be a udelay() inserted into the loop. He
countered with this:
spin_until_timeout(readb(foo) 0x80, 30 * HZ) {
udelay(10);
/* Maybe do other stuff */
}
But I don't know how to make that work *and* have it return a value indicating
timeout or success.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
On Wed, Mar 11, 2009 at 10:06:11PM +0300, Valentine Barshak wrote: Josh Boyer wrote: 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 vbars...@ru.mvista.com Signed-off-by: Mikhail Zolotaryov le...@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. I've been looking at the docs once again and actually I couldn't find an explanation there. And I don't have that e-mail from AMCC support that I got a while back regarding the issue anymore. There might have been some misunderstanding. The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip select field width is always fixed at one bit, but this doesn't actually mean that there's always one chip select used. The patch works fine on Sequoia and another Sequoia-like board with 1GB RAM installed, but it might not work with 2GB RAM. I've tried to play with DDR0_10 settings and Sequoia works fine regardless of what's actually written to DDR0_10. So, probably the best way would be to fix that in u-boot amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x0100); instead of mtsdram(DDR0_10, 0x0300); Sorry, for confusion, but after reviewing the docs, I think that only REDUC interpretation has to be fixed. The chips select part should be fixed in u-boot sdram code for Sequoia as was originally proposed by Mikhail. Ok, so we're back to using Mikhail's original patch then? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
Josh Boyer wrote: On Wed, Mar 11, 2009 at 10:06:11PM +0300, Valentine Barshak wrote: Josh Boyer wrote: 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 vbars...@ru.mvista.com Signed-off-by: Mikhail Zolotaryov le...@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. I've been looking at the docs once again and actually I couldn't find an explanation there. And I don't have that e-mail from AMCC support that I got a while back regarding the issue anymore. There might have been some misunderstanding. The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip select field width is always fixed at one bit, but this doesn't actually mean that there's always one chip select used. The patch works fine on Sequoia and another Sequoia-like board with 1GB RAM installed, but it might not work with 2GB RAM. I've tried to play with DDR0_10 settings and Sequoia works fine regardless of what's actually written to DDR0_10. So, probably the best way would be to fix that in u-boot amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x0100); instead of mtsdram(DDR0_10, 0x0300); Sorry, for confusion, but after reviewing the docs, I think that only REDUC interpretation has to be fixed. The chips select part should be fixed in u-boot sdram code for Sequoia as was originally proposed by Mikhail. Ok, so we're back to using Mikhail's original patch then? josh Yes, but until u-boot is fixed this will break Sequoia/Rainier support. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: make sysfs code use smp_call_function_single
Impact: performance improvement
This fixes 'powerpc: avoid cpumask games in arch/powerpc/kernel/sysfs.c'
which talked about using smp_call_function_single, but actually used
work_on_cpu (an older version of the patch).
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
arch/powerpc/kernel/sysfs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -135,14 +135,14 @@ EXPORT_SYMBOL(ppc_enable_pmcs);
EXPORT_SYMBOL(ppc_enable_pmcs);
#define SYSFS_PMCSETUP(NAME, ADDRESS) \
-static long read_##NAME(void *junk) \
+static void read_##NAME(void *val) \
{ \
- return mfspr(ADDRESS); \
+ *(unsigned long *)val = mfspr(ADDRESS); \
} \
static long write_##NAME(void *val) \
{ \
ppc_enable_pmcs(); \
- mtspr(ADDRESS, (unsigned long)val); \
+ mtspr(ADDRESS, *(unsigned long *)val); \
return 0; \
} \
static ssize_t show_##NAME(struct sys_device *dev, \
@@ -150,7 +150,8 @@ static ssize_t show_##NAME(struct sys_de
char *buf) \
{ \
struct cpu *cpu = container_of(dev, struct cpu, sysdev); \
- unsigned long val = work_on_cpu(cpu-sysdev.id, read_##NAME, NULL); \
+ unsigned long val; \
+ smp_call_function_single(cpu-sysdev.id, read_##NAME, val, 1); \
return sprintf(buf, %lx\n, val); \
} \
static ssize_t __used \
@@ -162,7 +163,7 @@ static ssize_t __used \
int ret = sscanf(buf, %lx, val); \
if (ret != 1) \
return -EINVAL; \
- work_on_cpu(cpu-sysdev.id, write_##NAME, (void *)val); \
+ smp_call_function_single(cpu-sysdev.id, write_##NAME, val, 1); \
return count; \
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: NFS problems on a MPC5200-based board
Original-Nachricht Datum: Thu, 12 Mar 2009 08:39:26 +1100 Von: Benjamin Herrenschmidt b...@kernel.crashing.org An: Bartłomiej Sięka t...@semihalf.com CC: linuxppc-dev@ozlabs.org, gerhard_pirc...@gmx.net, Grant Likely grant.lik...@secretlab.ca Betreff: Re: NFS problems on a MPC5200-based board On Wed, 2009-03-11 at 16:08 +0100, Bartłomiej Sięka wrote: Hi, This is a follow-up on NFS problems on an MPC5200-based board reported here a while back: http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612 To recap: while using NFS, especially while mounting the root filesystem over NFS, the system is really slow and displays a bunch of nfs: server 192.168.1.1 not responding, still trying messages. Sometimes it is able to get to the login prompt, sometimes not. In cases where the login is successful, the system is still extremely sluggish (console hangs for tens of seconds and longer). git bisect narrows down the troublesome commit as: Maybe you need to set CPU_FTR_NEED_COHERENT for the 5200 ? I would say the same, as the patch just replicates the CPU_FTR_NEED_COHERENT handling of the hash page table code. regards, Gerhard commit 4c456a67f501b8b15542c7c21c28812bf88f484b Author: Gerhard Pircher gerhard_pirc...@gmx.net Date: Fri Jan 23 06:51:28 2009 + powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code _PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL. Thus it has to be masked out, if the BAT mapping should be non cacheable or CPU_FTR_NEED_COHERENT is not set. This will work on normal SMP setups because we force-set CPU_FTR_NEED_COHERENT as part of CPU_FTR_COMMON on SMP. Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org We have tested recent mainline kernel (past 2.6.29-rc7) with the 4c456a6... commit reverted and NFS problems went away. Other people have also reported similar problems (original posters on Cc): http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792825.html http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792612.html The commit in question does not look directly related to NFS/ networking; moreover it is a fix for some other problem, so just reverting it is not an option, it seems (?). So how do we go about having NFS operational again? Any comments? Regards, Bartlomiej Sieka -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] introduce macro spin_event_timeout()
Timur Tabi wrote:
Benjamin Herrenschmidt wrote:
Well, there's a non-empty set of HW where polling as fast as you can
will effectively prevent it to make fwd progress...
Alan Cox mentioned this. He gave PCI and 10us as an example. I
suggested adding a third parameter that would be a udelay() inserted
into the loop. He countered with this:
spin_until_timeout(readb(foo) 0x80, 30 * HZ) {
udelay(10);
/* Maybe do other stuff */
}
Hmm, the person objecting that it could lead to people using it for
excessive timeouts suggested a timeout of *30 seconds*?
But I don't know how to make that work *and* have it return a value
indicating timeout or success.
And it also doesn't allow using the udelay as part of the timeout mechanism.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
On Thu, Mar 12, 2009 at 01:08:59AM +0300, Valentine wrote: So, probably the best way would be to fix that in u-boot amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x0100); instead of mtsdram(DDR0_10, 0x0300); Sorry, for confusion, but after reviewing the docs, I think that only REDUC interpretation has to be fixed. The chips select part should be fixed in u-boot sdram code for Sequoia as was originally proposed by Mikhail. Ok, so we're back to using Mikhail's original patch then? josh Yes, but until u-boot is fixed this will break Sequoia/Rainier support. Well, that's sort of a problem. The wrapper will have to deal with both a fixed and unfixed u-boot because not everyone will update their u-boot with the fix. So we need a patch for the wrapper that works in all cases. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] powerpc: clean up ssi.txt, add definition for fsl, ssi-asynchronous
Add the definition of the fsl,ssi-asynchronous property to ssi.txt (documentation of the device tree bindings for the Freescale SSI device). Also tidy up the layout of ssi.txt. Signed-off-by: Timur Tabi ti...@freescale.com --- v3: rebased v2: fixed typo, improved wording. Documentation/powerpc/dts-bindings/fsl/ssi.txt | 68 ++-- 1 files changed, 39 insertions(+), 29 deletions(-) diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt b/Documentation/powerpc/dts-bindings/fsl/ssi.txt index 7313322..5ff76c9 100644 --- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt +++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt @@ -4,46 +4,56 @@ The SSI is a serial device that communicates with audio codecs. It can be programmed in AC97, I2S, left-justified, or right-justified modes. Required properties: -- compatible : compatible list, containing fsl,ssi -- cell-index : the SSI, 0 = SSI1, 1 = SSI2, and so on -- reg: offset and length of the register set for the device -- interrupts : a b where a is the interrupt number and b is a - field that represents an encoding of the sense and - level information for the interrupt. This should be - encoded based on the information in section 2) - depending on the type of interrupt controller you - have. -- interrupt-parent : the phandle for the interrupt controller that - services interrupts for this device. -- fsl,mode : the operating mode for the SSI interface - i2s-slave - I2S mode, SSI is clock slave - i2s-master - I2S mode, SSI is clock master - lj-slave - left-justified mode, SSI is clock slave - lj-master - l.j. mode, SSI is clock master - rj-slave - right-justified mode, SSI is clock slave - rj-master - r.j., SSI is clock master - ac97-slave - AC97 mode, SSI is clock slave - ac97-master - AC97 mode, SSI is clock master -- fsl,playback-dma: phandle to a node for the DMA channel to use for +- compatible: Compatible list, contains fsl,ssi. +- cell-index: The SSI, 0 = SSI1, 1 = SSI2, and so on. +- reg: Offset and length of the register set for the device. +- interrupts: a b where a is the interrupt number and b is a +field that represents an encoding of the sense and +level information for the interrupt. This should be +encoded based on the information in section 2) +depending on the type of interrupt controller you +have. +- interrupt-parent: The phandle for the interrupt controller that +services interrupts for this device. +- fsl,mode: The operating mode for the SSI interface. +i2s-slave - I2S mode, SSI is clock slave +i2s-master - I2S mode, SSI is clock master +lj-slave - left-justified mode, SSI is clock slave +lj-master - l.j. mode, SSI is clock master +rj-slave - right-justified mode, SSI is clock slave +rj-master - r.j., SSI is clock master +ac97-slave - AC97 mode, SSI is clock slave +ac97-master - AC97 mode, SSI is clock master +- fsl,playback-dma: Phandle to a node for the DMA channel to use for playback of audio. This is typically dictated by SOC design. See the notes below. -- fsl,capture-dma: phandle to a node for the DMA channel to use for +- fsl,capture-dma: Phandle to a node for the DMA channel to use for capture (recording) of audio. This is typically dictated by SOC design. See the notes below. -- fsl,fifo-depth: the number of elements in the transmit and receive FIFOs. +- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs. This number is the maximum allowed value for SFCSR[TFWM0]. +- fsl,ssi-asynchronous: +If specified, the SSI is to be programmed in asynchronous +mode. In this mode, pins SRCK, STCK, SRFS, and STFS must +all be connected to valid signals. In synchronous mode, +SRCK and SRFS are ignored. Asynchronous mode allows +playback and capture to use different sample sizes and +sample rates. Some drivers may require that SRCK and STCK +be connected together, and SRFS and STFS be connected +together. This would still allow different sample sizes, +but not different sample rates. Optional properties: -- codec-handle : phandle to a 'codec' node that defines an audio - codec
[PATCH 1/3] powerpc: Fix page_ins details in lppaca comments
The page_ins member ends at byte 0x3, not 0x4. Also, fix up the
alignment.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
arch/powerpc/include/asm/lppaca.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/lppaca.h
b/arch/powerpc/include/asm/lppaca.h
index 25aaa97..b063121 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -133,7 +133,7 @@ struct lppaca {
//=
// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=
- u32 page_ins; // CMO Hint - # page ins by OS
x00-x04
+ u32 page_ins; // CMO Hint - # page ins by OS x00-x03
u8 pmc_save_area[252]; // PMC interrupt Area x04-xFF
} __attribute__((__aligned__(0x400)));
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: Add dispatch trace log fields to lppaca
PAPR v2.3 defines fields in the virtual processor area for a dispatch
trace log (DLT). Since we'd like to use the DLT, add the necessary
fields to struct lppaca.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
arch/powerpc/include/asm/lppaca.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h
b/arch/powerpc/include/asm/lppaca.h
index b063121..68235f7 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -97,7 +97,7 @@ struct lppaca {
u64 saved_gpr4; // Saved GPR4 x28-x2F
u64 saved_gpr5; // Saved GPR5 x30-x37
- u8 reserved4; // Reserved x38-x38
+ u8 dtl_enable_mask;// Dispatch Trace Log mask x38-x38
u8 donate_dedicated_cpu; // Donate dedicated CPU cycles x39-x39
u8 fpregs_in_use; // FP regs in use x3A-x3A
u8 pmcregs_in_use; // PMC regs in use x3B-x3B
@@ -134,7 +134,9 @@ struct lppaca {
// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=
u32 page_ins; // CMO Hint - # page ins by OS x00-x03
- u8 pmc_save_area[252]; // PMC interrupt Area x04-xFF
+ u8 reserved8[148]; // Reserved x04-x97
+ volatile u64 dtl_idx; // Dispatch Trace Log head idx x98-x9F
+ u8 reserved9[96]; // Reserved xA0-xFF
} __attribute__((__aligned__(0x400)));
extern struct lppaca lppaca[];
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: Add virtual processor dispatch trace log
pseries SPLPAR machines are able to retrieve a log of dispatch and
preempt events from the hypervisor. With this information, we can
see when and why each dispatch preempt is occuring.
This change adds a set of debugfs files allowing userspace to read this
dispatch log.
Based on initial patches from Nishanth Aravamudan n...@us.ibm.com.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
arch/powerpc/platforms/pseries/Kconfig | 10
arch/powerpc/platforms/pseries/Makefile |1
arch/powerpc/platforms/pseries/dtl.c| 274
arch/powerpc/platforms/pseries/plpar_wrappers.h | 10
4 files changed, 295 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index ddc2a30..730a5cd 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -63,3 +63,13 @@ config CMM
makes sense for a system running in an LPAR where the unused pages
will be reused for other LPARs. The interface allows firmware to
balance memory across many LPARs.
+
+config DTL
+ bool Dispatch Trace Log
+ depends on PPC_SPLPAR DEBUG_FS
+ help
+ SPLPAR machines can log hypervisor preempt dispatch events to a
+ kernel buffer. Saying Y here will enable logging these events,
+ which are accessible through a debugfs file.
+
+ Say N if you are unsure.
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index dfe574a..1b388b3 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_HVCS)+= hvcserver.o
obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
obj-$(CONFIG_PHYP_DUMP)+= phyp_dump.o
obj-$(CONFIG_CMM) += cmm.o
+obj-$(CONFIG_DTL) += dtl.o
diff --git a/arch/powerpc/platforms/pseries/dtl.c
b/arch/powerpc/platforms/pseries/dtl.c
new file mode 100644
index 000..dc9b0f8
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -0,0 +1,274 @@
+/*
+ * Virtual Processor Dispatch Trace Log
+ *
+ * (C) Copyright IBM Corporation 2009
+ *
+ * Author: Jeremy Kerr j...@ozlabs.org
+ *
+ * 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, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/init.h
+#include linux/debugfs.h
+#include asm/smp.h
+#include asm/system.h
+#include asm/uaccess.h
+
+#include plpar_wrappers.h
+
+/*
+ * Layout of entries in the hypervisor's DTL buffer. Although we don't
+ * actually access the internals of an entry (we only need to know the size),
+ * we might as well define it here for reference.
+ */
+struct dtl_entry {
+ u8 dispatch_reason;
+ u8 preempt_reason;
+ u16 processor_id;
+ u32 enqueue_to_dispatch_time;
+ u32 ready_to_enqueue_time;
+ u32 waiting_to_ready_time;
+ u64 timebase;
+ u64 fault_addr;
+ u64 srr0;
+ u64 srr1;
+};
+
+struct dtl {
+ struct dtl_entry*buf;
+ struct dentry *file;
+ int cpu;
+ int buf_entries;
+ u64 last_idx;
+};
+static DEFINE_PER_CPU(struct dtl, dtl);
+
+/*
+ * Dispatch trace log event mask:
+ * 0x7: 0x1: voluntary virtual processor waits
+ * 0x2: time-slice preempts
+ * 0x4: virtual partition memory page faults
+ */
+static u8 dtl_event_mask = 0x7;
+
+
+/*
+ * Size of per-cpu log buffers. Default is just under 16 pages worth.
+ */
+static int dtl_buf_entries = (16 * 85);
+
+
+static int dtl_enable(struct dtl *dtl)
+{
+ unsigned long addr;
+ int ret, hwcpu;
+
+ /* only allow one reader */
+ if (dtl-buf)
+ return -EBUSY;
+
+ /* we need to store the original allocation size for use during read */
+ dtl-buf_entries = dtl_buf_entries;
+
+ dtl-buf = kmalloc_node(dtl-buf_entries * sizeof(struct dtl_entry),
+ GFP_KERNEL, cpu_to_node(dtl-cpu));
+ if (!dtl-buf) {
+ printk(KERN_WARNING %s: buffer alloc failed for cpu %d\n,
+ __func__, dtl-cpu);
+ return -ENOMEM;
+ }
+
+ /* Register our dtl buffer with the hypervisor. The HV expects the
+* buffer
Interrupt mapping for MPC8323 board
We have a board similar to the MPC8323 rdb. In the board we have connected the IDSEL to AD18 we have only one minipci connector for it. We have interfaced a Wlan Card . When we do # lspci -x we get following 00:12.0 Network controller: RaLink RT2561/RT61 802.11g PCI 00: 14 18 01 03 07 00 10 04 00 00 80 02 08 80 00 00 10: 00 80 00 90 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 01 06 00 00 14 18 61 25 30: 00 00 00 00 40 00 00 00 00 00 00 00 13 01 00 00 In our circuit INTA is connected to IRQ4 . We are unable to transmit thro this card. We are not getting any interrupts.We want to make sure where to give the mapping of interrupts ? how to give that for IDsel AD 18, INTA should be mapped to IRQ4 . Is it that we need to change the dts file create a new dtb? if so where to get exact meaning of how to configure interrupt mapping in the dts file Regards Praveen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
