Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
Hello, Some time ago (July 24th 2009 my mailbox says) I emailed you and the linuxppc-dev list about my problems booting from the mesh SCSI controller. I just compiled 2.6.31 (actually, gentoo-sources-2.6.31-r10); but the problem remains I know that 2.6.33 is out, but as I didn't see any changes to the mesh-driver I guess that the problem is still there ... This is the logging I get when I boot (2.6.31): mesh_abort(ef8501e0) mesh: state at ef9eaa50, regs at f101, dma at f1014a00 ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0 dma stat=e0 cmdptr=2f8c2010 phase=5 msgphase=0 conn_tgt=0 data_ptr=0 dma_st=0 dma_ct=0 n_msgout=0 target 0: req=ef85901e0 goes_out=0 saved_ptr=0 mesh_abort(ef850280) mesh: state at ef9eaa50, regs at f101, dma at f1014a00 ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0 dma stat=e0 cmdptr=2f8c2010 phase=5 msgphase=0 conn_tgt=0 data_ptr=0 dma_st=0 dma_ct=0 n_msgout=0 target 0: req=ef8501e0 goes_out=0 saved_ptr=0 mesh_host_reset mesh_abort(ef8501e0) mesh: state at ef9eaa50, regs at f101, dma at f1014a00 ct= 0 seq=6a bs=4026 fc= 5 exc= 0 err= 0 im= 7 int= 0 sp= 2 fifo data=c0 fifo data=01 fifo data=03 fifo data=01 fifo data=19 dma stat=e0 cmdptr=2f8c2010 phase=3 msgphase=1 conn_tgt=0 data_ptr=0 dma_st=0 dma_ct=0 n_msgout=6 target 0: req=ef8501e0 goes_out=0 saved_ptr=0 mesh_host_reset ... [afterwards, it disconnects all the disks and then it panics as it cannot find the root partition] 2.6.29 runs fine ... but I guess that at some point, I would like to upgrade to the latest stable kernel. The machine is a PowerPC9600 with a 740 upgrade card, 1GB memory, kernel compiled with GCC 4.3.4 ... Of course I am willing to offer you all assistance you need to help you pin-point the problem... Thanks for your help Stef Stef Simoens schreef: Hello Ben, Thank you for your reply. On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote: I tried the latest 2.6.31-rc3-git3 (without any other patch). However, I have the same behaviour as the patched 2.6.30 (so: no BUG, but the mesh_abort messages). Would it be possible for you to roughly find out at what kernel version it stopped working ? (Some kernels may need my patch to avoid crashing) I am currently running 2.6.29-gentoo-r5 (that's somewhere at the end of 2.6.29, probably 2.6.29.5). I compiled 2.6.30 as soon as it came 'stable'. In any version of 2.6.30, I encounter the BUG (dma-mapping.h:218). I didn't react immediately, I actually guessed that the problem would have been reported and solved in another 2.6.30.x. Because it didn't, I started browsing the mailing-list (and found your patch). 2.6.30-gentoo-r3 with your patch applied doesn't give the bug, but gives the mesh_abort. Before asking the question, I wanted to build the latest 2.6.31-rc available to make sure my problem didn't get solved in the meantime. 2.6.31-rc3 gives the same mesh_abort. Would you like me to try all the linux-2.6.30-rc? Could you give me your best guess starting-point? I know that there exists something as git-disect ... but I have never used git (there always needs to be the first time, of course). Kind regards, Stef -- Stef Simoens stef.simo...@numericable.be +32 486 577 963 http://users.numericable.be/stef ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Skip over OF_DT_NOP when unflattening the device tree
On Fri, Mar 19, 2010 at 04:50:38PM +1100, Benjamin Herrenschmidt wrote: On Tue, 2010-03-09 at 12:30 -0700, Jason Gunthorpe wrote: NOPs within the property section are skipped, but NOPs between OF_DT_END_NODE and OF_DT_BEGIN_NODE were not. My firmware NOPs out entire nodes depending on various environment parameters. of_scan_flat_dt already handles NOP more generally.. Good catch, though that code has now moved over to drivers/of and is a bit different. Grant is going to fix it up though. Ah, I based the patch off 2.6.33.. Grant: let me know if you need some help/testing, nice to run into you again. Jason ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Skip over OF_DT_NOP when unflattening the device tree
On Fri, Mar 19, 2010 at 12:06 AM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Fri, Mar 19, 2010 at 04:50:38PM +1100, Benjamin Herrenschmidt wrote: On Tue, 2010-03-09 at 12:30 -0700, Jason Gunthorpe wrote: NOPs within the property section are skipped, but NOPs between OF_DT_END_NODE and OF_DT_BEGIN_NODE were not. My firmware NOPs out entire nodes depending on various environment parameters. of_scan_flat_dt already handles NOP more generally.. Good catch, though that code has now moved over to drivers/of and is a bit different. Grant is going to fix it up though. Ah, I based the patch off 2.6.33.. Grant: let me know if you need some help/testing, nice to run into you again. Would be nice if you could respin and test your patch against 2.6.34-rc1. :-) Otherwise I'll look at it tomorrow. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's a handful of powerpc fixes for 2.6.34, along with a patch from Fujita Tomonori to remove a config option that is mostly useless nowadays. Cheers, Ben. The following changes since commit 39710479303fd3affb3e204e9a7a75cc676977b5: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../vapier/blackfin are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Benjamin Herrenschmidt (1): Merge commit 'kumar/merge' into merge FUJITA Tomonori (2): powerpc: Fix swiotlb to respect the boot option powerpc: Remove IOMMU_VMERGE config option Kumar Gala (2): powerpc/85xx: Make sure lwarx hint isn't set on ppc32 powerpc/fsl-booke: Get coherent bit from PTE Márton Németh (1): powerpc: Do not call prink when CONFIG_PRINTK is not defined Nathan Lynch (1): powerpc: Use correct ccr bit for syscall error status arch/powerpc/Kconfig | 13 - arch/powerpc/include/asm/ppc-opcode.h |6 +++--- arch/powerpc/include/asm/syscall.h|6 +++--- arch/powerpc/kernel/head_fsl_booke.S |7 --- arch/powerpc/kernel/iommu.c |7 +-- arch/powerpc/kernel/setup_32.c|6 -- arch/powerpc/kernel/setup_64.c|6 -- arch/powerpc/mm/mem.c |6 ++ 8 files changed, 17 insertions(+), 40 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BestComm BD tasks, buffer done flag question
Hello,
I'm using Grant's platform SCLPC/BestComm driver to transfer data from
an FPGA (to disk). Very often I get a negative result from
bcom_buffer_done because BCOM_BD_READY is not set.
When searching for a solution I found this mail from Rob Broersen
talking about a similar promlem in the MPC5200's FEC interrupt
handler:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg16324.html
When I now do something ugly like
if (!bcom_buffer_done(lpbfifo-bcom_cur_task))
mdelay(1);
/* retry */
if (!bcom_buffer_done(lpbfifo-bcom_cur_task)) {
ERROR!!!
return IRQ_HANDLED;
}
HANDLE BD
in the ISR I always succeed, even in the cases where the first check
fails and I call the mdelay. Before that I very often ran into the
ERROR!!! case and my transfer failed.
Is there a better solution? Does the FEC interrupt handler really work
fine as it is right now? I ask, because when I assume that there would
be just one active DB (as it always is with the SCLPC platform driver)
this one would evt. stall if there wasn't a second interrupt causing
the loop to handle it in this second interrupt.
Roman
--
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH]: Minor quibble in macintosh/windfarm_pm81.c
Hello there, I just ran the sourceforge tool cppcheck over the source code of the new Linux kernel 2.6.34-rc1 It said [./macintosh/windfarm_pm81.c:760]: (style) Redundant condition. It is safe to deallocate a NULL poin ter [./macintosh/windfarm_pm81.c:762]: (style) Redundant condition. It is safe to deallocate a NULL poin ter The source code is /* Destroy control loops state structures */ if (wf_smu_sys_fans) kfree(wf_smu_sys_fans); if (wf_smu_cpu_fans) kfree(wf_smu_cpu_fans); Proposed patch file attached. Regards David Binderman _ Send us your Hotmail stories and be featured in our newsletter http://clk.atdmt.com/UKM/go/195013117/direct/01/ Signed-off-by: David Binderman dcb...@hotmail.com --- macintosh/windfarm_pm81.c.sav 2010-03-19 08:57:22.0 + +++ macintosh/windfarm_pm81.c 2010-03-19 08:57:34.0 + @@ -757,10 +757,8 @@ static int __devexit wf_smu_remove(struc wf_put_control(cpufreq_clamp); /* Destroy control loops state structures */ - if (wf_smu_sys_fans) - kfree(wf_smu_sys_fans); - if (wf_smu_cpu_fans) - kfree(wf_smu_cpu_fans); + kfree(wf_smu_sys_fans); + kfree(wf_smu_cpu_fans); return 0; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH]: core/gpio-pmf.c: 3 * redundant code
_ Send us your Hotmail stories and be featured in our newsletter http://clk.atdmt.com/UKM/go/195013117/direct/01/ Signed-off-by: David Binderman dcb...@hotmail.com --- aoa/core/gpio-pmf.c.sav 2010-03-19 10:07:30.0 + +++ aoa/core/gpio-pmf.c 2010-03-19 10:07:40.0 + @@ -115,12 +115,9 @@ static void pmf_gpio_exit(struct gpio_ru mutex_destroy(rt-line_in_notify.mutex); mutex_destroy(rt-line_out_notify.mutex); - if (rt-headphone_notify.gpio_private) - kfree(rt-headphone_notify.gpio_private); - if (rt-line_in_notify.gpio_private) - kfree(rt-line_in_notify.gpio_private); - if (rt-line_out_notify.gpio_private) - kfree(rt-line_out_notify.gpio_private); + kfree(rt-headphone_notify.gpio_private); + kfree(rt-line_in_notify.gpio_private); + kfree(rt-line_out_notify.gpio_private); } static void pmf_handle_notify_irq(void *data) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[GITPULL+PATCH 0/2 v3] irq: move some interrupt arch_* functions into struct irq_chip.
This small series ensures that struct irq_desc-chip_data is available for alternative irq_chip implementations. Since v2: pass x86_init_chip_data as a argument to irq_to_desc_alloc_node instead of calling in the arch code in order to get correct locking wrt the core code. Small impact on the SH arch code which is the only other user outside x86 and powerpc. Since v1: dropped the renaming portion of the series since it was basically wrong, the functions I'd implicated as ioapic specific are not at all. Ian. The following changes since commit 1ebbdcc83e75697c0d75eb091df172b7d93c84c1: Ingo Molnar (1): Merge branch 'perf/urgent' are available in the git repository at: git://xenbits.xensource.com/people/ianc/linux-2.6.git for-x86/irq Ian Campbell (2): irq: move some interrupt arch_* functions into struct irq_chip. x86: irq_desc-chip_data is always correct whether or not SPARSE_IRQ is enabled. arch/powerpc/kernel/irq.c |4 +- arch/sh/kernel/cpu/irq/ipr.c |2 +- arch/x86/include/asm/hw_irq.h | 11 ++- arch/x86/kernel/apic/io_apic.c | 67 arch/x86/kernel/uv_irq.c |5 +++ arch/x86/lguest/boot.c |2 +- drivers/sh/intc.c |7 ++-- drivers/xen/events.c |2 +- include/linux/interrupt.h |2 +- include/linux/irq.h| 16 ++--- kernel/irq/handle.c| 15 ++--- kernel/irq/numa_migrate.c | 12 ++- kernel/softirq.c |3 +- 13 files changed, 111 insertions(+), 37 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] irq: move some interrupt arch_* functions into struct irq_chip.
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
arch_init_chip_data cannot be moved into struct irq_chip because
irq_desc-chip is not known at the time the irq_desc is setup. Instead
rename arch_init_chip_data to arch_init_irq_desc for PowerPC, the
only other user, whose usage better matches the new name.
To replace the x86 arch_init_chip_data functionality
irq_to_desc_alloc_node now takes a pointer to a function to allocate
the chip data. This is necessary to ensure the allocation happens
under the correct locking at the core level. On PowerPC and SH
architectures (the other users of irq_to_desc_alloc_node) pass in NULL
which retains existing chip_data behaviour.
I've retained the chip_data behaviour for uv_irq although it isn't
clear to me if these interrupt types support migration or how closely
related to the APIC modes they really are. If it weren't for this the
x86_{init,copy,free}_chip_data functions could be static to
io_apic.c.
I've tested by booting on an 64 bit x86 system with sparse IRQ enabled
and 32 bit without, but it's not clear to me what actions I need to
take to actually exercise some of these code paths.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Michael Ellerman mich...@ellerman.id.au [PowerPC rename portion]
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Yinghai Lu ying...@kernel.org
Cc: Jeremy Fitzhardinge jer...@goop.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: x...@kernel.org
Cc: linuxppc-...@ozlabs.org
Cc: linux-ker...@vger.kernel.org
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: lgu...@ozlabs.org
Cc: Paul Mundt let...@linux-sh.org
Cc: linux...@vger.kernel.org
---
arch/powerpc/kernel/irq.c |4 +-
arch/sh/kernel/cpu/irq/ipr.c |2 +-
arch/x86/include/asm/hw_irq.h | 11 ++-
arch/x86/kernel/apic/io_apic.c | 64 ++-
arch/x86/kernel/uv_irq.c |5 +++
arch/x86/lguest/boot.c |2 +-
drivers/sh/intc.c |7 ++--
drivers/xen/events.c |2 +-
include/linux/interrupt.h |2 +-
include/linux/irq.h| 16 +++---
kernel/irq/handle.c| 15 ++---
kernel/irq/numa_migrate.c | 12 ++-
kernel/softirq.c |3 +-
13 files changed, 112 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..dc5a8c1 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -670,7 +670,7 @@ static int irq_setup_virq(struct irq_host *host, unsigned
int virq,
{
struct irq_desc *desc;
- desc = irq_to_desc_alloc_node(virq, 0);
+ desc = irq_to_desc_alloc_node(virq, 0, NULL);
if (!desc) {
pr_debug(irq: - allocating desc failed\n);
goto error;
@@ -1088,7 +1088,7 @@ int arch_early_irq_init(void)
return 0;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int arch_init_irq_desc(struct irq_desc *desc, int node)
{
desc-status |= IRQ_NOREQUEST;
return 0;
diff --git a/arch/sh/kernel/cpu/irq/ipr.c b/arch/sh/kernel/cpu/irq/ipr.c
index 9282d96..cf31454 100644
--- a/arch/sh/kernel/cpu/irq/ipr.c
+++ b/arch/sh/kernel/cpu/irq/ipr.c
@@ -67,7 +67,7 @@ void register_ipr_controller(struct ipr_desc *desc)
BUG_ON(p-ipr_idx = desc-nr_offsets);
BUG_ON(!desc-ipr_offsets[p-ipr_idx]);
- irq_desc = irq_to_desc_alloc_node(p-irq, numa_node_id());
+ irq_desc = irq_to_desc_alloc_node(p-irq, numa_node_id(), NULL);
if (unlikely(!irq_desc)) {
printk(KERN_INFO can not get irq_desc for %d\n,
p-irq);
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index a929c9e..1bc7063 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -20,9 +20,9 @@
#include linux/percpu.h
#include linux/profile.h
#include linux/smp.h
+#include linux/irq.h
#include asm/atomic.h
-#include asm/irq.h
#include asm/sections.h
/* Interrupt handlers registered during init_IRQ */
@@ -61,6 +61,15 @@ extern void init_VISWS_APIC_irqs(void);
extern void setup_IO_APIC(void);
extern void disable_IO_APIC(void);
+extern int x86_init_chip_data(struct irq_desc *desc, int node);
+
+#ifdef CONFIG_SPARSE_IRQ
+extern void x86_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node);
+extern void x86_free_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc);
+#endif
+
struct io_apic_irq_attr {
int ioapic;
int ioapic_pin;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
Re: [PATCH] powerpc/fsl: Add multiple MSI bank support
On Mar 18, 2010, at 10:06 PM, Michael Ellerman wrote:
On Thu, 2010-03-18 at 09:53 -0500, Kumar Gala wrote:
From: Lan Chunhe-B25806 b25...@freescale.com
Freescale QorIQ P4080 has three MSI banks and the original code
can not work well. This patch adds multiple MSI banks support for
Freescale processor.
Signed-off-by: Lan Chunhe-B25806 b25...@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
@@ -146,9 +149,13 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int
nvec, int type)
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
-struct fsl_msi *msi_data = fsl_msi;
+struct fsl_msi *msi_data;
list_for_each_entry(entry, pdev-msi_list, list) {
+if (entry-irq == NO_IRQ)
+continue;
This looks wrong, entry-irq should always be 0 here because it was just
kzalloc'ed - you should only be doing this check in teardown.
-WARN_ON(ppc_md.setup_msi_irqs);
-ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
-ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
-ppc_md.msi_check_device = fsl_msi_check_device;
+/* The multiple setting ppc_md.setup_msi_irqs will not harm things */
+if (!ppc_md.setup_msi_irqs) {
+ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
+ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
+ppc_md.msi_check_device = fsl_msi_check_device;
+} else if (ppc_md.setup_msi_irqs != fsl_setup_msi_irqs) {
+dev_err(dev-dev, Different MSI driver already installed!\n);
+err = -EBUSY; /* or some other error code */
+goto error_out;
+}
I liked it the way it was, because having two competing MSI backends
means something's probably not going to work. But it's your driver so
whatever you like.
The previous WARN_ON() is problematic when we have multiple (of the same type)
MSI blocks. The check was intended to do exactly what you are suggesting. If
you think its doing something else let us know.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
From: Amit Shah amit.s...@redhat.com
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
same time.
In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself
So this can happen
hvc_close hvc_remove
hung up ? - no
lock
tty = hp-tty
unlock
lock
hp-tty = NULL
unlock
notify del
kref_put the hvc struct
close completes
tty is destroyed
tty_hangup dead tty
tty-ops will be NULL
NULL-...
This patch adds some tty krefs and also converts to using tty_vhangup().
Reported-by: Alan Cox a...@lxorguk.ukuu.org.uk
Signed-off-by: Amit Shah amit.s...@redhat.com
CC: Alan Cox a...@lxorguk.ukuu.org.uk
CC: linuxppc-...@ozlabs.org
CC: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/char/hvc_console.c | 31 +--
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 465185f..ba55bba 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -312,6 +312,7 @@ static int hvc_open(struct tty_struct *tty, struct file *
filp)
spin_lock_irqsave(hp-lock, flags);
/* Check and then increment for fast path open. */
if (hp-count++ 0) {
+ tty_kref_get(tty);
spin_unlock_irqrestore(hp-lock, flags);
hvc_kick();
return 0;
@@ -319,7 +320,7 @@ static int hvc_open(struct tty_struct *tty, struct file *
filp)
tty-driver_data = hp;
- hp-tty = tty;
+ hp-tty = tty_kref_get(tty);
spin_unlock_irqrestore(hp-lock, flags);
@@ -336,6 +337,7 @@ static int hvc_open(struct tty_struct *tty, struct file *
filp)
spin_lock_irqsave(hp-lock, flags);
hp-tty = NULL;
spin_unlock_irqrestore(hp-lock, flags);
+ tty_kref_put(tty);
tty-driver_data = NULL;
kref_put(hp-kref, destroy_hvc_struct);
printk(KERN_ERR hvc_open: request_irq failed with rc %d.\n,
rc);
@@ -363,13 +365,18 @@ static void hvc_close(struct tty_struct *tty, struct file
* filp)
return;
hp = tty-driver_data;
+
spin_lock_irqsave(hp-lock, flags);
+ tty_kref_get(tty);
if (--hp-count == 0) {
/* We are done with the tty pointer now. */
hp-tty = NULL;
spin_unlock_irqrestore(hp-lock, flags);
+ /* Put the ref obtained in hvc_open() */
+ tty_kref_put(tty);
+
if (hp-ops-notifier_del)
hp-ops-notifier_del(hp, hp-data);
@@ -389,6 +396,7 @@ static void hvc_close(struct tty_struct *tty, struct file *
filp)
spin_unlock_irqrestore(hp-lock, flags);
}
+ tty_kref_put(tty);
kref_put(hp-kref, destroy_hvc_struct);
}
@@ -424,10 +432,11 @@ static void hvc_hangup(struct tty_struct *tty)
spin_unlock_irqrestore(hp-lock, flags);
if (hp-ops-notifier_hangup)
- hp-ops-notifier_hangup(hp, hp-data);
+ hp-ops-notifier_hangup(hp, hp-data);
while(temp_open_count) {
--temp_open_count;
+ tty_kref_put(tty);
kref_put(hp-kref, destroy_hvc_struct);
}
}
@@ -592,7 +601,7 @@ int hvc_poll(struct hvc_struct *hp)
}
/* No tty attached, just skip */
- tty = hp-tty;
+ tty = tty_kref_get(hp-tty);
if (tty == NULL)
goto bail;
@@ -672,6 +681,8 @@ int hvc_poll(struct hvc_struct *hp)
tty_flip_buffer_push(tty);
}
+ if (tty)
+ tty_kref_put(tty);
return poll_mask;
}
@@ -807,7 +818,7 @@ int hvc_remove(struct hvc_struct *hp)
struct tty_struct *tty;
spin_lock_irqsave(hp-lock, flags);
- tty = hp-tty;
+ tty = tty_kref_get(hp-tty);
if (hp-index MAX_NR_HVC_CONSOLES)
vtermnos[hp-index] = -1;
@@ -819,18 +830,18 @@ int hvc_remove(struct hvc_struct *hp)
/*
* We 'put' the instance that was grabbed when the kref instance
* was initialized using kref_init(). Let the last holder of this
-* kref cause it to be removed, which will probably be the tty_hangup
+* kref cause it to be removed, which will probably be the tty_vhangup
* below.
*/
[PATCH] [RFC] Xilinx Virtex 4 FX Soft FPU support
This patch enables support for Xilinx Virtex 4 FX singe-float FPU. Caveats: - Hard-float binaries which rely on in-kernel math emulation will give wrong results since they expect 64-bit double-precision instead of 32-bit single- precision numbers. Regards, Sergey Temerkhanov ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx Virtex 4 FX Soft FPU support
The patch. Regards, Resgey Temerkhanov diff -r 9d9ac97e095d .config --- a/.config Thu Feb 25 21:23:42 2010 +0300 +++ b/.config Thu Feb 25 21:49:02 2010 +0300 @@ -14,10 +14,12 @@ CONFIG_40x=y # CONFIG_44x is not set # CONFIG_E200 is not set +CONFIG_PPC_FPU=y CONFIG_4xx=y CONFIG_PPC_MMU_NOHASH=y # CONFIG_PPC_MM_SLICES is not set CONFIG_NOT_COHERENT_CACHE=y +CONFIG_XILINX_FPU=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set @@ -227,7 +229,7 @@ CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y # CONFIG_HAVE_AOUT is not set # CONFIG_BINFMT_MISC is not set -CONFIG_MATH_EMULATION=y +# CONFIG_MATH_EMULATION is not set # CONFIG_IOMMU_HELPER is not set # CONFIG_SWIOTLB is not set CONFIG_PPC_NEED_DMA_SYNC_OPS=y diff -r 9d9ac97e095d arch/powerpc/include/asm/ppc_asm.h --- a/arch/powerpc/include/asm/ppc_asm.h Thu Feb 25 21:23:42 2010 +0300 +++ b/arch/powerpc/include/asm/ppc_asm.h Thu Feb 25 21:49:02 2010 +0300 @@ -85,13 +85,23 @@ #define REST_8GPRS(n, base) REST_4GPRS(n, base); REST_4GPRS(n+4, base) #define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base) -#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) + +#ifdef CONFIG_XILINX_FPU +#define stfr stfs +#define lfr lfs +#else +#define stfr stfd +#define lfr lfd +#endif + + +#define SAVE_FPR(n, base) stfr n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) #define SAVE_2FPRS(n, base) SAVE_FPR(n, base); SAVE_FPR(n+1, base) #define SAVE_4FPRS(n, base) SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base) #define SAVE_8FPRS(n, base) SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base) #define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base) #define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base) -#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) +#define REST_FPR(n, base) lfr n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) #define REST_2FPRS(n, base) REST_FPR(n, base); REST_FPR(n+1, base) #define REST_4FPRS(n, base) REST_2FPRS(n, base); REST_2FPRS(n+2, base) #define REST_8FPRS(n, base) REST_4FPRS(n, base); REST_4FPRS(n+4, base) diff -r 9d9ac97e095d arch/powerpc/kernel/fpu.S --- a/arch/powerpc/kernel/fpu.S Thu Feb 25 21:23:42 2010 +0300 +++ b/arch/powerpc/kernel/fpu.S Thu Feb 25 21:49:02 2010 +0300 @@ -57,6 +57,9 @@ _GLOBAL(load_up_fpu) mfmsr r5 ori r5,r5,MSR_FP +#ifdef CONFIG_XILINX_FPU + oris r5,r5,msr_...@h +#endif #ifdef CONFIG_VSX BEGIN_FTR_SECTION oris r5,r5,msr_...@h @@ -85,6 +88,9 @@ toreal(r5) PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5) li r10,MSR_FP|MSR_FE0|MSR_FE1 +#ifdef CONFIG_XILINX_FPU + oris r10,r10,msr_...@h +#endif andc r4,r4,r10 /* disable FP for previous task */ PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5) 1: @@ -94,6 +100,9 @@ mfspr r5,SPRN_SPRG3 /* current task's THREAD (phys) */ lwz r4,THREAD_FPEXC_MODE(r5) ori r9,r9,MSR_FP /* enable FP for current */ +#ifdef CONFIG_XILINX_FPU + oris r9,r9,msr_...@h +#endif or r9,r9,r4 #else ld r4,PACACURRENT(r13) @@ -124,6 +133,9 @@ _GLOBAL(giveup_fpu) mfmsr r5 ori r5,r5,MSR_FP +#ifdef CONFIG_XILINX_FPU + oris r5,r5,msr_...@h +#endif #ifdef CONFIG_VSX BEGIN_FTR_SECTION oris r5,r5,msr_...@h @@ -145,6 +157,9 @@ beq 1f PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5) li r3,MSR_FP|MSR_FE0|MSR_FE1 +#ifdef CONFIG_XILINX_FPU + oris r3,r3,msr_...@h +#endif #ifdef CONFIG_VSX BEGIN_FTR_SECTION oris r3,r3,msr_...@h diff -r 9d9ac97e095d arch/powerpc/kernel/head_40x.S --- a/arch/powerpc/kernel/head_40x.S Thu Feb 25 21:23:42 2010 +0300 +++ b/arch/powerpc/kernel/head_40x.S Thu Feb 25 21:49:02 2010 +0300 @@ -420,7 +420,19 @@ addi r3,r1,STACK_FRAME_OVERHEAD EXC_XFER_STD(0x700, program_check_exception) +/* 0x0800 - FPU unavailable Exception */ +#ifdef CONFIG_PPC_FPU + START_EXCEPTION(0x0800, FloatingPointUnavailable) + NORMAL_EXCEPTION_PROLOG + beq 1f; \ + bl load_up_fpu; /* if from user, just load it up */ \ + b fast_exception_return; \ +1: addi r3,r1,STACK_FRAME_OVERHEAD; \ + EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception) +#else EXCEPTION(0x0800, Trap_08, unknown_exception, EXC_XFER_EE) +#endif + EXCEPTION(0x0900, Trap_09, unknown_exception, EXC_XFER_EE) EXCEPTION(0x0A00, Trap_0A, unknown_exception, EXC_XFER_EE) EXCEPTION(0x0B00, Trap_0B, unknown_exception, EXC_XFER_EE) @@ -432,7 +444,7 @@ EXCEPTION(0x0D00, Trap_0D, unknown_exception, EXC_XFER_EE) EXCEPTION(0x0E00, Trap_0E, unknown_exception, EXC_XFER_EE) - EXCEPTION(0x0F00, Trap_0F, unknown_exception, EXC_XFER_EE) + EXCEPTION(0x0F20, Trap_0F, unknown_exception, EXC_XFER_EE) /* 0x1000 - Programmable Interval Timer (PIT) Exception */ START_EXCEPTION(0x1000, Decrementer) @@ -821,8 +833,10 @@ * The PowerPC 4xx family of processors do not have an FPU, so this just * returns. */ +#ifndef CONFIG_PPC_FPU _ENTRY(giveup_fpu) blr +#endif /* This is where the main kernel code starts. */ diff -r 9d9ac97e095d arch/powerpc/platforms/Kconfig.cputype --- a/arch/powerpc/platforms/Kconfig.cputype
[PATCH v5 01/10] swiotbl: add back swiotlb_alloc_boot()
This patch makes swiotlb_alloc_boot() available again.
This weak function can be overloaded to modify slightly how the SWIOTLB
and the overflow areas are allocated during boot.
This will be used later to support the Nintendo Wii video game console,
which requires placing the SWIOTLB area above 0x1000 (MEM2).
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
include/linux/swiotlb.h |1 +
lib/swiotlb.c | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 8550d6b..c769939 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -54,6 +54,7 @@ extern void swiotlb_bounce(phys_addr_t phys, char *dma_addr,
size_t size,
enum dma_data_direction dir);
extern void swiotlb_full(struct device *dev, size_t size, int dir, int
do_panic);
+extern void __init *swiotlb_alloc_boot(size_t bytes, unsigned long nslabs);
#endif
/* swiotlb.c: dma_ops functions. */
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index c6bfa5d..ab1622a 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -136,6 +136,11 @@ void swiotlb_print_info(void)
(unsigned long long)pend);
}
+void * __weak __init swiotlb_alloc_boot(size_t size, unsigned long nslabs)
+{
+ return alloc_bootmem_low_pages(size);
+}
+
/*
* Statically reserve bounce buffer space and initialize bounce buffer data
* structures for the software IO TLB used to implement the DMA API.
@@ -155,7 +160,7 @@ swiotlb_init_with_default_size(size_t default_size, int
verbose)
/*
* Get IO TLB memory from the low pages
*/
- swiotlb_bk_start = alloc_bootmem_low_pages(bytes);
+ swiotlb_bk_start = swiotlb_alloc_boot(bytes, swiotlb_bk_nslabs);
if (!swiotlb_bk_start)
panic(Cannot allocate SWIOTLB buffer);
swiotlb_bk_end = swiotlb_bk_start + bytes;
@@ -175,7 +180,8 @@ swiotlb_init_with_default_size(size_t default_size, int
verbose)
/*
* Get the overflow emergency buffer
*/
- swiotlb_bk_overflow_buffer = alloc_bootmem_low(swiotlb_bk_overflow);
+ swiotlb_bk_overflow_buffer = swiotlb_alloc_boot(swiotlb_bk_overflow,
+ swiotlb_bk_nslabs);
if (!swiotlb_bk_overflow_buffer)
panic(Cannot allocate SWIOTLB overflow buffer!\n);
if (verbose)
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 02/10] swiotlb: make swiotlb_bounce() __weak
This patch converts swiotlb_bounce() into a weak function making it
overloadable by platform support code.
This will be used later to support the Nintendo Wii video game console,
which is a NOT_COHERENT_CACHE platform and requires explicit cache handling
when dealing with the swiotlb bounce buffers.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
lib/swiotlb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index ab1622a..9ce5cd2 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -328,7 +328,7 @@ EXPORT_SYMBOL_GPL(is_swiotlb_buffer);
/*
* Bounce: copy the swiotlb buffer back to the original dma location
*/
-void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
+void __weak swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
enum dma_data_direction dir)
{
unsigned long pfn = PFN_DOWN(phys);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 04/10] powerpc: add min_direct_dma_addr
This patch adds min_direct_dma_addr to struct dev_archdata.
min_direct_dma_addr can be used to define which is the minimum address
suitable for a DMA operation.
dma_capable() is updated to use this information in the SWIOTLB case.
This will be used later to support the Nintendo Wii video game console
which has limitations performing DMA to memory below 0x1000 (MEM1).
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/include/asm/device.h |1 +
arch/powerpc/include/asm/dma-mapping.h |2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 6d94d27..23f0009 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -27,6 +27,7 @@ struct dev_archdata {
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
+ dma_addr_t min_direct_dma_addr;
#endif
};
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 18ecec8..eda3ebe 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -193,6 +193,8 @@ static inline bool dma_capable(struct device *dev,
dma_addr_t addr, size_t size)
if (sd-max_direct_dma_addr addr + size sd-max_direct_dma_addr)
return 0;
+ if (sd-min_direct_dma_addr addr sd-min_direct_dma_addr)
+ return 0;
#endif
if (!dev-dma_mask)
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 05/10] USB: refactor unmap_urb_for_dma/map_urb_for_dma
Split unmap_urb_for_dma() and map_urb_for_dma() into smaller pieces
to make the code easier to read and maintain.
This patch adds four new URB flags which are used by map_urb_for_dma()
to mark URBs with the exact method used to map the setup packet and/or the
transfer buffer.
These flags are checked too at unmap_urb_for_dma() time to determine how
to unmap the setup packet and/or the transfer buffer. The flags are cleared
when the actual unmap happens.
No functional change.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
drivers/usb/core/hcd.c | 211 +++-
include/linux/usb.h|5 +
2 files changed, 143 insertions(+), 73 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 80995ef..44ad710 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1260,106 +1260,171 @@ static void hcd_free_coherent(struct usb_bus *bus,
dma_addr_t *dma_handle,
*dma_handle = 0;
}
-static int map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
- gfp_t mem_flags)
+static void unmap_urb_setup_packet(struct usb_hcd *hcd, struct urb *urb)
+{
+ if (urb-transfer_flags URB_SETUP_DMA_MAPPED) {
+ urb-transfer_flags = ~URB_SETUP_DMA_MAPPED;
+ dma_unmap_single(hcd-self.controller, urb-setup_dma,
+sizeof(struct usb_ctrlrequest),
+DMA_TO_DEVICE);
+ } else if (urb-transfer_flags URB_SETUP_BOUNCE_MAPPED) {
+ /* bounce from local memory */
+ urb-transfer_flags = ~URB_SETUP_BOUNCE_MAPPED;
+ hcd_free_coherent(urb-dev-bus, urb-setup_dma,
+ (void **)urb-setup_packet,
+ sizeof(struct usb_ctrlrequest),
+ DMA_TO_DEVICE);
+ } else {
+ /* nothing to do for PIO-based controller requests */
+ }
+}
+
+static void unmap_urb_transfer_buffer(struct usb_hcd *hcd, struct urb *urb)
{
enum dma_data_direction dir;
- int ret = 0;
- /* Map the URB's buffers for DMA access.
-* Lower level HCD code should use *_dma exclusively,
-* unless it uses pio or talks to another transport,
-* or uses the provided scatter gather list for bulk.
-*/
+ dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+ if (urb-transfer_flags URB_TRANSFER_DMA_MAPPED) {
+ urb-transfer_flags = ~URB_TRANSFER_DMA_MAPPED;
+ dma_unmap_single(hcd-self.controller,
+urb-transfer_dma,
+urb-transfer_buffer_length,
+dir);
+ } else if (urb-transfer_flags URB_TRANSFER_BOUNCE_MAPPED) {
+ /* bounce from local memory */
+ urb-transfer_flags = ~URB_TRANSFER_BOUNCE_MAPPED;
+ hcd_free_coherent(urb-dev-bus, urb-transfer_dma,
+ urb-transfer_buffer,
+ urb-transfer_buffer_length,
+ dir);
+ } else {
+ /* nothing to do for PIO-based controller requests */
+ }
+}
+
+static void unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
+{
if (is_root_hub(urb-dev))
+ return;
+
+ unmap_urb_setup_packet(hcd, urb);
+ unmap_urb_transfer_buffer(hcd, urb);
+}
+
+static int urb_needs_setup_map(struct usb_hcd *hcd, struct urb *urb)
+{
+ /* setup mappings are required only for control requests */
+ if (!usb_endpoint_xfer_control(urb-ep-desc))
+ return 0;
+
+ /* If the caller set URB_NO_SETUP_DMA_MAP then no mapping is needed */
+ if ((urb-transfer_flags URB_NO_SETUP_DMA_MAP))
+ return 0;
+
+ return 1;
+}
+
+static int urb_needs_transfer_map(struct usb_hcd *hcd, struct urb *urb)
+{
+ /* don't need to map anything if there's nothing to map */
+ if (urb-transfer_buffer_length == 0)
return 0;
- if (usb_endpoint_xfer_control(urb-ep-desc)
-!(urb-transfer_flags URB_NO_SETUP_DMA_MAP)) {
+ /* If the caller set URB_NO_SETUP_DMA_MAP then no mapping is needed */
+ if ((urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
+ return 0;
+
+ return 1;
+}
+
+static int map_urb_setup_packet(struct usb_hcd *hcd, struct urb *urb,
+ gfp_t mem_flags)
+{
+ int ret;
+
+ if (urb_needs_setup_map(hcd, urb)) {
if (hcd-self.uses_dma) {
urb-setup_dma = dma_map_single(
- hcd-self.controller,
- urb-setup_packet,
- sizeof(struct usb_ctrlrequest),
- DMA_TO_DEVICE);
+
[PATCH v5 06/10] USB: add HCD_NO_COHERENT_MEM host controller driver flag
The HCD_NO_COHERENT_MEM USB host controller driver flag can be enabled
to instruct the USB stack to avoid allocating coherent memory for USB
buffers.
This flag is useful to overcome some esoteric memory access restrictions
found in some platforms.
For example, the Nintendo Wii video game console is a NOT_COHERENT_CACHE
platform that is unable to safely perform non-32 bit uncached writes
to RAM because the byte enables are not connected to the bus.
Thus, in that platform, coherent DMA buffers cannot be directly used
by the kernel code unless it guarantees that all write accesses
to said buffers are done in 32 bit chunks (which is not the case in the
USB subsystem).
To avoid this unwanted behaviour HCD_NO_COHERENT_MEM can be enabled at
the HCD controller, causing USB buffer allocations to be satisfied from
normal kernel memory. In this case, the USB stack will make sure that
the buffers get properly mapped/unmapped for DMA transfers using the DMA
streaming mapping API.
Note that other parts of the USB stack may also use coherent memory,
like for example the hardware descriptors used in the EHCI controllers.
This needs to be checked and addressed separately. In the EHCI example,
hardware descriptors are accessed in 32-bit (or 64-bit) chunks, causing
no problems in the described scenario.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
drivers/usb/core/buffer.c | 29 +++--
drivers/usb/core/hcd.c| 32 +++-
drivers/usb/core/hcd.h| 13 +++--
3 files changed, 57 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 3ba2fff..10cd11d 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -36,6 +36,26 @@ static const size_t pool_max [HCD_BUFFER_POOLS] = {
/* SETUP primitives */
+static inline int hcd_uses_pio(struct usb_hcd *hcd)
+{
+ if ((!hcd-self.controller-dma_mask
+ !(hcd-driver-flags HCD_LOCAL_MEM)))
+ return 1;
+ return 0;
+}
+
+static inline int hcd_needs_non_dma_mem(struct usb_hcd *hcd)
+{
+ /*
+* PIO-based and HCD_NO_COHERENT_MEM-based controllers use
+* normal kernel memory.
+* The rest want DMA memory.
+*/
+ if (hcd_uses_pio(hcd) || (hcd-driver-flags HCD_NO_COHERENT_MEM))
+ return 1;
+ return 0;
+}
+
/**
* hcd_buffer_create - initialize buffer pools
* @hcd: the bus whose buffer pools are to be initialized
@@ -53,8 +73,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
charname[16];
int i, size;
- if (!hcd-self.controller-dma_mask
- !(hcd-driver-flags HCD_LOCAL_MEM))
+ if (hcd_needs_non_dma_mem(hcd))
return 0;
for (i = 0; i HCD_BUFFER_POOLS; i++) {
@@ -109,8 +128,7 @@ void *hcd_buffer_alloc(
int i;
/* some USB hosts just use PIO */
- if (!bus-controller-dma_mask
- !(hcd-driver-flags HCD_LOCAL_MEM)) {
+ if (hcd_needs_non_dma_mem(hcd)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
@@ -135,8 +153,7 @@ void hcd_buffer_free(
if (!addr)
return;
- if (!bus-controller-dma_mask
- !(hcd-driver-flags HCD_LOCAL_MEM)) {
+ if (hcd_needs_non_dma_mem(hcd)) {
kfree(addr);
return;
}
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 44ad710..174853a 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1316,9 +1316,19 @@ static int urb_needs_setup_map(struct usb_hcd *hcd,
struct urb *urb)
/* setup mappings are required only for control requests */
if (!usb_endpoint_xfer_control(urb-ep-desc))
return 0;
-
- /* If the caller set URB_NO_SETUP_DMA_MAP then no mapping is needed */
- if ((urb-transfer_flags URB_NO_SETUP_DMA_MAP))
+ /*
+* Setup packets are 8 bytes long and don't use scatter/gather.
+*
+* If the caller sets URB_NO_SETUP_DMA_MAP and urb-setup_dma
+* contains a valid DMA handle then it is already mapped, except
+* if the controller can't use coherent memory (HCD_NO_COHERENT_MEM).
+*
+* urb-setup_dma is set to ~0 when allocating USB buffers for
+* PIO-based or HCD_NO_COHERENT_MEM-based controllers.
+*/
+ if ((urb-transfer_flags URB_NO_SETUP_DMA_MAP)
+ urb-setup_dma != ~(dma_addr_t)0
+ !(hcd-driver-flags HCD_NO_COHERENT_MEM))
return 0;
return 1;
@@ -1330,8 +1340,20 @@ static int urb_needs_transfer_map(struct usb_hcd *hcd,
struct urb *urb)
if (urb-transfer_buffer_length == 0)
return 0;
- /* If the caller set URB_NO_SETUP_DMA_MAP then no mapping is needed */
- if ((urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
+
[PATCH v5 03/10] powerpc: add per-device dma coherent support
Use the generic per-device dma coherent allocator on powerpc.
This allows a driver to declare coherent memory area from where
a device can allocate coherent memory chunks.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/include/asm/dma-mapping.h |1 +
arch/powerpc/kernel/dma.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 80a973b..18ecec8 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -17,6 +17,7 @@
#include linux/dma-debug.h
#include asm/io.h
#include asm/swiotlb.h
+#include asm-generic/dma-coherent.h
#define DMA_ERROR_CODE (~(dma_addr_t)0x0)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 6215062..83d5232 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -27,6 +27,9 @@ void *dma_direct_alloc_coherent(struct device *dev, size_t
size,
{
void *ret;
#ifdef CONFIG_NOT_COHERENT_CACHE
+ if (dma_alloc_from_coherent(dev, size, dma_handle, ret))
+ return ret;
+
ret = __dma_alloc_coherent(dev, size, dma_handle, flag);
if (ret == NULL)
return NULL;
@@ -54,6 +57,8 @@ void dma_direct_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle)
{
#ifdef CONFIG_NOT_COHERENT_CACHE
+ if (dma_release_from_coherent(dev, get_order(size), vaddr))
+ return;
__dma_free_coherent(size, vaddr);
#else
free_pages((unsigned long)vaddr, get_order(size));
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 07/10] wii: have generic dma coherent
Let the Nintendo Wii gaming console use per-device dma coherent allocations. This will be used later by some of its drivers. Signed-off-by: Albert Herranz albert_herr...@yahoo.es --- arch/powerpc/platforms/embedded6xx/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig index 524d971..fe77ab2 100644 --- a/arch/powerpc/platforms/embedded6xx/Kconfig +++ b/arch/powerpc/platforms/embedded6xx/Kconfig @@ -119,6 +119,7 @@ config WII bool Nintendo-Wii depends on EMBEDDED6xx select GAMECUBE_COMMON + select HAVE_GENERIC_DMA_COHERENT help Select WII if configuring for the Nintendo Wii. More information at: http://gc-linux.sourceforge.net/ -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 00/10] wii: add usb 2.0 support
The following patch series adds USB 2.0 support for the Wii PowerPC
platform via the EHCI controller present in the Hollywood chipset
of the video game console.
v4 - v5
- Set the default IO TLB size via the kernel command line.
This is now possible on PowerPC thanks to a recent patch by Fujita Tomonori.
- swiotlb support for the Wii is now based on top of the swiotlb-0.6
patches from Konrad Rzeszutek Wilk.
- Keeps using v4 of the USB HCD_NO_COHERENT_MEM patch
Alan: I think you are also working in a patchset to make {un}map_urb_for_dma
remember how the urb was mapped, right?
Albert Herranz (10):
swiotbl: add back swiotlb_alloc_boot()
swiotlb: make swiotlb_bounce() __weak
powerpc: add per-device dma coherent support
powerpc: add min_direct_dma_addr
USB: refactor unmap_urb_for_dma/map_urb_for_dma
USB: add HCD_NO_COHERENT_MEM host controller driver flag
wii: have generic dma coherent
wii: add mem2 dma mapping ops
wii: enable swiotlb
wii: hollywood ehci controller support
arch/powerpc/boot/dts/wii.dts|2 +-
arch/powerpc/boot/wii.c | 44 +++
arch/powerpc/include/asm/device.h|1 +
arch/powerpc/include/asm/dma-mapping.h |3 +
arch/powerpc/include/asm/wii.h | 25 ++
arch/powerpc/kernel/dma.c|5 +
arch/powerpc/platforms/embedded6xx/Kconfig |3 +
arch/powerpc/platforms/embedded6xx/Makefile |2 +-
arch/powerpc/platforms/embedded6xx/wii-dma.c | 475 ++
arch/powerpc/platforms/embedded6xx/wii.c |1 +
drivers/usb/core/buffer.c| 29 ++-
drivers/usb/core/hcd.c | 233 +
drivers/usb/core/hcd.h | 13 +-
drivers/usb/host/Kconfig |8 +
drivers/usb/host/ehci-hcd.c |5 +
drivers/usb/host/ehci-hlwd.c | 233 +
drivers/usb/host/ehci.h | 23 ++
include/linux/swiotlb.h |1 +
include/linux/usb.h |5 +
lib/swiotlb.c| 12 +-
20 files changed, 1033 insertions(+), 90 deletions(-)
create mode 100644 arch/powerpc/include/asm/wii.h
create mode 100755 arch/powerpc/platforms/embedded6xx/wii-dma.c
create mode 100644 drivers/usb/host/ehci-hlwd.c
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 08/10] wii: add mem2 dma mapping ops
Some of the devices in the Hollywood chipset of the Nintendo Wii video
game console have restrictions performing DMA transfers to the first
contiguous RAM region (known as MEM1).
For example, up to 3 bytes of the last word of a DMA transfer of a
non-32 bit aligned length to MEM1 may be lost.
Such restrictions do not apply when using the second contiguous RAM
region (known as MEM2).
Add a set of DMA mapping operations which said devices can use to make
sure that DMA transfers are always performed to/from memory buffers
within MEM2.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/boot/wii.c | 44 +++
arch/powerpc/include/asm/wii.h | 25 ++
arch/powerpc/platforms/embedded6xx/Kconfig |1 +
arch/powerpc/platforms/embedded6xx/Makefile |2 +-
arch/powerpc/platforms/embedded6xx/wii-dma.c | 475 ++
5 files changed, 546 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/include/asm/wii.h
create mode 100755 arch/powerpc/platforms/embedded6xx/wii-dma.c
diff --git a/arch/powerpc/boot/wii.c b/arch/powerpc/boot/wii.c
index 2ebaec0..84ce593 100644
--- a/arch/powerpc/boot/wii.c
+++ b/arch/powerpc/boot/wii.c
@@ -30,6 +30,7 @@ BSS_STACK(8192);
#define MEM2_TOP (0x1000 + 64*1024*1024)
#define FIRMWARE_DEFAULT_SIZE (12*1024*1024)
+#define MEM2_DMA_DEFAULT_SIZE (512*1024)
struct mipc_infohdr {
char magic[3];
@@ -101,6 +102,42 @@ out:
}
+static char tmp_cmdline[COMMAND_LINE_SIZE];
+
+static void mem2_fixups(u32 *top, u32 *reg)
+{
+ /* ' mem2_dma=' + nnn + 'k...@0x' + */
+ const int max_param_len = 10 + 7 + 4 + 8;
+ void *chosen;
+ u32 dma_base, dma_size;
+ char *p;
+
+ chosen = finddevice(/chosen);
+ if (!chosen)
+ fatal(Can't find chosen node\n);
+
+ /* the MEM2 DMA region must fit within MEM2 */
+ dma_size = MEM2_DMA_DEFAULT_SIZE;
+ if (dma_size reg[3])
+ dma_size = reg[3];
+ /* reserve the region from the top of MEM2 */
+ *top -= dma_size;
+ dma_base = *top;
+ printf(mem2_dma: %...@0x%08x\n, dma_size 10, dma_base);
+
+ /*
+* Finally, add the MEM2 DMA region location information to the
+* kernel command line. The wii-dma driver will pick this info up.
+*/
+ getprop(chosen, bootargs, tmp_cmdline, COMMAND_LINE_SIZE-1);
+ p = strchr(tmp_cmdline, 0);
+ if (p - tmp_cmdline + max_param_len = COMMAND_LINE_SIZE)
+ fatal(No space left for mem2_dma param\n);
+
+ sprintf(p, mem2_dma=...@0x%08x, dma_size 10, dma_base);
+ setprop_str(chosen, bootargs, tmp_cmdline);
+}
+
static void platform_fixups(void)
{
void *mem;
@@ -127,9 +164,16 @@ static void platform_fixups(void)
mem2_boundary = MEM2_TOP - FIRMWARE_DEFAULT_SIZE;
}
+ mem2_fixups(mem2_boundary, reg);
+
if (mem2_boundary reg[2] mem2_boundary reg[2] + reg[3]) {
reg[3] = mem2_boundary - reg[2];
printf(top of MEM2 @ %08X\n, reg[2] + reg[3]);
+ /*
+* Find again the memory node as it may have changed its
+* position after adding some non-existing properties.
+*/
+ mem = finddevice(/memory);
setprop(mem, reg, reg, sizeof(reg));
}
diff --git a/arch/powerpc/include/asm/wii.h b/arch/powerpc/include/asm/wii.h
new file mode 100644
index 000..bb83c32
--- /dev/null
+++ b/arch/powerpc/include/asm/wii.h
@@ -0,0 +1,25 @@
+/*
+ * arch/powerpc/include/asm/wii.h
+ *
+ * Nintendo Wii board-specific definitions
+ * Copyright (C) 2010 The GameCube Linux Team
+ * Copyright (C) 2010 Albert Herranz
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#ifndef __ASM_POWERPC_WII_H
+#define __ASM_POWERPC_WII_H
+
+/*
+ * DMA operations for the Nintendo Wii.
+ */
+extern struct dma_map_ops wii_mem2_dma_ops;
+
+extern int wii_set_mem2_dma_constraints(struct device *dev);
+extern void wii_clear_mem2_dma_constraints(struct device *dev);
+
+#endif /* __ASM_POWERPC_WII_H */
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig
b/arch/powerpc/platforms/embedded6xx/Kconfig
index fe77ab2..f4fff0a 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -120,6 +120,7 @@ config WII
depends on EMBEDDED6xx
select GAMECUBE_COMMON
select HAVE_GENERIC_DMA_COHERENT
+ select SWIOTLB
help
Select WII if configuring for the Nintendo Wii.
More information at: http://gc-linux.sourceforge.net/
diff --git a/arch/powerpc/platforms/embedded6xx/Makefile
[PATCH v5 09/10] wii: enable swiotlb
Enable the use of a software IO TLB on the Nintendo Wii video game console.
This is used by the platform DMA support code to overcome the limitations
found in some of the devices within the Hollywood chipset.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/boot/dts/wii.dts|2 +-
arch/powerpc/platforms/embedded6xx/wii.c |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index 77528c9..92b8ca6 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -29,7 +29,7 @@
#size-cells = 1;
chosen {
- bootargs = root=/dev/mmcblk0p2 rootwait udbg-immortal;
+ bootargs = root=/dev/mmcblk0p2 swiotlb=512 rootwait
udbg-immortal;
};
memory {
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c
b/arch/powerpc/platforms/embedded6xx/wii.c
index 57e5b60..e63c5c8 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -164,6 +164,7 @@ static void __init wii_setup_arch(void)
clrbits32(hw_gpio + HW_GPIO_OUT(0),
HW_GPIO_SLOT_LED | HW_GPIO_SENSOR_BAR);
}
+ ppc_swiotlb_enable = 1;
}
static void wii_restart(char *cmd)
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 10/10] wii: hollywood ehci controller support
Add support for the USB Enhanced Host Controller Interface included
in the Hollywood chipset of the Nintendo Wii video game console.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/platforms/embedded6xx/Kconfig |1 +
drivers/usb/host/Kconfig |8 +
drivers/usb/host/ehci-hcd.c|5 +
drivers/usb/host/ehci-hlwd.c | 233
drivers/usb/host/ehci.h| 23 +++
5 files changed, 270 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/host/ehci-hlwd.c
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig
b/arch/powerpc/platforms/embedded6xx/Kconfig
index f4fff0a..63bc708 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -121,6 +121,7 @@ config WII
select GAMECUBE_COMMON
select HAVE_GENERIC_DMA_COHERENT
select SWIOTLB
+ select USB_ARCH_HAS_EHCI
help
Select WII if configuring for the Nintendo Wii.
More information at: http://gc-linux.sourceforge.net/
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 2678a16..342954f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -131,6 +131,14 @@ config USB_EHCI_HCD_PPC_OF
Enables support for the USB controller present on the PowerPC
OpenFirmware platform bus.
+config USB_EHCI_HCD_HLWD
+ bool Nintendo Wii (Hollywood) EHCI USB controller support
+ depends on USB_EHCI_HCD WII
+ default y
+ ---help---
+ Say Y here to support the EHCI USB controller found in the
+ Hollywood chipset of the Nintendo Wii video game console.
+
config USB_W90X900_EHCI
bool W90X900(W90P910) EHCI support
depends on USB_EHCI_HCD ARCH_W90X900
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 1ec3857..395c6a1 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1133,6 +1133,11 @@ MODULE_LICENSE (GPL);
#define OF_PLATFORM_DRIVER ehci_hcd_ppc_of_driver
#endif
+#ifdef CONFIG_USB_EHCI_HCD_HLWD
+#include ehci-hlwd.c
+#define OF_PLATFORM_DRIVER ehci_hcd_hlwd_driver
+#endif
+
#ifdef CONFIG_XPS_USB_HCD_XILINX
#include ehci-xilinx-of.c
#define OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver
diff --git a/drivers/usb/host/ehci-hlwd.c b/drivers/usb/host/ehci-hlwd.c
new file mode 100644
index 000..129e96b
--- /dev/null
+++ b/drivers/usb/host/ehci-hlwd.c
@@ -0,0 +1,233 @@
+/*
+ * drivers/usb/host/ehci-hlwd.c
+ *
+ * Nintendo Wii (Hollywood) USB Enhanced Host Controller Interface.
+ * Copyright (C) 2009-2010 The GameCube Linux Team
+ * Copyright (C) 2009,2010 Albert Herranz
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * Based on ehci-ppc-of.c
+ *
+ * EHCI HCD (Host Controller Driver) for USB.
+ *
+ * Bus Glue for PPC On-Chip EHCI driver on the of_platform bus
+ * Tested on AMCC PPC 440EPx
+ *
+ * Valentine Barshak vbars...@ru.mvista.com
+ *
+ * Based on ehci-ppc-soc.c by Stefan Roese s...@denx.de
+ * and ohci-ppc-of.c by Sylvain Munaut t...@246tnt.com
+ *
+ * This file is licenced under the GPL.
+ */
+
+#include linux/signal.h
+#include linux/of.h
+#include linux/of_platform.h
+#include asm/wii.h
+
+#define DRV_MODULE_NAME ehci-hlwd
+#define DRV_DESCRIPTION Nintendo Wii EHCI Host Controller
+#define DRV_AUTHOR Albert Herranz
+
+/*
+ * Non-standard registers.
+ */
+#define HLWD_EHCI_CTL 0x00cc /* Controller Control */
+#define HLWD_EHCI_CTL_INTE (115) /* Notify EHCI interrupts */
+
+/* called during probe() after chip reset completes */
+static int ehci_hlwd_reset(struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ int error;
+
+ dbg_hcs_params(ehci, reset);
+ dbg_hcc_params(ehci, reset);
+
+ error = ehci_halt(ehci);
+ if (error)
+ goto out;
+
+ error = ehci_init(hcd);
+ if (error)
+ goto out;
+
+ /* enable notification of EHCI interrupts */
+ setbits32(hcd-regs + HLWD_EHCI_CTL, HLWD_EHCI_CTL_INTE);
+
+ ehci-sbrn = 0x20;
+ error = ehci_reset(ehci);
+ ehci_port_power(ehci, 0);
+out:
+ return error;
+}
+
+static const struct hc_driver ehci_hlwd_hc_driver = {
+ .description= hcd_name,
+ .product_desc = Nintendo Wii EHCI Host Controller,
+ .hcd_priv_size = sizeof(struct ehci_hcd),
+
+ /*
+* generic hardware linkage
+*/
+ .irq= ehci_irq,
+ .flags = HCD_USB2 | HCD_NO_COHERENT_MEM,
+
+ /*
+* basic lifecycle operations
+*/
+ .reset = ehci_hlwd_reset,
+
Re: [PATCH v5 00/10] wii: add usb 2.0 support
On Fri, 19 Mar 2010, Albert Herranz wrote:
Alan: I think you are also working in a patchset to make {un}map_urb_for_dma
remember how the urb was mapped, right?
Yes; you can see an initial version here:
http://marc.info/?l=linux-usbm=126901183419219w=2
This is a bug fix, so it's likely to be merged before your work.
It's a messy situation, with two people changing the same code at the
same time. I think the best approach will be to wait until the bug-fix
patch is tested and accepted; then I can create a version of your 5/10
and 6/10 patches adding HCD_NO_COHERENT_MEM and the corresponding
behavior. That can stand by itself, and once it is accepted the rest
of your series should go through with no difficulty (at least, no
difficulties involving the USB core!).
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] irq: move some interrupt arch_* functions into struct irq_chip.
please check
Subject: [PATCH -v4] irq: move some interrupt arch_* functions into struct
irq_chip.
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
arch_init_chip_data cannot be moved into struct irq_chip because
irq_desc-chip is not known at the time the irq_desc is setup. Instead
rename arch_init_chip_data to arch_init_irq_desc for PowerPC, the
only other user, whose usage better matches the new name.
To replace the x86 arch_init_chip_data functionality
irq_to_desc_alloc_node now takes a pointer to a function to allocate
the chip data. This is necessary to ensure the allocation happens
under the correct locking at the core level. On PowerPC and SH
architectures (the other users of irq_to_desc_alloc_node) pass in NULL
which retains existing chip_data behaviour.
I've retained the chip_data behaviour for uv_irq although it isn't
clear to me if these interrupt types support migration or how closely
related to the APIC modes they really are. If it weren't for this the
x86_{init,copy,free}_chip_data functions could be static to
io_apic.c.
I've tested by booting on an 64 bit x86 system with sparse IRQ enabled
and 32 bit without, but it's not clear to me what actions I need to
take to actually exercise some of these code paths.
-v4: yinghai add irq_to_desc_alloc_node_x...
so could leave default path not changed...
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Michael Ellerman mich...@ellerman.id.au [PowerPC rename portion]
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Yinghai Lu ying...@kernel.org
Cc: Jeremy Fitzhardinge jer...@goop.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: x...@kernel.org
Cc: linuxppc-...@ozlabs.org
Cc: linux-ker...@vger.kernel.org
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: lgu...@ozlabs.org
Cc: Paul Mundt let...@linux-sh.org
Cc: linux...@vger.kernel.org
---
arch/powerpc/kernel/irq.c |2 -
arch/x86/include/asm/hw_irq.h |7 +
arch/x86/kernel/apic/io_apic.c | 49 +
arch/x86/kernel/uv_irq.c |3 ++
drivers/xen/events.c |7 +
include/linux/interrupt.h |1
include/linux/irq.h| 20
kernel/irq/chip.c |7 +
kernel/irq/handle.c| 13 ++
kernel/irq/numa_migrate.c | 12 --
kernel/softirq.c |5
11 files changed, 101 insertions(+), 25 deletions(-)
Index: linux-2.6/arch/powerpc/kernel/irq.c
===
--- linux-2.6.orig/arch/powerpc/kernel/irq.c
+++ linux-2.6/arch/powerpc/kernel/irq.c
@@ -1088,7 +1088,7 @@ int arch_early_irq_init(void)
return 0;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int arch_init_irq_desc(struct irq_desc *desc, int node, init_chip_data_fn fn)
{
desc-status |= IRQ_NOREQUEST;
return 0;
Index: linux-2.6/arch/x86/include/asm/hw_irq.h
===
--- linux-2.6.orig/arch/x86/include/asm/hw_irq.h
+++ linux-2.6/arch/x86/include/asm/hw_irq.h
@@ -20,9 +20,9 @@
#include linux/percpu.h
#include linux/profile.h
#include linux/smp.h
+#include linux/irq.h
#include asm/atomic.h
-#include asm/irq.h
#include asm/sections.h
/* Interrupt handlers registered during init_IRQ */
@@ -61,6 +61,11 @@ extern void init_VISWS_APIC_irqs(void);
extern void setup_IO_APIC(void);
extern void disable_IO_APIC(void);
+extern void x86_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node);
+extern void x86_free_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc);
+
struct io_apic_irq_attr {
int ioapic;
int ioapic_pin;
Index: linux-2.6/arch/x86/kernel/apic/io_apic.c
===
--- linux-2.6.orig/arch/x86/kernel/apic/io_apic.c
+++ linux-2.6/arch/x86/kernel/apic/io_apic.c
@@ -211,7 +211,7 @@ static struct irq_cfg *get_one_free_irq_
return cfg;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+static int x86_init_chip_data(struct irq_desc *desc, int node)
{
struct irq_cfg *cfg;
@@ -287,8 +287,8 @@ static void free_irq_2_pin(struct irq_cf
old_cfg-irq_2_pin = NULL;
}
-void arch_init_copy_chip_data(struct irq_desc *old_desc,
-struct irq_desc *desc, int node)
+void x86_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node)
{
struct irq_cfg *cfg;
struct irq_cfg *old_cfg;
@@ -312,7 +312,7 @@ static void free_irq_cfg(struct irq_cfg
Re: [PATCH v5 00/10] wii: add usb 2.0 support
Alan Stern wrote:
Alan: I think you are also working in a patchset to make {un}map_urb_for_dma
remember how the urb was mapped, right?
Yes; you can see an initial version here:
http://marc.info/?l=linux-usbm=126901183419219w=2
This is a bug fix, so it's likely to be merged before your work.
It's a messy situation, with two people changing the same code at the
same time. I think the best approach will be to wait until the bug-fix
patch is tested and accepted; then I can create a version of your 5/10
and 6/10 patches adding HCD_NO_COHERENT_MEM and the corresponding
behavior. That can stand by itself, and once it is accepted the rest
of your series should go through with no difficulty (at least, no
difficulties involving the USB core!).
Agreed. I'll keep an eye on these developments.
Alan Stern
Thanks a lot,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[v2 PATCH] of/flattree: Fix unhandled OF_DT_NOP tag when unflattening the device tree
From: Jason Gunthorpe jguntho...@obsidianresearch.com
NOPs within the property section are skipped, but NOPs between
OF_DT_END_NODE and OF_DT_BEGIN_NODE were not. My firmware NOPs out
entire nodes depending on various environment parameters.
of_scan_flat_dt already handles NOP more generally.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
v2 - adapted to new location of unflatten_dt_node().
Jason, please test against 2.6.34-rc1
drivers/of/fdt.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 406757a..dee4fb5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -376,8 +376,11 @@ unsigned long __init unflatten_dt_node(unsigned long mem,
if (!np-type)
np-type = NULL;
}
- while (tag == OF_DT_BEGIN_NODE) {
- mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
+ while (tag == OF_DT_BEGIN_NODE || tag == OF_DT_NOP) {
+ if (tag == OF_DT_NOP)
+ *p += 4;
+ else
+ mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
tag = be32_to_cpup((__be32 *)(*p));
}
if (tag != OF_DT_END_NODE) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 08/10] wii: add mem2 dma mapping ops
+int wii_set_mem2_dma_constraints(struct device *dev)
+{
+ struct dev_archdata *sd;
+
+ sd = dev-archdata;
+ sd-max_direct_dma_addr = 0;
+ sd-min_direct_dma_addr = wii_hole_start + wii_hole_size;
+
+ set_dma_ops(dev, wii_mem2_dma_ops);
+ return 0;
+}
+EXPORT_SYMBOL(wii_set_mem2_dma_constraints);
Can you make them EXPORT_SYMBOL_GPL?
+
+/**
+ * wii_clear_mem2_dma_constraints() - clears device MEM2 DMA constraints
+ * @dev: device for which DMA constraints are cleared
+ *
+ * Instructs device @dev to stop using MEM2 DMA buffers for DMA transfers.
+ * Must be called to undo wii_set_mem2_dma_constraints().
+ */
+void wii_clear_mem2_dma_constraints(struct device *dev)
+{
+ struct dev_archdata *sd;
+
+ sd = dev-archdata;
+ sd-max_direct_dma_addr = 0;
+ sd-min_direct_dma_addr = 0;
+
+ set_dma_ops(dev, dma_direct_ops);
+}
+EXPORT_SYMBOL(wii_clear_mem2_dma_constraints);
Ditto..
+
+/*
+ * swiotlb-based DMA ops for MEM2-only devices on the Wii.
+ *
+ */
+
+/*
+ * Allocate the SWIOTLB from MEM2.
+ */
+void * __init swiotlb_alloc_boot(size_t size, unsigned long nslabs)
+{
+ return __alloc_bootmem_low(size, PAGE_SIZE,
+wii_hole_start + wii_hole_size);
+}
+
+/*
+ * Bounce: copy the swiotlb buffer back to the original dma location
+ * This is a platform specific version replacing the generic __weak version.
+ */
+void swiotlb_bounce(phys_addr_t phys, char *dma_buf, size_t size,
+ enum dma_data_direction dir)
+{
+ void *vaddr = phys_to_virt(phys);
+
+ if (dir == DMA_TO_DEVICE) {
+ memcpy(dma_buf, vaddr, size);
+ __dma_sync(dma_buf, size, dir);
+ } else {
+ __dma_sync(dma_buf, size, dir);
+ memcpy(vaddr, dma_buf, size);
+ }
+}
+
+static dma_addr_t
+mem2_virt_to_bus(struct device *dev, void *address)
+{
+ return phys_to_dma(dev, virt_to_phys(address));
+}
+
+static int
+mem2_dma_mapping_error(struct device *dev, dma_addr_t dma_handle)
+{
+ return dma_handle == mem2_virt_to_bus(dev, swiotlb_bk_overflow_buffer);
+}
+
+static int
+mem2_dma_supported(struct device *dev, u64 mask)
+{
+ return mem2_virt_to_bus(dev, swiotlb_bk_end - 1) = mask;
+}
+
+/*
+ * Determines if a given DMA region specified by @dma_handle
+ * requires bouncing.
+ *
+ * Bouncing is required if the DMA region falls within MEM1.
+ */
+static int mem2_needs_dmabounce(dma_addr_t dma_handle)
+{
+ return dma_handle wii_hole_start;
+}
+
+/*
+ * Use the dma_direct_ops hooks for allocating and freeing coherent memory
+ * from the MEM2 DMA region.
+ */
+
+static void *mem2_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp)
+{
+ void *vaddr;
+
+ vaddr = dma_direct_ops.alloc_coherent(wii_mem2_dma_dev(), size,
+ dma_handle, gfp);
+ if (vaddr mem2_needs_dmabounce(*dma_handle)) {
+ dma_direct_ops.free_coherent(wii_mem2_dma_dev(), size, vaddr,
+ *dma_handle);
+ dev_err(dev, failed to allocate MEM2 coherent memory\n);
+ vaddr = NULL;
+ }
+ return vaddr;
+}
+
+static void mem2_free_coherent(struct device *dev, size_t size,
+void *vaddr, dma_addr_t dma_handle)
+{
+ dma_direct_ops.free_coherent(wii_mem2_dma_dev(), size, vaddr,
+ dma_handle);
+}
+
+/*
+ * Maps (part of) a page so it can be safely accessed by a device.
+ *
+ * Calls the corresponding dma_direct_ops hook if the page region falls
+ * within MEM2.
+ * Otherwise, a bounce buffer allocated from MEM2 coherent memory is used.
+ */
+static dma_addr_t
+mem2_map_page(struct device *dev, struct page *page, unsigned long offset,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ phys_addr_t phys = page_to_phys(page) + offset;
+ dma_addr_t dma_handle = phys_to_dma(dev, phys);
+ dma_addr_t swiotlb_start_dma;
+ void *map;
+
+ BUG_ON(dir == DMA_NONE);
+
+ if (dma_capable(dev, dma_handle, size) !swiotlb_force) {
+ return dma_direct_ops.map_page(dev, page, offset, size,
+dir, attrs);
+ }
+
+ swiotlb_start_dma = mem2_virt_to_bus(dev, swiotlb_bk_start);
+ map = swiotlb_bk_map_single(dev, phys, swiotlb_start_dma, size, dir);
+ if (!map) {
+ swiotlb_full(dev, size, dir, 1);
+ map = swiotlb_bk_overflow_buffer;
+ }
+
+ dma_handle = mem2_virt_to_bus(dev, map);
+ BUG_ON(!dma_capable(dev, dma_handle, size));
+
+ return dma_handle;
+}
+
+/*
+ * Unmaps (part of) a page previously mapped.
+ *
+ * Calls the corresponding dma_direct_ops hook if the DMA region
Re: [PATCH v5 08/10] wii: add mem2 dma mapping ops
+/*
+ * The mem2_dma device.
+ *
+ * This device owns a pool of coherent MEM2 memory that can be shared among
+ * several devices requiring MEM2 DMA buffers, instead of dedicating specific
+ * pools for each device.
+ *
+ * A device can use the shared coherent MEM2 memory pool by calling
+ * wii_set_mem2_dma_constraints().
+ *
+ */
+
+struct mem2_dma {
+ struct platform_device *pdev;
+
The space there isn't neccessary.
+ dma_addr_t dma_base;
I think you need only one of them. You don't seem to use 'base'
+ void *base;
+ size_t size;
+};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2 PATCH] of/flattree: Fix unhandled OF_DT_NOP tag when unflattening the device tree
On Fri, Mar 19, 2010 at 02:01:49PM -0600, Grant Likely wrote: From: Jason Gunthorpe jguntho...@obsidianresearch.com NOPs within the property section are skipped, but NOPs between OF_DT_END_NODE and OF_DT_BEGIN_NODE were not. My firmware NOPs out entire nodes depending on various environment parameters. of_scan_flat_dt already handles NOP more generally. Fwiw, there's a test program in the libfdt/dtc tree called nopulate which will liberally spread NOPs through a device tree blob (one between every other tag), which might be useful for testing this -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 08/10] wii: add mem2 dma mapping ops
Konrad Rzeszutek Wilk wrote:
+/*
+ * The mem2_dma device.
+ *
+ * This device owns a pool of coherent MEM2 memory that can be shared
among
+ * several devices requiring MEM2 DMA buffers, instead of dedicating
specific
+ * pools for each device.
+ *
+ * A device can use the shared coherent MEM2 memory pool by calling
+ * wii_set_mem2_dma_constraints().
+ *
+ */
+
+struct mem2_dma {
+struct platform_device *pdev;
+
The space there isn't neccessary.
Yes. Having it or not is just a matter of formatting style taste.
+dma_addr_t dma_base;
I think you need only one of them. You don't seem to use 'base'
+void *base;
+size_t size;
+};
I can even get rid of the whole struct mem2_dma and just use a struct
platform_device now that there's no mem2_dma_exit() function.
I'll do that on the next iteration.
Thanks for your comments.
Cheers,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 08/10] wii: add mem2 dma mapping ops
Konrad Rzeszutek Wilk wrote:
+int wii_set_mem2_dma_constraints(struct device *dev)
+{
+struct dev_archdata *sd;
+
+sd = dev-archdata;
+sd-max_direct_dma_addr = 0;
+sd-min_direct_dma_addr = wii_hole_start + wii_hole_size;
+
+set_dma_ops(dev, wii_mem2_dma_ops);
+return 0;
+}
+EXPORT_SYMBOL(wii_set_mem2_dma_constraints);
Can you make them EXPORT_SYMBOL_GPL?
Sure. I don't know why I didn't use the *_GPL flavour on first place.
Thanks,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
