* Re: Hard-coded virtual address used by dma_alloc_coherent
From: Remi Machet @ 2008-07-24 21:43 UTC (permalink / raw)
To: Scott Wood; +Cc: Linux PPC
In-Reply-To: <4888D808.8000406@freescale.com>
On Thu, 2008-07-24 at 14:29 -0500, Scott Wood wrote:
> Remi Machet wrote:
> > I have noticed that the DMA allocation for non-coherent PowerPC
> > architecture is using a hard coded virtual memory address for its memory
> > pool. This address is typically 0xFF100000 (set by
> > CONFIG_CONSISTENT_START) and can conflict with early ioremap in systems
> > that enable HIGHMEM.
> >
> > Is there any reason why we have to use an arbitrary virtual address ? If
> > the virtual address must be known at compile time, can't we use fixmap ?
>
> The hardcoded address predates when fixmap was added to powerpc. It
> should be updated to use fixmap.
Ok, I will look into that.
> > I also can't figure out why we need to use a virtual address known at
> > compilation time and cannot just allocate pages using get_free_pages and
> > mark them as non cacheable and non swappable.
>
> We probably don't need a compile-time address, though we can't just
> change the page attributes in-place as the pages will often covered by
> large TLB entries.
If we use alloc_pages to allocate the physical memory and get_vm_area to
get a virtual address (and its associated PTE), wouldn't map_vm_area
take care of breaking the TLB into smaller chunks if necessary ?
Remi
^ permalink raw reply
* Re: lockdep badness
From: Nathan Lynch @ 2008-07-24 19:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080724192300.GE9594@localdomain>
Nathan Lynch wrote:
>
> A couple of stack traces below, the first is from benh's tree, the
> second is from 2.6.26. The lockdep self-tests all pass at boot.
Sorry, should have pointed out the code that is warning more
specifically.
> RTAS daemon started
> RTAS: event: 295, Type: Dump Notification Event, Severity: 2
> ------------[ cut here ]------------
> Badness at kernel/lockdep.c:2719
check_flags():
if (irqs_disabled_flags(flags)) {
if (DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)) {
printk("possible reason: unannotated
irqs-off.\n");
}
} else {
>>> if (DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled)) {
printk("possible reason: unannotated
irqs-on.\n");
}
}
> NIP: c0000000000b06dc LR: c0000000000b06c0 CTR: 0000000000000000
> REGS: c0000000e787b9a0 TRAP: 0700 Not tainted (2.6.26)
> MSR: 8000000000029032 <EE,ME,IR,DR> CR: 24000042 XER: 20000000
> TASK = c0000000e91a6100[428] 'rtasd' THREAD: c0000000e7878000 CPU: 1
> GPR00: 0000000000000000 c0000000e787bc20 c000000000a71270 0000000000000001
> GPR04: 0000000000000001 c00000000004d648 0000040100000000 0000040100000000
> GPR08: 0000000000000000 c000000000f1f858 0000000000000020 0000000000000001
> GPR12: 0000000000010000 c000000000aac600 00000000002146f4 0000000000214744
> GPR16: 4000000002040000 00000000029015b0 00000000002a3c00 c0000000008cc988
> GPR20: 0000000002901598 0000000000000000 0000000000000124 0000000000000002
> GPR24: 0000000000000001 0000000000000008 0000000000000001 c0000000009fdf00
> GPR28: c00000000004d648 c000000000943e98 c0000000009d9b40 c0000000e787bc20
> NIP [c0000000000b06dc] .check_flags+0x9c/0x174
> LR [c0000000000b06c0] .check_flags+0x80/0x174
> Call Trace:
> [c0000000e787bc20] [c0000000e787bc70] 0xc0000000e787bc70 (unreliable)
> [c0000000e787bca0] [c0000000000b5ac8] .lock_release+0x7c/0x208
> [c0000000e787bd50] [c0000000005e12c0] ._spin_unlock_irqrestore+0x34/0x94
> [c0000000e787bde0] [c00000000004d648] .pSeries_log_error+0x380/0x3f0
> [c0000000e787bef0] [c00000000004d8e4] .rtasd+0x98/0x100
> [c0000000e787bf90] [c000000000029d20] .kernel_thread+0x4c/0x68
> Instruction dump:
> e92d01b0 80090904 2f800000 40be002c 481ece4d 60000000 2fa30000 419e00c4
> e93e80c0 80090000 2f800000 409e00b4 <0fe00000> 480000ac 78290464 80090014
> possible reason: unannotated irqs-on.
> irq event stamp: 20
> hardirqs last enabled at (19): [<c0000000000b405c>] .trace_hardirqs_on+0x1c/0x3
> 0
> hardirqs last disabled at (20): [<c0000000000b0d80>] .trace_hardirqs_off+0x1c/0x
> 30
> softirqs last enabled at (0): [<c00000000008293c>] .copy_process+0x3c8/0x1040
> softirqs last disabled at (0): [<0000000000000000>] 0x0
>
> ===============
>
> ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
> ipr 0000:00:01.0: Found IOA with IRQ: 289
> ipr 0000:00:01.0: Starting IOA initialization sequence.
> ipr 0000:00:01.0: Adapter firmware version: 02200023
> ipr 0000:00:01.0: IOA initialized.
> ------------[ cut here ]------------
> Badness at kernel/lockdep.c:2037
trace_hardirqs_on():
if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
return;
>>> if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
return;
> NIP: c0000000000b29fc LR: c0000000000b29e0 CTR: 0000000000000000
> REGS: c00000000fffb890 TRAP: 0700 Not tainted (2.6.26)
> MSR: 8000000000021032 <ME,IR,DR> CR: 28000022 XER: 00000004
> TASK = c000000000996730[0] 'swapper' THREAD: c000000000a60000 CPU: 0
> GPR00: 0000000000000000 c00000000fffbb10 c000000000a61ad8 0000000000000001
> GPR04: 0000000000035112 c000000000426708 0000000000000000 0000000000000970
> GPR08: 0000000000000000 c000000000ec6ad0 0000000000000001 0000000000000001
> GPR12: 0000000000043bd8 c000000000a9d400 00000000002146f4 0000000000214744
> GPR16: 4000000002040000 00000000028f37a8 00000000002a3c00 c0000000008b3790
> GPR20: 00000000028f3790 0000000001a3f920 c0000000008b37a8 c0000000e6252000
> GPR24: c0000000e6454a48 0000000000100100 0000000000200200 c0000000005d8824
> GPR28: c000000000afba18 c000000000996730 c0000000009cb7f0 c00000000fffbb10
> NIP [c0000000000b29fc] .trace_hardirqs_on+0x120/0x1b0
> LR [c0000000000b29e0] .trace_hardirqs_on+0x104/0x1b0
> Call Trace:
> [c00000000fffbb10] [c00000000fffbbb0] 0xc00000000fffbbb0 (unreliable)
> [c00000000fffbbb0] [c0000000005d8824] ._spin_unlock_irq+0x40/0x68
> [c00000000fffbc40] [c000000000426708] .ipr_ioa_reset_done+0x218/0x2ac
> [c00000000fffbd00] [c00000000041bdb8] .ipr_reset_ioa_job+0xc8/0xf4
> [c00000000fffbd90] [c000000000424ffc] .ipr_isr+0x280/0x628
> [c00000000fffbe50] [c0000000000ccc70] .handle_IRQ_event+0x58/0xd4
> [c00000000fffbef0] [c0000000000cef4c] .handle_fasteoi_irq+0x128/0x1c8
> [c00000000fffbf90] [c000000000029918] .call_handle_irq+0x1c/0x2c
> [c000000000a63a20] [c00000000000d9cc] .do_IRQ+0x138/0x248
> [c000000000a63ad0] [c000000000004ca8] hardware_interrupt_entry+0x28/0x2c
> --- Exception: 501 at .raw_local_irq_restore+0x8c/0xa4
> LR = .cpu_idle+0x140/0x210
> [c000000000a63e60] [c0000000005da07c] .rest_init+0x7c/0x98
> [c000000000a63ee0] [c000000000866f10] .start_kernel+0x488/0x4b0
> [c000000000a63f90] [c000000000008584] .start_here_common+0x4c/0xc8
> Instruction dump:
> e92d01b0 80090954 2f800000 41be002c 481e61fd 60000000 2fa30000 419e0080
> e93e80c0 80090000 2f800000 409e0070 <0fe00000> 48000068 7fa3eb78 38800001
> scsi0 : IBM 572C Storage Adapter
> scsi 0:3:0:0: Direct-Access IBM-ESXS ST973402SS B522 PQ: 0 ANSI: 5
^ permalink raw reply
* Re: Hard-coded virtual address used by dma_alloc_coherent
From: Scott Wood @ 2008-07-24 19:29 UTC (permalink / raw)
To: Remi Machet; +Cc: Linux PPC
In-Reply-To: <1216927153.19203.62.camel@pcds-ts102.slac.stanford.edu>
Remi Machet wrote:
> I have noticed that the DMA allocation for non-coherent PowerPC
> architecture is using a hard coded virtual memory address for its memory
> pool. This address is typically 0xFF100000 (set by
> CONFIG_CONSISTENT_START) and can conflict with early ioremap in systems
> that enable HIGHMEM.
>
> Is there any reason why we have to use an arbitrary virtual address ? If
> the virtual address must be known at compile time, can't we use fixmap ?
The hardcoded address predates when fixmap was added to powerpc. It
should be updated to use fixmap.
> I also can't figure out why we need to use a virtual address known at
> compilation time and cannot just allocate pages using get_free_pages and
> mark them as non cacheable and non swappable.
We probably don't need a compile-time address, though we can't just
change the page attributes in-place as the pages will often covered by
large TLB entries.
-Scott
^ permalink raw reply
* lockdep badness
From: Nathan Lynch @ 2008-07-24 19:23 UTC (permalink / raw)
To: linuxppc-dev
I'm seeing warnings from the lockdep code itself in recent kernels on
a Power6 blade (v2.6.26 and benh's -next branch).
Something to do with powerpc's "lazy" interrupt-disabling, perhaps?
A couple of stack traces below, the first is from benh's tree, the
second is from 2.6.26. The lockdep self-tests all pass at boot.
RTAS daemon started
RTAS: event: 295, Type: Dump Notification Event, Severity: 2
------------[ cut here ]------------
Badness at kernel/lockdep.c:2719
NIP: c0000000000b06dc LR: c0000000000b06c0 CTR: 0000000000000000
REGS: c0000000e787b9a0 TRAP: 0700 Not tainted (2.6.26)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 24000042 XER: 20000000
TASK = c0000000e91a6100[428] 'rtasd' THREAD: c0000000e7878000 CPU: 1
GPR00: 0000000000000000 c0000000e787bc20 c000000000a71270 0000000000000001
GPR04: 0000000000000001 c00000000004d648 0000040100000000 0000040100000000
GPR08: 0000000000000000 c000000000f1f858 0000000000000020 0000000000000001
GPR12: 0000000000010000 c000000000aac600 00000000002146f4 0000000000214744
GPR16: 4000000002040000 00000000029015b0 00000000002a3c00 c0000000008cc988
GPR20: 0000000002901598 0000000000000000 0000000000000124 0000000000000002
GPR24: 0000000000000001 0000000000000008 0000000000000001 c0000000009fdf00
GPR28: c00000000004d648 c000000000943e98 c0000000009d9b40 c0000000e787bc20
NIP [c0000000000b06dc] .check_flags+0x9c/0x174
LR [c0000000000b06c0] .check_flags+0x80/0x174
Call Trace:
[c0000000e787bc20] [c0000000e787bc70] 0xc0000000e787bc70 (unreliable)
[c0000000e787bca0] [c0000000000b5ac8] .lock_release+0x7c/0x208
[c0000000e787bd50] [c0000000005e12c0] ._spin_unlock_irqrestore+0x34/0x94
[c0000000e787bde0] [c00000000004d648] .pSeries_log_error+0x380/0x3f0
[c0000000e787bef0] [c00000000004d8e4] .rtasd+0x98/0x100
[c0000000e787bf90] [c000000000029d20] .kernel_thread+0x4c/0x68
Instruction dump:
e92d01b0 80090904 2f800000 40be002c 481ece4d 60000000 2fa30000 419e00c4
e93e80c0 80090000 2f800000 409e00b4 <0fe00000> 480000ac 78290464 80090014
possible reason: unannotated irqs-on.
irq event stamp: 20
hardirqs last enabled at (19): [<c0000000000b405c>] .trace_hardirqs_on+0x1c/0x3
0
hardirqs last disabled at (20): [<c0000000000b0d80>] .trace_hardirqs_off+0x1c/0x
30
softirqs last enabled at (0): [<c00000000008293c>] .copy_process+0x3c8/0x1040
softirqs last disabled at (0): [<0000000000000000>] 0x0
===============
ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
ipr 0000:00:01.0: Found IOA with IRQ: 289
ipr 0000:00:01.0: Starting IOA initialization sequence.
ipr 0000:00:01.0: Adapter firmware version: 02200023
ipr 0000:00:01.0: IOA initialized.
------------[ cut here ]------------
Badness at kernel/lockdep.c:2037
NIP: c0000000000b29fc LR: c0000000000b29e0 CTR: 0000000000000000
REGS: c00000000fffb890 TRAP: 0700 Not tainted (2.6.26)
MSR: 8000000000021032 <ME,IR,DR> CR: 28000022 XER: 00000004
TASK = c000000000996730[0] 'swapper' THREAD: c000000000a60000 CPU: 0
GPR00: 0000000000000000 c00000000fffbb10 c000000000a61ad8 0000000000000001
GPR04: 0000000000035112 c000000000426708 0000000000000000 0000000000000970
GPR08: 0000000000000000 c000000000ec6ad0 0000000000000001 0000000000000001
GPR12: 0000000000043bd8 c000000000a9d400 00000000002146f4 0000000000214744
GPR16: 4000000002040000 00000000028f37a8 00000000002a3c00 c0000000008b3790
GPR20: 00000000028f3790 0000000001a3f920 c0000000008b37a8 c0000000e6252000
GPR24: c0000000e6454a48 0000000000100100 0000000000200200 c0000000005d8824
GPR28: c000000000afba18 c000000000996730 c0000000009cb7f0 c00000000fffbb10
NIP [c0000000000b29fc] .trace_hardirqs_on+0x120/0x1b0
LR [c0000000000b29e0] .trace_hardirqs_on+0x104/0x1b0
Call Trace:
[c00000000fffbb10] [c00000000fffbbb0] 0xc00000000fffbbb0 (unreliable)
[c00000000fffbbb0] [c0000000005d8824] ._spin_unlock_irq+0x40/0x68
[c00000000fffbc40] [c000000000426708] .ipr_ioa_reset_done+0x218/0x2ac
[c00000000fffbd00] [c00000000041bdb8] .ipr_reset_ioa_job+0xc8/0xf4
[c00000000fffbd90] [c000000000424ffc] .ipr_isr+0x280/0x628
[c00000000fffbe50] [c0000000000ccc70] .handle_IRQ_event+0x58/0xd4
[c00000000fffbef0] [c0000000000cef4c] .handle_fasteoi_irq+0x128/0x1c8
[c00000000fffbf90] [c000000000029918] .call_handle_irq+0x1c/0x2c
[c000000000a63a20] [c00000000000d9cc] .do_IRQ+0x138/0x248
[c000000000a63ad0] [c000000000004ca8] hardware_interrupt_entry+0x28/0x2c
--- Exception: 501 at .raw_local_irq_restore+0x8c/0xa4
LR = .cpu_idle+0x140/0x210
[c000000000a63e60] [c0000000005da07c] .rest_init+0x7c/0x98
[c000000000a63ee0] [c000000000866f10] .start_kernel+0x488/0x4b0
[c000000000a63f90] [c000000000008584] .start_here_common+0x4c/0xc8
Instruction dump:
e92d01b0 80090954 2f800000 41be002c 481e61fd 60000000 2fa30000 419e0080
e93e80c0 80090000 2f800000 409e0070 <0fe00000> 48000068 7fa3eb78 38800001
scsi0 : IBM 572C Storage Adapter
scsi 0:3:0:0: Direct-Access IBM-ESXS ST973402SS B522 PQ: 0 ANSI: 5
^ permalink raw reply
* Hard-coded virtual address used by dma_alloc_coherent
From: Remi Machet @ 2008-07-24 19:19 UTC (permalink / raw)
To: Linux PPC
Hi,
I have noticed that the DMA allocation for non-coherent PowerPC
architecture is using a hard coded virtual memory address for its memory
pool. This address is typically 0xFF100000 (set by
CONFIG_CONSISTENT_START) and can conflict with early ioremap in systems
that enable HIGHMEM.
Is there any reason why we have to use an arbitrary virtual address ? If
the virtual address must be known at compile time, can't we use fixmap ?
I also can't figure out why we need to use a virtual address known at
compilation time and cannot just allocate pages using get_free_pages and
mark them as non cacheable and non swappable.
For those of you that want to check it out, the code is in
arch/powerpc/lib/dma-noncoherent.c
Thanks,
Remi
^ permalink raw reply
* Re: [ANN] Device Tree Mailing List
From: Grant Likely @ 2008-07-24 19:07 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, devicetree-discuss, parch
In-Reply-To: <20080724145706.138af140@lappy.seanm.ca>
On Thu, Jul 24, 2008 at 2:57 PM, Sean MacLennan <smaclennan@pikatech.com> wrote:
> On Thu, 24 Jul 2008 14:36:09 -0400
> "Hugh Blemings" <hugh@blemings.org> wrote:
>
>> Hiya,
>>
>> Grant Likely and Josh Boyer organised a Bird of Feather session on
>> Device Trees today at the Ottawa Linux Symposium, about a dozen folk
>> there all told.
>>
>> Was agreed that there was now enough non-PowerPC specific interest in
>> Device Trees to make a generic list a useful thing to have, so have
>> gone ahead and got one set up;
>>
>> https://ozlabs.org/mailman/listinfo/devicetree-discuss
>>
>> For folk I knew to be interested/involved in DT stuff you may have
>> already received an invitation to join, I trust this was in order.
>>
>> If you didn't, please don't feel left out, I just did a quick off the
>> top of my head search through the mailing list archive :)
>
> I assume that powerpc specific device tree questions/patches can still
> be posted here though?
If it is related to bindings (even powerpc-specific bindings) I think
it is better to discuss them on the new list. Doing so helps keep
usage conventions consistent across all architectures.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [ANN] Device Tree Mailing List
From: Sean MacLennan @ 2008-07-24 18:57 UTC (permalink / raw)
To: Hugh Blemings; +Cc: linuxppc-dev, parch
In-Reply-To: <20080724143609.60274eed.hugh@blemings.org>
On Thu, 24 Jul 2008 14:36:09 -0400
"Hugh Blemings" <hugh@blemings.org> wrote:
> Hiya,
>
> Grant Likely and Josh Boyer organised a Bird of Feather session on
> Device Trees today at the Ottawa Linux Symposium, about a dozen folk
> there all told.
>
> Was agreed that there was now enough non-PowerPC specific interest in
> Device Trees to make a generic list a useful thing to have, so have
> gone ahead and got one set up;
>
> https://ozlabs.org/mailman/listinfo/devicetree-discuss
>
> For folk I knew to be interested/involved in DT stuff you may have
> already received an invitation to join, I trust this was in order.
>
> If you didn't, please don't feel left out, I just did a quick off the
> top of my head search through the mailing list archive :)
I assume that powerpc specific device tree questions/patches can still
be posted here though?
Cheers,
Sean
^ permalink raw reply
* [ANN] Device Tree Mailing List
From: Hugh Blemings @ 2008-07-24 18:36 UTC (permalink / raw)
To: linuxppc-dev, parch
Hiya,
Grant Likely and Josh Boyer organised a Bird of Feather session on Device Trees today at the Ottawa Linux Symposium, about a dozen folk there all told.
Was agreed that there was now enough non-PowerPC specific interest in Device Trees to make a generic list a useful thing to have, so have gone ahead and got one set up;
https://ozlabs.org/mailman/listinfo/devicetree-discuss
For folk I knew to be interested/involved in DT stuff you may have already received an invitation to join, I trust this was in order.
If you didn't, please don't feel left out, I just did a quick off the top of my head search through the mailing list archive :)
Regards,
Hugh
^ permalink raw reply
* Re: [PATCH] watchdog: delete unused driver mpc8xx_wdt.c
From: Vitaly Bordug @ 2008-07-24 17:50 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev list, wim, Kernel, Linux
In-Reply-To: <488857CD.6080007@scram.de>
В Thu, 24 Jul 2008 12:22:05 +0200
Jochen Friedrich <jochen@scram.de> пишет:
> The watchdog driver mpc8xx_wdt.c was a device interface to
> arch/ppc/syslib/m8xx_wdt.c for MPC8xx hardware. Now that ARCH=ppc is
> gone, this driver is of no more use. For ARCH=powerpc, MPC8xx hardware
> is supported by mpc8xxx_wdt.c.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
-Vitaly
^ permalink raw reply
* [PATCHv2] cpm_uart: Modem control lines support
From: Laurent Pinchart @ 2008-07-24 16:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <2F3F000A-AC69-4C15-A535-F93B60BA191E@kernel.crashing.org>
This patch replaces the get_mctrl/set_mctrl stubs with modem control line
read/write access through the GPIO lib.
Available modem control lines are described in the device tree using GPIO
bindings. The driver expect a GPIO pin for each of the CTS, RTS, DCD, DSR,
DTR and RI signals. Unused control lines can be left out.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
Documentation/powerpc/booting-without-of.txt | 10 ++++++
drivers/serial/cpm_uart/cpm_uart.h | 10 ++++++
drivers/serial/cpm_uart/cpm_uart_core.c | 40 ++++++++++++++++++++++++--
3 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt
index 1d2a772..21a3484 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt
@@ -7,6 +7,15 @@
- fsl,cpm2-scc-uart
- fsl,qe-uart
+Modem control lines connected to GPIO controllers are listed in the gpios
+property as described in booting-without-of.txt, section IX.1 in the following
+order:
+
+CTS, RTS, DCD, DSR, DTR, and RI.
+
+The gpios property is optional and can be left out when control lines are
+not used.
+
Example:
serial@11a00 {
@@ -18,4 +27,6 @@
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
+ gpios = <&gpio_c 15 0
+ &gpio_d 29 0>;
};
diff --git a/drivers/serial/cpm_uart/cpm_uart.h b/drivers/serial/cpm_uart/cpm_uart.h
index 0cc39f8..d0c55e2 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -50,6 +50,15 @@
#define SCC_WAIT_CLOSING 100
+#define GPIO_CTS 0
+#define GPIO_RTS 1
+#define GPIO_DCD 2
+#define GPIO_DSR 3
+#define GPIO_DTR 4
+#define GPIO_RI 5
+
+#define NUM_GPIOS (GPIO_RI+1)
+
struct uart_cpm_port {
struct uart_port port;
u16 rx_nrfifos;
@@ -82,6 +91,7 @@ struct uart_cpm_port {
int wait_closing;
/* value to combine with opcode to form cpm command */
u32 command;
+ int gpios[NUM_GPIOS];
};
extern int cpm_uart_nr;
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index d10a16e..d3c19e5 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -43,6 +43,8 @@
#include <linux/dma-mapping.h>
#include <linux/fs_uart_pd.h>
#include <linux/of_platform.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -96,13 +98,41 @@ static unsigned int cpm_uart_tx_empty(struct uart_port *port)
static void cpm_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
- /* Whee. Do nothing. */
+ struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
+
+ if (pinfo->gpios[GPIO_RTS] >= 0)
+ gpio_set_value(pinfo->gpios[GPIO_RTS], !(mctrl & TIOCM_RTS));
+
+ if (pinfo->gpios[GPIO_DTR] >= 0)
+ gpio_set_value(pinfo->gpios[GPIO_DTR], !(mctrl & TIOCM_DTR));
}
static unsigned int cpm_uart_get_mctrl(struct uart_port *port)
{
- /* Whee. Do nothing. */
- return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+ struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
+ unsigned int mctrl = TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+
+ if (pinfo->gpios[GPIO_CTS] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_CTS]))
+ mctrl &= ~TIOCM_CTS;
+ }
+
+ if (pinfo->gpios[GPIO_DSR] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_DSR]))
+ mctrl &= ~TIOCM_DSR;
+ }
+
+ if (pinfo->gpios[GPIO_DCD] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_DCD]))
+ mctrl &= ~TIOCM_CAR;
+ }
+
+ if (pinfo->gpios[GPIO_RI] >= 0) {
+ if (!gpio_get_value(pinfo->gpios[GPIO_RI]))
+ mctrl |= TIOCM_RNG;
+ }
+
+ return mctrl;
}
/*
@@ -893,6 +923,7 @@ static int cpm_uart_init_port(struct device_node *np,
void __iomem *mem, *pram;
int len;
int ret;
+ int i;
data = of_get_property(np, "fsl,cpm-brg", &len);
if (!data || len != 4) {
@@ -952,6 +983,9 @@ static int cpm_uart_init_port(struct device_node *np,
goto out_pram;
}
+ for (i = 0; i < NUM_GPIOS; i++)
+ pinfo->gpios[i] = of_get_gpio(np, i);
+
return cpm_uart_request_port(&pinfo->port);
out_pram:
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* [PATCHv4] cpm2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Laurent Pinchart @ 2008-07-24 16:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <524AC131-C155-416F-A8D7-EF1C6FD9A35B@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 6038 bytes --]
This patch implement GPIO LIB support for the CPM2 GPIOs. The code can also be
used for CPM1 GPIO port E, as both cores are compatible at the register level.
Based on earlier work by Jochen Friedrich.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
Cc: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/platforms/Kconfig | 2 +
arch/powerpc/sysdev/cpm2.c | 11 ++++
arch/powerpc/sysdev/cpm_common.c | 123 ++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/cpm.h | 3 +
4 files changed, 139 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 87454c5..7e67e26 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -280,6 +280,8 @@ config CPM2
depends on MPC85xx || 8260
select CPM
select PPC_LIB_RHEAP
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
help
The CPM2 (Communications Processor Module) is a coprocessor on
embedded CPUs made by Freescale. Selecting this option means that
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 5a6c5df..9311778 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -377,3 +377,14 @@ void cpm2_set_pin(int port, int pin, int flags)
else
clrbits32(&iop[port].odr, pin);
}
+
+static int cpm_init_par_io(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,cpm2-pario-bank")
+ cpm2_gpiochip_add32(np);
+ return 0;
+}
+arch_initcall(cpm_init_par_io);
+
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index cb7df2d..b957a48 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -19,6 +19,8 @@
#include <linux/init.h>
#include <linux/of_device.h>
+#include <linux/spinlock.h>
+#include <linux/of.h>
#include <asm/udbg.h>
#include <asm/io.h>
@@ -28,6 +30,10 @@
#include <mm/mmu_decl.h>
+#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
+#include <linux/of_gpio.h>
+#endif
+
#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
static u32 __iomem *cpm_udbg_txdesc =
(u32 __iomem __force *)CONFIG_PPC_EARLY_DEBUG_CPM_ADDR;
@@ -198,3 +204,120 @@ dma_addr_t cpm_muram_dma(void __iomem *addr)
return muram_pbase + ((u8 __iomem *)addr - muram_vbase);
}
EXPORT_SYMBOL(cpm_muram_dma);
+
+#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
+
+struct cpm2_ioports {
+ u32 dir, par, sor, odr, dat;
+ u32 res[3];
+};
+
+struct cpm2_gpio32_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u32 cpdata;
+};
+
+static inline struct cpm2_gpio32_chip *
+to_cpm2_gpio32_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm2_gpio32_chip, mm_gc);
+}
+
+static void cpm2_gpio32_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+
+ cpm2_gc->cpdata = in_be32(&iop->dat);
+}
+
+static int cpm2_gpio32_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ return !!(in_be32(&iop->dat) & pin_mask);
+}
+
+static void cpm2_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
+
+ spin_lock_irqsave(&cpm2_gc->lock, flags);
+
+ if (value)
+ cpm2_gc->cpdata |= pin_mask;
+ else
+ cpm2_gc->cpdata &= ~pin_mask;
+
+ out_be32(&iop->dat, cpm2_gc->cpdata);
+
+ spin_unlock_irqrestore(&cpm2_gc->lock, flags);
+}
+
+static int cpm2_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ setbits32(&iop->dir, pin_mask);
+
+ cpm2_gpio32_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm2_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ clrbits32(&iop->dir, pin_mask);
+
+ return 0;
+}
+
+int cpm2_gpiochip_add32(struct device_node *np)
+{
+ struct cpm2_gpio32_chip *cpm2_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ cpm2_gc = kzalloc(sizeof(*cpm2_gc), GFP_KERNEL);
+ if (!cpm2_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&cpm2_gc->lock);
+
+ mm_gc = &cpm2_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ mm_gc->save_regs = cpm2_gpio32_save_regs;
+ of_gc->gpio_cells = 2;
+ gc->ngpio = 32;
+ gc->direction_input = cpm2_gpio32_dir_in;
+ gc->direction_output = cpm2_gpio32_dir_out;
+ gc->get = cpm2_gpio32_get;
+ gc->set = cpm2_gpio32_set;
+
+ return of_mm_gpiochip_add(np, mm_gc);
+}
+#endif /* CONFIG_CPM2 || CONFIG_8xx_GPIO */
diff --git a/include/asm-powerpc/cpm.h b/include/asm-powerpc/cpm.h
index ede38ff..23b72ee 100644
--- a/include/asm-powerpc/cpm.h
+++ b/include/asm-powerpc/cpm.h
@@ -3,6 +3,7 @@
#include <linux/compiler.h>
#include <linux/types.h>
+#include <linux/of.h>
/* Opcodes common to CPM1 and CPM2
*/
@@ -99,4 +100,6 @@ void __iomem *cpm_muram_addr(unsigned long offset);
dma_addr_t cpm_muram_dma(void __iomem *addr);
int cpm_command(u32 command, u8 opcode);
+int cpm2_gpiochip_add32(struct device_node *np);
+
#endif
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* [PATCH] c2k: fix list of enabled address space
From: Remi Machet @ 2008-07-24 15:53 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linux PPC, Welch, Martyn (GE EntSol, Intelligent Platforms)
The Marvell chip SRAM was disabled and some reserved bit set by mistake.
This bug was found thanks to Martyn Welch.
Signed-off-by: Remi Machet <rmachet@slac.stanford.edu>
---
arch/powerpc/boot/cuboot-c2k.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/cuboot-c2k.c b/arch/powerpc/boot/cuboot-c2k.c
index e435949..cf993ea 100644
--- a/arch/powerpc/boot/cuboot-c2k.c
+++ b/arch/powerpc/boot/cuboot-c2k.c
@@ -56,7 +56,7 @@ static void c2k_bridge_setup(u32 mem_size)
fatal("Error: Missing marvell,mv64360 device tree node\n\r");
enables = in_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE));
- enables |= 0x007ffe00; /* Disable all cpu->pci windows */
+ enables |= 0x0007fe00; /* Disable all cpu->pci windows */
out_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE), enables);
/* Get the cpu -> pci i/o & mem mappings from the device tree */
^ permalink raw reply related
* Re: [PATCHv2] cpm_uart: Fix break generation
From: Laurent Pinchart @ 2008-07-24 15:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: scottwood, linuxppc-dev, linux-serial
In-Reply-To: <EFAF51F5-D2A4-4A8F-AB94-0A746B67E190@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
On Thursday 24 July 2008, Kumar Gala wrote:
>
> On Jul 24, 2008, at 9:21 AM, Laurent Pinchart wrote:
>
> > When generating a break condition on a serial port, the CPM must be
> > told beforehand how long the break should be. Unfortunately, this
> > information is not available through the current serial break handling
> > API. This patch works around the problem by requesting a 32767 characters
> > break followed by a 0 characters break after the requested duration. The
> > CPM will stop the first break when the second one is requested. This might
> > not work with future CPM revisions.
>
> What do you mean by future CPM revision? Do you mean QE?
I was thinking about minor revisions of the CPM2 silicon as described in http://www.freescale.com/files/32bit/doc/app_note/AN2291.pdf
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCHv2] cpm_uart: Fix break generation
From: Kumar Gala @ 2008-07-24 15:14 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: scottwood, linuxppc-dev, linux-serial
In-Reply-To: <200807241621.58719.laurentp@cse-semaphore.com>
On Jul 24, 2008, at 9:21 AM, Laurent Pinchart wrote:
> When generating a break condition on a serial port, the CPM must be
> told
> beforehand how long the break should be. Unfortunately, this
> information is
> not available through the current serial break handling API. This
> patch works
> around the problem by requesting a 32767 characters break followed
> by a 0
> characters break after the requested duration. The CPM will stop the
> first
> break when the second one is requested. This might not work with
> future CPM
> revisions.
What do you mean by future CPM revision? Do you mean QE?
- k
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Kumar Gala @ 2008-07-24 15:12 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <200807241647.00564.laurentp@cse-semaphore.com>
On Jul 24, 2008, at 9:46 AM, Laurent Pinchart wrote:
> Hi Kumar,
>
> On Friday 18 July 2008, Kumar Gala wrote:
>> On Jul 18, 2008, at 10:30 AM, Jochen Friedrich wrote:
>>>> On Jun 18, 2008, at 12:08 PM, Laurent Pinchart wrote:
>>>>
>>>>> +#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
>>>>> +
>>>>> +struct cpm2_ioports {
>>>>> + u32 dir, par, sor, odr, dat;
>>>>> + u32 res[3];
>>>>> +};
>>>>> +
>>>>
>>>> is this really common for both CPM2 and 8xx? if so why the name?
>>>
>>> It is common to CPM2 and Port E of CPM1.
>>
>> but ports a-d are different on cpm1? I guess I'd like to see both
>> patches to understand the commonality and differences.
>
> As Jorgen mentionned, both patches are still in patchwork:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=19045
> http://patchwork.ozlabs.org/linuxppc/patch?id=19386
>
> Would it be possible for you to review them in time for 2.6.27 ?
Yes. Can you resend the first patch and add some details in the
commit message about the fact we can also use this code for 8xx/CPM1
port E.
- k
^ permalink raw reply
* Re: DTS configuration of external interrupts on 8347
From: Richard Whitlock @ 2008-07-24 15:06 UTC (permalink / raw)
To: Sean MacLennan; +Cc: richw, linuxppc-dev
In-Reply-To: <20080723131335.00eadc6a@lappy.seanm.ca>
Sean MacLennan wrote:
> On Wed, 23 Jul 2008 15:58:38 +0100
> "Richard Whitlock" <richard.whitlo@btconnect.com> wrote:
>
>
>> I have a small problem with a port of linux 2.6.26 to a custom board.
>> Our board is almost identical to the Analogue & Micro asp 8347 board,
>> so I'm using Kumar Gala's excellent fsl tree (thank you Kumar) as it
>> already has a defconfig for the asp.
>> Thanks also to Bryan O'Donoghue for pointing us in the direction of
>> the asp port in the first place.
>>
>> The problem we have is I am unable to request an external interrupt.
>> We have an FPGA which has an interrupt line - HW IRQ_0, so thats
>> linux IRQ 48. I have added the following to the dts file:
>>
>> fpgaKFAF@0xF8000000 {
>> interrupts = <48 8>;
>> interrupt-parent = <&ipic>;
>> }
>>
>> but whenever I call request_irq() it returns -ENOSYS.
>>
>> The driver loads fine, and the open function does very little - a
>> call to ioremap() - which works, and a call to request_irq() which
>> does not. Is there anything else I have to do to configure this
>> interrupt?
>>
>
> I don't think you have enough information in the dts. We do the same
> thing on the warp (you can look at the warp.dts):
>
> fpga@2,0 {
> compatible = "pika,fpga";
> reg = <0x00000002 0x00000000 0x00001000>;
> interrupts = <0x18 0x8>;
> interrupt-parent = <&UIC0>;
> };
>
> You need the compatible, maybe "kfaf,fpga", and I believe the reg entry
> although you could try without it.
>
> You then can use:
>
> of_find_compatible_node
> irq_of_parse_and_map
> request_irq
>
> platforms/44x/warp.c shows an example using the ad7414. Just change the
> ad7414 string to your compatible string.
>
> Cheers,
> Sean
>
>
>
>
Sean,
Thanks for that - our original code had no call to irq_of_parse_and_map().
We've put that in, as well as a call to of_find_compatible_node(), and
now everything works fine. We have also modified our dts file along the
lines you suggested.
Cheers,
Richard.
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Laurent Pinchart @ 2008-07-24 14:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <C98DF5D7-0E3D-4FDA-A831-55CFD5F4590C@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
Hi Kumar,
On Friday 18 July 2008, Kumar Gala wrote:
> On Jul 18, 2008, at 10:30 AM, Jochen Friedrich wrote:
> >> On Jun 18, 2008, at 12:08 PM, Laurent Pinchart wrote:
> >>
> >>> +#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
> >>> +
> >>> +struct cpm2_ioports {
> >>> + u32 dir, par, sor, odr, dat;
> >>> + u32 res[3];
> >>> +};
> >>> +
> >>
> >> is this really common for both CPM2 and 8xx? if so why the name?
> >
> > It is common to CPM2 and Port E of CPM1.
>
> but ports a-d are different on cpm1? I guess I'd like to see both
> patches to understand the commonality and differences.
As Jorgen mentionned, both patches are still in patchwork:
http://patchwork.ozlabs.org/linuxppc/patch?id=19045
http://patchwork.ozlabs.org/linuxppc/patch?id=19386
Would it be possible for you to review them in time for 2.6.27 ?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCHv2] cpm_uart: Fix break generation
From: Laurent Pinchart @ 2008-07-24 14:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, linux-serial
In-Reply-To: <200806261338.19358.laurentp@cse-semaphore.com>
When generating a break condition on a serial port, the CPM must be told
beforehand how long the break should be. Unfortunately, this information is
not available through the current serial break handling API. This patch works
around the problem by requesting a 32767 characters break followed by a 0
characters break after the requested duration. The CPM will stop the first
break when the second one is requested. This might not work with future CPM
revisions.
---
drivers/serial/cpm_uart/cpm_uart_core.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index c29d87d..aa0a284 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -269,13 +269,19 @@ static void cpm_uart_break_ctl(struct uart_port *port, int break_state)
{
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
+ u16 __iomem *brkcr = IS_SMC(pinfo) ? &pinfo->smcup->smc_brkcr
+ : &pinfo->sccup->scc_brkcr;
pr_debug("CPM uart[%d]:break ctrl, break_state: %d\n", port->line,
break_state);
- if (break_state)
+ if (break_state) {
+ out_be16(brkcr, 32767);
cpm_line_cr_cmd(pinfo, CPM_CR_STOP_TX);
- else
+ } else {
+ out_be16(brkcr, 0);
+ cpm_line_cr_cmd(pinfo, CPM_CR_STOP_TX);
cpm_line_cr_cmd(pinfo, CPM_CR_RESTART_TX);
+ }
}
/*
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* RE: Xilinx Linux 2.6 for XPS LL_TEMAC and LL_FIFO problem
From: John Linn @ 2008-07-24 13:24 UTC (permalink / raw)
To: Koss, Mike (Mission Systems), Mirek23, linuxppc-embedded
In-Reply-To: <EDAE140DF1B2FC42B5867C22CA0B333FFA5D56@XMBIL132.northgrum.com>
Hi Mirek,
We are not currently testing the LL TEMAC driver with the LL FIFO. We
only test with the DMA configuration. I also realize this may not be
documented that well and we may need to work on that.
Our reasoning is that in the Virtex5 FXT devices the DMA is hard so that
it does not cost any more LUTs to use the DMA and most people want the
performance. =
Is there a specific reason you're wanting to use the LL FIFO rather than
DMA as this information might help us in the future?
We would welcome any patches to the driver if LL FIFO is a needed
feature. Patches can be sent to git@xilinx.com.
Thanks,
John
> -----Original Message-----
> From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Koss, Mike
(Mission Systems)
> Sent: Thursday, July 24, 2008 6:56 AM
> To: Mirek23; linuxppc-embedded@ozlabs.org
> Subject: RE: Xilinx Linux 2.6 for XPS LL_TEMAC and LL_FIFO problem
> =
> Mirek,
> =
> I'm currently using the driver (CONFIG_XILINX_LLTEMAC) with the DMA
> portion with no problem, which is what you kind of eluded to. From
what
> I've seen, the drver source does support the FIFO portion. It just
> relies on having the proper definition for the TEMAC in either the DTS
> or the xparameters.
> =
> I'm currently using the 2.6.26-rc8 kernel (HEAD?) from git.xilinx.com
as
> well, and mine builds with no problem for arch/ppc. Yes, I still have
> not moved to arch/powerpc. I will be moving to the new arch in the
very
> near future. (My current test system is actually a mish-mash of 2.6.22
> w/ the driver from xilinx-2.6.26 tree).
> =
> Are you using arch/powerpc or arch/ppc? Are you generating your DTS
from
> your MHS file using the bsp generator for EDK on git.xilinx.com? Is
this
> for one of the reference boards (ML403, ML405, etc)? What is the
problem
> that you're having with the build of the kernel?
> =
> -- Mike
> =
> -----Original Message-----
> From: Mirek23 [mailto:miroslaw.dach@psi.ch]
> Sent: Thursday, July 24, 2008 5:20 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Xilinx Linux 2.6 for XPS LL_TEMAC and LL_FIFO problem
> =
> =
> Dear All,
> =
> I have done a design using EDK 8.2 using Hard_Temac IP component. In
the
> EDK
> 9.2 there is a new idea to use ll_temac in conjunction with ll_fifo or
> ll_dma. So far I was using happily the linux kernel by Grant Likey.
> Unfortunately it does not deal with ll_temac. I have download the
kernel
> from git.xilinx.com.
> =
> I have tried to build the kernel 2.6.26 (by xilinx) but it seems to
be
> that it is not well prepared for ll_fifo.
> I have noticed that in drivers/xilinx_common there are files related
to
> ll_fifo but in the drivers/Makefile there is no rule to build ll_fifo.
> The same refers to the file arch/ppc/syslib/virtex_devices.c -> there
> are no entries for LL_FIFO. I have the impression that one can use
only
> LL_DMA but not LL_FIFO.
> =
> Does anybody has modified the kernel to deal with LL_TEMAC together
with
> LL_FIFO?
> I will be grateful for any hint.
> =
> Best Regards
> =
> Mirek
> --
> View this message in context:
>
http://www.nabble.com/Compile-time-error%2C-compiling-Xilinx-Linux-2.6-f
> or-XPS-LLTEMAC-tp16065692p18628194.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> =
> =
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* RE: Xilinx Linux 2.6 for XPS LL_TEMAC and LL_FIFO problem
From: Koss, Mike (Mission Systems) @ 2008-07-24 12:55 UTC (permalink / raw)
To: Mirek23, linuxppc-embedded
In-Reply-To: <18628194.post@talk.nabble.com>
Mirek,
I'm currently using the driver (CONFIG_XILINX_LLTEMAC) with the DMA
portion with no problem, which is what you kind of eluded to. From what
I've seen, the drver source does support the FIFO portion. It just
relies on having the proper definition for the TEMAC in either the DTS
or the xparameters.
I'm currently using the 2.6.26-rc8 kernel (HEAD?) from git.xilinx.com as
well, and mine builds with no problem for arch/ppc. Yes, I still have
not moved to arch/powerpc. I will be moving to the new arch in the very
near future. (My current test system is actually a mish-mash of 2.6.22
w/ the driver from xilinx-2.6.26 tree).=20
Are you using arch/powerpc or arch/ppc? Are you generating your DTS from
your MHS file using the bsp generator for EDK on git.xilinx.com? Is this
for one of the reference boards (ML403, ML405, etc)? What is the problem
that you're having with the build of the kernel?
-- Mike
-----Original Message-----
From: Mirek23 [mailto:miroslaw.dach@psi.ch]=20
Sent: Thursday, July 24, 2008 5:20 AM
To: linuxppc-embedded@ozlabs.org
Subject: Xilinx Linux 2.6 for XPS LL_TEMAC and LL_FIFO problem
Dear All,
I have done a design using EDK 8.2 using Hard_Temac IP component. In the
EDK
9.2 there is a new idea to use ll_temac in conjunction with ll_fifo or
ll_dma. So far I was using happily the linux kernel by Grant Likey.
Unfortunately it does not deal with ll_temac. I have download the kernel
from git.xilinx.com.
I have tried to build the kernel 2.6.26 (by xilinx) but it seems to be
that it is not well prepared for ll_fifo.
I have noticed that in drivers/xilinx_common there are files related to
ll_fifo but in the drivers/Makefile there is no rule to build ll_fifo.
The same refers to the file arch/ppc/syslib/virtex_devices.c -> there
are no entries for LL_FIFO. I have the impression that one can use only
LL_DMA but not LL_FIFO.
Does anybody has modified the kernel to deal with LL_TEMAC together with
LL_FIFO?
I will be grateful for any hint.
Best Regards
Mirek
--
View this message in context:
http://www.nabble.com/Compile-time-error%2C-compiling-Xilinx-Linux-2.6-f
or-XPS-LLTEMAC-tp16065692p18628194.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Getting GPIO to build again
From: Jochen Friedrich @ 2008-07-24 12:24 UTC (permalink / raw)
To: avorontsov; +Cc: ppc-dev
In-Reply-To: <20080724120839.GA24673@polina.dev.rtsoft.ru>
Hi Anton,
> Though, with this patch:
> http://lkml.org/lkml/2008/7/10/269
>
> We'll only have to select ARCH_WANT_OPTIONAL_GPIOLIB. Maybe for whole
> powerpc.
That would simplify the GPIO support patches for CPM1/2, as well.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH 2/2][RT] powerpc - Make the irq reverse mapping radix tree lockless
From: Sebastien Dugue @ 2008-07-24 12:18 UTC (permalink / raw)
To: Nick Piggin
Cc: Tim Chavez, Linux-rt, linux-kernel, Jean Pierre Dion, linux-ppc,
Paul Mackerras, Gilles Carry
In-Reply-To: <200807242111.35338.nickpiggin@yahoo.com.au>
On Thu, 24 Jul 2008 21:11:34 +1000 Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> On Thursday 24 July 2008 20:50, Sebastien Dugue wrote:
> > From: Sebastien Dugue <sebastien.dugue@bull.net>
> > Date: Tue, 22 Jul 2008 11:56:41 +0200
> > Subject: [PATCH][RT] powerpc - Make the irq reverse mapping radix tree
> > lockless
> >
> > The radix tree used by interrupt controllers for their irq reverse
> > mapping (currently only the XICS found on pSeries) have a complex locking
> > scheme dating back to before the advent of the concurrent radix tree on
> > preempt-rt.
> >
> > Take advantage of this and of the fact that the items of the tree are
> > pointers to a static array (irq_map) elements which can never go under us
> > to simplify the locking.
> >
> > Concurrency between readers and writers are handled by the intrinsic
> > properties of the concurrent radix tree. Concurrency between the tree
> > initialization which is done asynchronously with readers and writers access
> > is handled via an atomic variable (revmap_trees_allocated) set when the
> > tree has been initialized and checked before any reader or writer access
> > just like we used to check for tree.gfp_mask != 0 before.
>
> Hmm, RCU radix tree is in mainline too for quite a while. I thought
> Ben had already converted this code over ages ago...
Mainline does not have the concurrent radix tree which this patch
is based on, but maybe it's overkill and the RCU radix tree is enough.
Not sure, will have to think about it a bit more.
>
> Nothing against the -rt patch, but mainline should probably be updated
> to use RCU as well?
>
If rcu radix tree is enough, then definitely yes.
Sebastien.
^ permalink raw reply
* Re: Getting GPIO to build again
From: Anton Vorontsov @ 2008-07-24 12:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: ppc-dev
In-Reply-To: <9e4733910807232034x3af76073x979ef608ddfbebfb@mail.gmail.com>
On Wed, Jul 23, 2008 at 11:34:28PM -0400, Jon Smirl wrote:
> This lets me build again, no clue if it is the correct fix.
No, I don't think that this is correct. OF_GPIO isn't GENERIC_GPIO
provider. GPIO controllers should select GENERIC_GPIO instead.
Though, with this patch:
http://lkml.org/lkml/2008/7/10/269
We'll only have to select ARCH_WANT_OPTIONAL_GPIOLIB. Maybe for whole
powerpc.
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 3a7a11a..e14dbe3 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -3,6 +3,7 @@ config OF_DEVICE
> depends on OF && (SPARC || PPC_OF)
>
> config OF_GPIO
> + select GENERIC_GPIO
> def_bool y
> depends on OF && PPC_OF && HAVE_GPIO_LIB
> help
>
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [RFC] cpm_uart: Add generic clock API support to set baudrates
From: Laurent Pinchart @ 2008-07-24 12:05 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]
This patch introduces baudrate setting support via the generic clock API.
When present the optional device tree clock property is used instead of
fsl-cpm-brg. Platforms can then define complex clock schemes, to output
the serial clock on an external pin for instance.
This is required to support RS485 ports on a platform I'm working on (TBox
CPU32 - see http://www.cse-semaphore.com/products/t-box/t-box-ms.php).
---
drivers/serial/cpm_uart/cpm_uart.h | 1 +
drivers/serial/cpm_uart/cpm_uart_core.c | 26 +++++++++++++++++++-------
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart.h b/drivers/serial/cpm_uart/cpm_uart.h
index d0c55e2..2e64c03 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -77,6 +77,7 @@ struct uart_cpm_port {
unsigned char *rx_buf;
u32 flags;
void (*set_lineif)(struct uart_cpm_port *);
+ struct clk *clk;
u8 brg;
uint dp_addr;
void *mem_addr;
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index d3c19e5..438e460 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -44,6 +44,7 @@
#include <linux/fs_uart_pd.h>
#include <linux/gpio.h>
#include <linux/of_gpio.h>
+#include <linux/clk.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -641,7 +642,10 @@ static void cpm_uart_set_termios(struct uart_port *port,
out_be16(&sccp->scc_psmr, (sbits << 12) | scval);
}
- cpm_set_brg(pinfo->brg - 1, baud);
+ if (pinfo->clk)
+ clk_set_rate(pinfo->clk, baud);
+ else
+ cpm_set_brg(pinfo->brg - 1, baud);
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -991,13 +995,21 @@ static int cpm_uart_init_port(struct device_node *np,
int ret;
int i;
- data = of_get_property(np, "fsl,cpm-brg", &len);
- if (!data || len != 4) {
- printk(KERN_ERR "CPM UART %s has no/invalid "
- "fsl,cpm-brg property.\n", np->name);
- return -EINVAL;
+ data = of_get_property(np, "clock", NULL);
+ if (data) {
+ struct clk *clk = clk_get(NULL, (const char*)data);
+ if (!IS_ERR(clk))
+ pinfo->clk = clk;
+ }
+ if (!pinfo->clk) {
+ data = of_get_property(np, "fsl,cpm-brg", &len);
+ if (!data || len != 4) {
+ printk(KERN_ERR "CPM UART %s has no/invalid "
+ "fsl,cpm-brg property.\n", np->name);
+ return -EINVAL;
+ }
+ pinfo->brg = *data;
}
- pinfo->brg = *data;
data = of_get_property(np, "fsl,cpm-command", &len);
if (!data || len != 4) {
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2][RT] powerpc - Make the irq reverse mapping radix tree lockless
From: Nick Piggin @ 2008-07-24 11:11 UTC (permalink / raw)
To: Sebastien Dugue
Cc: Tim Chavez, Linux-rt, linux-kernel, Jean Pierre Dion, linux-ppc,
Paul Mackerras, Gilles Carry
In-Reply-To: <20080724125044.53b604cb@bull.net>
On Thursday 24 July 2008 20:50, Sebastien Dugue wrote:
> From: Sebastien Dugue <sebastien.dugue@bull.net>
> Date: Tue, 22 Jul 2008 11:56:41 +0200
> Subject: [PATCH][RT] powerpc - Make the irq reverse mapping radix tree
> lockless
>
> The radix tree used by interrupt controllers for their irq reverse
> mapping (currently only the XICS found on pSeries) have a complex locking
> scheme dating back to before the advent of the concurrent radix tree on
> preempt-rt.
>
> Take advantage of this and of the fact that the items of the tree are
> pointers to a static array (irq_map) elements which can never go under us
> to simplify the locking.
>
> Concurrency between readers and writers are handled by the intrinsic
> properties of the concurrent radix tree. Concurrency between the tree
> initialization which is done asynchronously with readers and writers access
> is handled via an atomic variable (revmap_trees_allocated) set when the
> tree has been initialized and checked before any reader or writer access
> just like we used to check for tree.gfp_mask != 0 before.
Hmm, RCU radix tree is in mainline too for quite a while. I thought
Ben had already converted this code over ages ago...
Nothing against the -rt patch, but mainline should probably be updated
to use RCU as well?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox